This document is a quick cheat sheet of most common geth and parity configurations explained — usually, everything you need to know running an Ethereum node.
Light nodes
Light clients only store the header chain and request everything else on-demand from the network. They can verify the validity of the data against the state roots in the block headers.
❯ geth --syncmode light
Synchronizes block headers for a light client with the Ethereum network using the Light Ethereum Subprotocol (LES) starting at a trusted checkpoint inserted by the developers:
INFO [01-05|22:42:27.103] Added trusted checkpoint chain=mainnet block=6848511 hash=5e9f76…d9d6ac
WARN [01-05|22:42:27.123] Light client mode is an experimental feature
INFO [01-05|22:43:13.912] Block synchronisation started
INFO [01-05|22:43:40.953] Updated latest header based on CHT number=6848511 hash=5e9f76…d9d6ac age=4w9h38m
INFO [01-05|22:44:01.569] Imported new block headers count=192 elapsed=2.386s number=6848703 hash=2e78ec…851f48 age=4w8h54m
INFO [01-05|22:44:08.962] Imported new block headers count=192 elapsed=341.059ms number=6848895 hash=4b8c89…d6b233 age=4w8h5m
INFO [01-05|22:44:12.912] Imported new block headers count=192 elapsed=392.806ms number=6849087 hash=1b80b2…8515b4 age=4w7h15m
INFO [01-05|22:44:42.234] Imported new block headers count=192 elapsed=379.507ms number=6849279 hash=ef9c20…605416 age=4w6h29m
Note, how it inserts the trusted checkpoint and imports remaining headers afterward.
❯ parity --light
Synchronizes block headers for a light client with the Ethereum network using the Parity Light Protocol (PIP) starting at a trusted checkpoint inserted by the developers:
2019-01-05 22:46:08 Running in experimental Light Client mode.
2019-01-05 22:46:08 Inserting hardcoded block #6692865 in chain
2019-01-05 22:46:08 Debug API is not available in light client mode.
2019-01-05 22:46:23 Syncing #6692865 0xa988…8132 0.0 hdr/s 0+ 0 Qed 2/50 peers 664 bytes cache 0 bytes queue RPC: 0 conn, 0 req/s, 0 µs
2019-01-05 22:47:59 Syncing #6693604 0x10bc…90fd 147.8 hdr/s 535+ 0 Qed 4/50 peers 480 KiB cache 404 KiB queue RPC: 0 conn, 0 req/s, 0 µs
2019-01-05 22:48:09 Syncing #6698114 0x1b74…9c97 451.0 hdr/s 122+ 0 Qed 3/50 peers 3 MiB cache 95 KiB queue RPC: 0 conn, 0 req/s, 0 µs
Note, how it inserts a hardcoded block and synchronizes remaining headers subsequently.
❯ parity --light --no-hardcoded-sync
Synchronizes block headers for a light client with the Ethereum network using the Parity Light Protocol (PIP) starting at genesis:
2019-01-05 22:48:17 Running in experimental Light Client mode.
2019-01-05 22:48:17 Debug API is not available in light client mode.
2019-01-05 22:48:17 Public node URL: enode://4959d0273c8b7410ce46a47907c52c64c32cd4fca4ce3bfbb62c1f9d2d52a64d37d94b5a9e00e61fc218af482b6e04ea2c5d21480a0a079e15077020e4870590@192.168.1.110:30303
2019-01-05 22:48:27 Syncing #0 0xd4e5…8fa3 0.0 hdr/s 0+ 0 Qed 1/50 peers 0 bytes cache 0 bytes queue RPC: 0 conn, 0 req/s, 0 µs
2019-01-05 22:48:37 Syncing #3356 0x4f82…dbf7 335.6 hdr/s 223+ 0 Qed 2/50 peers 2 MiB cache 172 KiB queue RPC: 0 conn, 0 req/s, 0 µs
2019-01-05 22:48:42 Syncing #5977 0x8339…9045 524.2 hdr/s 160+ 0 Qed 2/50 peers 4 MiB cache 126 KiB queue RPC: 0 conn, 0 req/s, 0 µs
Note, how it synchronizes headers starting at #0.
Full nodes
Full nodes have the full blockchain data available on disk and can serve the network with any data on request.
❯ geth
The default mode. Synchronizes a full node doing a fast synchronization by downloading the entire state database, requesting the headers first, and filling in block bodies and receipts afterward.
INFO [01-05|22:56:41.759] Loaded most recent local header number=0 hash=d4e567…cb8fa3 td=17179869184 age=49y8mo3w
INFO [01-05|22:56:41.759] Loaded most recent local full block number=0 hash=d4e567…cb8fa3 td=17179869184 age=49y8mo3w
INFO [01-05|22:56:41.759] Loaded most recent local fast block number=0 hash=d4e567…cb8fa3 td=17179869184 age=49y8mo3w
Once the fast sync reached the best block of the Ethereum network, it switches to a full sync mode (see below).
❯ geth --syncmode full
Synchronizes a full node starting at genesis verifying all blocks and executing all transactions. This mode is a bit slower than the fast sync mode but comes with increased security.
❯ parity
The default mode. Synchronizes a full Ethereum node using warp synchronization mode by downloading a snapshot of the 30_000 best blocks and the latest state database.
2019-01-05 23:00:33 Syncing snapshot 0/2577 #0 4/25 peers 8 KiB chain 3 MiB db 0 bytes queue 11 KiB sync RPC: 0 conn, 0 req/s, 0 µs
2019-01-05 23:00:43 Syncing snapshot 2/2577 #0 7/25 peers 8 KiB chain 3 MiB db 0 bytes queue 11 KiB sync RPC: 0 conn, 0 req/s, 0 µs
2019-01-05 23:00:48 Syncing snapshot 3/2577 #0 9/25 peers 8 KiB chain 3 MiB db 0 bytes queue 11 KiB sync RPC: 0 conn, 0 req/s, 0 µs
Once the snapshot is restored, the client switches to full sync and ancient blocks are synchronized from the network in background, denoted by yellow block numbers in the logs.
❯ parity --no-warp
Synchronizes a full node starting at genesis verifying all blocks and executing all transactions. This mode is a bit slower than the warp sync mode but comes with increased security.
Archive nodes
In addition to the chain data which is kept by all full nodes, it is possible to build an archive of historical states.
❯ geth --syncmode full --gcmode archive
Synchronizes an archive node starting at genesis, thoroughly verifying all blocks, executing all transactions, and writing all intermediate states to disk ("archive").
INFO [01-05|23:04:54.981] Imported new chain segment blocks=2 txs=0 mgas=0.000 elapsed=741.138ms mgasps=0.000 number=2 hash=b495a1…4698c9 age=3y5mo3w cache=0.00B
INFO [01-05|23:04:56.475] Imported new chain segment blocks=4 txs=0 mgas=0.000 elapsed=27.599ms mgasps=0.000 number=6 hash=1f1aed…6b326e age=3y5mo3w cache=0.00B
INFO [01-05|23:05:03.616] Imported new chain segment blocks=86 txs=0 mgas=0.000 elapsed=206.526ms mgasps=0.000 number=92 hash=c86dcb…f8b64c age=3y5mo3w cache=0.00B
In Geth, this is called gcmode which refers to the concept of garbage collection. Setting it to archive basically turns it off.
❯ parity --no-warp --pruning archive
Synchronizes an archive node starting at genesis, thoroughly verifying all blocks, executing all transactions, and writing all intermediate states to disk ("archive").
2019-01-05 23:03:21 State DB configuration: archive
2019-01-05 23:03:21 Warning: Warp Sync is disabled because of non-default pruning mode.
2019-01-05 23:03:31 Syncing #1689 0x3c91…2cea 169.80 blk/s 0.0 tx/s 0 Mgas/s 4019+ 0 Qed #5715 9/25 peers 2 MiB chain 51 KiB db 7 MiB queue 7 MiB sync RPC: 0 conn, 0 req/s, 0 µs
2019-01-05 23:03:41 Syncing #6422 0x750c…dc88 473.30 blk/s 0.0 tx/s 0 Mgas/s 6270+ 0 Qed #12700 12/25 peers 5 MiB chain 120 KiB db 10 MiB queue 12 MiB sync RPC: 0 conn, 0 req/s, 0 µs
2019-01-05 23:03:51 Syncing #11293 0x576c…7163 487.20 blk/s 0.0 tx/s 0 Mgas/s 13332+ 0 Qed #24638 19/25 peers 7 MiB chain 166 KiB db 20 MiB queue 8 MiB sync RPC: 0 conn, 0 req/s, 0 µs
In Parity, this is called pruning which refers to the concept of state trie pruning. Setting it to archive basically turns it off.
Thanks for reading thus far. That's it basically.
Top comments (1)
Super helpful, Afri! Thank you!
A few questions:
Can you elaborate a little more on "filling in block bodies and receipts afterward"? Is that referring to the "best block" pivot to full sync mode?
Isn't it more than a bit slower? And this is distinguished from an archive because it's not committing intermediate states to local disk, is that correct?
How is this different from what Geth Full is doing?
Thanks again for teasing these apart. Super helpful!