Proof of History — The Clock

This whole book chases 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 thing that takes an ordered list of inputs and applies them one by one. So before you can run anything fast, you have to answer a smaller, nastier question first — in what order did the inputs arrive? On one computer that is free: there is one clock, one queue, one truth. Across thousands of machines that mutually distrust each other, it is the single most expensive thing in the system.

This part is about Solana’s answer to that ordering problem: Proof of History, a verifiable clock built from nothing but a hash function called over and over. It is the first of the three pillars that let Solana push tens of thousands of transactions per second, and it is the one people misunderstand most — so we build it from the ground up, in code, until there is nothing left to hand-wave.

The core claim, stated plainly

Proof of History is not consensus. It does not choose who is right, it does not resist Sybils, and it does not decide which fork wins. All it does is stamp events into a provable, tamper-evident order — before any voting happens. Say it as a slogan and keep it in your head for the whole part:

Proof of History orders events. Consensus agrees on them. Those are two different jobs, and PoH does the cheap one first.

Every other high-throughput chain pays for ordering with conversation: validators exchange messages — “when did you see this transaction?” — until they agree on a sequence. At a few hundred transactions per second that chatter is tolerable. At the rates Solana targets, it is the bottleneck that eats the whole machine. PoH removes the conversation entirely by turning “what time is it, and in what order did these happen?” into a fact you can read off the data alone, on your own hardware, without asking anyone.

The mechanism in one paragraph

Take SHA-256 and feed its output back into itself: h = sha256(h), forever. Because the hash is pre-image resistant, the only way to know the value after N iterations is to actually compute all N of them in sequence — you cannot skip ahead and you cannot split the work across cores. So the chain is a count of real elapsed work: a clock that ticks once per hash and cannot be fast-forwarded. To stamp an event into that timeline, you mix it in — do one hash over sha256(state || event) instead of over the state alone. Every later hash now depends on that event, so it is provably after everything before it and before everything after it. Order is established by construction. And here is the payoff: producing the chain is strictly sequential, but verifying it is embarrassingly parallel, because each recorded checkpoint pins the hash a verifier needs to check its segment independently. Slow to build, fast to check — that asymmetry is the entire trick.

   genesis ─►(tick)─►(tick)─►(record A)─►(tick)─►(record B)─►(tick)─►
                                 ▲                    ▲
                           A sealed here        B sealed here, after A
                           (its position is baked into every hash that follows)

Roadmap for this part

Read these in order. They walk from why ordering is expensive to why a clock buys you throughput — building and verifying a real hash-chain clock in the middle.

#	Page	The one-line takeaway
2	Why Ordering Is Expensive	There is no trustworthy global clock across distrusting machines, so classic systems buy order with rounds of messaging — the bottleneck PoH exists to remove.
3	A Clock Made of Hashes	`h = sha256(h)` iterated cannot be precomputed or parallelized, so a hash count is a forgery-proof measure of elapsed, sequential time.
4	Stamping Events Into Time	Mixing an event in as `sha256(state \|\| event)` seals its position; reordering or moving it breaks every hash that follows.
5	Ticks, Slots, and Hashes-per-Tick	Bare `tick`s give the chain a steady cadence; calibrating hashes-per-tick makes the stream track wall-clock time and defines slots.
6	Verifying the Clock in Parallel	Verification does the same total work as production but splits across cores, because each `Entry` pins its own boundary hash — the asymmetry that makes PoH pay off.
7	Order First, Vote Second	With order established cheaply by PoH, consensus only has to vote on validity, not negotiate sequence — decoupling that keeps the pipeline fed at high TPS.
900	Revision — The Clock	The whole part recapped in one pass: ordering problem → hash clock → recording → cadence → parallel verify → clock-before-consensus.

The grounding code

You do not have to take any of this on faith. This part is built around a small, real Rust crate you can read and run: rust/solmini/src/poh.rs. It is under 250 lines and implements the entire clock — tick, record, verify, and the Entry checkpoint type — with unit tests that prove the three properties that matter: a clean chain verifies, flipping one byte of any recorded hash is caught, and swapping two events fails to verify. When a page shows a snippet, it is lifted from that file, not invented for the page.

