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.

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.

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.