A special thanks to
What are Consensus Mechanisms?
Consensus mechanisms are the guardrails in a blockchain network that ensure that all participants in the network agree on one source of truth to provide reliability along the network. These mechanisms contribute to the security of the network as well. The idea of the consensus mechanism spun from the distributed system computing world to solve the coordination issue. The Byzantine Fault Tolerance concept states that all the network participants must agree on one source of truth to avoid failure. This is necessary as blockchains are decentralized systems with no central authority, making it essential to achieve consensus among nodes, even if some try to disrupt the process.
Over the years, there has been the rise of some consensus mechanisms that are used by various blockchain systems. In 2009, the first mainstream consensus mechanism (proof of work) was introduced due to the inception of Bitcoin. More so, other mechanisms, such as the famous Proof of Stake of Ethereum, Proof of Capacity, and Delegated Proof of Stake, among others, have been introduced. This article will focus on the Solana Proof of History, how it works, its benefits, and a comparison with the Ethereum Proof of Stake.
Solana’s Proof of History
Modern blockchains build on distributed computing principles that emerged in the late 20th century. A core concept of distributed systems is consensus, where multiple nodes agree on a shared state. Consensus enables concurrent systems by allowing nodes to repeatedly synchronize state—a core mechanism fundamental to modern blockchains.
One of the major challenges in distributed systems—and, by extension, blockchains—is dealing with unreliable nodes. The Byzantine Generals’ Problem depicts this challenge: nodes may experience intermittent delays, lost connections, inconsistent event ordering, and difficulty synchronizing timestamps. Anatoly Yakovenko, co-founder of Solana, introduced Proof of History (PoH) to solve this timing issue. Yakovenko’s experience at Qualcomm, optimizing high-frequency communication systems, shaped his approach to Proof of History.
Proof of History allows Solana to establish a verifiable order of events before a consensus is reached. PoH uses a cryptographic function to generate a verifiable sequence of timestamps and enables transactions to be pre-ordered before consensus. By pre-ordering transactions, PoH enables validators to process them in parallel and reduces confirmation time.
In blockchain networks, transactions are data structures that record actions that occurred onchain and are bundled into blocks before being confirmed and added to the state of the network. Transactions and blocks are the foundations of blockchain networks, ensuring consensus. Solana prioritizes high throughput (the number of transactions processed per second) while reducing latency to improve network responsiveness.
A Proof of History Example
To analyze the Proof of History in more detail, let’s assume that there are three leaders and that the leader schedule is:
At first, the leader is A. Following the finalization of A block, B takes over, followed by C. Immediately, A has finalized its block; B has assumed the new role of the leader and begins emitting its block. This is a scenario depicting the rotation of the leader as well as an attack attempt on the leader:
- The current leader, A, first produces a block.
- The next leader, B, then begins emitting the produced blocks amongst the nodes.
- Then, C tries to publish its block before B’s block is fully propagated, thereby attempting to front-run B’s block.
- In order for C’s block to be added to the state of the network, it must mislead the network into believing B’s block was never broadcasted.
But the leader schedule says that B goes after A, and if C emanates a block that has the same proof of history length that B would have, at that point, it will be self-evident to any other validator that C is cheating since it emitted its block amid B‘s space*.* So, C must make it seem that B never transmitted a block at all. In other words, it would have to make the grouping of blocks seem like the following:
If B’s block were lost, at that point, a legitimate C would have gone through all of B‘s slot, creating a proof of history grouping showing that it held up for the full term of B‘s slot, and then it would start emitting a block after that, and at that point, counting the continuation of the proof of history arrangement into and at that point through its slot. Other validators will acknowledge C‘s block as valid since it is the correct leader (C) in the correct slot (two slots after A‘s slot). Therefore, C must compute sufficient Proof of History hashes to show that it waited for all of B’s slots before starting its block. But in the interim, B is already submitting its block that chains off of A, and so from the network’s viewpoint, the following occurs:
- A completes a valid block with legitimate Proof of History.
- B starts emitting its block concurrently, and the network sees that B is active and producing a block correctly chained off of A and with valid Proof of History.
Now, one of two things can happen:
- If C is slower at computing PoH than B, B will complete its block right about the same time that C starts emitting its block. The network has already seen B‘s block by this point, so it just invalidates C‘s block. Due to network latencies, validators may get both blocks late and may not be able to tell whether to accept B‘s block or C‘s block, but 2/3 of the validators (by stake weight) would have to see C‘s complete block well before any of B’s block to accept it.
- If C is faster at computing PoH than B, then it can start sending its block sometime before B is done emitting its block. It is very, very unlikely for C to be so much faster than B that it can begin its block before a significant fraction of B‘s block is already done and seen by the network; however, C is more likely to win than it was in the previous case, especially in the case of network latencies making B‘s block late, but still unlikely.
Therefore, C‘s relative speed compared to B confirms how likely it is to compete successfully with (i.e., censor) B, but C would have to be much, much faster than B to compete effectively and have any reasonable chance of censoring B. And because all validators use CPUs that are known to be at or close to the fastest available for computing iterative SHA-256, it is very unlikely for C to be so much faster than B that it can significantly compete with B for a block in B‘s slot.
So, what are the upsides and downsides of PoH?
Proof of Stake itself guarantees consensus as long as the nodes in the network are honest, but it does not guarantee speed or high throughput. Hence, the implementation of Solana’s PoH allows for high throughput while also ensuring the security of the network. In Solana, transactions are grouped into blocks, and the blocks are connected into a cryptographically verifiable sequence. This allows any block to “prove” that it is part of the Solana blockchain by having received 66% of stake-weighted votes. The upsides of Solana PoH are:
- The network has shorter block times because transactions are handled in bulk and in seconds. This allows for resource optimization, as the nodes do not wait for all participants’ nodes to reach a consensus. It also allows for parallel execution and efficient use of computational power.
- The use of the Verifiable Delay Functions (this makes Solana a SHA256 chain) adds an extra layer of security to Solana, as altering transactions is expensive and resource-intensive; this means recalculating all transactions in a sequential hash. More so, any node can verify the order of events as a result of the cryptographic timestamp on all blocks. This promotes further transparency in the network.
While Proof of History enhances scalability, it also increases complexity. This introduces a higher risk of software bugs and makes Solana more resource-intensive, raising the barrier to entry for validators. Furthermore, Solana, being a SHA256 chain, makes the network cost and resource-intensive, as it reduces the barrier for participation in the network, as the necessary hardware needed to participate is high-end. So what now?
Solana’s high hardware requirements raise an interesting debate: will advancements in computing power lower barriers to entry, or will demand higher performance continue to rise? This creates a fine line between Moore’s law and the Jevons paradox in the world of Solana. According to Moore’s law, the hardware requirement to participate in the network should go lower over time due to the availability and affordability of once-expensive, powerful hardware. More so, Moore’s law observes that the number of transistors on a microchip doubles roughly every two years, leading to an increase in computing power. So, how does this relate to the Jevons paradox? This paradox states that.
“…when
technological advancements make aresource moreefficient to use (thereby reducing the amount needed for a single application); however, as the cost of using the resource drops, overalldemand increases , causing total resource consumption to rise.”Jevons paradox:
William Stanley Jevons
However, the Jevons Paradox suggests that increased efficiency often leads to greater overall consumption rather than reduced usage. This is evident in Solana’s hardware requirements—while more efficient processors and GPUs become available, the network’s demand for high-performance hardware continues to rise. As Solana scales and processes more transactions, validator nodes require increasingly powerful machines, driving greater overall computational demand despite hardware improvements.
Solana’s Proof of History offers some additional features to the existing consensus mechanism in terms of achieving shorter block times and faster transaction speeds. However, the relationship between Moore’s Law and Jevons Paradox points to a growing issue, as stated above. This has pushed the Solana community to explore potential solutions, such as engineering new clients and utilizing available blockspaces to counter the demand for computational power.
While the existing solutions look promising, my research into Solana’s architecture and other solutions—particularly Dankrad’s work, which depicts using the last consensus block as a reference—has pushed me to a new suggestion. This approach involves using the relative time of the last confirmed block as a reference.
To understand this suggestion, let’s explore how Solana would operate solely with its Proof of Stake consensus mechanism, without Proof of History. The following is an excerpt published by Dankrad three years ago.
Solana, without Proof of History—Dankrad
Proof of History (PoH) is a mechanism that measures elapsed time in Solana. The function computed is similar to a Verifiable Delay Function (VDF); it is a SHA-256 hash chain. While it is not efficiently verifiable (the verification takes the same resources as the computation, but it is parallelizable), for practical purposes, we can consider it like a VDF. It takes an input and computes a deterministic output based on it, and anyone can verify that this output is correct. Furthermore, it seems unlikely that hash chains can be parallelized in a meaningful way, so it takes a certain amount of “wall clock time” to compute the function.
Like many Proof of Stake (PoS) chains, Solana has a deterministic block proposer schedule. Whenever a proposer creates a block, they must include a PoH proof that the 400ms block delay has elapsed. Sometimes, block proposers don’t show up, meaning the next proposer in the schedule has to create a block and “skip” over the missed slot. In this case, they would have to provide an 800ms PoH. More generally, to skip k slots, a 400ms * (k + 1) PoH must be computed.
In practice, this mechanism ensures that blocks are spaced by 400ms. Concretely, if block proposer n shows up on time, proposer n+1 cannot create a concurrent block (that skips slot n) without computing a PoH at twice the speed.
How other chains solve this
The common solution is to assign a fixed time to slots. So in Solana’s case, if slot n is at 12 noon, then n+1 can only be proposed at 12:00:00.40. This is enforced by application of the fork choice rule: No block that is ahead of its time will be considered for the fork choice rule, and thus, for voting. (In Solana’s terms, where there is no fork choice rule, this simply would mean that nodes would not consider block n+1 for voting until 12:00:00.40).
The challenge with this algorithm is that it only works if clocks are well synchronized. In practice, NTP does a good job at synchronizing clocks within 10ms or so. But under adversarial conditions, it is indeed harder to keep this synchronization. This is Solana’s main argument why simple synchronized clocks are not enough, and the Proof-of-History construction is necessary. I think this is a valid argument; while I believe that time sync protocols can be hardened, that in itself is also a difficult task.
An Alternative Solution
Here, I propose a solution that has the same properties as Proof of History but without the need for explicit delay computations. The key idea is to use the relative time of the last confirmed block as a reference rather than fixing an absolute time for future slots.
Let’s assume the last block in consensus is at height n and was proposed at time t. By “in consensus,” voting on this block is complete, and it has been confirmed. Note that t is not the time when consensus is achieved but when the node first receives the block. Each node may have a slightly different view of t due to network propagation delays.
From this point, we can determine the times for subsequent slots n+k as t + (avg time) × k. For example, if the average propagation time of the last few blocks is 400ms, then a proposal for slot n+k will not be considered for voting until the time t + 400ms × k. Any proposals received before this time will simply be queued for later and not voted on until appropriate.
The practical implication of this approach is that the leader for slot n+1 would have at least 400ms to make their proposal, ensuring that their block can propagate in time. Assuming their block propagates as quickly as the previous one, it will be considered for slot n+1 if sent before time t + 400ms. This timing mechanism guarantees the same block ordering property that Proof of History enforces without requiring a fixed computation delay between blocks.
Final Thoughts
Advancements in hardware and client software will enable Solana to process more transactions efficiently, aligning with Moore’s Law. However, the Jevons Paradox suggests that increased efficiency may drive higher computational demands. Hence, this allows the network to achieve more feats, such as raising the block limit and further shortening the block times, allowing for optimum computational power utilization.
Furthermore, the Solana community has been able to show that building blocks in parallel is possible, as the network validator was able to produce a block in under 110 milliseconds, and this means as Solana optimizes its execution layer, block propagation times may continue to decrease, further enhancing network performance.
I appreciate you taking the time to read through this piece.
