Fork Choice Rules

A distributed network can receive two valid blocks extending the same parent. Nodes need a deterministic rule for deciding which branch to build on and present as the current head. That rule is fork choice.

Fork choice is applied only after validity checks. An invalid block is not a candidate merely because it has many descendants or votes.

Bitcoin nodes compare valid branches by accumulated proof of work. A branch with more total work becomes the preferred chain, even if another branch was seen first. This rule aligns miners around the history that would be most expensive to reproduce.

Raw block count is not the security metric; proof-of-work difficulty represented by the chain matters.

Ethereum proof of stake uses a fork-choice algorithm based on validator attestations, commonly described through LMD-GHOST. Validator votes contribute stake weight to candidate branches, and the algorithm walks from a justified checkpoint toward the branch with the strongest support.

Finality then operates through checkpoint votes. Fork choice determines the current head before or between finalization events.

An adversary can try to delay blocks, withhold votes, or exploit network asymmetry so honest nodes temporarily see different support. Protocol designers add proposer timing, attestation rules, slashing conditions, and finality checkpoints to limit these strategies.

Network quality matters because fork choice only has access to messages a node has actually received.

Fork choice is the rule a node uses when more than one valid candidate branch is available. That makes it conceptually separate from validation. Validation filters out blocks that violate protocol rules; fork choice ranks the remaining valid candidates.

Bitcoin's rule is based on accumulated proof of work. A branch with more valid blocks is not automatically preferred if another valid branch represents more total work. Ethereum proof of stake uses validator attestations in its fork-choice process, reflecting a different consensus resource and message structure.

Fork choice is also distinct from finality. A node may temporarily prefer one head while an older checkpoint has already become finalized. New unfinalized blocks can still be reorganized without changing finalized history. This separation lets protocols combine rapid head selection with slower, stronger settlement guarantees.

A useful systems exercise is to imagine two branches arriving at different times. The node first checks whether each branch is valid. It then applies the fork-choice rule to decide which head to build on or present as canonical. If later evidence changes the ranking, the node may reorganize to a different valid branch unless finality prevents the change.

Thus, “the canonical chain” is not a mystical object stored somewhere centrally; it is the result of nodes independently applying common validity and fork-choice rules to the information they have received.

1. What is the difference between validation and fork choice?

2. Why can a node receive two valid branches?

3. How does Bitcoin rank competing valid histories?

4. Why is fork choice not identical to finality?

5. What is a chain reorganization, and when can it occur?

6. Correct this statement: “The longest visible branch is always the canonical branch on every blockchain.”