Revision — Consensus Recap

The book’s throughline is a single question: how do you build a single global state machine that runs at hardware speed without falling apart? This part answered the “without falling apart” half. A machine that never disagreed with itself would be trivial to keep consistent — but Solana is thousands of independent validators, on different hardware, in different data centers, all producing and receiving blocks at once. Left alone they will drift into competing versions of history. Consensus is the machinery that pulls those versions back into one.

You have now built every piece of that machinery, from the overview through optimistic confirmation and finality. This page is a straight read-through: no new mechanism, no exercises — just the whole part told back as one story, so the pieces lock into a single shape before you move on to execution.

The one idea to keep: three jobs, kept apart

The most common thing people get wrong about Solana is the sentence “Proof of History is Solana’s consensus.” It isn’t, and seeing why is the fastest way to understand the entire part. Consensus on Solana is three separate jobs, and the whole design works because they are kept separate:

   PoS   ──►  WHO gets to speak, and how much their vote weighs
   PoH   ──►  WHEN each thing happened — the order, stamped by a clock
   Tower ──►  WHICH fork everyone commits to, and how hard they commit

• Proof of Stake decides who. Stake — SOL locked up and delegated to a validator — is the scarce resource that buys influence. It sets who is allowed to produce blocks and how heavily each vote counts. This is the Sybil defence: you cannot cheaply spin up a thousand fake validators to outvote the honest ones, because votes are weighted by stake, not by node count.
• Proof of History decides when. PoH is a verifiable clock, not a vote. It is a sequential SHA-256 hash chain — h = sha256(h), over and over — where the count of hashes is a measure of elapsed time, and mixing an event into the chain seals its position by construction. It produces an agreed ordering of events that anyone can verify from the data alone.
• Tower BFT decides which fork. When the network temporarily splits into competing chains, Tower BFT is the voting rule that makes validators converge on exactly one of them and then refuse to abandon it. It is the actual Byzantine-fault-tolerant agreement protocol.

Say the sentence back to yourself and the myth dissolves: PoH gives you order, but order is not agreement. Two validators can hold two different, perfectly well-ordered forks. Something still has to choose between them — and that something is Tower BFT, adjudicating over stake weights from PoS. PoH is not consensus; PoH is what makes consensus cheap. Hold onto that distinction, because the rest of the recap is just following it through the pipeline.

Retracing the pipeline, in order

Read these six stages in sequence and you have re-derived the whole part.

1. Stake sets the leader schedule — in advance

Because votes and block production are weighted by stake, and stake changes only slowly (it is locked and only shifts at epoch boundaries), the network can compute the entire leader schedule for an upcoming epoch ahead of time. Everyone knows, slot by slot, who the leader will be before the epoch begins. See Stake and the Leader Schedule.

This is not a detail — it is a load-bearing simplification. On a chain that picks its next block producer by lottery at the last moment, validators must constantly ask “whose turn is it?” On Solana that question was answered in advance, deterministically, from stake. A slot arrives, and there is exactly one validator everyone already agreed is entitled to produce it. No leader-election round trip. The clock ticks, and the pre-agreed leader is already streaming.

2. Votes are weighted by stake

The current leader stamps transactions into the PoH stream and broadcasts the resulting entries. Every other validator replays that chain locally — remember, verification is embarrassingly parallel even though production is strictly serial — and if it likes what it sees, it votes for that block. A vote is itself a transaction, and its weight is the voter’s stake. See Stake-Weighted Voting.

This is where PoS and the BFT protocol meet. The threshold that matters is the classic Byzantine one: a fork is safe to treat as agreed once validators holding more than two-thirds of stake have voted for it. Two-thirds, not a headcount — which is exactly why the who job had to come first. Weighting by stake is what makes “two-thirds of the network” a meaningful, un-Sybil-able quantity.

3. Exponential lockouts build a tower

A validator does not just vote once and forget it. Each vote comes with a lockout: a promise not to vote for a conflicting fork for some number of slots. And the lockouts grow exponentially — every time you vote again on the same fork, the lockout on your earlier votes roughly doubles. See Tower BFT and Exponential Lockouts.

   vote 1  ──►  lockout ~2 slots
   vote 2  ──►  vote 1 now locked ~4 slots
   vote 3  ──►  vote 1 now locked ~8 slots
   …                          … (doubling)
   after n consecutive votes, the oldest is locked for ~2^n slots

