Solana: สถาปัตยกรรมใหม่สำหรับบล็อกเชนประสิทธิภาพสูง

Abstract

This paper presents a new blockchain architecture based on Proof of History (PoH) — a proof for verifying order and passage of time between events. PoH is used to encode trustless passage of time into a ledger, creating a historical record that proves that an event occurred at a specific moment in time. When used alongside a Proof of Stake consensus algorithm, PoH can reduce messaging overhead in a Byzantine Fault Tolerant replicated state machine, resulting in sub-second finality times.

The key innovation is the construction of a verifiable delay function implemented as a sequential pre-image resistant hash chain. The PoH sequence continuously runs and outputs a cryptographic proof that some amount of time has elapsed between two events. Data can be inserted into the sequence by appending it to the state that is hashed, thereby creating a timestamp that guarantees the data existed before the next hash was generated. This mechanism establishes a globally available, non-interactive source of time that all participants can verify independently.

By providing a trusted clock before consensus, PoH dramatically reduces the communication complexity of agreement. Validators can verify the relative ordering of events and the passage of time between them without communicating with each other. This allows the system to choose a leader, have that leader sequence user messages, and have validators process those messages in the order dictated by the PoH sequence, all without the traditional overhead of two-phase commit or synchronous coordination. The result is a blockchain capable of processing hundreds of thousands of transactions per second on a standard gigabit network while preserving the decentralization and security guarantees expected of a permissionless system.

The architecture integrates PoH with a Tower BFT consensus mechanism, a data plane optimized for streaming (Turbine), a mempool-less transaction forwarding protocol (Gulf Stream), a parallel smart contract runtime (Sealevel), and a Proof of Replication scheme for distributed storage verification. Together these components form a system whose throughput scales naturally with improvements in hardware — faster processors generate more PoH hashes per second, faster GPUs verify more signatures, and higher-bandwidth networks carry more transaction data — allowing performance to track Moore's Law without protocol changes.

Introduction

Blockchains are an implementation of fault tolerant replicated state machines. Currently available public blockchains do not rely on time, or make a weak assumption about the participants' abilities to keep time. Each node in the network typically maintains its own local clock without any guarantee that it is consistent with any other node in the network. The lack of a trusted source of time means that when a message timestamp is used to accept or reject a message, there is no guarantee that every other participant in the network will make the exact same choice. This limitation forces blockchain protocols into complex coordination patterns where nodes must exchange messages to agree on ordering.

The key observation driving Solana's design is that if a reliable source of time is available — a clock that all participants can verify without trusting each other — many of the fundamental scaling limitations of existing blockchains can be removed. In traditional consensus systems like PBFT or Tendermint, every validator must communicate with every other validator to agree on the order of transactions. This produces O(n^2) message complexity, which limits the practical network size and throughput. If ordering is established before consensus begins, validators only need to confirm that they have seen the same sequence, dramatically reducing the communication required.

Proof of History provides exactly this: a cryptographic clock that produces a verifiable record of time passage. PoH is implemented as a sequential computation — a SHA-256 hash chain where each output is used as the input for the next hash. Because SHA-256 is a pre-image resistant function, the only way to produce the output for a given position in the chain is to compute every intermediate hash from the starting point. This means the chain cannot be parallelized or shortcut, and the number of hashes between two events represents a provable lower bound on the real time that has elapsed between them.

The PoH generator runs continuously, producing hashes as fast as the hardware allows. When an event occurs (such as a transaction arriving), its data is mixed into the hash chain by including it as part of the next hash input. The resulting hash and the current counter value form a timestamp for that event. Any verifier can check that the event was incorporated at that specific position in the chain by recomputing the hashes from a known checkpoint. Because SHA-256 is cheap to verify in parallel but expensive to generate sequentially, a single PoH generator can timestamp events at the rate of a single core, while thousands of verifier cores can confirm those timestamps simultaneously.

This paper describes a new blockchain design that leverages PoH as a global clock, enabling a pipeline of optimizations: leader-based block production with predetermined schedules, streaming block propagation, GPU-accelerated signature verification, and parallel transaction execution. The net effect is a system that pushes the bottleneck from consensus messaging to raw hardware throughput — specifically, the bandwidth of the network connection and the speed of the PoH generator's CPU core.

Outline

The remainder of this paper is organized as follows. We first describe the Proof of History mechanism in detail, explaining its construction from sequential SHA-256 hashing and the properties that make it suitable as a verifiable delay function. We then describe how data is inserted into the PoH sequence and how the resulting timestamps can be verified efficiently.

