Crypto Newbie / Simulators / Proof of History
Proof of History Simulator — Solana's Verifiable Clock
Solana is the only major chain using Proof of History — a pre-consensus mechanism that timestamps transactions BEFORE validators vote on them. The chain is a sequential SHA-256 hash chain where each step depends on the previous. Two key properties: building the chain MUST be sequential (no parallelism), but VERIFYING any tick can be done independently in parallel. This is what lets Solana skip the negotiation phase most other chains spend block time on.
Chain configuration
Embedded events
Chain (showing first 30 ticks + events)
| Tick | Hash | Event |
|---|---|---|
| 0 | e1b8c4fe | — |
| 1 | ee444bbf | — |
| 2 | c0c995d5 | — |
| 3 | 01c00217 | — |
| 4 | aa2e0a03 | — |
| 5 | 89e29d94 | tx: alice→bob 10 SOL |
| 6 | 68bb8395 | — |
| 7 | 89f85bf8 | — |
| 8 | 9079c315 | — |
| 9 | a32ee400 | — |
| 10 | b45beed1 | — |
| 11 | 76a4b9bd | — |
| 12 | 2ec42aaa | tx: carol→dave 0.5 SOL |
| 13 | d0423d30 | — |
| 14 | 2dc3511b | — |
| 15 | 6a8f8d18 | — |
| 16 | 106e048f | — |
| 17 | fb915dfb | — |
| 18 | 90118b7a | tx: bob→eve 3 SOL |
| 19 | 9ccdfc78 | — |
| 20 | 34f250c2 | — |
| 21 | 04488aaa | — |
| 22 | c45a4788 | — |
| 23 | bb4eda75 | — |
| 24 | 3bf7af2d | — |
| 25 | 177e20e2 | — |
| 26 | 842ee0e4 | — |
| 27 | d82e6468 | — |
| 28 | 3f0421c8 | — |
| 29 | 6bf667fe | — |
Verify a single tick (parallel-safe)
You only need the predecessor hash + event data — no need to recompute the whole chain.
✓ Hash verifies against previous tick + event data.
Tamper test
The sequential-build, parallel-verify duality
To produce tick[N], a node must have already computed tick[N-1]. There's no way to parallelise — each hash takes some real time, and you can't get to tick[100] without doing 99 hashes first. But to VERIFY tick[100] given the chain, you only need tick[99]'s hash plus any data inserted at tick[100]. You don't need to recompute the chain. This means the chain itself encodes real elapsed time (verifiable), while verification scales horizontally.
Embedding transactions as events
When a Solana validator wants to log 'transaction X happened around now', they don't try to negotiate a timestamp with other validators. They just insert the transaction's hash into the next PoH tick. Now the transaction is provably ordered relative to every other event in the PoH chain — without consensus rounds, without timestamp arguments. The simulator above shows this: add events at specific tick numbers, see them embedded in the hash chain.
Why PoH lets Solana parallelise consensus
Other chains (Bitcoin, Ethereum, Tendermint) bundle two things into block production: (1) what transactions go in, (2) what order they go in. Negotiating order takes communication rounds. Solana decouples these: PoH establishes order continuously, and consensus only needs to confirm 'which PoH chain is canonical'. Validators can now run consensus in parallel with PoH stream production, achieving the 400ms block times that everything else uses just to negotiate.
The tamper-detection property
Try the tamper test in the simulator: change one event's data after the chain is built. The single tick's hash no longer verifies. But the downstream hashes (computed before the tamper) STILL match each other — because we didn't rebuild them. A verifier walking from genesis spots the discrepancy at the exact tick. This is why PoH is 'verifiable': any divergence from the canonical chain is immediately localised.
Frequently asked questions
+Is PoH a consensus mechanism on its own?
No. PoH is a pre-consensus PRIMITIVE that establishes verifiable ordering. Solana then runs Tower BFT (a PoS-based consensus) on top of PoH to agree on which PoH chain is canonical. Bitcoin uses PoW for both ordering and consensus; Solana separates the concerns — PoH for ordering, Tower BFT for agreement.
+Why don't other chains use PoH if it's so good?
Three reasons: (1) PoH requires sequential hashing at very high rate — Solana validators need beefy hardware to keep up. (2) PoH centralises the leader role (whoever's currently building the PoH stream has temporary power to censor or reorder). (3) The whole 'parallel verification' benefit only pays off if your bottleneck was ordering negotiation — for chains that aren't trying to hit 60k TPS, the complexity isn't worth it.
+Does PoH need expensive hardware?
Yes. To produce a fast PoH stream, the validator needs the latest CPUs with fast SHA-256 acceleration. Solana validator hardware specs are higher than most chains: 256GB RAM, latest-gen CPU, NVMe storage. This is why Solana has ~2000 validators vs Ethereum's ~1M — the hardware barrier is real.
+Why does the simulator use FNV-1a instead of SHA-256?
Pure pedagogy. FNV-1a is fast, deterministic, and synchronous in JS — easy to demo in a browser. SHA-256 (what real Solana uses) is more secure but slower. The mathematical properties (sequential build, parallel verify, tamper detection) are identical between the two; we just use the simpler hash for visualisation clarity.
+What happens if a PoH leader misbehaves?
Tower BFT (Solana's consensus on top of PoH) detects when a leader's PoH stream diverges from canonical and votes against it. The leader rotation means no single validator holds the PoH role for long. If a leader skips their slot or produces an invalid stream, the next leader takes over from the last valid tick. Long-running deception requires colluding leaders — which Tower BFT's slashing economics make expensive.