Order First, Vote Second

The previous page established the asymmetry that makes Proof of History pay off: producing the chain is strictly sequential, but verifying it splits across cores because every Entry pins its own boundary hash. That is a nice property of a data structure. This page is where the property turns into throughput.

The whole part has been building one machine — a clock made of hashes — so that we could now claim the thing the part exists to prove: ordering, which on every other high-throughput chain is a chatty negotiation between validators, becomes a fact you read off the data. Once that is true, the expensive conversation disappears from the hot path, and the single global state machine can be fed at hardware speed. Let us make that precise.

The pipeline: record as you receive, broadcast, verify in parallel

Here is the leader’s job in three moves. It is doing nothing you have not already seen — tick and record from the companion crate — but now aimed at live traffic.

1. Transactions arrive at the current leader over the network, in some receipt order.
2. The leader records each one into the PoH chain as it arrives — one record call folds the transaction (reduced to a 32-byte mixin) into the rolling hash state, sealing it into a fixed position. Between bursts it emits bare ticks so the clock keeps a steady cadence.
3. The leader broadcasts the resulting Entry stream to every other validator.

   incoming txs:   tx1   tx2        tx3  tx4 tx5
                    │     │          │    │   │
   leader (PoH):  ─►rec──►rec──tick──►rec─►rec─►rec──tick──►  (one core, sequential)
                    │     │          │    │   │
   entries:       [E1]  [E2]  [Et]  [E3][E4][E5] [Et] …
                    │
                    └──────────── broadcast to all validators ──────────────►

   validator A:   verify E1│E2│Et│E3│E4│E5│…   ┐
   validator B:   verify E1│E2│Et│E3│E4│E5│…   ├─ each locally, in parallel,
   validator C:   verify E1│E2│Et│E3│E4│E5│…   ┘  no messages between them

Read the bottom three rows carefully, because that is the punchline. Validators A, B, and C never talk to each other to agree on the order of tx1..tx5. They do not need to. The order is inside the entries: tx1 was mixed in before tx2, which is before tx3, and any attempt to move one breaks every hash after it (that is the reordering property we proved in code). Each validator replays the stream on its own cores, confirms every recorded hash, and arrives at the exact same sequence the leader produced — independently, from the data alone.

What a record call actually stamps

The mixin the leader folds in is a hash of the transaction (in real Solana, of a batch of them), not the raw bytes on the wire. From the crate:

// From rust/solmini/src/poh.rs — the leader's inner loop, conceptually:
let entry = poh.record(n_hashes, &transaction_bytes);
//          │          │           └─ reduced to sha256(tx) and mixed into the last hash
//          │          └─ n-1 bare ticks, then one mixing hash
//          └─ returns { num_hashes, hash, mixin: Some(sha256(tx)) }
broadcast(entry);

The Entry carries everything a verifier needs: how many hashes since the last checkpoint, the resulting hash, and the mixin. Nothing about who saw the transaction when travels with it, because that question no longer has to be answered by agreement — it is answered by position in the chain.

The expensive step that disappears

To see the win, name precisely what is being removed. On a chain that orders by consensus, before a block can be agreed, validators run a sub-protocol whose entire purpose is to agree on sequence and timing: which transaction came first, and roughly when did each of us see it? That sub-protocol is rounds of messaging — proposals, votes, timeouts — and its cost grows with both the number of validators and the transaction rate. Why Ordering Is Expensive is the whole story of why: there is no trustworthy global clock across distrusting machines, so they buy one with conversation.

Proof of History deletes that conversation from the hot path. Not optimizes — deletes. There is no round of “what time did you see this?” because the leader already answered it, unforgeably, by stamping each transaction into a position that every validator can verify without asking anyone.

   Order-by-consensus (per batch):
       recv txs ─► [round: propose order] ─► [round: vote on order] ─► ... ─► agreed order ─► execute
                    └──────────── O(validators) messages, repeated per batch ───────────┘

   Order-by-PoH:
       recv txs ─► leader records into PoH ─► broadcast entries ─► each validator verifies locally ─► order known
                    └───────────────────── zero inter-validator ordering messages ─────────────────┘