Next, we present the network design of Solana, including the leader rotation mechanism, the data plane used for block-propagation/" class="glossary-link" data-slug="block-propagation" title="block propagation">block propagation, and the transaction forwarding protocol that eliminates the need for a traditional mempool. We explain how the predetermined leader schedule, made possible by PoH's trusted clock, enables clients to send transactions directly to the upcoming leader, reducing confirmation latency.

We then describe how Proof of History integrates with a Proof of Stake consensus algorithm. The consensus mechanism, bft/" class="glossary-link" data-slug="tower-bft" title="Tower BFT">Tower BFT, uses PoH as a cryptographic clock to implement time-based lockouts that grow exponentially with each consecutive vote. This design produces a system where the cost of reverting a confirmed block increases exponentially over time, providing practical finality within seconds.

The paper proceeds to describe Streaming Proof of Replication, a mechanism for validators to prove they are storing a copy of the ledger state. This component addresses data availability — the requirement that enough copies of the blockchain data exist across the network for any participant to reconstruct the full state.

Finally, we present the system architecture as an integrated pipeline. The Transaction Processing Unit (TPU) fetches transactions, verifies signatures on the GPU, executes transactions in parallel using the Sealevel runtime, and writes the results to the ledger. We present performance projections based on the computational limits of current hardware and demonstrate that the system can process over 710,000 transactions per second on a standard gigabit network, with this throughput scaling as hardware improves over time.

Throughout the paper, we compare our approach against existing designs where relevant. Traditional blockchains process transactions sequentially and reach consensus through all-to-all communication. Solana replaces these serial bottlenecks with a pipelined, parallelized architecture where the PoH sequence serves as the coordinating mechanism, allowing each component to operate at its maximum hardware-limited throughput.

Network Design

Solana's network operates on a rotating leader model where a single validator at a time is designated as the leader, responsible for producing the PoH sequence and ordering transactions into blocks. Validators are assigned leader slots according to a stake-weighted schedule that is derived deterministically from the PoH sequence itself. Because every validator can independently compute the same leader schedule from the same PoH state, the rotation is globally consistent without requiring any coordination messages.

A leader slot lasts for a fixed number of PoH ticks (currently configured at 800ms worth of hashes). During its slot, the leader ingests transactions from clients, orders them into the PoH stream, and produces a block that is streamed to the rest of the network. At the end of its slot, the next leader in the schedule takes over, continuing the PoH sequence from where the previous leader stopped. If a leader fails to produce a block during its slot — due to a crash, network partition, or malicious behavior — the slot is skipped and the next leader begins its rotation, with the gap in the PoH sequence serving as a verifiable record that time passed but no block was produced.

The data plane uses a protocol called Turbine, which is designed to maximize the use of network bandwidth while minimizing the data each individual validator must transmit. When a leader produces a block, it does not broadcast the entire block to every validator. Instead, the block is broken into small packets called shreds using Reed-Solomon erasure coding. The leader sends each shred to a different validator in a tree structure called a fanout tree. Each validator that receives a shred retransmits it to a fixed number of downstream validators in the tree, and those validators retransmit to their downstream neighbors, and so on. This creates a propagation pattern similar to BitTorrent, where the network's aggregate bandwidth is used to distribute the block rather than requiring the leader to have enough bandwidth to serve every validator directly.

Erasure coding is critical to Turbine's design. The leader encodes each block into data shreds and recovery shreds such that any sufficiently large subset of the total shreds is enough to reconstruct the full block. Even if some shreds are lost due to network failures or if some validators in the fanout tree fail to retransmit, the remaining validators can still recover the complete block from the shreds they did receive. This provides resilience against both random packet loss and targeted adversarial behavior.

Gulf Stream is Solana's transaction forwarding protocol, which eliminates the traditional mempool used by most blockchain networks. In a conventional blockchain, transactions are broadcast to the entire network and stored in each node's mempool until they are included in a block. This approach wastes bandwidth, as every transaction is transmitted to every node regardless of whether that node will process it. Gulf Stream instead forwards transactions directly to the expected leader. Because the leader schedule is known in advance (derived from the PoH state), clients and validators can determine which validator will be the leader for upcoming slots and forward transactions accordingly.

When a client submits a transaction, it includes a recent blockhash (a reference to a recent PoH checkpoint) that serves as a transaction lifetime marker. The transaction is valid only for a limited number of slots after the referenced blockhash. If the transaction is not processed within that window, it expires and the client must resubmit it with a more recent blockhash. This expiration mechanism prevents stale transactions from accumulating and allows validators to prune unprocessed transactions efficiently, keeping memory usage bounded without maintaining a global mempool.