// The heart of it, from rust/solmini/src/poh.rs:
pub fn hash_once(h: &Hash) -> Hash { sha256(h) }              // a bare tick
pub fn hash_with(h: &Hash, mix: &Hash) -> Hash {              // a tick that folds an event in
    let mut hasher = Sha256::new();
    hasher.update(h);
    hasher.update(mix);
    hasher.finalize().into()
}

If you prefer to learn by building it yourself, the same clock is constructed step by step in the companion Rust Playbook, Project 7 (p7-solana), especially Day 27 · Proof of History, which sits between the throughput problem (Day 26) and the account model (Day 28). This part is the conceptual treatment; that day is the hands-on one. They cover the same code from two angles.

A hash count only becomes a time once you fix the machine. On reference hardware a core computes on the order of a few million SHA-256 hashes per second — the exact rate swings with the chip and whether SHA hardware extensions are used, so treat the figure as illustrative:

   elapsed ≈ hash_count / hashrate

   2,000,000 hashes / 2,000,000 hashes-per-sec  ≈  1 second

On its own, “190 hashes since genesis” is not a duration. But on a known machine the count converts directly to time — and more importantly it gives every event a precise, forgery-proof ordinal position, which is the part order-before-consensus actually needs. Solana calibrates hashes-per-tick so the tick stream tracks real time; slot targets in the ~400 ms range have been used. Treat those exact parameters as version-dependent — the durable fact is count ⇒ order, and roughly ⇒ time.

The thread

Everything in this part turns on one distinction: sequential work versus parallelizable work. PoH is valuable precisely because producing the clock is sequential (so its length is honest proof that time passed) while verifying it is parallel (so the whole network can check it cheaply). Hold that asymmetry in mind as you read — and notice that later parts of Solana’s design flip it on purpose: when execution finally runs, Solana wants transactions that don’t depend on each other, so it can run them in parallel. PoH makes production serial so time is trustworthy; Sealevel makes execution parallel so throughput is high. Same distinction, used in opposite directions. That is the shape of the whole machine.

Check your understanding

State the book’s throughline in your own words, then explain why “in what order did the inputs arrive?” is the first problem a global state machine has to solve.
The part’s core claim is that PoH is “not consensus.” What job does PoH actually do, and what job is left for consensus?
Why can the production of a PoH chain not be parallelized or precomputed, and why does that make a hash count a measure of elapsed time?
What does “mixing an event in” compute, and what does that guarantee about the event’s position relative to everything before and after it?
The part promises that verifying the clock is cheap even though building it is slow. In one sentence, what makes verification parallelizable given that each checkpoint records its own ending hash?

Show answers

The throughline is: how do you build a single global state machine that runs at hardware speed without falling apart? A state machine applies an ordered list of inputs one at a time, so before anything can run you must know the order the inputs arrived in. On one computer that is free (one clock, one queue); across thousands of distrusting machines it is the most expensive thing in the system, so it must be solved first.
PoH’s only job is to stamp events into a provable, tamper-evident order (a verifiable clock). It is not consensus, not Sybil resistance, and does not pick forks. Consensus (PoS / Tower BFT) does the remaining job: agreeing on which ordered history is valid and final. PoH does the cheap ordering job first so consensus only has to vote on validity, not negotiate sequence.
Each hash takes the previous hash as its input (h = sha256(h)), forming a strict dependency chain, so extra cores cannot help and you cannot compute a future value without doing every step in between. Because each hash costs a roughly fixed time on a given machine, the number of hashes performed is proportional to the real time that elapsed.
It computes sha256(state || sha256(event)) — one hash that folds the event into the rolling state. From that point on every hash depends on the event, so the event is provably after everything earlier and before everything later; its position is fixed by construction and cannot change without redoing all subsequent work.
Each checkpoint (Entry) records its own ending hash, which is exactly the starting hash of the next segment — so a verifier already knows the start and claimed end of every segment and can recompute each one independently on a different core.