Picture the votes stacked up — that stack is the “tower.” The higher a vote sits in your tower, the longer you are committed to the fork beneath it. The economic logic is the point: abandoning a fork you are deeply locked into means you cannot vote (and cannot earn) for a long time, and doing it dishonestly can cost you stake. So the tower converts “I voted for this fork” into “it becomes ever more expensive for me to change my mind.” Commitment compounds.

4. Fork choice picks the heaviest fork

When forks compete, each validator applies one rule: follow the heaviest fork — the one with the most accumulated stake-weighted votes behind it, subject to the lockouts you are already bound by. See Fork Choice — Picking the Heaviest Fork.

Heaviest-fork choice plus exponential lockouts is a positive feedback loop that manufactures agreement. A fork that is slightly ahead attracts the next round of votes; those votes make it heavier still; being heavier, it attracts even more; and every validator that votes for it deepens its own lockout, making the choice progressively harder to reverse. A near-tie collapses quickly into a runaway winner. The minority fork is not so much defeated as starved — validators are locked away from it and drawn toward the mass that everyone else is converging on.

5. Optimistic confirmation ripens into finality

Once more than two-thirds of stake has voted for a block, it reaches optimistic confirmation: overwhelmingly likely to stick, good enough for most applications to act on within about a second. Keep building on top, keep voting, let more blocks and lockouts pile on, and that confirmation hardens into finality — the point where reversing the block would require so much stake to violate its lockouts (and be slashed) that it is treated as economically impossible. See Optimistic Confirmation vs Finality.

   proposed ──► voted ──► optimistically confirmed ──► rooted / final
   (a leader   (>2/3      (safe to act on,             (reversal is
    stamps it)  stake      ~sub-second)                 economically
                voted)                                  impossible)

Finality on Solana is a gradient, not a switch. That is a deliberate trade: you get a usable answer almost immediately and pay for stronger guarantees with a little more time, rather than waiting for one hard confirmation event.

The thesis, in one line

Now put the whole part back together and the throughline of this part comes into focus:

PoH is what makes BFT voting cheap — and cheap voting is what lets lockouts grow and finality arrive at hardware speed.

Walk the causal chain. On a classical BFT chain, the expensive part is not the voting arithmetic; it is that validators must first negotiate what order and time events happened in, exchanging “when did you see this?” messages before they can even agree on what they are voting about. That negotiation is the throughput ceiling.

PoH deletes that negotiation. The order is a property you read off the hash chain, verifiable by anyone, with no round trip. So a vote no longer means “let’s argue about ordering and then agree”; it means the cheap thing — “I attest to this already-ordered chain, at this height, with my stake behind it.” Because each vote is cheap, validators can vote constantly, slot after slot. Constant voting is exactly what feeds the exponential tower: the lockouts only compound if you keep stacking votes. And a fast-growing tower over a heaviest fork is what makes finality arrive in about a second instead of minutes.

So the three jobs are not just tidily separated — they are separated in order to make each other cheap. PoH makes voting cheap; cheap voting makes commitment compound fast; fast-compounding commitment makes finality arrive at hardware speed. Remove the clock and the whole cascade stalls, because every vote would drag ordering negotiation back in with it. That is why “PoH is consensus” is both wrong and revealing: PoH isn’t the agreement, but without it the agreement could not run this fast.

Back to the throughline — and forward

Zoom back out to the book’s question: a single global state machine at hardware speed, without falling apart. This part is the “without falling apart” guarantee. Out of thousands of validators producing and receiving blocks concurrently, consensus produces exactly one agreed answer to two questions that the rest of the machine cannot function without: in what order did the transactions happen, and which fork is the real one?

That agreed, finalized order is the handoff to everything downstream. Execution and the runtime never have to wonder what happened first — consensus already sealed it. When you get to how Solana runs those transactions (the account model that declares each transaction’s footprint up front, and the Sealevel scheduler that runs non-conflicting transactions in parallel across cores), it is all built on top of the single ordered, agreed stream this part produces. Parallel execution is only safe because consensus already fixed the order it is executing within.

Two parts of the same bet, then. Consensus is Solana’s answer to “how do many machines agree at hardware speed”; execution is its answer to “how does one machine run the agreed work at hardware speed.” You have now built the first. The order is sealed, the fork is chosen, finality is a gradient that ripens in about a second — and the state machine is ready to execute.