Skip to main content
netspecsEthereum networking

4.6.1.Node bootstrap

Stage
Current
Version
Sources
6 pinned sources

An Ethereum node starts three separate trust and connection paths: its local Engine API link, execution peer discovery, and consensus peer discovery.

Bootstrap process

  1. The operator gives the consensus and execution clients the same Engine API JWT secret. The clients connect and may exchange capabilities.
  2. The execution client loads static peers, discv4 bootnodes, DNS trees, or discv5 records. It filters chain-compatible records and opens RLPx.
  3. RLPx authenticates the remote node key and negotiates eth and optional satellite capabilities. The initial eth Status confirms the network ID, genesis hash, fork ID, and the peer's available block range.
  4. The consensus client waits until it knows genesis data, then loads trusted ENRs and runs discv5 lookup.
  5. It checks the eth2 fork identity, addresses, and advertised subnets. It opens libp2p, verifies the Peer ID, and negotiates streams.

The consensus client checks the advertised custody-group count before it uses data-column subnets.

  1. Req/Resp Status confirms the consensus fork digest, finalized checkpoint, and head. The node joins the gossip topics and data subnets it needs.

Failure and recovery

The node keeps the execution and consensus peer pools separate. A useful peer on one layer does not prove compatibility on the other. Failed endpoints enter bounded retry and backoff. Bad signatures, identity mismatch, or chain mismatch remove the candidate.

If the Engine API link fails, network peers may stay connected, but the consensus client cannot safely validate or build execution payloads. It restores the authenticated local link before normal head processing resumes.

Design rationale

Discovery records provide candidates. Authenticated handshakes and protocol status messages establish the identities and chain state used by live sessions.