Fork ID

Definition

A fork ID summarizes a blockchain's genesis and activated fork schedule so peers can detect incompatible network histories during connection. Peers use it to reject clearly incompatible connections while allowing nodes that are safely before or after known upgrades to communicate. It is not the same as an EVM chain ID and does not authenticate a peer or prove canonical state.

Overview

Meaning and scope

A fork ID summarizes a blockchain’s genesis and activated fork schedule so peers can detect incompatible network histories during connection. Peers use it to reject clearly incompatible connections while allowing nodes that are safely before or after known upgrades to communicate. It is not the same as an EVM chain ID and does not authenticate a peer or prove canonical state.

Mechanism and operation

A fork ID is a compact compatibility signal exchanged by peers. In Ethereum’s discovery and handshake conventions, it combines a hash derived from genesis and past fork activations with information about the next expected fork. Client implementations must calculate fork IDs from the correct genesis and schedule, including network-specific upgrades. Operators should investigate widespread mismatches as configuration or upgrade failures. Applications still need chain ID, genesis verification, synchronization, and finality checks beyond peer-level fork compatibility. Fork ID should be tied to specific competing block hashes, heights, fork-choice rules, and the point at which the local canonical view changed.

Practical payment example

Two Ethereum peers advertise protocol compatibility information while connecting. A node refuses a mismatched branch configuration rather than combining transaction results from networks following different fork histories.

Operational checks

Applications affected by Fork ID should roll dependent state backward idempotently and then replay the new canonical history. The likelihood and impact of Fork ID depend on consensus design, network partitions, client faults, finality, and participant concentration. Monitoring should retain old and new block references, affected transactions, confirmation depths, and the trigger for every business-state change.

Distinctions and limits

Fork IDs help peers detect protocol compatibility, but they do not replace chain identity, authentication, synchronization, or finality verification.

Related definitions: fork, fork activations.

Example

Comparison

It is not the same as an EVM chain ID and does not authenticate a peer or prove canonical state. A height alone is insufficient because several valid or invalid branches can contain different transactions at the same position.

Key Takeaway