Sync & Networking
DevP2P and the eth wire protocols, snap sync versus full sync, and how a fresh node catches up safely.
Third-party documentation. This is independently authored analysis of the public Go Ethereum (Geth) codebase — not the official docs, and not reviewed or endorsed by the Go Ethereum (Geth) team.
Sync & Networking
A Geth node is one peer among thousands in a permissionless network; this module covers how it finds peers, speaks to them, and catches up with the chain.
DevP2P discovery
Node discovery runs over UDP (the discovery v4/v5 protocols), maintaining a routing table of candidates by XOR distance. TCP connections then carry the actual protocol sessions: capability negotiation selects eth wire versions and any auxiliary protocols both sides support.
The eth wire protocol
Peers exchange status (genesis, fork digest, head) before anything else — mismatched networks disconnect immediately. Thereafter: new block announcements propagate by hash or full payload, transaction gossip floods the pool, and request/response pairs serve headers, block bodies, receipts, and (in snap mode) account/storage ranges.
Full sync versus snap sync
Full sync replays every historical block through the EVM from genesis — maximally verifiable, increasingly slow. Snap sync (the modern default) downloads the current state as flat account and storage ranges from peers, verifies each range against the state root via Merkle proofs, then executes only recent blocks. A fresh node reaches the tip in hours rather than days.
Serving and limits
Geth throttles how much it serves to keep sync honest, tracks peer reputation, and caps inbound work. Operators tune max peers, RPC rate limits, and serving windows depending on whether a node prioritizes its own sync or public usefulness.