The combination of known leader schedules, direct transaction forwarding, and transaction expiration means that by the time a validator becomes the leader, it already has most of the transactions it needs to build its block. There is no need to wait for mempool synchronization or to gossip unconfirmed transactions across the network. This design reduces confirmation latency because transactions arrive at the leader before it begins its slot, and it reduces network bandwidth consumption because transactions are forwarded along targeted paths rather than broadcast to all validators.

Proof of History

Proof of History is a sequence of computations that provides a cryptographic way to verify the passage of time between two events. It uses a sequential pre-image resistant hash function — specifically SHA-256 — that is run continuously, with the previous output used as the next input. Periodically, the current count and hash output are recorded, and each recorded sample can be verified by an external computer in the time it takes to evaluate the hash function from the starting state to the recorded sample.

The construction is straightforward. Starting from some initial hash value hash_0, the PoH generator computes:

hash_1 = SHA256(hash_0)
hash_2 = SHA256(hash_1)
hash_3 = SHA256(hash_2)
...
hash_n = SHA256(hash_{n-1})

Each hash in the sequence can only be computed after the previous one. Because SHA-256 is pre-image resistant, there is no known way to find hash_n without computing all intermediate hashes hash_1 through hash_{n-1}. This property means the sequence acts as a verifiable delay function (VDF): producing n hashes requires sequential work proportional to n, and no amount of parallel hardware can accelerate the computation. The elapsed wall-clock time to generate n hashes on a given processor provides a lower bound on the real time that passed during generation.

The critical asymmetry exploited by PoH is between generation and verification. While the hash chain must be generated sequentially on a single core, it can be verified in parallel by splitting it into segments. If a verifier receives the sequence along with checkpoints (hash value and counter pairs), it can divide the work among multiple cores. For example, given checkpoints at positions 0, 1000, 2000, and 3000, four cores can simultaneously verify the segments [0,1000], [1000,2000], [2000,3000] by each recomputing 1000 hashes and checking that the endpoint matches. This means verification is approximately c times faster than generation, where c is the number of cores available to the verifier.

Generation (sequential, single core):

  hash_0 → hash_1 → hash_2 → ... → hash_999 → hash_1000 → ... → hash_2000

Verification (parallel, multi-core):

  Core 1: hash_0    → ... → hash_999  ✓ matches checkpoint
  Core 2: hash_1000 → ... → hash_1999 ✓ matches checkpoint
  Core 3: hash_2000 → ... → hash_2999 ✓ matches checkpoint

Data can be inserted into the PoH sequence to create timestamps. When external data — such as a transaction hash, a photograph of a newspaper front page, or any arbitrary bytes — needs to be timestamped, it is appended to the current hash state and included in the next hash computation. For example, if the current state is hash_n and external data D arrives, the generator computes hash_{n+1} = SHA256(hash_n || SHA256(D)), where || denotes concatenation. The PoH record then includes the entry (n+1, D, hash_{n+1}), proving that data D existed before hash_{n+1} was computed and after hash_n was computed. The data insertion is irreversible: removing or altering D would change hash_{n+1} and every subsequent hash in the chain.

This data insertion mechanism provides a total ordering of events. If event A is inserted at position n and event B is inserted at position m where n m, then the hash chain proves that A was recorded before B. The number of hashes between positions n and m provides a lower bound on the time that elapsed between the two events. This ordering is non-interactive — any observer who has access to the hash chain can independently verify the ordering without communicating with the generator or any other observer.

The security of PoH rests on the pre-image resistance of SHA-256. An attacker who wants to forge a PoH sequence — inserting a different event at a given position while maintaining a valid hash chain — would need to recompute the entire chain from the point of forgery. Because the generator is running continuously at the maximum speed of a single core, the attacker's forged chain would always be behind the legitimate chain. To catch up, the attacker would need hardware that is faster than the generator's hardware on a single-core sequential SHA-256 computation, which is bounded by the laws of physics and the current state of semiconductor technology. This makes PoH manipulation economically and physically impractical for any reasonably provisioned generator.

Proof of History Sequence

The Proof of History sequence is a continuous stream of hash computations that serves as the backbone of Solana's temporal ordering system. The sequence begins with an arbitrary seed value and proceeds indefinitely, with the generator computing SHA-256 hashes as fast as the underlying hardware allows. Alongside the hash values, the generator maintains a monotonically increasing counter that records the total number of hashes computed since the sequence began. This counter serves as the canonical "clock tick" for the network.

The PoH output is recorded as a series of entries, each containing the counter value, the hash output, and optionally any data that was mixed into the hash at that position. Not every hash is recorded — the generator may output entries at regular intervals (for example, every 800,000 hashes), producing checkpoints that divide the sequence into verifiable segments. Between checkpoints, the generator may also produce entries at irregular intervals whenever data is inserted into the sequence. The complete sequence of entries forms the PoH log, which serves as a verifiable timeline for all events on the network.

