Skip to main content
netspecsEthereum networking

1.2.Fork identification

Stage
Current
Version
Sources
3 pinned sources

Consensus ENRs carry the current fork digest and the next scheduled boundary. The ENR is a discovery hint. The status handshake and the fork digest in a gossip topic remain the final protocol checks.

eth2 field

Every consensus ENR MUST contain eth2, encoded as the 16-byte SSZ container:

ENRForkID:
  fork_digest: ForkDigest       # Bytes4
  next_fork_version: Version    # Bytes4
  next_fork_epoch: Epoch        # Uint64

fork_digest is compute_fork_digest(genesis_validators_root, epoch). The epoch is the node's current wall-clock epoch, not the epoch of its synced head.

The helper takes the first four bytes of compute_fork_data_root(compute_fork_version(epoch), genesis_validators_root). The genesis validators root prevents two networks with the same fork version from sharing a digest.

next_fork_version names the next regular fork and next_fork_epoch names its activation epoch. When no regular fork is planned, the version is the current version and the epoch is FAR_FUTURE_EPOCH.

The structure uses next_fork_epoch as the earliest regular or blob-parameters-only boundary. next_fork_version changes only for a regular fork. If a blob schedule changes at the same epoch as a regular fork, that boundary is treated as the regular fork.

Fulu digest and nfd

The node computes BlobParameters(epoch) and XORs compute_fork_data_root(fork_version, genesis_validators_root) with hash(uint_to_bytes(blob_parameters.epoch) + uint_to_bytes(blob_parameters.max_blobs_per_block)). The first four bytes of that XOR are the digest. This gives each blob-parameter-only boundary its own topic and status namespace.

Once FULU_FORK_EPOCH is assigned, the ENR MUST also contain nfd, an SSZ Bytes4 containing the digest for the next regular or blob-parameter-only boundary. With no next boundary, nfd is four zero bytes. A peer that does not know this field ignores it as an unknown ENR key.

Compatibility and updates

Clients SHOULD prefer peers whose complete ENRForkID matches. They MAY dial a peer with the same current digest and different next-fork fields. The peers remain usable until the earlier advertised boundary, then need matching records.

A mismatch in nfd MUST NOT trigger a disconnect before the boundary; the client MAY disconnect at or after that boundary. A client without nfd can still detect a planned split from next_fork_epoch.

The node derives fields from the schedule and wall clock and increments the ENR sequence number whenever a value changes. Normal nodes SHOULD wait for genesis values before publishing a normal record. A pre-genesis bootnode may publish the zero-root genesis values, then MUST update the record after genesis.

Failure handling

Reject an eth2 value that is not valid SSZ ENRForkID or an nfd value that is not four bytes. Treat a current digest mismatch as a different network or fork. Do not use the head epoch to build the field, and do not disconnect early only because a future field differs.

Scope and status

This page defines the consensus ENR fork fields and their update checks. The fields do not assert client support for an unscheduled fork.