Consensus — Tower BFT & Proof of Stake

The Proof of History part left you with a powerful object: a single, verifiable clock that every validator can check independently, and a firehose of transactions stamped into a definite order. That feels like it should be the whole game. It is not. Ordering is not agreement.

A shared clock tells you when an event sits in the stream. It does not tell you which stream is the real one when two leaders produce competing histories, and it does not tell you whose opinion counts when they disagree. Those are the two questions this part answers. By the end you will be able to trace a single slot from “a validator was chosen to lead it” all the way to “the network will never roll this back,” and say exactly which mechanism does which job.

Ordering is not agreement

Here is the gap PoH leaves open. Imagine the leader for slot 100 is slow, or partitioned, or malicious. A block still needs to exist for slot 100, so the network’s view can split: some validators build on the block they saw, others build on a different one, and now there are two forks claiming the same slot height.

                       ┌─ block 100a ─ block 101a ─ block 102a   (fork A)
   ... block 99 ───────┤
                       └─ block 100b ─ block 101b               (fork B)

   PoH proves each block's INTERNAL order and timing.
   PoH does NOT tell you whether A or B is the canonical chain.

Both forks can be perfectly well-ordered internally — every hash checks out on each branch. The clock has done its job and the ambiguity remains. Choosing between A and B, and doing it in a way that a Byzantine minority cannot subvert, is a consensus problem, and consensus is what this part builds.

Three jobs, cleanly separated

The single most common confusion about Solana is collapsing three distinct mechanisms into one word (“Proof of History is the consensus”). It is not. Solana runs three separate systems, each answering a different question. Keep this table; you will reuse it on every page of this part.

Question	Mechanism	What it decides
Who has influence?	Proof of Stake	Voting power is proportional to staked SOL. This is the Sybil defense — you cannot fake weight, only buy it.
When did it happen?	Proof of History	A verifiable hash-chain clock fixes the order and timing of events, so no one negotiates timestamps.
Which fork wins?	Tower BFT	A stake-weighted BFT vote, run on top of the PoH clock, that converges the network on one canonical fork and eventually makes it irreversible.

Read the table as a pipeline: Proof of Stake decides how heavy each validator’s vote is, the PoH clock decides what they are voting about (a specific slot in a specific order), and Tower BFT is the voting rule that turns all those weighted opinions into a single agreed history. None of the three can be removed without breaking the other two — a point we return to in the architect’s lens on the individual pages.

The central thesis of this part

Why does Solana bother with its own consensus name at all, instead of reusing an off-the-shelf BFT protocol? Because classical Byzantine Fault Tolerant protocols are chatty. To agree on ordering, nodes in a traditional BFT system exchange rounds of messages proposing and confirming timestamps and sequence numbers — and that message complexity is exactly what caps throughput on other chains.

Solana’s key insight is this:

PoH-as-a-clock is what makes BFT voting cheap enough to run at hardware speed.

Because every validator already shares the same verifiable clock, they do not need to negotiate when things happened — the clock is common knowledge, proven from the data itself. That collapses the expensive part of BFT. Validators only have to vote on which fork, and they can attach a cheap, escalating commitment to each vote (an exponential lockout: each vote you cast promises not to abandon that fork for a doubling number of slots) without a round of timestamp negotiation. The clock turns a conversation into a broadcast. That is the entire reason Tower BFT can keep up with sub-second slots instead of dragging the chain back to committee-sized speeds.

   Classic BFT   :  propose ⇄ pre-vote ⇄ commit   (many messages per decision)
   Tower BFT     :  everyone reads the SAME PoH clock, then broadcasts one vote
                    with an exponential lockout — no timestamp haggling

Hold onto that thesis. Every page in this part is, in some sense, spending the PoH clock to buy cheap agreement.

The roadmap for this part

Read these in order. Each page installs one piece of the pipeline from “who leads” to “when is it final.”

