Consensus from first principles: safety, liveness and finality

The problem: one log, many strangers

A blockchain is a replicated state machine. Every node starts from the same genesis state and applies the same deterministic transition function to the same ordered list of transactions, so agreeing on the state reduces to agreeing on the order of the log. Consensus is the protocol that produces that order while some nodes crash, some lie, messages arrive late or never, and anyone may join. The last condition is what separates public chains from the replicated databases the theory was built for. Identities are free, so voting power has to be tied to something scarce: hash power or stake (see proof of work versus proof of stake).

Three results that bound every design

FLP (Fischer, Lynch and Paterson, 1985). In a fully asynchronous network, where any message can be delayed by any finite amount, no deterministic protocol can ensure consensus terminates if even one process may crash. The adversary can always delay the one message that would have decided the outcome. Real protocols escape with randomness or, far more often, with timing assumptions.

Partial synchrony (Dwork, Lynch and Stockmeyer, 1988). The network may behave arbitrarily badly until an unknown global stabilization time (GST), after which messages arrive within a bound Δ. Protocols built for this model keep safety at all times and regain liveness after GST. Almost every BFT protocol in production, including Ethereum’s finality gadget, is designed against this model.

The one third bound. Under partial synchrony, tolerating f Byzantine participants needs n ≥ 3f + 1. The argument is quorum intersection. A protocol must be able to move on with n − f responses, since the faulty ones may stay silent, and any two such quorums must share an honest member or two parts of the network could be told different stories:

The consequence is a choice every chain makes, sometimes without saying so: when the network partitions or more than a third of participants vanish, do you keep producing blocks (liveness, at the risk of reorgs) or stop until a supermajority returns (safety)? Neu, Tas and Tse formalized this in 2020 as the availability and finality dilemma and showed that one protocol can serve both, as two ledgers, one available and one final. Ethereum follows this two ledger pattern, although its fork choice needed later patches, notably proposer boost, against attacks the same authors found.

Nakamoto consensus: the heaviest chain wins

Bitcoin’s rule fits in a sentence: extend the valid chain with the most cumulative work. There is no voting and no membership list. Miners come and go and the chain always progresses, a property called dynamic availability. The price is that no block is ever final in the deterministic sense. A block is buried under work, and reversing it means out-mining the rest of the network from that point on.

Section 11 of the Bitcoin whitepaper models the attacker as a random walk. With attacker hash share q and honest share p = 1 − q, the chance of ever catching up from z blocks behind falls exponentially in z:

Six confirmations is a convention, not a law of nature: it holds a 10% attacker to about 0.02%, but a 30% attacker still succeeds about 13% of the time. Two more results matter. Eyal and Sirer showed in 2013 that honest mining is not incentive compatible: a selfish miner who withholds blocks profits above (1 − γ) ÷ (3 − 2γ) of hash power, where γ is the share of honest miners who build on the attacker’s block during a tie. That is one third at γ = 0 and one quarter at γ = 1/2. And the whole safety argument assumes blocks propagate much faster than they are found, which is why Bitcoin keeps a 10 minute target, retuned every 2,016 blocks by the difficulty adjustment.

Classical BFT: vote, lock, commit

The other lineage starts from a known validator set and explicit votes. PBFT (Castro and Liskov, 1999) runs three phases per decision, pre-prepare, prepare and commit, plus a view change protocol to replace a faulty leader. Every replica talks to every other, so message complexity is quadratic, which is why classical BFT was long assumed to stop at a few dozen nodes.

Tendermint, maintained today as CometBFT and used across the Cosmos ecosystem, adapted the idea to blockchains. Each height runs rounds of propose, prevote and precommit. A validator that sees prevotes from more than two thirds of voting power for a block (a "polka") locks on it and precommits. Precommits from more than two thirds commit the block, and the commit is final the moment it happens. The lock is what carries safety across rounds: a validator may only release it after seeing a newer polka for something else. HotStuff (2019) later made leader replacement linear and pipelined the phases so each block advances its predecessors, shaping many of the protocols that followed.

Ethereum Gasper: a fork choice plus a finality gadget

Ethereum runs both lineages at once. LMD GHOST is a fork choice that picks a head every slot and keeps the chain available. Casper FFG is a finality gadget on top that finalizes checkpoints BFT style, and the fork choice is never allowed to revert them. The combination was specified as Gasper in 2020. The values below are the mainnet parameters in the consensus specs as of September 2026.

LMD GHOST

Latest Message Driven Greedy Heaviest Observed SubTree. Start at the latest justified checkpoint, walk down the block tree, and at every fork take the child whose subtree carries the most weight, counting only each validator’s most recent attestation. The proposer boost temporarily adds 40% of a committee’s weight to a timely block in its own slot, which stops an attacker from splitting honest votes evenly between two siblings.

Casper FFG

Every attestation also carries an FFG vote: a source, the latest justified checkpoint the validator knows, and a target, the first block of the current epoch. When links with the same source and target carry 2/3 of stake, the target is justified. A justified checkpoint is finalized when the next epoch’s checkpoint is justified with it as the source. Normally checkpoint N is justified at the end of epoch N and finalized at the end of epoch N + 1, two epochs or 12.8 minutes. A transaction in the middle of an epoch waits for the next checkpoint, so real waits run from about 13 to 19 minutes, which is why ethereum.org rounds it to about 15. Two rules make a finalized checkpoint expensive to contradict:

