This article provides an explanation of the two key mechanisms that play a crucial role in Solana’s high throughput: Delegated Proof-of-Stake (DPoS) and Proof-of-History (PoH). The article, titled “Solana: Delegated Proof-of-Stake (DPoS) and Proof-of-History (PoH)”, is compiled and written by Block Unicorn based on research from Cookies Research.
Table of Contents:
1. Traditional Consensus Mechanisms
2. What is Proof-of-History (PoH)?
3. A Technical Deep Dive into PoH
4. Delegated Proof-of-Stake (DPoS)
5. High-Level Overview of Solana’s Consensus Mechanism
Conclusion
The consensus mechanism of a blockchain is responsible for validating the validity of transactions and adding them to the blockchain in an accurate order. The efficiency of the validation and ordering process varies depending on the chosen consensus mechanism, resulting in different levels of throughput. In the field of blockchain, Solana is a high-performance chain with a block time of 400 milliseconds and an average transactions per second (TPS) ranging from 2,000 to 3,000, with a theoretical peak TPS of 65,000 (for reference, Ethereum’s TPS is approximately 12).
This article aims to highlight the two frameworks in Solana that play a crucial role in its high throughput: the Delegated Proof-of-Stake (DPoS) consensus mechanism and the Proof-of-History (PoH) mechanism.
Let’s start by understanding a key bottleneck in blockchain: scalability.
In a decentralized blockchain network, each node has its own internal clock and executes based on this local system clock. When a transaction occurs, the node adds a timestamp to the transaction based on this local system clock.
The following image shows the internal clocks of nodes:
The final timestamp for confirming or rejecting a transaction is also based on this local system clock. In traditional consensus mechanisms such as Proof of Work (PoW) and Proof of Stake (PoS), all nodes need to communicate with each other to coordinate their local clocks and ensure a consistent understanding of time when processing transactions. Communication between nodes helps establish a common time reference to ensure a consistent perception of time throughout the network, thereby coordinating the order and confirmation of transactions.
For a decentralized blockchain with thousands of nodes distributed worldwide, it is inevitable that there will be differences in the local system clocks of nodes, resulting in inconsistencies in the timestamps of transactions between different nodes. This becomes a problem when nodes need to reach consensus on which transactions have occurred and the order of these transactions in a block. This is known as the timestamp synchronization problem, which becomes more severe and complex as the network enhances decentralization by increasing the number of nodes.
Ultimately, this creates a possible pathway for malicious attacks. The differences in time allow malicious actors to broadcast false transactions with similar timestamps to manipulate the network. To prevent manipulation of transactions, a significant amount of time and processing power is required to verify the accuracy of timestamps. This can lead to delays in block confirmations or even rejection of blocks (as nodes may vote to consider a block invalid due to different timestamps).
Proof-of-History (PoH) is used in Solana to prove that transactions are correctly ordered, which can be easily verified by validators in the network.
In contrast to the situation where each node has its independent clock mentioned in the first section, PoH can be seen as a global clock that all nodes use to verify the passage of time between two events. Through this global clock, nodes view the same transaction history, eliminating any potential divergence in transaction order. This allows for quick consensus, significantly reducing the time it takes to verify transactions and add them to the blockchain.
PoH relies on a cryptographic technique to establish a continuous, time-ordered record of transactions. Let’s delve deeper into this.
Each transaction undergoes SHA-256 processing, which is a cryptographic hash function known for its ability to accept any input and generate a unique, unpredictable output. When a transaction is hashed, its output becomes the input for the next transaction hash. This process establishes an inherent order of transactions in the hash output, forming a long and continuous chain.
PoH (Proof-of-History) leverages a Verifiable Delay Function (VDF), which emphasizes the importance of verifying the passage of time in a blockchain. VDF is a computationally intensive function that depends not only on the previous hash but also on the time elapsed. This mechanism allows Solana to cryptographically demonstrate the passage of true time, generating a continuous output. As a result, there is a clear and verifiable transaction order, ensuring a consistent timeline of events. Validators can easily verify how much time has passed, further enhancing the network’s credibility.
The use of PoH (Proof-of-History) in Solana adds a powerful layer of security and integrity. Tampering with any part of the hash chain would require re-computing all subsequent hashes, which is a computationally intensive task that protects the network from alterations.
PoH (Proof-of-History) significantly reduces the amount of information that validators need to process for each block. By using the most recent version of the hash for the state of transactions, the block confirmation time is greatly shortened. When validators (or replica nodes) receive a block, the PoH (Proof-of-History) sequence provides them with a cryptographically reliable transaction order that they can trust without the need for re-verification. This efficiency is crucial for speeding up the consensus mechanism as the network can quickly choose and move to the next validator for block validation.
Building on a better understanding of PoH, this section will explain how PoH is applied in Solana’s consensus mechanism (DPoS).
In DPoS, each validator who stakes SOL tokens can participate in network governance by voting on the validity of blocks and deciding whether to add them to the blockchain. Individuals who do not want to directly participate in the proof-of-stake process (including you and me) can delegate their tokens to other validators, effectively making them delegates. This delegation process distributes the voting power of the delegates (proportional to the amount of SOL they hold) to these validators. As a reward for staking SOL, delegates receive a portion of the block rewards.
The operation of the DPoS system is such that nodes with larger stakes are more likely to be selected to validate transactions and add them to the blockchain, increasing their chances of receiving block rewards and incentivizing nodes to maintain a high level of performance and integrity.
Now that we have an understanding of both DPoS and PoH, let’s combine this knowledge to outline what a typical block confirmation looks like on Solana.
1. Selection of Leader Node: The leader node is responsible for generating the PoH sequence (history proof sorting transactions) and constructing a block.
The selection process is based on the node’s stake weight, which is increased by tokens delegated to it by token holders. The leadership role rotates among validators.
2. Timestamping Transactions: The leader node receives transactions and timestamps them using PoH, forming the transaction order.
3. Block Construction: Using the sequence from PoH, the leader node subsequently constructs a block.
4. Block Propagation: The newly constructed block is propagated to replica nodes (other validators in the decentralized network).
5. Transaction Validity Verification: Replica nodes verify two components:
a. Transaction Order: They verify if the transactions are correctly ordered using the PoH sequence. This verification does not require round-trip communication between nodes (unlike common consensus mechanisms like PoW and PoS) as it is based on a global clock.
b. Transaction Validity: They check if the transactions comply with network rules and are valid.
6. Block Finalization: After validating the transaction order and validity, the block is added to the blockchain. The next leader node is then chosen, and the entire process starts again.
Solana has been continuously working on improving its blockchain architecture, with recent developments including QUIC, Stake-weighted QoS, and a localized fee market. Additionally, the ecosystem is eagerly awaiting the launch of Firedancer, which is expected to significantly enhance its efficiency. Of note, Solana’s unique architecture, OPOS (Only Proof-of-History), may bring new use cases.
Related Reports
Solana can be an Ethereum Layer 2! Founder claims compatibility with EVM after shard upgrade.
Behind the surge of BONK: Gotbit, the market maker planning to make waves on Solana?
Stablecoin breaking into Solana’s ecosystem: Will Paxos’ USDP explode?