Multiple data items can be inserted at the same PoH index by hashing them together before mixing into the state. For example, if transactions Tx_1 and Tx_2 arrive simultaneously, the generator computes hash_{n+1} = SHA256(hash_n || SHA256(Tx_1) || SHA256(Tx_2)). The ordering within a single PoH index is determined by the generator (the leader), while the ordering between different PoH indices is determined by the hash chain. This two-level ordering scheme provides both fine-grained (intra-tick) and coarse-grained (inter-tick) temporal resolution.

Verification of the PoH sequence proceeds in two phases. In the first phase, a verifier checks the structural integrity of the hash chain by recomputing hashes between checkpoints and confirming that the computed output matches the recorded checkpoint value. This can be parallelized across multiple cores, with each core independently verifying one segment. In the second phase, the verifier checks that data insertions are correct by confirming that the hash at each insertion point correctly incorporates the declared data. Both phases can run simultaneously on different cores, making verification significantly faster than generation.

The PoH sequence also supports light proofs. A node that wants to prove that a specific event occurred at a specific position in the PoH sequence need not transmit the entire hash chain. Instead, it can provide the event data, the PoH hash at the insertion point, the hashes at the surrounding checkpoints, and a compact proof that the checkpoints are part of the canonical PoH sequence (confirmed by validator votes). The verifier can then check the segment containing the insertion point and confirm the event's position without processing the full sequence.

A critical design consideration is the speed of the PoH generator. The generator should use the fastest available single-core hardware for SHA-256 computation, because the rate of hash production determines the "tick rate" of the cryptographic clock. If an adversary has access to significantly faster hardware, they could generate an alternative PoH sequence faster than the legitimate generator, potentially creating a forged timeline. In practice, the fastest SHA-256 hardware available is commodity ASIC or high-end CPU hardware, and the difference in single-core performance between the fastest and second-fastest hardware is small — typically within a factor of two. This means an attacker's forged sequence would still fall behind the legitimate sequence as long as the legitimate generator starts first and the attacker cannot sustain twice the single-core hash rate indefinitely.

The PoH sequence naturally handles the passage of time during periods of inactivity. When no transactions are being submitted, the generator continues to compute hashes, producing "empty ticks" that advance the clock without recording any events. These empty ticks prove that time passed even when no activity occurred, which is important for features like transaction expiration and for distinguishing between a leader that produced an empty slot (because no transactions arrived) and a leader that failed to produce any output at all.

Timestamp

Each hash and counter published by the PoH generator represents a unique timestamp. This timestamp is a proof that the data was created before the hash was generated. The PoH sequence can be used to embed wall-clock time estimates that validators collectively agree upon, creating a bridge between the cryptographic clock and human-readable time.

The mechanism works as follows. Each PoH tick represents a cryptographic timestamp — a position in the hash chain that can be verified but that does not directly correspond to a wall-clock time. To establish a mapping between PoH ticks and real-world time, validators periodically submit signed observations of their local wall-clock time along with the current PoH tick count. These observations are recorded in the PoH stream. After collecting observations from a sufficient number of validators, the network can compute a bounded estimate of the real-world time at each PoH tick by taking the stake-weighted median of the reported times.

Validator Timestamp Observations:

PoH Tick 500000:
  Validator A (10% stake): 2017-11-15T12:00:00.000Z
  Validator B (15% stake): 2017-11-15T12:00:00.012Z
  Validator C (20% stake): 2017-11-15T12:00:00.005Z
  Validator D (5% stake):  2017-11-15T12:00:00.008Z

Stake-weighted median → 2017-11-15T12:00:00.006Z
Bound: ±20ms (based on PoH tick rate and observation spread)

The bound on the wall-clock estimate depends on two factors: the variance in network propagation delays (which affects when different validators observe the same PoH tick) and the granularity of the PoH clock (which depends on the hash rate of the generator). On a 4GHz processor computing approximately 4 million SHA-256 hashes per second, the PoH clock has a resolution of approximately 0.25 microseconds per tick. Network propagation delays are typically on the order of tens to hundreds of milliseconds, so the bound on wall-clock estimates is dominated by network latency rather than PoH resolution.

This timestamp mechanism is important for several protocol features. Transaction expiration relies on timestamps to determine when a transaction's referenced blockhash has become too old. Stake lockup periods use timestamps to determine when staked tokens can be withdrawn. Oracle integrations use timestamps to verify the freshness of external data feeds. And any on-chain program that needs to implement time-dependent logic — such as scheduled payments, time-locked contracts, or rate limiting — can use the PoH-derived timestamps as a trusted time source.

