Why Ordering Is Expensive

The part overview promised that Solana’s headline trick is a clock made of hashes. Before we build one, we have to earn it: you should feel, in your bones, why a fast global machine cannot afford to ask what time it is. This page is the problem statement. The next four pages are the answer.

The whole book turns on one question — how do you build a single global state machine that runs at hardware speed without falling apart? A state machine is just a starting state plus an ordered list of operations. Everyone who replays the same operations in the same order lands on the same state. So the entire game reduces to one deceptively simple prerequisite: everyone must agree on the order. This page shows that agreeing on order is, on its own, expensive — and that the expense is a conversation. Kill the conversation and you unlock the throughput the rest of the book chases.

Order is the only thing that matters

Two operations, applied to the same balance:

   op A:  "set balance = 100"
   op B:  "balance = balance * 2"

   A then B  →  200   (set 100, then double)
   B then A  →  100   (double first — but A overwrites it, so B is lost)

The operations are identical. The inputs are identical. Only the order differs, and the final state differs completely. This is not a contrived edge case — it is the defining property of shared mutable state. A blockchain is a replicated state machine: thousands of validators each hold a copy of the ledger and each replay the same transactions. If two honest validators disagree about whether Alice’s transfer happened before or after Bob’s, they compute two different ledgers, and the network has forked — it is no longer one machine.

So “build one global machine” is really “make every validator agree on one total order of transactions.” Everything else — signatures, execution, fees — is downstream of that. The hard part is that the machines are spread across the planet and do not trust each other.

There is no clock you can trust

The intuitive fix is: timestamp everything. Each transaction carries the time it arrived; sort by timestamp; done. In a single computer this works. Across a distributed system it collapses, for two independent reasons.

Clocks drift

Every machine has its own physical oscillator, and no two run at exactly the same rate. A cheap quartz clock drifts by seconds per day; even machines synced with NTP disagree by milliseconds, and NTP itself can be delayed, jittered, or briefly wrong. At sub-second block times, a few milliseconds of disagreement is enough to flip the order of two transactions. There is no shared physical “now” that all validators can read — only a scatter of slightly-wrong local clocks.

   node A's clock:  10:00:00.014
   node B's clock:  10:00:00.009      same instant, three readings,
   node C's clock:  10:00:00.021      three different "times"

You cannot sort a global ledger by a quantity that every node measures differently.

Any node can lie

Drift is the honest failure. The deeper problem is adversarial. A timestamp is just a number a node writes into a message — nothing stops a node from writing whatever number it likes. A validator that sees Alice’s transaction at 10:00:05 can claim it saw it at 10:00:00, to shove Alice ahead of a competing trade. In a system where money is at stake, “when did you see this?” is answered by economically motivated liars.

   reality:   node saw tx at 10:00:05
   message:   "I saw tx at 10:00:00"   ← costs nothing to forge

So a raw timestamp fails twice: honest nodes disagree by accident (drift), and dishonest nodes disagree on purpose (lies). We need order that does not depend on trusting anyone’s clock. Hold that thought — it is exactly the property the hash chain on the next page will deliver.

The classic fix: validators talk it out

If you cannot trust timestamps, the textbook distributed-systems answer is to vote on order by exchanging messages. This is the heart of every classical Byzantine-fault-tolerant (BFT) protocol — PBFT, Tendermint, HotStuff, and their kin. The mechanism, stripped to its skeleton:

1. A leader proposes a batch of transactions in some order.
2. Every validator broadcasts “I accept this order” (a vote) to the others.
3. Once a validator has heard a supermajority (more than two-thirds) agree, the order is committed — now permanent.

The magic of BFT is that it tolerates liars: as long as more than two-thirds of the stake is honest, the honest majority’s agreement pins the order down, and no minority of liars can rewrite it. This is a genuine, proven solution to the ordering problem. It works. The trouble is not correctness — it is cost.

The conversation is the bottleneck

Look at step 2. Every validator must hear from a supermajority of every other validator, for every thing they agree on. That is a lot of messages, and — more importantly — a lot of round-trips. A round-trip is a message out and a reply back across the physical network, and the speed of light does not negotiate.

   4 validators, everyone tells everyone:

        A ──────► B          messages ≈ N²
        A ──────► C          each commit waits for
        A ──────► D          a supermajority to REPLY
        B ──────► A          → multiple network round-trips
        B ──────► C            before order is final
        ... (12 arrows for N=4; 9,900 for N=100)

Two costs stack up:

• Message volume grows with the number of validators — naively on the order of N² for all-to-all voting. More validators means quadratically more chatter.
• Latency is bounded by round-trips. Even with infinite bandwidth, each commit must wait for messages to physically cross the network and come back — tens to hundreds of milliseconds per round, several rounds per commit.

Now put a throughput target on it. If ordering itself requires a multi-round global conversation for each batch, then your transactions-per-second is capped by how fast that conversation can complete — not by how fast your CPUs can execute. At a handful of transactions per second this is invisible. At the thousands per second Solana wants, the conversation is the wall you hit.

By the numbers — the round-trip tax

Say a cross-continent round-trip is ~150 ms, and a classical BFT commit needs a few communication rounds before an order is final. Then the ordering step alone imposes a floor on finality:

   1 round-trip           ≈ 150 ms
   ~3 rounds per commit   ≈ 450 ms   ← latency floor, before any execution

   if a batch cannot finalize faster than ~450 ms,
   and each batch is one "step" of the machine,
   ordering throughput is bounded no matter how fast the CPUs are.

