LibraryConsensus2018Design paperCorpus record
Solana: A new architecture for a high performance blockchain
Solana. Anatoly Yakovenko.
Yakovenko's design note for a ledger that encodes the passage of time as a verifiable hash chain, called Proof of History, so that validators spend less effort agreeing on order.
Solana's paper bets that a chain can order a firehose of transactions if every node shares a clock, built by hashing the passage of time, and if signature checks are done before the block is agreed.
The five-minute read
The clock is the product
Proof of History is a verifiable delay function used as a timestamp. A hash chain proves that a duration passed between two events, because the only way to produce it was to compute it in sequence.
Leaders still exist
The clock does not remove block production. A leader, scheduled in rotation, orders transactions and stamps them into the hash sequence. Other nodes verify the sequence instead of trusting the leader's word for time.
Gulf Stream and pipeline are about not waiting
The paper describes forwarding transactions to the expected next leader, and pipelining validation across hardware stages. Throughput in the paper is a pipeline claim, not a consensus theorem standing alone.
Tower BFT sits on the clock
Votes are lockouts that get longer as a node commits. The paper's bet is that a shared notion of time makes those timeouts meaningful. Without the clock, the voting story is an ordinary Byzantine protocol.
Hardware is not a footnote
The architecture assumes fast cores, many threads, and GPUs or equivalent for signature verification. A node that cannot keep the pipeline is not a slower honest node. It is outside the design.
One action, walked through
- A leader is scheduled for a slot from the stake-weighted rotation.
- Transactions arrive, often forwarded ahead of the slot, and are checked for signatures in a parallel stage.
- The leader sequences them and mixes their hashes into the ongoing Proof of History chain, so order and time are the same object.
- Verifiers recompute enough of the sequence to confirm the leader did not invent the timestamps, and they execute the transactions.
- Votes extend lockouts. A block becomes economically hard to reverse as the lockouts stack, under the paper's Tower rules.
The argument, unpacked
A clock is not consensus
Proof of History proves that time passed and that events were ordered inside one leader's sequence. It does not, by itself, decide which leader you should believe if two leaders speak. That decision is the voting protocol. Slides that call the hash chain 'the consensus algorithm' have collapsed two layers.
Throughput figures are scenario figures
The paper's large transactions-per-second numbers assume a data centre network, batched signatures, and a pipeline that stays full. They are not a measurement of the worst slot on a public network years later. Quote them as design targets of the text, or do not quote them.
The leader schedule is a centralisation surface
Rotation spreads the right to order, but the leader of a slot can still censor inside the slot, and a cluster of stake can take many slots. The paper's performance depends on leaders being online and well connected. Liveness and neutrality are operational facts on top of the architecture.
What has to be true
- Verifiers can recompute the hash sequence fast enough to keep up. The delay function is only a clock if the verifier's hardware matches the assumption.
- Network delay is small relative to slot time, in the data-centre sense the paper uses.
- Stake-weighted leader rotation and Tower lockouts are both implemented. One without the other is a partial reading.
- Users tolerate a node set that looks more like a cluster than a laptop swarm.
What happened after the paper
The live Solana network added, changed and tuned runtime details — Gulf Stream, QUIC delivery, local fee markets, and several scheduler revisions — after this architecture paper. Outages and fixes belong to that history. They are not pages of the 2018 text, and they also mean the paper is not a status report.
What to check before you use the idea
- Which component orders transactions, and which component only timestamps them?
- What hardware class is a verifying node assumed to have?
- How long is a leader's slot, and what happens when the leader is silent?
- Are the paper's throughput numbers labelled as targets or as a current measurement?
Terms
- Proof of History
- A sequential hash chain that acts as a clock. Checking it shows that a stretch of time and an order of events occurred.
- Leader schedule
- The stake-weighted roster of who may produce the sequence in each slot.
- Tower BFT
- The voting rule that stacks increasing lockouts so a node cannot cheaply change an old vote.
- Pipeline
- Overlapping signature checks, execution and broadcast so a core is not idle while the network waits.
The problem the paper names
In a usual BFT network, nodes spend messages establishing what happened before what. The paper's claim is that a hash chain, produced by a sequencer and checked by everyone else, can carry a lower bound on time between events before consensus starts.
What the design proposes
- Proof of History is a sequential hash. Checking it can be parallel; producing it cannot.
- The clock is an input to consensus, not a replacement for voting. The paper pairs it with a consensus algorithm.
- The text is explicit that it is a design for comment, not an offer of tokens.
How the mechanism is specified
- A verifier recomputes hashes from the claimed starting point. Gaps in the chain imply time passed.
- Leaders, voting and data propagation are separate moving parts. PoH does not make them honest.
- Later production choices — Turbine, Gulf Stream, local fee markets — are not this PDF.
What this page does not treat as proven
- The paper's theoretical discussion of throughput is not a measurement of the live network, and this page will not repeat it as one.
- A verifiable clock still has a leader who produces it. Censorship and leader rotation are outside the clock.
- Hardware assumptions in the note are assumptions. They are not a requirement we are imposing on any reader.
Why a venture studio still reads it
The useful separation is clock versus consensus. A venture that needs ordered events from machines should say which component is a proof of elapsed time and which component is an agreement that the events were valid.
This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.
Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.