mirror of
https://github.com/status-im/nimbus-eth1.git
synced 2025-01-30 22:16:25 +00:00
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
Snap sync test & debugging scenario
===================================
Start snap/1 server
-------------------
# Enter nimbus directory for snap/1 protocol server.
cd server
# Tell nimbus to stop full sync after 2 mio blocks.
echo 2000000 > full-limit.txt
# Tell nimbus to use this predefined key ID
echo 123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0 > full-id.key
./build/nimbus \
--tcp-port:30319 --nat=None --sync-mode=full \
--protocols=snap --discovery=none \
--net-key=./full-id.key \
--sync-ctrl-file=./full-limit.txt \
--log-level:TRACE
# Wait for several hours until enough blocks have been downloaded so that
# snap sync data are available. The full 2 mio blocks are available if the
# log ticker shows something like
#
# INF 2023-03-17 [..] Sync statistics (suspended) topics="full-tick" [..] persistent=#2000080 [..]
#
# where the persistent=#2000080 field might vary
Start snap/1 client
-------------------
# Note: When the snap/1 server has enough blocks, the client can be started.
# Enter nimbus directory for snap/1 protocol server
cd client
# Tell nimbus to use this pivot block number. This number must be smaller
# than the 2000000 written into the file full-limit.txt above.
echo 600000 > snap/snap-update.txt.
# Tell nimbus to use this hard coded peer enode.
echo enode://192d7e7a302bd4ff27f48d7852621e0d3cb863a6dd67dd44e0314a25a3aa866837f0d2460b4444dc66e7b7a2cd56a2de1c31b2a2ba4e23549bf3ba3b0c4f2eb5@127.0.0.1:30319 > snap/full-servers.txt
./build/nimbus \
--tcp-port:30102 --nat=None --sync-mode=snap \
--protocols=none --discovery=none \
--static-peers-file=./full-servers.txt \
--sync-ctrl-file=./snap-update.txt \
--log-level:TRACE
Modifications while the programs are syncing
--------------------------------------------
# Increasing the number in the files full/full-limit.txt or
# snap/snap-update.txt will be recognised while running. Decreasing
# or removing will be ignored.