0a3bc102eb
* Update sync scheduler pool mode why: The pool mode allows to loop over active peers one after another. This is ideal for soft re-starting peers. As this is a two tier experience (start/stop, setup/release) the loop must be run twice. This is controlled by a more rigid re-definition of how to use the `poolMode` flag. * Mitigate RLP serialiser deficiency why: Currently, serialising the `BlockBody` in not conevrtible and need to be checked in the `eth` module. Currently a local fix for the wire protocol applies. Unit tests will stay (after this local solution will have been removed.) * Code cosmetics and massage details: Main part is `types.toStr()` as a unified function for logging block numbers. * Allow to use a logical genesis replacement (start of history) why: Snap sync will set up an arbitrary pivot at a block number different from zero. In fact, the higher the block number the better. details: A non-genesis start of history will currently only affect the score values which were derived from the difficulty. * Provide function to store the snap pivot block header in chain db why: Together with the start of history facility, this allows to proceed with full syncing once snap has finished. details: Snap db storage was switched from a sub-tables to the flat chain db. * Provide database completeness and sanity checker details: For debugging on smaller databases, only * Implement snap -> full sync switch |
||
|---|---|---|
| .. | ||
| ticker.nim | ||
| worker.nim | ||
| worker_desc.nim | ||