Understanding Solana's Consensus Mechanism: Delegated Proof of Stake and Proof of History
TechFlow Selected TechFlow Selected
Understanding Solana's Consensus Mechanism: Delegated Proof of Stake and Proof of History
This article aims to highlight two architectures that play a crucial role in Solana and contribute to its high throughput: DPoS and PoH.
Navigating Web3 tides with focused insightsAuthor: Cookies Research
Translation: Block unicorn
A blockchain's consensus mechanism is responsible for validating the legitimacy of transactions and adding them to the blockchain in accurate order. Depending on the chosen consensus mechanism, the efficiency of validation and ordering varies, resulting in different levels of throughput. In the blockchain space, Solana is a high-performance chain with a 400-millisecond block time, averaging between 2,000 and 3,000 transactions per second (TPS), and a theoretical peak TPS of 65,000 (for reference, Ethereum’s TPS is around 12).
This article aims to highlight two architectural components critical to Solana—its delegated proof-of-stake (DPoS) consensus mechanism and Proof of History (PoH)—both of which contribute significantly to its high throughput.
1. Traditional Consensus Mechanisms
Let’s begin by understanding a key bottleneck in blockchains: scalability.
Each node in a distributed blockchain network has its own internal clock, operating according to this local system time. When a transaction occurs, the node timestamps it based on this local system clock.
The image below illustrates the internal clocks within nodes:
The final confirmation or rejection of transaction timestamps also relies on this local system clock. In traditional consensus mechanisms—such as Proof of Work (PoW) and Proof of Stake (PoS)—all nodes must communicate with each other to synchronize their local clocks, ensuring consistent understanding of time when processing transactions. This inter-node communication helps establish a shared temporal reference, aligning the entire network’s perception of time to coordinate transaction ordering and confirmation.
For a distributed blockchain with thousands of nodes spread globally, discrepancies among local system clocks are inevitable, leading to inconsistent transaction timestamps across nodes. This becomes problematic when nodes need to reach agreement on which transactions occurred and their sequence within blocks. This is known as the timestamp synchronization problem, which worsens and grows more complex as the network scales up node count to enhance decentralization.
Ultimately, this opens a potential pathway for malicious attacks. Time discrepancies allow bad actors to broadcast fake transactions with timestamps resembling legitimate ones, attempting to take control of the network. To prevent transaction manipulation, significant time and computational power are required to verify timestamp accuracy. This can lead to delays in block confirmation, or even block rejection (as nodes may vote a block invalid due to conflicting timestamps).
2. What is Proof of History (PoH)?
Proof of History (PoH) in Solana is used to prove that transactions are correctly ordered, and this ordering can be easily verified by validators in the network.
Contrary to the scenario described in Section 1—where each node operates on its independent clock—PoH functions like a global clock that all nodes use to verify the passage of time between two events. With this global clock, nodes view the same transaction history, eliminating any disagreement about transaction order. This enables rapid consensus, greatly reducing the time required to validate and add transactions to the blockchain.
PoH relies on a cryptographic method to create a continuous, time-ordered record of transactions. Let’s dive deeper into how it works.
3. Technical Deep Dive into PoH
Each transaction is processed using SHA-256, a cryptographic hash function known for taking any input and producing a unique, unpredictable output. When a transaction is hashed, its output becomes the input for the next transaction’s hash. This process establishes an inherent order among transactions within the hash outputs, forming a long, continuous chain.
PoH leverages Verifiable Delay Functions (VDFs), which play a crucial role in verifying the passage of time within a blockchain. VDFs are computationally intensive functions that depend not only on the previous hash but also incorporate elapsed time. This mechanism allows Solana to cryptographically demonstrate that real time has passed, generating sequential outputs. As a result, there is a clear, verifiable transaction order, ensuring a consistent timeline of events. Validators can therefore easily verify how much time has elapsed, further enhancing the network’s trustworthiness.
The use of PoH in Solana adds a robust layer of security and integrity. Tampering with any part of the hash chain would require recomputing all subsequent hashes—an effort-intensive task that protects the network from unauthorized changes.
PoH significantly reduces the amount of information validators need to process per block. By using the hashed version of the latest transaction state, block confirmation times are drastically shortened. When a validator (or replica node) receives a block, the PoH sequence provides them with a cryptographically reliable transaction order they can trust without needing to revalidate. This efficiency is vital for accelerating the consensus mechanism, enabling the network to quickly select and transition to the next validator for block validation.
4. Delegated Proof of Stake (DPoS)
With a better understanding of PoH, this section explains how PoH integrates into Solana’s consensus mechanism—Delegated Proof of Stake (DPoS).
In DPoS, every validator that stakes $SOL can participate in network governance—voting on the validity of blocks and deciding whether to add them to the blockchain. $SOL holders who do not wish to directly participate in the staking process (including you and me) can delegate their tokens to other validators, effectively making them delegators. This delegation assigns voting power—proportional to the amount of $SOL owned—to these validators. In return for staking $SOL, delegators receive a portion of the block rewards.
The DPoS system operates on the principle that nodes with larger stakes are more likely to be selected to validate transactions and add them to the blockchain. The opportunity to earn block rewards incentivizes nodes to maintain high performance and integrity.
Now that we understand both DPoS and PoH, let’s combine this knowledge to outline what a typical block confirmation looks like on Solana.
5. High-Level Overview of Solana’s Consensus Mechanism
1. Leader Node Selection: The leader node is responsible for generating the PoH sequence (Proof of History ordering transactions) and creating the block.
This selection is based on the node’s stake weight, which increases as token holders delegate their $SOL to it. The leadership role rotates among validators.
2. Timestamping Transactions: The leader node receives transactions and uses PoH to timestamp them, establishing transaction order.
3. Block Creation: Using the sequence from PoH, the leader node then begins constructing a block.
4. Block Propagation: The newly created block is sent to replica nodes (other validators in the distributed network).
5. Transaction Validity Verification: Replica nodes verify two components:
a. Transaction Order: Using the PoH sequence to verify that transactions are correctly ordered. Because it acts as a global clock, this verification does not require round-trip communication between nodes (unlike common consensus mechanisms such as PoW and PoS).
b. Transaction Validity: Checking that transactions comply with network rules and are valid.
6. Block Finalization: After verifying transaction order and validity, the block is added to the blockchain. The next leader node is then selected, and the entire process restarts.
Conclusion
Solana continues to relentlessly improve its blockchain architecture. Recent developments include QUIC, stake-weighted QoS, and localized fee markets. Additionally, the ecosystem eagerly anticipates significant efficiency gains from the rollout of Firedancer. Notably, Solana’s unique architecture—OPOS (Only on Solana)—may unlock new use cases.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
cookies
