A node needs a rule for choosing its current valid chain head.
LET’S PICTURE IT
When two valid draft continuations exist, a club needs an agreed method to choose which one it follows next.
SEE IT FOR YOURSELF
Receive, check and share across independent nodesStep 1 / 4
A node receives a proposed transaction or block-related message. Receipt is not the same as accepting its claims.
A node receives a proposed transaction or block-related message. Receipt is not the same as accepting its claims.The node checks the relevant authorization and protocol rules. Popularity does not make an invalid state transition valid.Valid candidate data can propagate to peers. Connections and timing differ, so there is no perfect simultaneous worldwide view.Peers validate under the same protocol rules. This illustration is about verification and propagation, not a complete proof-of-stake consensus algorithm.
Animated local teaching model. No wallet, RPC or live blockchain data. Some labels and hashes are abbreviated for readability.
Validity comes before preference
A branch containing an invalid execution transition does not become acceptable merely because someone advertises support for it. Fork choice operates within the protocol’s validity and consensus context.
Recent votes guide the head
Ethereum’s proof-of-stake fork-choice mechanism uses attestation information and specified weighting rules. It should not be reduced to counting web users or choosing whichever block number looks largest.
New information can change a local view
A node can learn delayed votes or blocks and update its head. This helps explain reorganizations of recent unfinalized history and temporary differences between providers.
Finality supplies another boundary
Checkpoint finality is a stronger chain commitment than the current head alone. Applications should know whether they are asking about latest execution, accepted head or finalized state.
QUICK CHECK · NO PRESSURE
Is “choose the page with the most social-media likes” Ethereum fork choice?