A critical security property of PoH timestamps is that they cannot be manipulated by a single malicious leader. A leader could attempt to assign incorrect wall-clock times to PoH ticks, but because the wall-clock estimates are computed from the stake-weighted median of multiple validators' observations, a single malicious validator (even one with significant stake) cannot significantly skew the median. To shift the median by more than the normal observation variance, an attacker would need to control a majority of the stake, which would compromise the security of the consensus mechanism itself and is therefore outside the threat model.

The PoH clock also provides a mechanism for detecting leaders that are running at an abnormal rate. If a leader is generating PoH hashes significantly faster or slower than expected (relative to the observed wall-clock rate of previous leaders), validators can detect this discrepancy and reject blocks from that leader. This prevents attacks where a malicious leader attempts to compress or extend time by manipulating the rate of PoH generation. The expected PoH rate is calibrated based on the observed performance of the network's hardware, and validators maintain a running estimate of the normal rate to detect anomalies.

Proof of Stake Consensus

Solana uses a Proof of Stake consensus mechanism called bft/" class="glossary-link" data-slug="tower-bft" title="Tower BFT">Tower BFT that is specifically designed to leverage the temporal guarantees provided by Proof of History. In Tower BFT, validators stake SOL tokens as collateral and vote on the validity of blocks produced by leaders. Validators earn rewards proportional to their stake for correctly participating in consensus, and they risk having their stake slashed if they violate the protocol rules. The stake-weighted voting ensures that the consensus decision reflects the economic interests of the network's stakeholders.

The fundamental innovation in Tower BFT is the use of PoH as a clock for implementing exponentially increasing lockout periods. When a validator votes on a block at a specific PoH slot, it commits to that fork of the ledger. Each consecutive vote on the same fork doubles the lockout period before the validator can switch to an alternative fork. Specifically, if a validator has made n consecutive votes on a particular fork, the lockout period before the oldest of those votes expires is 2^n PoH slots. This exponential growth means that after a modest number of consecutive votes (for example, 32), the lockout period becomes astronomically long — over 4 billion slots, which at typical slot times would take decades to expire.

Tower BFT Exponential Lockout:

Vote #  Lockout (slots)   Cumulative commitment
─────────────────────────────────────────────────
1       2                 Low — can switch forks quickly
2       4
3       8
4       16
5       32
...
12      4,096             Minutes of lockout
...
20      1,048,576         Hours of lockout
...
32      4,294,967,296     Effectively permanent (decades)

This lockout mechanism creates a natural finality gradient. A block that has received votes from validators representing a supermajority of stake, where those validators have many consecutive votes on the fork containing that block, is effectively finalized. Reverting such a block would require those validators to wait for their lockouts to expire — a period that grows exponentially and quickly becomes impractical. In practice, blocks achieve effective finality within seconds, as validators rapidly accumulate consecutive votes on the canonical fork.

The integration with PoH is what makes this lockout scheme practical. In traditional BFT systems, lockout periods would need to be measured in wall-clock time, which requires nodes to trust each other's clocks or engage in complex time-synchronization protocols. With PoH, lockout periods are measured in PoH slots — a verifiable, tamper-proof unit of time. Every validator can independently verify whether a given lockout has expired by checking the PoH sequence, without trusting any other node's clock. This eliminates the ambiguity that would otherwise make time-based lockouts vulnerable to manipulation.

Slashing is the mechanism by which validators are penalized for violating protocol rules. The primary slashable offense is equivocation: voting on two conflicting forks during a period when the validator should be locked out on one fork. If a validator votes on fork A and then votes on a conflicting fork B before their lockout on A expires, any observer who possesses both votes can construct a slashing proof. This proof demonstrates that the validator violated its lockout commitment, and the network can automatically destroy a portion of the validator's staked tokens as punishment. The economic cost of slashing makes equivocation irrational for any validator whose stake exceeds the potential profit from the attack.

Leader selection in Tower BFT is determined by the PoH sequence and the current stake distribution. The leader schedule is computed deterministically from a recent snapshot of the stake distribution and a seed derived from the PoH state. This computation is performed independently by every validator, and because both inputs (stake distribution and PoH state) are part of the consensus state, all honest validators arrive at the same leader schedule. The schedule is computed for upcoming epochs (periods of several hundred thousand slots), giving the network advance notice of which validator will lead each slot. This predictability enables the Gulf Stream transaction forwarding protocol and allows validators to prepare for their leadership slots in advance.