These figures are illustrative, not a benchmark of any specific protocol — the durable point is the shape: latency is set by physics (round-trips), not by compute, and it does not fall when you buy faster machines. To go faster you must remove round-trips from the hot path, not add cores. That is the entire motivation for what comes next.

Three jobs, kept separate

Here is where most explanations of Solana go wrong, so we will be precise. The conversation above is doing several distinct jobs at once, and the key insight of Proof of History is that these jobs can be unbundled. There are exactly three:

   ┌───────────────────────┬──────────────────────────────┬─────────────────────┐
   │ Sybil resistance      │ Ordering / timekeeping       │ Final agreement     │
   │ WHO has influence?    │ WHEN did things happen?      │ WHICH fork wins?    │
   ├───────────────────────┼──────────────────────────────┼─────────────────────┤
   │ Proof of Stake        │ Proof of History             │ a PoS BFT vote      │
   │ (staked SOL)          │ (a hash-chain clock)         │ ("Tower BFT")       │
   └───────────────────────┴──────────────────────────────┴─────────────────────┘

• Sybil resistance — who has influence? In an open network anyone can spin up a million fake identities. Something scarce must gate influence so votes cannot be faked by sheer numbers. Solana uses Proof of Stake: influence is proportional to staked SOL, which costs real money to acquire. (This is not what Proof of History does — a common myth.)
• Ordering / timekeeping — when did things happen? Given the honest participants, in what sequence did the transactions occur? This is the job the timestamp-and-vote conversation was doing, and the one PoH will take over.
• Final agreement — which fork wins? When two valid histories briefly exist, the network must converge on one. Solana settles this with a Proof-of-Stake BFT vote (Tower BFT) — but crucially, that vote runs on top of an ordering PoH already established.

Classical BFT tangles all three into one chatty protocol. That is why it is expensive: the round-trips that decide which fork wins also carry the burden of deciding in what order things happened. If you could split ordering out — make it something every node computes independently, with no messages — the remaining agreement vote would have far less to do.

The goal for the rest of this part

State it sharply, because the next pages are built to hit it exactly:

Make ordering a property you can read off the data alone — no round-trips — so that consensus starts from an already-ordered stream.

Instead of validators negotiating an order by talking, the leader produces a stream of transactions whose order is baked into the bytes. Any validator, handed that stream, can verify the order by itself, offline, with zero messages to anyone else. Ordering stops being a conversation and becomes a computation over data you already have.

If that is possible, the payoff is enormous. The expensive BFT conversation no longer has to establish order — it only has to vote on validity over a sequence whose order is already fixed and self-evident. We have taken the biggest job out of the hot path.

   classical:  receive txs ─► TALK to agree on order ─► execute
                                    ▲
                              round-trips here = the bottleneck

   Solana's goal:  receive txs ─► order is IN the data (no talk) ─► verify locally ─► vote on validity

Back to the throughline

Recall the book’s one question: a single global state machine at hardware speed. “Hardware speed” means the machine should be limited by how fast silicon can hash, sign, and execute — not by how fast packets can cross an ocean and come back. A chatty ordering step puts a network round-trip in the hot path of every step the machine takes, and network round-trips do not get faster when you buy a better CPU. They are governed by distance and the speed of light.

So the first thing a hardware-speed global machine must do is get the conversation out of the ordering path. Everything in this part — the hash-chain clock, mixing events in, ticks and slots, parallel verification — is one sustained answer to that single demand. On the next page we build the object that makes it possible: a clock made of hashes, a sequence that cannot be faked without doing the work, and whose order any node can check alone.

Check your understanding

1. Why is order — not the operations or their inputs — the thing that decides a state machine’s final state? Give the two-operation intuition.
2. Timestamping transactions fails in a distributed system for two independent reasons. Name both, and say which one is the adversarial failure.
3. The classical fix (BFT-style voting on order) is correct and tolerates liars. So what exactly is wrong with it, and why does the problem get worse as you add validators?
4. Distinguish the three jobs — Sybil resistance, ordering/timekeeping, and final agreement — and say which mechanism Solana assigns to each. Which one is PoH?
5. State the goal for the rest of this part in one sentence, and connect it to the book’s throughline about “hardware speed.”

Show answers

1. A state machine is a start state plus an ordered list of operations; the same operations in a different order produce different states. For example set balance = 100 then balance = balance * 2 yields 200, but the reverse order yields a different result — identical operations and inputs, different order, different final state. If validators disagree on order, they compute different ledgers and the network forks.
2. Clock drift — every machine’s oscillator runs at a slightly different rate, so honest nodes disagree about “now” by enough to flip the order of two transactions. Lying — a timestamp is just a number a node writes, so a node can forge it to reorder transactions in its favor. Lying is the adversarial failure; drift is the honest one.
3. It is correct but expensive: committing an order requires validators to exchange votes and wait for a supermajority to reply, which means multiple network round-trips per commit. Round-trip latency is set by physics, not compute, so it caps throughput regardless of CPU speed. It worsens with more validators because all-to-all voting scales roughly as N² in message volume.
4. Sybil resistance (who has influence) → Proof of Stake, gated by staked SOL. Ordering/timekeeping (when things happened) → Proof of History, a hash-chain clock. Final agreement (which fork wins) → a PoS BFT vote, Tower BFT, running on top of the PoH order. PoH is the ordering job only — not Sybil resistance and not fork choice.
5. Make ordering a property you can read off the data alone, with no round-trips, so consensus starts from an already-ordered stream. This serves “hardware speed” because a chatty ordering step puts a network round-trip — bounded by the speed of light, not by silicon — into the hot path of every step, so removing the conversation lets the machine run as fast as its hardware can hash, sign, and execute.