Explaining Nethermind logs
A quick start example for Görli Testnet Nethermind synchronization
After the node starts, you will see some initial info about the node and then the sync will start. Görli fast sync uses a
fast blockssync mode initially. The
fast blockssync picks some known
pivot blockfrom the past and downloads
receiptsdownwards all the way to
genesis block. All blocks from 0 to the
pivot blockare showed as
Old Headersin the
fast blocks synclogs. The console display shows the number growing from 0 to pivot, but this is just to make the display more user-friendly.
You will see some information about the sync progress, like below:
- 1.Shows the number of already downloaded
receiptsunder the name
Downloadedout of all to be downloaded in the fast blocks stage.
- 2.Shows the current queue of already downloaded
receiptswaiting for being saved to the database.
- 3.Shows the current download speed (blocks per second - bps).
- 4.Shows the average download speed (blocks per second - bps).
Fast blocks sync logs
When the fast blocks stage finishes, there will be some period of downloading blocks between the
latest blockswhich will have some additional info:
- 1.Shows the last entry from the fast blocks stage.
- 2.Shows the mode transition moment.
- 3.Displays the speed (in blocks per second) of all
receiptsat the same time.
- 4.Additional info will appear every 30000 blocks with information about the Görli epoch being stored.
Görli fast sync logs
fast syncpart finished, the node will transition to the
state sync stagewhen the
state trieis being downloaded. Much information is displayed about the progress, as this process may take a long time on mainnet (a few hours).
- 1.Total elapsed time in
state syncis displayed.
- 2.The total percentage of downloaded DB size is displayed (on mainnet the sync finishes around 34GB in March 2020, on Görli around 800MB).
branchesstands for the percentage of downloaded branches.
- 4.Download speed in kilobytes per second is displayed.
accountsstands for the number of accounts data downloaded already.
nodesstands for the number of
Patricia trie nodesdownloaded by the sync process.
diagnosticshows the time spent in the DB write / read access. The higher the value, the worse. It may get much worse if you restart the node during the sync process, as we need to recreate some caches then by reading data from the DB.
Görli state sync logs
When the state sync is nearing completion, you may see a series of
branch syncinformation reloading many times from 0% to nearly 100%. This is the node trying to retrieve the few remaining state nodes and progressing with the head block rapidly:
Görli branch sync logs
At some point, the entire state is downloaded and the node enters the
full syncmode and will allow you to issue CLI / Web3 queries and send / receive transactions🥳
rootis saved at the moment when the entire
Patricia trieis downloaded.
- 2.We also clearly state that the node transitions to the
- 3.When you see the block being processed, then you are in the
full syncand the newly arrived block is being calculated.
- 4.Every two minutes you will see a summary of connected peers with their client version, IP address, highest synced block, and data download speeds.
Görli full sync logs
Also, every now and then, a peer report will appear like below:
- 1.First bracket is for Allocated contexts. It has possible values of
Sfor Snap, and
- 2.Second bracket is for Sleeping contexts. It has possible values of
Sfor Snap, and
- 3.Third bracket contains Peer Info.
- 4.Fourth bracket is for Speeds as Follows:
- Headers Transfer
- Bodies Transfer
- Receipts Transfer
- Node Data Transfer
- Snap Ranges Transfer
- 5.Fifth bracket is for Client Info like Client Name, Client Version, Operating System and Language Version.