Validators that are not currently serving as leader participate in consensus by voting on blocks produced by the current leader. When a validator receives a block, it verifies the PoH sequence, executes the transactions in the block, and if everything is valid, casts a vote for that block by signing the block's hash along with the PoH slot number. These votes are themselves transactions that are submitted to the leader of the current slot for inclusion in the PoH stream. Once a block has received votes representing more than two-thirds of the total stake, it is considered confirmed and all validators can advance their local view of the finalized state.

Streaming Proof of Replication

Proof of Replication (PoRep) addresses the data availability problem in blockchain systems: ensuring that sufficient copies of the ledger data exist across the network so that any participant can reconstruct the complete state. In many blockchain designs, there is no verifiable mechanism to ensure that validators are actually storing the data they claim to store. A validator might discard historical data after processing it, relying on other validators to maintain copies. If enough validators adopt this strategy, the network's data redundancy degrades and the ledger may become unrecoverable.

Solana implements a streaming version of PoRep that allows validators to continuously prove they are storing and replicating ledger segments. The approach is based on encrypting the ledger data with a validator-specific key and then proving that the encrypted data exists and is stored correctly. Because each validator's encrypted copy is unique (due to the validator-specific key), a validator cannot fake their storage proof by copying another validator's encrypted data.

The encryption process uses CBC (Cipher Block Chaining) mode, where each encrypted block depends on the plaintext of the current block and the ciphertext of the previous block. This chaining property is essential: to produce the encrypted version of block n, the validator must possess both the plaintext of block n and the ciphertext of block n-1. This means the validator cannot compute arbitrary encrypted blocks without having processed all preceding blocks, ensuring that the encrypted ledger is a faithful replica of the original data.

The validator-specific encryption key is derived from the validator's identity (their public key) and a PoH-derived seed that changes periodically. This periodic key rotation ensures that validators must re-encrypt their stored data at regular intervals, preventing them from performing the encryption once and then discarding the plaintext. The PoH seed for key derivation is chosen such that the encryption key for a given period cannot be known until that period begins, preventing validators from pre-computing encrypted data.

Storage challenges are issued through the PoH sequence. The network periodically selects random positions in the encrypted ledger and requests validators to provide the encrypted block at that position along with a Merkle proof demonstrating its position in the validator's encrypted ledger tree. Because the challenge positions are derived from the PoH state (which cannot be predicted in advance), validators cannot selectively store only the blocks that they expect to be challenged on. They must store the complete encrypted ledger to respond correctly to arbitrary challenges.

The verification of challenge responses is efficient. A verifier needs only the validator's public key, the PoH-derived encryption seed, the challenged position, and the Merkle root of the validator's encrypted ledger (which is published on-chain). The verifier computes the expected encryption key, checks that the provided encrypted block is consistent with the claimed plaintext at that position using CBC decryption, and verifies the Merkle proof against the published root. This entire verification can be done without accessing the validator's full encrypted ledger.

The streaming aspect of Solana's PoRep means that the encryption and proof generation happen continuously as new blocks are produced, rather than in discrete rounds. As the leader produces new blocks, validators encrypt them into their local PoRep store immediately. Challenge responses can be generated at any time by looking up the requested position in the local encrypted ledger and constructing a Merkle proof. This continuous operation ensures that proof of replication is always current and does not introduce latency spikes from periodic proof generation.

The combination of PoRep with PoH creates a complete accountability framework for data storage. PoH provides verifiable timestamps that record when data was created, and PoRep provides verifiable proofs that the data is being stored and replicated across the network. Together, they ensure that the blockchain's historical data remains available and intact, even if individual validators leave the network or attempt to discard data to reduce their storage costs.

System Architecture

Solana's system architecture is organized as a multi-stage pipeline, analogous to the instruction pipeline in a modern CPU. Each stage of the pipeline performs a specific function, and multiple stages operate concurrently on different batches of transactions. This pipelining ensures that the hardware is utilized continuously — while one batch of transactions is being executed, the next batch is having its signatures verified, and the batch after that is being fetched from the network. The result is a system that achieves throughput limited by the slowest pipeline stage rather than the sum of all stage latencies.

The Transaction Processing Unit (TPU) is the core component of the pipeline. It consists of four stages that process transactions sequentially within each stage but concurrently across stages:

The Fetch stage receives transaction packets from the network. Transactions arrive via UDP, and the fetch stage groups them into batches for the next pipeline stage. UDP is used instead of TCP because the overhead of TCP connection management and congestion control is unnecessary when transactions are small, independently verifiable, and can be safely dropped and retried. The fetch stage also performs basic structural validation, discarding malformed packets before they consume resources in later stages.

