The need for proof-of-history, explained
In a distributed network like a blockchain, synchronizing a common timeline of transactions is a significant challenge. Most blockchains achieve this by coordinating blocks through network-wide communication; however, this approach can create delays and slow down transaction finality, especially as more nodes join the network.
Solana’s founder, Anatoly Yakovenko, saw a way to address this “clock problem” by introducing a cryptographic solution that provides a historical record of transactions. By giving every transaction a verifiable timestamp, Solana can create a cryptographic order of events without requiring constant network consensus on the time or order. This solution, known as proof-of-history, became a central feature that sets Solana apart, allowing it to achieve high speeds without compromising on decentralization.
Solana has become one of the most talked-about layer-1 blockchains, primarily due to its unprecedented transaction speeds and low fees. At the core of this high-performance platform lies an innovative concept: proof-of-history (PoH).
Unlike blockchains like Bitcoin and Ethereum that rely solely on consensus mechanisms like proof-of-work (PoW) or proof-of-stake (PoS), respectively, Solana combines PoH with PoS to achieve a high-throughput, low-latency system.
This unique combination allows Solana to handle thousands of transactions per second, solving significant bottlenecks faced by other chains.
How proof-of-history (PoH) works
Proof-of-history works by establishing a cryptographic clock that timestamps each transaction, creating a record that can prove when each transaction occurred.
This process uses a verifiable delay function (VDF), in Solana’s case based on SHA-256 hashing, to create a continuous, sequential chain of hashes. Each hash references the previous one, forming a unique timeline.
The uniqueness of PoH lies in the fact that each hash is both verifiable and dependent on the previous one. This chain of hashes essentially creates a “clock” that all nodes in the network can follow, allowing them to agree on the order of transactions without communicating directly. Nodes can then validate blocks and transactions in a pre-ordered sequence, speeding up the entire process.
How PoH speeds up consensus on Solana
PoH allows Solana to achieve faster, more efficient consensus by pre-ordering transactions, enabling rapid block times and processing thousands of transactions per second.
In traditional PoS or PoW systems, blocks are created through a network-wide voting process, which requires consensus on each block’s timestamp and ordering.
PoH allows Solana to skip this step by pre-ordering transactions, meaning that validators can process transactions as they arrive without waiting for network-wide agreement. This reduces the amount of communication required and makes the validation process faster and more efficient.
With PoH, Solana can reach consensus much more quickly because every node has access to the same verifiable timeline. This enables predictable and rapid block times — Solana regularly achieves 400-millisecond block times, which is faster than many centralized systems. By solving the synchronization problem, PoH allows Solana to process thousands of transactions per second with high consistency.
Interaction between proof-of-history and proof-of-stake
While PoH provides the timeline and order of transactions, PoS handles validator selection and network security.
In Solana’s PoS system, validators are chosen based on their stake in the network. The higher the stake, the more likely a validator is selected to add new blocks. This stake-weighted selection process keeps the network secure by aligning validators’ incentives with the network’s health.
PoH and PoS work together seamlessly. Here’s how:
PoH provides the ordered list of events, while PoS determines who gets to add them to the blockchain.
The elected validator, also known as the “leader,” collects and orders transactions in line with PoH’s timestamps. This synergy between PoH and PoS allows Solana to maintain both speed and security, a balance that has been challenging for many other blockchains to achieve.
Role of the lead validator in block creation on Solana
On Solana, a lead validator (or “leader”) is selected to create blocks during a given slot. This validator is responsible for organizing and timestamping transactions in alignment with the PoH timeline.
By leveraging PoH, the leader can place each transaction in a specific order, eliminating the need for other validators to validate the sequence of transactions actively.
Once the lead validator has created the block, it is then verified by other nodes.
Since the block already adheres to the PoH timeline, verification is quicker and more efficient. This role of the lead validator is crucial to Solana’s scalability, as it ensures that blocks are created and confirmed at rapid speeds.
Here is the thematic flow of consensus that brings together PoH and PoS, resulting in a high-throughput, low-latency blockchain.
Step 1: Validator leaders on Solana are chosen based on a stake-weighted system, where validators with larger Solana (SOL) stakes are more likely to be selected as leaders. This means entities that invest more in the network are more likely to be responsible for block production, promoting an alignment of incentives with network security.
Step 2: The PoH consensus mechanism sets up a rotation schedule for leaders. The schedule is known in advance, and each leader is assigned a “slot,” which is a brief period (about 400 milliseconds) in which they will gather transactions and produce a block. This predictable rotation allows validators to anticipate when they will act as leaders, making it easier to prepare for upcoming responsibilities.
Step 3: During its assigned slot, the leader gathers transactions from the network. The PoH mechanism enables the leader to timestamp each transaction with a unique cryptographic signature, creating an ordered sequence of transactions. This ordering is integral to PoH, allowing transactions to be verified and validated by other nodes in the correct sequence.
Step 4: The leader then organizes the ordered transactions into a block, embedding a timestamp that aligns with the PoH sequence. This sequence acts as a historical record that confirms the transaction order without requiring every validator to reach a consensus on each transaction individually. The PoH timestamp also serves as proof that the transactions were processed in real-time, providing a verifiable ledger.
Step 5: Once the block is created, the leader broadcasts it to the rest of the network using Solana’s Turbine protocol. Turbine divides the data into smaller packets and distributes them across validators, ensuring efficient propagation even with high transaction volumes.
Step 6: Other validators receive the block and validate it against the PoH sequence, confirming that the timestamped order aligns with the expected historical record. Since the transactions are already pre-ordered by the leader, validators can quickly check the sequence without needing additional communication for ordering, accelerating the validation process.
Step 7: After the block is validated, it is added to the blockchain, finalizing the transaction records. The role of the leader then rotates to the next scheduled validator, who begins collecting transactions for the following slot. This cycle continues and allows Solana to achieve continuous block production and maintain high throughput.
Additional innovations on Solana: Turbine and Pipelining
In addition to PoH, Solana employs other technical innovations like Turbine and Pipelining to optimize performance further.
Data propagation in large networks can become slow and congested, leading to bottlenecks. Turbine solves this by breaking down data into smaller pieces and transmitting it across nodes in parallel, similar to how BitTorrent splits files. This helps maintain low latency and high throughput, especially in a global network.
Solana’s pipelining architecture allows different stages of transaction processing to run simultaneously. This division of processing tasks across resources enables transactions to flow continuously without waiting, increasing throughput and making the system more efficient.
By combining Turbine and Pipelining with PoH, Solana can process transactions quickly without hitting common bottlenecks faced by traditional blockchains.
Why Solana has no mempool
A mempool is a holding area for unconfirmed transactions that most blockchains use to manage pending transactions. Solana, however, has no traditional mempool due to PoH. In Solana’s system, transactions are timestamped as soon as they enter the network, which allows them to be processed in real-time.
This real-time processing eliminates the need for a mempool, as transactions don’t wait in line — they’re either accepted and ordered immediately or discarded. By removing the mempool, Solana reduces latency and ensures that transactions are processed with minimal delay, a key factor in maintaining its high-speed performance.
Does PoH allow Solana to function without a mempool?
PoH’s unique timestamping function is what enables Solana to operate without a mempool.
Since PoH provides a built-in sequence for transactions, validators can instantly process transactions without needing to store them temporarily. This immediate ordering simplifies the transaction flow and allows the network to handle high volumes without the added complexity of managing a mempool.
While this approach brings impressive speed advantages, it also requires careful management of validator duties and network security to prevent congestion. Solana’s design balances these elements, making it one of the fastest blockchains in production.
Block leaders — a centralization vector in Solana’s PoH consensus model?
Frequent selection of the same validators as leaders in the PoH mechanism could centralize block production, potentially reducing validator diversity and increasing risks related to MEV extraction.
As leaders are responsible for organizing and ordering transactions, they hold a crucial role in the network. Having the same few validators frequently chosen as leaders could result in a situation where a small group of well-resourced validators gain outsized influence over block production. This could potentially diminish the diversity of validators actively participating in the block creation process.
As block leaders have the sole responsibility to order transactions, they could also manage additional revenues using maximum extractable value (MEV) transactions. However, the speed of the chain already reduces the possibilities for MEV, unlike slower chains. Yet this is one of the risks of the PoH mechanism.
