Sign in

Proof of History

Most blockchains spend a lot of their throughput on the question "what time is it?" Validators have to agree on the order of events, and figuring that out usually means a lot of back-and-forth voting before any real work can land. Solana's answer is a clock that everyone can verify after the fact, without trusting anyone in particular. That clock is called Proof of History. Understanding what it is and what it is not is the last conceptual piece before code.

A tamper-proof stopwatch

Picture a notary in a small room with a stopwatch and a stack of paper. Every few seconds, the notary writes down a number, stamps it, and posts it on the wall. Each number is derived from the previous one in a specific way that takes a known amount of effort. Anyone who walks past the wall later can read down the list and verify two things: the numbers were produced in that exact order, and the gaps between them represent real elapsed time.

Proof of History is the digital version of that. There is no actual notary, only a hash function applied to its own output, over and over. Each output becomes the input to the next. The result is a long chain of hashes where every link can only have come after the link before it. The chain encodes time by representing the work that had to happen between one moment and the next, rather than by reading a clock.

This is what people mean when they call PoH a "cryptographic clock." The chain is the clock. Producing it costs measurable effort. Verifying that the effort happened costs almost nothing.

Proof of History is a hash chain tick 0 starting seed hash tick 1 8c4f... d2a1 hash tick 2 f0b3... 7e94 hash tick 3 2a17... c8e2 . . . producing the chain takes time you cannot skip Why this is a clock Each tick is one SHA-256 of the previous tick. A single CPU can do this around 10,000 times per millisecond. No shortcut exists. To reach tick N, you have to compute every step from 0 to N in order. If you see tick N, you know the work between tick 0 and tick N actually happened.

The hash function used is SHA-256, the same one Bitcoin uses for mining. The key property is that it has no known shortcut. Given an input, there is no way to compute the result faster than just running the function. And given a result, there is no way to compute an input that would produce it without trying inputs one at a time. To produce the chain, you must do the work. To reach tick a thousand from tick zero, you must compute every tick between them in order.

That property is what makes the chain a clock. A single computer running this loop will produce tick N after a measurable amount of time, and nobody, however well-funded, can cheat their way to tick N+1 ahead of schedule.

Slow to produce, fast to verify

The trick that makes Proof of History useful, rather than just expensive, is the asymmetry between producing the chain and verifying it.

Producing the chain is strictly sequential. The leader who is responsible for advancing the clock has to compute each tick from the previous one, on a single CPU core, one at a time. The next tick cannot start until the current tick is finished. This is the source of the "time" guarantee, since the only way to reach tick N is to spend the work between zero and N. Cores cannot help. Faster machines cannot help much. The chain advances at roughly the speed a single core can hash.

Verifying the chain is the opposite. To check that the chain is valid, you just need to confirm that each tick really is the hash of the previous one. That check is independent for every link. You can give a thousand different cores a different section of the chain, and they can all verify their slices at the same time. The whole chain gets verified in the time it takes the slowest core to finish its slice.

Slow to produce, fast to verify The leader produces the chain (sequentially) leader: → hash → hash → hash → hash → hash → hash → hash → ... one CPU core, one tick at a time cannot be parallelized: each tick depends on the previous one Everyone else verifies the chain (in parallel) validator A: checks ticks 0..999 on core 1 validator A: checks ticks 1000..1999 on core 2 validator A: checks ticks 2000..2999 on core 3 validator B: checks ticks 0..999 on core 1, in parallel verification is just "does hashing this input give the next output?" each section is independent, so any number of cores or machines can split the work a network of 1,000 validators can verify the chain 1,000 times faster than one CPU produced it This is the asymmetry the network depends on. One CPU labors. Thousands verify cheaply.

This is the whole engineering bet behind Solana's throughput. The leader doing the hard work of running the clock is a single machine. The rest of the network, hundreds or thousands of validators, can keep up with that machine because their job is cheaper than the leader's by orders of magnitude. The chain produces fast, the network verifies faster, and nobody has to vote on "what time is it" before any real work can happen.

Where transactions enter the picture

The clock by itself is just a sequence of hashes. To turn it into something useful, transactions get mixed into the chain as it advances. When a transaction arrives at the leader, the leader hashes the transaction's contents into the next tick along with the previous hash. Now the resulting tick depends on both the chain's history and that specific transaction. The transaction has a verifiable position on the clock: "this happened at tick N, between tick N-1 and tick N+1, no earlier and no later."

This is what the recent_blockhash field on every transaction refers to. The blockhash is a snapshot of a recent point on the PoH chain. Including it in the transaction proves the transaction was built after that point, which is what keeps old transactions from being replayed indefinitely. Once enough time has passed and the blockhash falls outside the validity window of about 150 slots, roughly a minute, the network rejects any transaction still referencing it.

Where PoH sits in Solana's block production 1. PoH ticks (the clock) The leader runs the hash chain continuously. Each tick is a verified moment in time. A new tick happens about every 6.25 microseconds. 2. Transactions get stamped into the chain As transactions arrive, the leader hashes their contents into the next tick. Now each transaction has a verifiable position: "this happened at tick N." 3. Ticks group into slots (the blocks) Every 64 ticks (about 400 ms) the leader produces a slot, which is Solana's block. The slot wraps everything the leader did during that window. 4. Validators vote (the actual consensus) A separate mechanism, Tower BFT, takes the slots and finalizes them into the canonical chain. PoH is the timestamps. Consensus is the agreement on which sequence of slots is the real one.

Every 64 ticks, the leader bundles up everything that happened in that window and produces a slot. A slot is what Solana calls a block. At roughly 400 milliseconds per slot, this is the production rate that gives Solana its reputation for fast block times. The blocks come fast because the clock advances fast, and the clock advances fast because verifying it is cheap.

What PoH is and is not

A common confusion is to call PoH "Solana's consensus mechanism." It is not. PoH is a clock. Consensus is the process by which validators agree on which version of history is the canonical one when multiple are possible. Those are different jobs.

Solana's consensus mechanism is called Tower BFT. It runs on top of PoH and uses the timestamps PoH provides to coordinate voting without the back-and-forth that other chains require. Validators see the same PoH chain everyone else sees, vote on which slots they believe are valid, and the network converges on a single canonical sequence. PoH speeds up consensus by removing one of the hardest parts of the problem, but it does not replace it.

A second confusion is to think PoH is what makes Solana secure. It does not. PoH does not protect against double-spends, censorship, or invalid state transitions. Those protections come from the consensus layer and the runtime's validation rules. PoH only protects against rewriting the order of past events, since rewriting would require redoing all the hash work between the rewritten point and the present.

In practice, almost nothing about your day-to-day Solana development depends on the internals of PoH. You include a recent_blockhash in every transaction. You see slots arrive at roughly 400ms intervals. You read confirmations from validators voting on those slots. The clock is in the background, doing its job, while you write programs that operate on accounts.