The SigVerify stage performs cryptographic signature verification on each transaction. Solana uses Ed25519 signatures, and this stage offloads the verification to GPUs using CUDA. A single modern GPU can verify over 900,000 Ed25519 signatures per second by executing thousands of verification operations in parallel across its CUDA cores. This is the key to removing signature verification as a bottleneck — while a single CPU core might verify only a few thousand signatures per second, a commodity GPU can handle nearly a million. The GPU receives a batch of transactions, verifies all signatures in parallel, and returns the results indicating which transactions have valid signatures.

The Banking stage is where transactions are actually executed against the current state of the ledger. This stage uses Sealevel, Solana's parallel smart contract runtime. Sealevel analyzes each transaction to determine which accounts it reads from and writes to. Transactions that access disjoint sets of accounts can be executed in parallel across multiple CPU cores, because they cannot interfere with each other. Transactions that access overlapping accounts are serialized to prevent race conditions.

This account-level parallelism is possible because Solana programs (smart contracts) must declare upfront which accounts they will access. The runtime uses this declaration to build a dependency graph and schedule non-conflicting transactions across available CPU cores. Programs are executed in a sandboxed BPF (Berkeley Packet Filter) virtual machine, which provides memory safety and deterministic execution. The BPF runtime also enforces compute budgets to prevent any single transaction from consuming excessive resources.

The Write stage commits the executed transactions to the ledger and integrates them into the PoH sequence. The leader's PoH generator incorporates the transaction results into the hash chain, producing a PoH entry that timestamps the batch of executed transactions. The entry, along with the transaction data and execution results, is then transmitted to other validators via the Turbine protocol and written to local persistent storage.

The Cloudbreak state storage system is designed to support the parallelism required by the rest of the pipeline. Traditional blockchain state storage uses a single key-value store (such as LevelDB or RocksDB) that serializes all read and write operations. Cloudbreak uses memory-mapped files and a concurrent data structure that allows multiple threads to read and write different accounts simultaneously. Accounts are stored in separate memory regions, so accessing one account does not block access to another. This architecture ensures that the state storage layer does not become a bottleneck even when thousands of transactions are being executed in parallel.

The overall system architecture also includes the Archiver network, which provides long-term decentralized storage for historical ledger data. Active validators need only maintain the recent state and a sliding window of recent blocks. Older blocks are offloaded to Archiver nodes, which prove they are storing the data using the Proof of Replication mechanism described earlier. This separation of concerns allows validators to operate with bounded storage requirements while ensuring that the full history of the ledger remains available to any participant who needs it.

Performance

The theoretical throughput of the Solana architecture is determined by three potential bottlenecks: network bandwidth, signature verification rate, and transaction execution rate. The system is designed so that improvements in any of these dimensions directly increase throughput, with the overall rate limited by whichever bottleneck is currently the tightest.

On a standard 1 gigabit per second (Gbps) network connection, the maximum data throughput is approximately 125 megabytes per second. A typical Solana transaction is 250 bytes including the signature, account addresses, instruction data, and metadata. At 250 bytes per transaction, a 1 Gbps connection can carry approximately 500,000 transactions per second. With 10 Gbps networking (increasingly available in data centers), this number rises to approximately 5 million transactions per second. The Turbine block-propagation/" class="glossary-link" data-slug="block-propagation" title="block propagation">block propagation protocol ensures that the network's aggregate bandwidth is utilized efficiently, so the bottleneck is the leader's outbound bandwidth rather than the total network capacity.

Throughput Projections by Network Bandwidth:

Network    Bandwidth     Tx Size    Max Throughput
──────────────────────────────────────────────────
1 Gbps     125 MB/s      250 B      500,000 TPS
10 Gbps    1.25 GB/s     250 B      5,000,000 TPS
40 Gbps    5 GB/s        250 B      20,000,000 TPS

Signature verification, often the computational bottleneck in blockchain systems, is addressed through GPU parallelization. A single NVIDIA GTX 1080 Ti GPU can verify approximately 900,000 Ed25519 signatures per second. Higher-end GPUs and future hardware generations will increase this rate further. Because signature verification is embarrassingly parallel (each signature is independent), the verification rate scales linearly with the number of GPU cores. With multiple GPUs, a single node can verify millions of signatures per second, ensuring that cryptographic validation does not constrain the system.

The PoH generator runs on a dedicated CPU core, producing approximately 4 million SHA-256 hashes per second on a 4 GHz processor. This provides a clock resolution of 0.25 microseconds per tick, which is more than sufficient for ordering millions of transactions per second. The sequential nature of PoH generation means this component cannot be parallelized, but the hash rate is high enough that the PoH generator is not a bottleneck. As CPU clock speeds increase and SHA-256 instruction sets improve (Intel SHA Extensions, ARM Cryptography Extensions), the PoH tick rate will increase accordingly.

