Skip to main content
netspecsEthereum networking

3.1.4.Execution discovery profile

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

Discovery inputs

Execution clients combine configured bootnodes, signed DNS trees, discv4, and discv5. Each method produces candidate identities and endpoints.

DNS discovery gives an authenticated bootstrap set. discv4 supplies an execution routing table. discv5 supplies ENR-native encrypted discovery and application requests.

Execution ENR fork ID

The ENR eth entry is an RLP list whose first item is an EIP-2124 ForkID:

[[fork-hash, fork-next], ...]

The first item applies to the eth capability. Later items are reserved for other capabilities.

The fork hash summarizes past fork blocks from genesis. fork-next is the next known fork block or zero. A client uses this entry to remove clear mismatches before it opens RLPx.

Candidate process

  1. Load configured static and DNS bootnodes.
  2. Check every ENR signature and sequence.
  3. Add valid records to the selected discovery table.
  4. Apply the ENR ForkID check when the eth entry exists.
  5. Select reachable TCP endpoints and open RLPx.
  6. Apply the authoritative chain check in eth Status.

An absent eth entry does not make a common ENR invalid. It removes the early execution-chain compatibility hint.

Failure handling

  • Reject invalid ENRs and invalid DNS proofs.
  • Reject expired or invalid discv4 packets.
  • Keep records with unknown ENR keys.
  • Do not treat an ENR fork match as a completed eth handshake.
  • Do not transfer reputation when the node identity changes.

Design rationale

Several discovery sources reduce dependence on one bootstrap path. The ENR ForkID avoids many incompatible TCP handshakes without making discovery depend on full chain state.

History

Execution discovery began with static nodes and discv4. EIP-1459 added DNS trees. EIP-778 added ENRs, and the eth entry added EIP-2124 fork filtering.