The bottleneck did not move to a faster machine or a cleverer protocol. The problem class changed: ordering stopped being a distributed-agreement problem and became a local-verification problem. Local verification parallelizes across your own cores (last page); distributed agreement does not parallelize away, because its cost is the coordination.

By the numbers — where the messages went

Consider a naïve all-to-all ordering round among N validators: every validator sends its view to every other, which is on the order of N² messages per batch you want to order. Push the batch rate up and that term dominates.

   order-by-consensus:   messages_to_order ≈ N² per batch  ×  batches per second
   order-by-PoH:         messages_to_order  = 0            (order is in the broadcast data)

With PoH the leader still broadcasts the entries — that bandwidth does not vanish — but the coordination messages whose only job was to agree on sequence drop to zero. Validators do more local hashing instead, and local hashing is exactly the work that splits across cores. Treat N² as the illustrative worst case; real BFT protocols do better than naïve all-to-all, but the point stands: the term that grew with both N and batch rate is gone from the ordering step.

The decoupling: PoH orders, consensus votes

This is the sentence to carry out of the whole part, so we state it flatly:

PoH is not the vote. It orders events cheaply and first. Then consensus votes on validity, second.

It is easy to hear “Proof of History” and slot it next to “Proof of Work” and “Proof of Stake” as a third way to pick who is right. It is not. PoH decides nothing about validity, honesty, or which fork wins. It answers exactly one question — in what order did these events happen? — and it answers it before any voting starts. Solana still needs a real consensus mechanism for the questions PoH refuses to touch:

• Is this transaction valid? (Signatures, balances, program rules — that is the runtime’s job, checked by every validator.)
• Which fork is canonical, and when is it final? (That is Proof of Stake and Tower BFT — validators stake and vote to converge on one history and finalize it.)

Because PoH already fixed the order, those votes are cheaper and simpler. A validator voting in Tower BFT is not arguing about sequence — sequence is settled, verifiable, identical for everyone. It is voting on which already-ordered fork to commit to. We split one hard, chatty problem (“agree on a valid ordering”) into a cheap one done by construction (“order”) and a smaller one done by voting (“validity and finality”).

   ┌──────────────────────────── one commit's journey ────────────────────────────┐
   │  ORDER  (PoH, cheap, no votes)          VOTE  (PoS / Tower BFT, on validity)  │
   │  leader stamps tx into the chain  ──►   validators vote on the ordered fork   │
   │  everyone verifies order locally        → converge on one history, finalize   │
   └───────────────────────────────────────────────────────────────────────────────┘

That split is the point of the part. Removing the ordering conversation from the hot path is a large part of how one chain keeps a hardware-speed pipeline fed: the scarce, un-parallelizable resource — cross-network agreement — is spent only on the questions that genuinely need a vote, not on the clock.

Under the hood — what “the leader” implies, and the trick it unlocks

There is a quiet dependency in everything above: for the leader to stamp transactions into the chain, everyone has to know who the leader is for this stretch of time. Solana gets this for free from the clock. Because PoH gives the network a predictable cadence — ticks group into slots at a known rate (Ticks, Slots, and Hashes-per-Tick) — the protocol can publish a leader schedule in advance: validator X leads slots 100–103, validator Y leads 104–107, and so on. The clock is what makes “slot 104” a thing everyone agrees on without asking.

A known schedule pays off downstream in a way that matters for throughput. If every node knows who will lead next, a node holding a transaction does not have to wait and broadcast blindly — it can forward the transaction ahead of time, directly to the upcoming leader, so the transaction is already queued at the machine that will stamp it the moment its slot opens. In Solana this is roughly what the transaction-forwarding path does: the predictable schedule turns “flood the network and hope” into “hand it to the next leader.” We do not build that mechanism in solmini — it lives further down the validator pipeline — but notice the chain of consequences: a verifiable clock ⇒ a predictable cadence ⇒ a known leader schedule ⇒ transactions delivered just-in-time to keep the pipe full. Each throughput trick in later parts pulls on this thread.

It actually happened — a stalled clock stalls everything downstream

The flip side of “order first” is a hard dependency: if the clock does not advance, nothing after it can proceed. On September 14, 2021, Solana mainnet-beta halted for roughly 17 hours. A flood of transactions (bot traffic around a token launch) overwhelmed the leader pipeline; forwarded transactions piled up faster than leaders could process them, validators fell out of consensus, and the network could not agree to keep producing slots until operators coordinated a restart.

