Validity and preference are different
Consensus software first decides whether blocks satisfy the protocol's validity rules. Fork choice then determines which competing valid branch the node should extend or regard as its head. Bitcoin's design compares accumulated proof of work; Ethereum combines a vote-weighted head-selection rule with checkpoint finality through Gasper. Calling every system a longest-chain protocol hides these differences and can confuse block count with the actual measure of support.
2 sources for this section
A temporary disagreement
Two valid blocks can be observed close together because participants do not receive network messages simultaneously. Different nodes may initially prefer different branches and later converge as more evidence arrives. A transaction visible on a discarded branch can return to the pending set or be included elsewhere. This explains why seeing a transaction in a block and treating it as final are different judgments, particularly during congestion, outages, or unusual network conditions.
2 sources for this section
What to examine in a protocol
Ask what weights are counted, how recent votes are handled, how finalized checkpoints constrain selection, and what assumptions support convergence. Fork choice cannot make an invalid state transition valid simply because it has popular support; clients still apply their rules. Conversely, cryptographically valid signatures do not necessarily establish that a branch is the one users intend after a long-range attack. The head rule, finality mechanism, and synchronization model should be explained together.
2 sources for this section
The source notesEvidence & further reading4 sources
- Bitcoin: A Peer-to-Peer Electronic Cash System Satoshi Nakamoto · Primary source · accessed 2026-09-21
- Gasper: fork choice and finality Ethereum.org · Primary source · accessed 2026-09-21
- Ethereum proof of stake Ethereum.org · Primary source · accessed 2026-09-21
- Weak subjectivity Ethereum.org · Primary source · accessed 2026-09-21