DEV Community

Cover image for Ethereum node configuration modes cheat sheet
Afri Schoedon
Afri Schoedon

Posted on

Ethereum node configuration modes cheat sheet

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)

Collapse
 
cooganb profile image
cooganb

Super helpful, Afri! Thank you!

A few questions:

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.

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?

[Geth Full Mode:] This mode is a bit slower than the fast sync mode but comes with increased security.

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?

[Geth Archive Mode:] "thoroughly verifying all blocks, executing all transactions"

How is this different from what Geth Full is doing?

Thanks again for teasing these apart. Super helpful!