Transaction execution throughput depends on the complexity of the transactions and the degree of parallelism achievable. For simple value transfers that access only two accounts (sender and receiver), the execution rate is very high because most transfers involve different accounts and can be executed in parallel. For smart contract interactions that access shared state, parallelism is reduced and execution becomes the bottleneck. The Sealevel runtime is designed to maximize parallelism by executing non-conflicting transactions on different CPU cores, and modern server hardware with 32 or more cores provides substantial parallel execution capacity.

Pipeline Stage Throughput (approximate, current hardware):

Stage              Hardware         Throughput
─────────────────────────────────────────────────
Fetch              1 Gbps NIC       500,000 TPS
SigVerify          1x GTX 1080 Ti   900,000 SPS
Banking/Execute    32-core CPU      ~400,000 TPS (simple transfers)
PoH Generator      4 GHz core       4,000,000 hashes/sec
Write/Storage      NVMe SSD         ~1,000,000 IOPS

A critical property of Solana's performance model is that it scales with Moore's Law. As hardware improves across all dimensions — faster CPUs, more powerful GPUs, higher-bandwidth networks, faster storage — the system's throughput increases proportionally without requiring any changes to the protocol. This is a deliberate design choice that distinguishes Solana from blockchains whose throughput is limited by protocol-level constraints (such as fixed block sizes or fixed block intervals) that require governance decisions and hard forks to change. In Solana, the protocol automatically takes advantage of whatever hardware is available, meaning that the performance ceiling rises continuously as technology advances.

Latency is another critical performance dimension. The end-to-end latency from transaction submission to confirmation depends on several factors: network propagation time to the leader, the leader's slot length (currently approximately 400ms), the time for the block to propagate to validators via Turbine, and the time for validators to vote and reach confirmation (typically 1-2 additional slots). In total, a transaction submitted to the current leader can be confirmed in approximately 400ms to 800ms under normal conditions. This latency is orders of magnitude lower than proof-of-work blockchains (which require minutes) and comparable to or faster than most proof-of-stake systems.

Conclusion

This paper has presented a new blockchain architecture built on Proof of History, a mechanism for creating a verifiable, trustless record of time passage using sequential SHA-256 hashing. By establishing a cryptographic clock before consensus, PoH removes the coordination bottleneck that limits the throughput of existing blockchain systems. Validators no longer need to communicate extensively to agree on the ordering of events — the PoH sequence provides a canonical timeline that all participants can verify independently.

The key insight underlying Solana's design is that time is the missing primitive in distributed systems. Traditional consensus protocols must solve two problems simultaneously: agreeing on what happened and agreeing on when it happened. By separating these concerns — using PoH to establish when and consensus to confirm what — the system reduces the complexity of consensus from a coordination-intensive process to a simple confirmation step. This separation enables a pipeline architecture where block production, propagation, signature verification, and transaction execution all happen concurrently, maximizing hardware utilization.

The integration of PoH with the other components of the architecture produces a system with several distinctive properties. bft/" class="glossary-link" data-slug="tower-bft" title="Tower BFT">Tower BFT provides fast finality through exponentially increasing lockouts anchored to verifiable PoH timestamps. Gulf Stream eliminates the mempool by leveraging the predictable leader-schedule/" class="glossary-link" data-slug="leader-schedule" title="leader schedule">leader schedule that PoH enables. Turbine uses erasure coding and tree-structured propagation to distribute blocks efficiently. Sealevel executes non-conflicting transactions in parallel across multiple CPU cores. And Streaming Proof of Replication ensures that the ledger data is properly stored and replicated across the network.

The performance characteristics of this architecture are fundamentally different from those of previous blockchain designs. Instead of being limited by protocol-level constraints — fixed block sizes, fixed block intervals, sequential execution — Solana's throughput is limited only by the hardware available to validators. On current commodity hardware, the system can process hundreds of thousands of transactions per second with sub-second confirmation times. As hardware continues to improve following Moore's Law, these numbers will increase without requiring protocol changes or governance decisions.

The implications for blockchain adoption are significant. Many applications that require high throughput and low latency — decentralized exchanges, payment systems, gaming platforms, social networks, and Internet-of-Things data processing — have been unable to build on existing blockchain infrastructure due to performance limitations. Solana's architecture demonstrates that it is possible to build a blockchain that achieves performance levels comparable to centralized systems while maintaining the decentralization, security, and censorship resistance that make blockchains valuable. Proof of History provides the foundation for a new generation of decentralized applications that can operate at the scale demanded by global adoption.