Proof of History: Scheduled Turns Instead of Races
Replace the race to produce with a verifiable clock that pre-schedules every turn.
- Difficulty
- Expert
- Time to result
- ~months to results
- Steps
- 6
- Confidence
- 90%
Blockchains that let producers race to publish create ties, forks, and a resolution delay — the same interference problem two radio towers have when they transmit at once. Proof of History removes the race by manufacturing verifiable time: a pre-image-resistant hash run slowly, recursively, on a single core, so the number of iterations proves that real time elapsed. Because every participant can verify that clock independently, block-production slots can be scheduled in advance rather than won. Producers no longer negotiate round by round over whose turn it is; they transmit inside their assigned window and forfeit it if they miss. The synchronization overhead that dominates classical Byzantine-fault-tolerant systems disappears, and throughput becomes a hardware question instead of a consensus question.
Origin
Yakovenko describes two coffees, a beer, and a 4am eureka while at Dropbox: run the same hash function used in proof of work slowly and recursively on a single thread, and it proves elapsed time. Tying that to the time-division multiple access scheduling he knew from Qualcomm radio work took months more with the engineers he recruited.
Core principles
- 01Contention is a cost you pay every round; scheduling pays it once.
- 02A problem that looks new is usually an old problem in a new domain.
- 03If two participants can act simultaneously, you have built a tie-breaking problem.
- 04A clock only helps if every participant can verify it without trusting its owner.
- 05Forfeiting a missed turn is cheaper than renegotiating whose turn it was.
How to run it
- 1
Name the contention you pay for every cycle
Identify the moment where two or more participants can legitimately act at the same instant. In a proof-of-work chain that moment is two blocks produced simultaneously, which forks the chain and forces someone downstream to pick.
Pro tip Measure how much of your cycle time is resolution rather than work — that number is your headroom.
- 2
Find the older domain that already solved it
Contention over a shared channel is not new. Two radio towers transmitting on the same frequency interfere and produce noise, and the fix was to give each tower a synchronized clock and alternate.
Pro tip Look for fields where the constraint was physical and therefore forced an honest solution decades ago.
Watch out Transplanting the vocabulary without the mechanism gets you an analogy, not a design.
- 3
Build a clock anyone can verify
Take a pre-image-resistant hash and run it recursively on a single core, single thread. The output chain proves a minimum amount of real time passed, and any observer can check it without trusting the producer.
Pro tip Sequentiality is the whole point: the function must resist parallelization or hardware buys you time.
Watch out A clock that a well-funded participant can run faster reintroduces the race you just removed.
- 4
Pre-assign slots against the clock
Once time is verifiable, assign each participant a window in advance. Nobody has to ask whose turn it is because the schedule was derivable before the round began.
Pro tip Publish the schedule far enough ahead that participants can pre-position data and connections.
- 5
Make a missed turn forfeit, not renegotiated
If a participant does not act inside its window, the slot passes on automatically. This is the difference between a turn-based system and a scheduled one, and it is where the speed comes from.
Pro tip Treat forfeiture as normal operation, not an error path worth alerting on.
Watch out Adding a recovery round 'just in case' restores the per-round synchronization cost you eliminated.
- 6
Re-measure and chase the new bottleneck
With ordering resolved, the limit moves to bandwidth, cores, and I/O. Re-benchmark honestly and point the next round of optimization at whatever the hardware now constrains.
Pro tip Write down the theoretical hardware ceiling so you know how much of it your software is actually using.
In the wild
Classical Byzantine-fault-tolerant systems work like a meeting: one participant speaks, everyone checks that they spoke, then the next participant gets a turn after those checks clear. Yakovenko's scheduled version behaves like a button passing automatically between windows in a video call — if you do not speak in your moment, you cannot speak, and the button moves on. Removing the per-step check-in is what he credits for Solana running faster than Tendermint and the other proof-of-stake networks, with benchmarks around 50,000 transactions per second and peaks over 65,000.
→ Consensus overhead stopped being the limiting factor; bandwidth and hardware became the ceiling instead.
The transplant source: early radio towers sharing a frequency interfered with each other and produced noise. Rather than build ever-better interference resolution, engineers gave every tower a tightly synchronized clock and alternated transmission windows so no two towers ever overrun each other. The same pattern carries voice traffic on cellular networks.
→ A shared, contended channel carries many independent streams cleanly because ordering was decided before transmission, not during it.
Common mistakes
Building the clock to run as fast as possible
The instinct from proof of work is to parallelize and finish first. Here speed is the failure mode — the function must be deliberately slow and sequential, or extra hardware buys an unfair share of time.
Keeping a fallback voting round
Teams often schedule slots but retain a consensus round to handle misses. That reintroduces the per-round synchronization cost and erases most of the throughput gain.
Assuming the old bottleneck was the only one
Removing ordering contention exposes bandwidth, core count, and I/O limits immediately. Teams that do not re-benchmark ship a scheduler and wonder why throughput barely moved.
Is it for you?
Best for
Engineers designing high-throughput distributed or real-time systems where ordering, not computation, is the bottleneck.
Not ideal for
Systems whose entire value proposition is objective, from-scratch verification by any newcomer with no trusted starting point.
From the transcript
“So the first optimization that anyone's ever tried is why don't we give each tower a very synchronized clock and have them alternate?”
“You actually make that thing slow and recursive and force it to be running in a single core on a single thread in the computer.”
“And that difference between going from turn based to this scheduled system is why Solana is faster than Tendermint or all the other proof of…”
From the episode
Special: Solana (with CEO Anatoly Yakovenko)