Two roads to finality
In the previous guide you watched Ethereum's Gasper inch a block toward finality: wait two epochs — about thirteen minutes — and a finalized checkpoint becomes economically irreversible. The block is never stamped final at birth; it grows safer as attestations pile up, the way a buried transaction grows safer with more confirmations under proof of work. This is probabilistic, delayed finality, and Ethereum chose it on purpose.
Now imagine a different promise: the moment a block is produced, it is final — no confirmations, no thirteen-minute wait, no reorg, ever. That is what a Tendermint chain offers, and it does so by reaching back to a 1980s result in distributed computing rather than to Satoshi's chain race. This capstone guide of the proof-of-stake rung contrasts the two philosophies and opens up the machinery of classical Byzantine fault tolerance.
The Byzantine Generals Problem and the two-thirds rule
Several generals surround a city, each camped on a different hill. They must all attack together or all retreat — a half-hearted, split assault loses. They can only send messengers, some messengers are slow, and worse, some generals are traitors who whisper "attack" to one neighbor and "retreat" to another. How can the loyal generals reach the same decision despite the liars? That is the Byzantine Generals Problem (Lamport, Shostak, Pease, 1982), and it is exactly the situation validators face: agree on the next block even though some of them may be malicious, offline, or lying.
The classical answer, formalized for real systems by PBFT (Practical Byzantine Fault Tolerance, Castro & Liskov, 1999), is a counting rule: with n = 3f + 1 participants you can tolerate up to f Byzantine ones, as long as you require a quorum of more than two-thirds to agree on anything. Not a half — two-thirds. The extra margin is what survives both liars and a slow, message-dropping network at the same time.
Why two-thirds and not a simple majority? Because two supermajorities must overlap in an honest node. Take 100 equal validators, so f = 33 and a quorum is 67 (just over two-thirds). Any two quorums of 67 share at least 67 + 67 − 100 = 34 validators. To finalize two conflicting blocks at the same height, both would need 67 votes — but the 34 validators in the overlap would have voted for both, i.e. equivocated. With at most 33 traitors, that overlap of 34 must contain at least one honest validator, and an honest validator never votes for two conflicting blocks. So a fork is impossible unless 34 — over one-third — cheat at once. That is the whole game.
Tendermint's three steps: propose, prevote, precommit
Tendermint turns that counting rule into a rhythm. Each block height is decided in one or more rounds, and every round marches through three steps: propose → prevote → precommit. A deterministic, stake-weighted round-robin picks the proposer for each round, so everyone already agrees on whose turn it is — no mining lottery required.
// Tendermint consensus (simplified) — run by every validator at height H
for round in 0, 1, 2, ...:
proposer = proposer_for(H, round) // deterministic, stake-weighted round-robin
// ---- PROPOSE ----
if self == proposer:
block = lockedBlock if locked else build_block(mempool)
broadcast Proposal(H, round, block)
proposal = await_proposal(timeout_propose)
// ---- PREVOTE ----
if proposal is valid and (not locked or proposal == lockedBlock):
broadcast Prevote(H, round, hash(proposal))
else:
broadcast Prevote(H, round, nil)
prevotes = collect_prevotes(timeout_prevote)
// ---- PRECOMMIT ----
if prevotes has > 2/3 voting power for some block B: // a "polka"
locked = true; lockedBlock = B; lockedRound = round
broadcast Precommit(H, round, B)
else:
broadcast Precommit(H, round, nil)
precommits = collect_precommits(timeout_precommit)
// ---- COMMIT / DECIDE ----
if precommits has > 2/3 voting power for some block B:
commit B at height H // FINAL: irreversible, no reorg possible
break // advance to height H+1
// otherwise: no decision this round -> next round, new proposer- Propose: the round's proposer broadcasts one candidate block built from the mempool.
- Prevote: every validator that received a valid proposal broadcasts a prevote for its hash; those that timed out or saw an invalid block prevote nil.
- Polka: with 100 equal validators, the moment a validator sees ≥67 prevotes for the same block, that block has a polka — supermajority approval at the prevote step.
- Precommit: on seeing the polka the validator locks on that block and broadcasts a precommit for it.
- Commit: the first time a validator sees ≥67 precommits for the block, it commits — the block is final and the chain moves to the next height. If the round instead times out (a bad proposer, network lag), everyone advances to the next round with a fresh proposer and tries again.
Locking, accountability, and why it's safe
One round is easy; the danger lurks across rounds. Suppose round 0 stalls — a few validators saw enough precommits for block A and committed it, but a network hiccup meant most did not, and round 1 starts. If validators were free to now back a different block B, two conflicting blocks could each gather +2/3 over time. Locking prevents this. When a validator precommits to A in round 0, it locks on A: in every later round it will only prevote for A, and will switch its lock to some B only if it actually witnesses a polka for B in a higher round. Because a polka itself needs +2/3, a validator can never be tricked into abandoning a block that a supermajority already precommitted.
This delivers accountable safety, the same prize Casper FFG aims at. Recall the overlap argument: forking two finalized blocks requires ≥34 of our 100 validators to precommit to both — to equivocate. Equivocation is not a vague accusation; each precommit is a validator-signed message, so the two contradictory signatures are a cryptographic confession. They become a slashing proof anyone can submit, and the offenders lose their stake and are ejected. So an attacker cannot break safety cheaply or anonymously: a fork costs at least a third of all staked capital, burned and provable.
Safety over liveness: BFT chains halt, they don't fork
Every consensus design must balance two properties: safety (never finalize two conflicting blocks) and liveness (keep producing new blocks). A foundational result says you cannot guarantee both in an unreliable network — so each system picks which to sacrifice when things go wrong. Tendermint chooses safety. If more than one-third of voting power goes offline or is partitioned away, no block can reach the +2/3 precommit threshold, so the chain simply stops. It produces no blocks at all rather than risk two halves of the network finalizing different histories.
Ethereum makes the opposite call. Its fork-choice rule, LMD-GHOST, always picks a head and keeps the chain alive during a partition; Casper FFG layers finality on top, and if finality stalls because no supermajority can be reached, the inactivity leak slowly drains the offline validators' stake until the online set is back above two-thirds and can finalize again. Ethereum keeps moving but may go un-final for a while; a Tendermint chain freezes solid but never contradicts itself. Neither is "better" — they are different bargains.
The price of instant finality: O(n²) and small validator sets
Instant finality is not free, and the bill is paid in decentralization. To commit a block, every validator must hear the prevotes and precommits of (more than two-thirds of) every other validator. That is all-to-all communication: with n validators, on the order of n² vote messages fly across the network each block. At 180 validators that is roughly 180 × 180 ≈ 32,000 messages per step — fine. At a million validators it would be 10¹² — utterly impossible.
This is why a Tendermint chain caps its active set at a few hundred validators — the Cosmos Hub runs ~180, with a hard limit voted on by governance — while Ethereum's design lets ~1,000,000 validators participate. Ethereum buys that scale precisely by giving up instant finality: it splits validators into committees, has only a sample attest each slot, and aggregates their BLS signatures into one, accepting the ~13-minute finality delay in return. The contrast is a clean instance of the scalability trilemma: fast finality, large validator set, simple design — pick your trade.
Which road, and where they converge
So when does instant finality earn its decentralization cost? Above all when other chains need to trust your blocks fast. Cosmos's IBC protocol lets chains pass messages by verifying each other's headers, and that is only sound if a header, once seen, can never be reverted — exactly what single-block BFT finality guarantees. App-chains that want their own sovereign validator set, predictable ~1–6 second block times, and no reorg risk for bridges and exchanges reach naturally for Tendermint. Chains that prize the largest, most permissionless validator set and maximum censorship resistance lean toward Ethereum-style probabilistic consensus.
The two roads are quietly converging. Ethereum's finality today is supplied by a finality gadget bolted onto a probabilistic chain, but the active research goal of single-slot finality is to finalize every slot in seconds — importing the very BFT instant-finality property Tendermint has had all along, while keeping a giant validator set through aggressive signature aggregation. The frontier is no longer "probabilistic versus BFT" but "how big a validator set can we keep while still finalizing in one slot."
That closes the proof-of-stake rung. You now know why staking replaced electricity, how a validator earns and is slashed, what finality means in both the probabilistic Gasper world and the instant BFT world, and the deep safety-versus-liveness bargain that separates a chain that halts from a chain that forks. Carry one sentence forward: finality is a promise about what can never be undone, and every consensus design is a different price paid for that promise.