# ethereum/consensus-specs, phase0: the two Casper FFG slashing conditions
def is_slashable_attestation_data(data_1, data_2) -> bool:
    return (
        # Double vote: two different votes for the same target epoch
        (data_1 != data_2 and data_1.target.epoch == data_2.target.epoch)
        or
        # Surround vote: one vote's source..target span strictly contains the other's
        (data_1.source.epoch < data_2.source.epoch and data_2.target.epoch < data_1.target.epoch)
    )

Together they give accountable safety. For two conflicting checkpoints to both be finalized, two sets holding 2/3 of stake must have voted for them, so at least 2/3 + 2/3 − 1 = 1/3 of stake signed votes that break a rule (for a fixed validator set), and the evidence can be submitted onchain. Since Electra a slashed validator loses 1/4,096 of its effective balance at once, is forced to exit, and about 18 days later pays a correlation penalty that scales with everything slashed in the surrounding 36 days:

An isolated mistake costs a small fraction of one ETH. A coordinated attack by a third of stake costs all of it. That is what economic finality means: reverting a finalized checkpoint is possible, but only by burning at least a third of everything staked (see slashing and what validators do).

The inactivity leak: how finality comes back

If more than a third of stake goes offline, no checkpoint can be justified, yet LMD GHOST keeps producing blocks. Once the finality delay passes 4 epochs, the chain enters an inactivity leak. Each validator has an inactivity score that rises by 4 for every epoch it misses a timely target vote, and each epoch it is charged:

After t epochs offline the score is about 4t, so the per epoch charge is about balance × t ÷ 2²⁴ and the cumulative loss grows with t². Participants lose nothing to the leak, though they earn no attestation rewards while it lasts. The offline share of stake shrinks until the online validators hold 2/3 again and finality resumes. Simulating the rule for 32 ETH validators, and ignoring the much smaller ordinary penalties for missed votes:

Mainnet has seen the early stages. On May 11 and 12, 2023, a client resource exhaustion bug delayed finality for 4 and then 9 epochs while blocks kept coming, and the second episode triggered the leak, costing inactive validators roughly 28 ETH in total according to the Prysm team’s post-mortem. The design has an uncomfortable corollary: in a true network split, each side leaks the other side’s validators, and after a few weeks both sides could in principle finalize. A long partition is therefore resolved socially, by the community choosing a chain, not by the protocol alone.

Solana: a clock, Tower BFT and Alpenglow

Solana chased latency by a different route. Proof of history is a sequential SHA-256 hash chain the leader runs continuously and mixes transactions into, so anyone can verify ordering and approximate elapsed time without trusting timestamps. It is a clock, not a consensus protocol: validators still vote on which fork to follow. Leaders are scheduled in advance for windows of four consecutive slots.

Tower BFT

Validators vote with onchain vote transactions, and every vote carries a lockout. After voting for slot s, a validator may not vote on a conflicting fork until slot s + 2^c, where c is the vote’s confirmation count, 1 when cast and rising as later votes stack on top, so each new vote doubles the lockouts beneath it. When 32 votes are stacked, the oldest reaches maximum lockout, leaves the tower and its slot is rooted. Two checks sit on top: a validator will not vote if the vote 8 deep in its tower lacks support from 2/3 of stake, and it may only switch forks after seeing more than 38% of stake on the other side.

RPC commitment levels map onto this. confirmed is optimistic confirmation, a supermajority has voted on the block; finalized means rooted. The Alpenglow proposal puts Tower BFT finality at 12.8 seconds, which is 32 slots of 400 ms. Slot times have since moved: under SIMD-0525, mainnet stepped its target from 400 ms to 350, 300 and then 250 ms between August and mid September 2026, with a 200 ms step still pending, so the same 32 slot depth now takes about 8 seconds. The proposal also notes that Tower BFT has no published security proof.

Alpenglow

SIMD-0326 (Kniep, Sliwinski and Wattenhofer) replaces Tower BFT with Votor. Votes leave the chain: validators send them to each other directly and aggregate them into BLS12-381 certificates.

The result is a deliberate "20+20" trade: safety against up to 20% Byzantine stake instead of the classical 33%, in exchange for one round finality in the common case and liveness with a further 20% of stake simply offline. Alpenglow also caps the active set at the 2,000 highest staked validators, replaces vote fees with a burned validator admission ticket of 1.6 SOL per epoch in the proposal (about 0.8 SOL a day at the original 400 ms slots), and keeps Turbine for block propagation until a separate Rotor proposal. Public testing targets finality of roughly 150 milliseconds.

The designs side by side

Open questions

• Faster Ethereum finality. ethereum.org (updated July 2026) describes single slot finality as research that is not expected to ship for several years. The Ethereum Foundation’s lean Ethereum vision (July 2025) aims at finality in seconds, with hash based aggregate signatures eventually replacing BLS.
• Is 20% the right bound? Alpenglow bets that crash tolerance and one round latency matter more in practice than the last 13 points of Byzantine tolerance. Whether stake concentration makes that bet safe is an open argument.
• Timing games. Proposers who delay blocks to capture more MEV eat into the timing assumptions the fork choice relies on. See the MEV supply chain.
• Long range attacks. Keys that have exited can cheaply sign an alternative history. Proof of stake answers with weak subjectivity: new nodes start from a recent trusted checkpoint rather than from genesis.
• Validator count versus message cost. Signature aggregation is what lets Ethereum count votes from a very large set; Alpenglow instead caps its set at 2,000. The scheme choices behind both are in signature schemes.

Common questions

Where to go next