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.
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.
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.
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.