Skip to content
Financial Context Wiki

Fork-Choice Rules: Valid Branches, Weight, and Canonical Heads

A fork-choice rule maps a node's validated local view to a current canonical head. Analyze candidate validity, ancestry, cumulative work or vote weight, checkpoints, timing, tie-breaks, reorganization effects, and finality separately.

Updated

Educational protocol analysis only. A node’s current head is conditional on the network, rule version, validated local view, weight evidence, checkpoint and time; it is not automatically finalized or safe for irreversible application settlement.

Direct answer

A fork-choice rule is the protocol procedure that maps a node’s validated local view of competing blocks and consensus messages to a current canonical head. Its output is provisional and observer-relative: two honest nodes can briefly choose different heads because they have received different valid blocks, votes or timing events. Once their admissible views converge under the protocol’s network assumptions, the rule is intended to converge too.

Fork choice does not make an invalid block valid. State-transition, authorization, proof, ancestry and data-availability checks determine which candidates are admissible before their weight is compared. Nor is the selected head necessarily finalized. Fork choice identifies the branch to extend now; a finality rule may protect an older ancestor with stronger safety evidence. Replacing the current head can be ordinary operation, while replacing a finalized checkpoint would cross a different protocol boundary.

“Longest chain” is not a universal formula. Bitcoin selects a most-work valid chain: cumulative expected proof of work, not raw height, is decisive. Ethereum’s LMD-GHOST starts from a justified checkpoint, filters for viable branches, and greedily follows the child with the greatest latest-message attesting balance, plus any applicable proposer boost; only the latest eligible message from each validator contributes. Other protocols may use availability certificates, leader locks, rounds or explicit commit certificates rather than a persistent heaviest-branch competition.

The result depends on exact inputs: chain and network, fork version, trusted anchor, current time or slot, known valid blocks, parent links, work or voting-weight snapshot, latest messages, equivocation evidence, justified and finalized checkpoints, availability state, proposer timing and deterministic tie-breaks. A block-explorer badge or one RPC result is an observation of one node’s output, not the rule or independent proof of its inputs.

How to analyze a fork-choice rule

  1. Fix identity and version. Record chain, network, consensus fork, client version, genesis or trusted anchor, current height or slot and the exact rule active there. Do not import mainnet logic into a testnet, sidechain, rollup or future proposal.
  2. Build the admissible block graph. Verify hashes, parents, consensus proofs, state transitions, execution payload status and required data availability. Mark unknown, optimistic, invalid and pruned nodes explicitly; weight must not rescue an invalid branch.
  3. Reconstruct ancestry and constraints. Find the common ancestor and confirm which candidates descend from required checkpoints, locks or certificates. Separate a raw observed tree from the filtered tree the rule may actually consider.
  4. Reproduce every weight input. For PoW, decode targets and sum per-block proof into cumulative chainwork. For voting rules, verify validator identity, active effective balance or other weight, message domain, target root, slot or epoch, latest-message replacement, equivocation treatment and any temporary boost.
  5. Execute selection and tie-breaks exactly. Apply the specified recursion or comparator at each branch, using protocol rounding and deterministic ordering. Record whether equal weight permits temporary local preference rather than pretending the tie is final agreement.
  6. Reconcile head changes. When the winner changes, identify detached and attached blocks, roll back and replay state, reconcile receipts, logs and the mempool, and calculate reorganization depth from the common ancestor. Keep head, safe, justified, committed and finalized labels distinct.
  7. Stress and monitor the deployed system. Test delayed or withheld blocks, partitions, stale votes, equivocation, balancing, proposer timing, client disagreement, weak checkpoints and unavailable data. Compare independent nodes and alarm on unexpected head divergence, deep reorganization or conflict with finalized state before irreversible downstream action.

In current Bitcoin Core, candidate ordering first compares nChainWork; equal-work candidates are then ordered by earliest activatable sequence, with an internal fallback tie-break. The RPC field blocks is the height of the most-work fully validated chain, while bestblockhash identifies its tip. In Ethereum’s current fork-choice specification, get_head(store) starts at justified_checkpoint, walks a filtered tree and chooses the child maximizing (get_weight(store, child), child.root) at each step. Those implementation details are protocol- and version-specific, not generic definitions of consensus.

Worked examples

1. Bitcoin cumulative-work switch

Two valid branches share common ancestor C. The current tips have chainwork(A)=240 and chainwork(B)=235, so the node selects A even if a casual height display makes the branches look similar. A new valid block adds work 10 to branch B:

