You're a validator in São Paulo. The Frankfurt proposer's block lands at your node at 2.8 seconds into the slot, just inside the deadline, but the attestations from a dense cluster of Asian validators hit you at 5.1 seconds, after your local fork choice has already run. From where you sit, the canonical block looks light. A competing fork looks heavier. You back the wrong horse, briefly, and you never even knew the race was on.
This is not an edge case. It is Tuesday.
Gasper, the consensus protocol underneath Ethereum's proof-of-stake network, was designed specifically for this situation. Understanding how it resolves competing heads is the difference between thinking of Ethereum as a single authoritative ledger and understanding what it actually is: a probabilistic agreement machine that converges on truth through accumulated weight.
Two Protocols Stitched Together
Gasper is a compound protocol. It fuses two distinct mechanisms: LMD-GHOST (Latest Message Driven Greediest Heaviest Observed SubTree), which handles real-time fork choice, and Casper FFG (Friendly Finality Gadget), which handles periodic, irreversible finalization. They handle different timescales. LMD-GHOST runs slot-by-slot and picks a head right now. Casper FFG runs epoch-by-epoch (one epoch is 32 slots, roughly 6.4 minutes) and locks in checkpoints that can never be reorganized.
The fork choice question, the one about competing heads, lives entirely in LMD-GHOST territory.
The Weight That Actually Gets Counted
Here is the mechanism in plain terms. Every validator gets exactly one vote per epoch, and that vote is their "latest message": the most recent block they attested to. When a node runs LMD-GHOST to find the canonical head, it starts at the last finalized checkpoint and walks forward, at each fork counting only the latest message from each validator. Old votes for a block are overwritten by newer ones. Only the freshest attestation per validator counts.
This is the key design choice, and it's a good one. It means a late attestation doesn't dilute the vote count for the block it endorses. If validator 0x7a3f attested to block A in slot 100 and then attested to block B in slot 101, only the slot 101 vote counts toward the fork choice calculation. The slot 100 vote is discarded from the tally entirely.
So what happens when attestations arrive out of order?
Say block B is proposed in slot 101, but a third of the network's attestations for it are delayed by a slow peer-to-peer gossip path. A downstream validator, running its fork choice at slot 102, sees only two-thirds of the expected attestations for B. The other third are stuck in transit. Competing block B' (an honest fork, maybe from a validator who didn't receive B in time) has its attestations arrive promptly. From this downstream node's local view, B' looks heavier.
That node temporarily selects B' as its head. It builds on B'. It proposes a block on top of B'.
Then the delayed attestations for B arrive.
What Happens When the Late Votes Land
LMD-GHOST doesn't care about arrival order. It cares about the current state of the latest-message database. When the delayed attestations for B are processed, those validators' latest messages update to point at B. The subtree weight under B increases. If it crosses the weight of B', the fork choice flips. The node now sees B as the canonical head.
This is a reorg. Small, local, temporary. The block proposed on top of B' is now orphaned, at least from this node's perspective, and the proposer of that block loses its attestation rewards. That is the actual cost of out-of-order attestations: not broken consensus, but wasted proposals and missed rewards.
To put numbers on it: take two validators, Priya in Singapore and Marcus in São Paulo, both running identical hardware. The proposer for a given slot is in Frankfurt. Priya receives the block and its attestations within 1.2 seconds. Marcus receives the block at 2.8 seconds, just inside the 4-second attestation deadline, but the Asian validator attestations reach him at 5.1 seconds, after his local fork choice has already run. Marcus temporarily sees a lighter subtree for the canonical block and backs a competitor. Priya never wavers. By the slot's end, when all attestations have propagated, both nodes converge on the same head. Marcus experienced a one-slot local reorg. Priya didn't notice.
Same protocol. Same block. Two completely different experiences of consensus, both resolving correctly.
The Finality Layer Underneath It All
All of this slot-by-slot churn happens above a floor that Casper FFG sets. Once a checkpoint block collects supermajority attestations (two-thirds of staked ETH by weight) in two consecutive epochs, it becomes finalized. Finalized blocks cannot be reorganized without destroying at least one-third of all staked ETH, because doing so would require validators to make conflicting votes that the slashing mechanism (the protocol's penalty for provably malicious double-voting) would catch and punish.
LMD-GHOST's probabilistic, arrival-order-sensitive behavior is therefore bounded. It can only shuffle blocks sitting above the last finalized checkpoint. Everything below that line is settled.
In practice, finality arrives roughly every two epochs, so about 12 to 13 minutes after a block is included. Before that point, a block's position in the chain is a strong probability, not a guarantee. After that point, it is as close to irreversible as a distributed system gets.
One thing worth naming plainly: LMD-GHOST has known theoretical vulnerabilities under adversarial conditions, particularly around "balancing attacks" where a well-resourced attacker strategically withholds and releases attestations to keep the network split between two forks. Ethereum researchers have documented these scenarios. The practical mitigations include proposer boost (a temporary weight bonus given to the current slot's proposed block) and view-merge rules added to client implementations after the Merge. These aren't clean theoretical solutions so much as practical friction that makes the attack expensive and difficult to sustain.
The protocol is not a theorem. It's an engineering tradeoff, and anyone who tells you otherwise is selling something.
The Slot Is a Moving Window, Not a Snapshot
The deepest misconception about Gasper is treating a slot boundary as a clean cutoff, as if the protocol takes a photograph at second 12 and renders a verdict. It doesn't. The fork choice runs continuously, updating as new messages arrive. A block that looks like the head at second 8 might not be the head at second 11. Validators are expected to attest to the head they see at roughly the 4-second mark in the slot, but the chain's local view keeps evolving past that moment.
Ask yourself: if consensus were that tidy, why would proposer boost even need to exist?
You're not watching a vote being counted. You're watching a river finding its level, new water arriving from different directions at different speeds, the surface constantly adjusting. The fact that it converges at all, reliably, across thousands of nodes with heterogeneous hardware and intercontinental latency, is the actual engineering achievement. The temporary reorgs and the missed rewards are not bugs in that picture. They are the friction that proves the machine is real.