The lesson for this page is not that PoH failed — the clock mechanism is not what broke. It is that decoupling ordering from voting does not make the pipeline behind it infinite. PoH removes the ordering conversation, which lets the leader stamp transactions extremely fast; but a leader that is handed more than it can ingest still backs up, and everything downstream — voting, finality — stalls with it. Order-first buys enormous headroom; it does not repeal the need to shed load when the firehose exceeds the machine. Later reliability parts return to exactly this.

The architect’s lens

• Why does it exist? To move ordering off the network’s slow, coordination-bound path and onto each validator’s fast, local, parallel path — so the scarce resource (cross-machine agreement) is spent only where a vote is genuinely required.
• What problem does it solve? The per-batch, O(N²)-ish messaging tax that a distributed system otherwise pays to agree on sequence and timing before it can commit anything. With PoH that tax on ordering drops to zero.
• What are the trade-offs? You accept a single sequential leader stamping the clock (production cannot be parallelized) and a hard dependency on that clock advancing. In exchange you get order-by-construction that every validator verifies without a conversation. When the leader is healthy this is a huge win; when it is overloaded, everything behind it waits.
• When should I avoid it? When your throughput target is low enough that ordering-by-messaging is not the bottleneck, or when you cannot tolerate the liveness dependency on a leader-driven clock. A few hundred transactions per second do not need this machine; the design earns its keep only at rates where the ordering conversation would dominate.
• What breaks if I remove it? Ordering goes back to being a distributed-agreement problem: validators must exchange rounds of messages to agree on sequence before every commit, consensus votes now have to negotiate order and validity together, and the pipeline can no longer be fed at hardware speed because the clock is once again a conversation.

Check your understanding

1. Walk the leader’s pipeline in three steps, and explain in one sentence why the validators at the bottom of the diagram never message each other about order.
2. Name precisely the expensive step PoH removes from the hot path. Why does that step’s cost grow with both the validator count and the transaction rate?
3. The page insists “PoH is not the vote.” What two questions does PoH refuse to answer, and which mechanism answers each?
4. Restate the “order first, vote second” decoupling in one sentence, and explain why the votes that remain are cheaper than they would be without PoH.
5. Trace the chain from “verifiable clock” to “transactions forwarded ahead of a leader’s slot.” What intermediate property makes that forwarding trick possible?

Show answers

1. (a) Transactions arrive at the leader in receipt order; (b) the leader records each into the PoH chain as it arrives, sealing it into a fixed position, ticking between bursts; (c) the leader broadcasts the resulting Entry stream. Validators never message each other about order because the order is inside the entries — each transaction’s position is baked into every subsequent hash, so each validator replays and verifies the same sequence locally, from the data alone.
2. It removes the inter-validator messaging that agrees on the order and timing of transactions — the “what time did you see this?” rounds that must complete before a batch can be committed. Its cost grows with the validator count (more parties to hear from, on the order of N² messages in the naïve case) and with the transaction rate (the ordering round repeats per batch), so both terms multiply.
3. PoH refuses to answer (a) is this transaction valid? — answered by the runtime, which every validator checks against signatures, balances, and program rules; and (b) which fork is canonical and when is it final? — answered by Proof of Stake and Tower BFT, where staked validators vote to converge on one history and finalize it. PoH only fixes order.
4. Order is established first and cheaply by PoH (by construction, no votes), and only then does consensus vote on validity and finality. The remaining votes are cheaper because sequence is already settled and identical for everyone — validators vote on which already-ordered fork to commit, not on what the order should be, so one hard chatty problem is split into a free one (order) plus a smaller one (validity/finality).
5. Verifiable clock ⇒ a predictable, steady cadence (ticks grouped into slots at a known rate) ⇒ a leader schedule published in advance so everyone knows who leads which upcoming slot ⇒ nodes can forward a transaction directly to the next leader ahead of its slot, so it is already queued when the slot opens. The intermediate property that unlocks it is the known-in-advance leader schedule, which only exists because the clock’s cadence is predictable.