chainwork(B') = 235 + 10 = 245

Because 245 > 240, B becomes the most-work candidate. The node disconnects A’s blocks after C, connects B through B', and reconciles transactions. Raw block count is insufficient when per-block targets differ, and equal work is a temporary tie case rather than proof of finality.

2. Greedy heaviest observed subtree

Use a simplified LMD-GHOST tree rooted at justified checkpoint J. Its children are A and B. Latest eligible validator messages give A’s whole subtree weight 61 and B’s subtree 39, so the first greedy step selects A. A has children A_1 and A_2 with subtree weights 34 and 27; the next step selects A_1.

The head is found by choosing the heaviest child repeatedly, not by counting branch length or selecting the leaf with the largest isolated direct vote. Production rules also include viability filtering, balance snapshots, equivocation handling, proposer timing and tie-breaks omitted from this teaching tree.

3. Latest-message replacement

Suppose eligible latest messages initially give branch A weight 55 and branch B weight 45. A validator of weight 20 later sends a newer eligible message supporting a descendant of B. Latest-message accounting removes that validator’s old support from A and adds it to B:

A: 55 - 20 = 35; B: 45 + 20 = 65

The weight is counted once, not on both branches, so the selected path can change. This is not permission to vote inconsistently: if valid attester-slashing evidence identifies equivocation, the current Ethereum store tracks the equivocating validator and excludes that weight from ordinary attestation scoring.

4. Checkpoint filtering and proposer boost

Assume a node observes raw latest-message weight 70 on a branch conflicting with its finalized checkpoint and weight 30 on a viable descendant. The conflicting branch is excluded before head selection; raw majority weight cannot override the finalized-checkpoint constraint through ordinary fork choice.

Now consider two viable children in the current slot with attestation weights 35 and 50. Under the cited Ethereum configuration, a timely proposer boost equals 40% of one committee’s weight, not 40 percent of total stake. If committee weight is 100 and the boost applies to the 35-weight child, its comparison score becomes 35 + 40 = 75, so it beats 50 for that step. The boost is temporary and fork-specific; it is neither an extra validator vote nor finality.

Risks and review failures

Candidate set and evidence

  • Comparing branch weight before validating parents, state transitions, proofs, payload status or required data.
  • Treating unknown or optimistic execution, unavailable data or a headers-only view as fully validated state.
  • Using block height, timestamp, transaction count, fees or explorer popularity as a substitute for the specified weight.
  • Summing displayed difficulty instead of reproducing per-block proof and cumulative chainwork under the correct targets.
  • Counting every historical vote instead of each validator’s latest eligible message under the correct weight snapshot.
  • Ignoring message domain, root, slot, epoch, timeliness, signature, equivocation and slashing evidence.
  • Comparing raw branches that the protocol’s checkpoint, lock, certificate or availability filter makes ineligible.
  • Applying a future specification, another network’s parameter or an implementation optimization as current consensus law.

Selection and operational failure

  • Describing Bitcoin’s rule as raw “longest height” or Ethereum’s rule as a simple two-thirds head vote.
  • Replacing greedy subtree recursion with a global leaf score, or omitting proposer boost, rounding and root tie-breaks.
  • Assuming nodes with different arrival order, clocks or message views must report the same head immediately.
  • Failing to disconnect and replay state, receipts, logs, indexes and mempool entries correctly during a reorganization.
  • Letting client implementations diverge on validity, checkpoint viability, latest messages, timing or tie-breaks.
  • Missing balancing, withholding, equivocation, partition, eclipse, delayed-vote and proposer-reorganization conditions.
  • Trusting one RPC, explorer, relay, client family, cloud or validator operator as an independent view of consensus.

Finality and application mismatch

  • Calling the selected head finalized, irreversible or safe without the protocol’s separate finality evidence.
  • Releasing deposits, bridge messages or irreversible trades on a transient head without value-sensitive policy.
  • Assuming a finalized ancestor guarantees correctness or availability of every newer head, payload, oracle or application result.
  • Using a fixed confirmation count across chains with different work, vote, checkpoint and recovery models.
  • Treating emergency checkpoints, weak-subjectivity anchors or social recovery as ordinary fork-choice inputs with no trust boundary.

Common misconceptions

  • The longest branch always wins. The protocol may compare cumulative work, weighted latest messages, certificates or another score; raw height alone is not universal.
  • The heaviest observed branch is automatically valid. Validity and availability filter candidates before weight can select among them.
  • Fork choice and finality are the same rule. Fork choice selects the current head to extend; finality protects an ancestor under additional safety conditions.
  • Every validator vote remains in the total forever. In latest-message rules, a newer eligible message replaces the validator’s prior fork-choice support.
  • One explorer proves the canonical chain. It reports one infrastructure stack’s view; independent validation and reconciliation are still required.

Sources

Navigation

Search the wiki...