The Two Rounds You Never See
You submit a transaction. You watch the block explorer. A green checkmark appears, the word "confirmed" shows up next to it, and you close the tab. What you didn't see was the two-round supermajority vote running underneath that confirmation, the one that determines whether your transaction is actually permanent or merely sitting on a very long probabilistic leash.
That vote is Gasper. The threshold that triggers finalization is more precise than most guides admit.
Checkpoints, Not Blocks
Gasper doesn't try to finalize every block. Epochs handle the heavy lifting instead: fixed windows of 32 slots, each slot 12 seconds, one epoch roughly 6.4 minutes. The last block in each epoch becomes a checkpoint.
Finality is a property of checkpoints. Individual blocks inherit it.
The protocol runs two checkpoint concepts in parallel. A checkpoint is justified once it collects enough attestations. It is finalized when a subsequent checkpoint, one that directly references it as a parent, also gets justified. You need two consecutive justified checkpoints to finalize the earlier one. One round isn't enough, and that constraint is load-bearing, not decorative.
Why two rounds? Classical BFT research supplies the answer. A single round of votes can be rolled back if enough validators equivocate. The second round, on a child checkpoint, is essentially the network confirming that the first round wasn't a lie. It closes the window for certain fork-choice attacks.
The Two-Thirds Threshold, With Actual Numbers
The justification threshold is a supermajority: strictly more than two-thirds of the total active validator set by stake weight, not raw validator count.
Say the network has 500,000 active validators, each holding 32 ETH. To justify a checkpoint, attestations must cross the two-thirds line, meaning votes from at least 333,334 validators (rounded up from exactly two-thirds of 500,000). Not 50%. Not a comfortable 60%. Two-thirds plus one.
The number comes from Byzantine fault tolerance theory. If up to one-third of validators are malicious or simply offline, a supermajority from the remaining two-thirds still guarantees honest representation. The geometry matters here: two groups each holding more than two-thirds of the stake must overlap. They share validators. And those validators can't honestly sign two incompatible checkpoints without triggering slashing.
Slashing is the enforcement layer, the pressure valve that makes the whole pipe hold. A validator who signs two conflicting attestations for the same slot loses a portion of their 32 ETH deposit and gets ejected from the set. The economic cost makes equivocation irrational, which is what transforms the two-thirds threshold from an aspiration into a guarantee.
Consider a concrete scenario. Two validators, Priya and Marcus, both running standard client setups with 32 ETH staked. Priya's node is well-connected; she attests in slot 3 of epoch N. Marcus had a connectivity hiccup and missed the epoch's first half, attesting late in slot 28. Both attestations still count toward the justification tally, because the protocol aggregates across the entire epoch window. Priya earns a slightly higher reward for timeliness; Marcus takes a small penalty for lateness. The checkpoint doesn't care about their individual schedules. It cares whether the aggregate crosses two-thirds. If the network's 500,000 validators collectively produce enough attestations before the epoch closes, the checkpoint is justified. Priya and Marcus both moved the needle.
Liveness Versus Safety: An Honest Tradeoff
Gasper is explicitly designed to favor safety over liveness under adversarial conditions. This is the right call, and anyone who argues otherwise hasn't thought carefully about what "finalizing the wrong block" costs.
If the network fragments and fewer than two-thirds of validators can communicate, finalization stops. Blocks keep being produced (liveness degrades gracefully) but nothing gets finalized. The chain idles.
This is correct behavior. A system that finalizes under partition conditions would be finalizing different blocks on different sides of the partition simultaneously, which is exactly the double-spend scenario the entire architecture exists to prevent. Think of it like a circuit breaker: the lights go out, but the building doesn't burn down.
The tradeoff becomes visible under real network stress. When a large fraction of validators goes offline simultaneously (a major cloud provider outage is the textbook example), the justification threshold stops being met. The chain keeps growing, but the finality horizon freezes. Once connectivity restores and participation climbs back above two-thirds, justification resumes and finalization catches up.
Do you still think of Ethereum finality as "wait six blocks," by analogy with proof-of-work? It isn't that. Proof-of-work finality is probabilistic and continuous. Gasper finality is discrete and absolute: a finalized checkpoint cannot be reorganized without destroying at least one-third of all staked ETH, because that's the minimum an attacker needs to burn through the slashing conditions. The protocol's published security analysis puts that cost in the billions at any realistic stake level. Probabilistic and absolute are genuinely different categories, and collapsing them is a mistake.
What the Fork Choice Rule Actually Does
Gasper combines two components. LMD-GHOST handles fork choice (which chain tip to build on). Casper FFG handles the finality votes. They are coupled, not independent.
LMD-GHOST: Latest Message Driven Greediest Heaviest Observed SubTree. Ugly acronym, clean logic. When a validator sees a fork, it follows the branch with the most recent accumulated attestation weight. "Latest message" means only each validator's most recent attestation counts, which prevents stale votes from distorting current decisions.
Casper FFG then overlays the supermajority checkpointing on top. The fork choice respects finalized checkpoints as absolute anchors. A validator will never vote for a chain that conflicts with a finalized checkpoint, regardless of what LMD-GHOST's weight calculation suggests. Finality is a hard constraint, not a soft preference.
The interaction between the two matters when thinking about the justification threshold. LMD-GHOST can temporarily pull validators onto a fork that Casper FFG hasn't yet justified. That fork may get abandoned if attestations don't accumulate fast enough. The two-thirds threshold is the gate that converts a fork-choice preference into a permanent record.
If two-thirds feels aggressive compared to simple majority systems, that's because it is. The cost of getting finality wrong on a network holding hundreds of billions in assets is not symmetric with the cost of making validators wait one more epoch. Asymmetric costs demand asymmetric thresholds. The math knew that before the critics did.