Skip to main content
netspecsEthereum networking

4.1.8.Execution synchronization

Stage
Current
Validity
Active non-fork protocol.
Sources
3 pinned sources

Data planes

Execution sync uses eth for headers, bodies, receipts, transactions, and chain progress. It can use snap for recent account state, storage, and bytecode.

snap is a dependent satellite of eth. The peers negotiate chain and fork identity through eth Status; snap does not provide a second chain check or canonical-head announcement.

Initial chain sync

The execution wire protocol assumes that the client learns the canonical head from consensus or another trusted chain source. A typical full sync then:

  1. Downloads headers from the selected head toward genesis in ordered ranges.
  2. Checks each parent link and header commitment.
  3. Fetches bodies by the checked block hashes and validates their roots.
  4. Fetches receipts and checks complete or explicitly continued lists.
  5. Selects a recent state pivot and downloads its state when snap is used.
  6. Reconstructs and checks the state root before accepting the snapshot.

Requests can span several peers. A response does not become canonical state until the client checks its header commitments or Merkle proof.

State synchronization

The client requests account and storage ranges in trie-key order, then fetches code and heals missing trie paths with GetTrieNodes. Boundary proofs prove the start and last returned item. The client accepts the rebuilt state only when its root matches the trusted pivot header.

The clean /execution/snap topic resolves to this snap/1 contract. The separate snap/2 variant records an in-progress block-access-list design and does not alter this current flow.

Head sync

After initial sync, consensus selects the execution head through the Engine API. Execution peers provide missing headers, bodies, receipts, and transactions. The execution client does not choose a post-Merge canonical head from legacy NewBlock announcements.

Backfill

A checkpoint-synced node can run head sync and old-history backfill in parallel. It uses each peer's advertised earliest, latest, and latest-hash range to schedule body and receipt requests. Headers remain available from genesis in the eth contract, but old bodies and receipts may require archive peers or an overlay network.

Reorg handling

A reorg cancels work tied only to the old branch. Hash-keyed objects remain checkable, but the scheduler applies them only to the branch selected by consensus.

A pivot change can require new range proofs and trie healing. The client keys downloaded ranges to the pivot root and does not apply a proof from the orphaned branch to the new state.

Failure handling

  • Reject invalid header links, roots, proofs, bodies, or receipts.
  • Do not use one peer as the only source of unverified chain structure.
  • Retry truncated responses from their exact continuation point.
  • Reassign work when a peer's advertised range does not cover it.
  • Return to a new state pivot when proofs cannot reconcile downloaded state.

Design rationale

Separating chain data from state ranges lets a client choose its local state representation. Header commitments keep both download paths tied to one chain.

History

Early fast sync fetched general trie nodes through eth. eth/67 removed that surface. snap introduced checked flat-state ranges and local trie rebuild.