#	Page	What it establishes
2	Stake and the Leader Schedule	How staked SOL both weights votes and, via the PoH clock, pre-computes which validator leads which slot — so the network knows the schedule in advance.
3	Stake-Weighted Voting	What a vote actually is, how votes are weighted by stake, and what threshold of stake it takes for the network to consider a slot agreed.
4	Tower BFT and Exponential Lockouts	The heart of the part: how each vote commits a validator to a fork for a doubling number of slots, making it progressively costlier to switch and driving convergence.
5	Fork Choice — Picking the Heaviest Fork	The rule for choosing between competing forks: follow the fork with the most stake-weighted votes behind it, respecting each validator’s lockouts.
6	Optimistic Confirmation vs Finality	The difference between “very probably settled” (optimistic confirmation) and “provably irreversible” (finality / rooted), and why users usually act on the former.
900	Revision — Consensus Recap	The whole part in one breath: the three jobs, the lockout mechanism, fork choice, and the confirmation-versus-finality distinction.

By the end of page 6 you should be able to take any slot and narrate its life: it was assigned to a leader by the stake-weighted schedule, filled with a PoH-ordered block, voted on by stake-weighted validators whose lockouts deepen with each vote, selected over rival forks by the heaviest-fork rule, confirmed optimistically within a fraction of a second, and finally rooted so it can never be undone.

The thread

The book’s throughline is how do you build a single global state machine that runs at hardware speed without falling apart? This part is where “without falling apart” gets teeth. A single global state machine only exists if everyone agrees on one history — the instant two forks are treated as equally valid, the “single” in “single global state machine” is a lie.

So carry this question through every page:

What makes switching forks expensive — and is it expensive enough to keep everyone converged without being so expensive the network can’t recover from an honest split?

That tension is the whole design. Make lockouts too shallow and validators flit between forks and never converge. Make them too deep and an honest partition can strand stake on a losing fork, hurting liveness — the same liveness fragility the foundations part warned is the price of the monolithic bet. Tower BFT’s exponential lockout is the specific dial Solana chose to walk that line, and it only works because the PoH clock makes the voting cheap.

This part also leans on the account model in a concrete way: a validator’s vote is itself a transaction that updates a vote account on-chain, and its stake is tracked in a stake account. Consensus is not a separate subsystem bolted to the side — it runs through the same state machine it secures.

The first concrete question is the simplest one: before anyone can vote on a block, someone has to produce it — so who leads which slot, and how does the network know in advance? Start with Stake and the Leader Schedule.

Check your understanding

1. PoH gives every validator a shared, verifiable clock and an ordered stream of transactions. Why is that not enough to constitute consensus — what question does it leave open?
2. Name the three separate jobs Solana keeps distinct, the mechanism responsible for each, and the one-word question each answers.
3. State this part’s central thesis in one sentence, and explain why a shared PoH clock makes BFT voting cheaper than a classical BFT protocol.
4. In one line each, what does the leader schedule page, the fork-choice page, and the optimistic-confirmation page each contribute to the story of a single slot’s life?
5. The part’s thread asks what makes switching forks expensive. Explain the two-sided danger: what goes wrong if that cost is too low, and what goes wrong if it is too high?

Show answers

1. PoH proves the internal order and timing of events within a stream, but it cannot decide which stream is canonical when two leaders produce competing forks at the same slot, nor whose opinion counts when validators disagree. Both forks can be internally well-ordered and still conflict — choosing between them, safely against a Byzantine minority, is the consensus problem PoH leaves open.
2. Proof of Stake answers who has influence (voting power ∝ staked SOL — the Sybil defense). Proof of History answers when things happened (a verifiable clock fixing order and timing). Tower BFT answers which fork wins (a stake-weighted BFT vote run on top of the clock that converges the network and eventually makes a fork irreversible).
3. Thesis: PoH-as-a-clock is what makes BFT voting cheap enough to run at hardware speed. Classical BFT spends rounds of messages negotiating order and timestamps; because every validator already shares the same verifiable PoH clock, that negotiation is unnecessary — validators only broadcast which fork they vote for (with an exponential lockout), turning a multi-round conversation into a cheap broadcast.
4. Leader schedule: the slot was assigned to a specific validator in advance, by stake, using the PoH clock. Fork choice: when that slot’s block competed with rivals, the network picked the fork with the most stake-weighted votes behind it. Optimistic confirmation: the block became “very probably settled” within a fraction of a second, well before it was provably irreversible (finalized/rooted).
5. If switching forks is too cheap, validators keep hopping between forks and the network never converges on one history — no single state machine. If it is too expensive, an honest network partition can lock validators onto a fork that turns out to lose, stranding their stake and stalling progress — a liveness failure. Tower BFT’s exponential lockout is the dial chosen to sit between those two failure modes.