Subscribe to Cookies Research
Cookies ResearchCoW Swap: Intents, MEV, and Batch Auctions
Low Fees and MEV-Resistant Trades: Made possible through intent-based architectureSpecial thanks to Anna and Alex for feedback and input on CoW Swap and its novel design mechanismsKey TakeawaysCoW Swap is an intent-based application that allows users to leverage signed messages to express their intent to trade (e.g. swap token A to token B)A batch auction mechanism is utilized, in which a network of solvers compete amongst each other to maximize user orders surplus, via Coincidence of Wants (...
Cookies Research1inch Fusion: Cost-Efficient, MEV-resistant Swaps
Key Takeaways1inch Fusion offers users the most favourable swap rates while being MEV-resistantA dutch auction model is utilized, where the swap rate is decreased over timeOrders are filled by resolvers, which are professional market makers, to give the best ratesUsers get to swap gas-free, as gas is paid by the resolversWhat is 1inch?1inch is a decentralized exchange (DEX) aggregator that aggregates liquidity across the various DEXs. This contributes to deep liquidity on 1inch, offering user...
Cookies ResearchMonad: Highly Performant, Parallelized, EVM Compatible L1
Summary thread available here.Key TakeawaysHigh Performance | Solid stats 10,000 TPS. 1 second block time. 1 second finality.EVM Compatible | Building is a piece of cake Full EVM Bytecode Compatibility: Applications built for Ethereum can be deployed on Monad with no code changes Full Ethereum RPC Compatibility: User-facing infrastructure (e.g. MetaMask) can be used seamlesslyUnique Architecture | The core to high performance 2 main fundamental architecture employed by Monad to allow for high...
<100 subscribers
Cookies ResearchCoW Swap: Intents, MEV, and Batch Auctions
Low Fees and MEV-Resistant Trades: Made possible through intent-based architectureSpecial thanks to Anna and Alex for feedback and input on CoW Swap and its novel design mechanismsKey TakeawaysCoW Swap is an intent-based application that allows users to leverage signed messages to express their intent to trade (e.g. swap token A to token B)A batch auction mechanism is utilized, in which a network of solvers compete amongst each other to maximize user orders surplus, via Coincidence of Wants (...
Cookies Research1inch Fusion: Cost-Efficient, MEV-resistant Swaps
Key Takeaways1inch Fusion offers users the most favourable swap rates while being MEV-resistantA dutch auction model is utilized, where the swap rate is decreased over timeOrders are filled by resolvers, which are professional market makers, to give the best ratesUsers get to swap gas-free, as gas is paid by the resolversWhat is 1inch?1inch is a decentralized exchange (DEX) aggregator that aggregates liquidity across the various DEXs. This contributes to deep liquidity on 1inch, offering user...
Cookies ResearchMonad: Highly Performant, Parallelized, EVM Compatible L1
Summary thread available here.Key TakeawaysHigh Performance | Solid stats 10,000 TPS. 1 second block time. 1 second finality.EVM Compatible | Building is a piece of cake Full EVM Bytecode Compatibility: Applications built for Ethereum can be deployed on Monad with no code changes Full Ethereum RPC Compatibility: User-facing infrastructure (e.g. MetaMask) can be used seamlesslyUnique Architecture | The core to high performance 2 main fundamental architecture employed by Monad to allow for high...
Share Dialog
Share Dialog
Table of Contents:
Traditional Consensus Mechanisms
What is Proof-of-History (PoH)
Technical Dive into PoH
Delegated Proof-of-Stake (DPoS)
High Level Overview of Solana’s Consensus Mechanism
Conclusion
A blockchain’s consensus mechanism is responsible for validating transactions’ validity and adding them to the blockchain in an accurate sequence. Depending on the consensus mechanism chosen, the efficiency of the validation and ordering processes differs, resulting in different levels of throughput. In the realm of blockchains, Solana is a high-performing chain, with a 400ms block time and transactions per second (TPS) averaging between 2,000 to 3,000, with a theoretical peak TPS of 65,000 (for reference, Ethereum’s TPS is roughly 12).
This article aims to highlight a couple of Solana’s architectures that play a critical role in contributing to it’s high throughput, namely it’s Delegated Proof-of-Stake (DPoS) consensus mechanism and Proof-of-History (PoH) mechanism.
Let’s begin by understanding one of the key existing bottlenecks of blockchains: scalability.
Each node in a decentralized blockchain network has its own internal clock that it operates by. When a transaction occurs, nodes will timestamp the transaction according to this local system clock.
The eventual confirmation or rejection of the transactions will also be timestamped according to this local system block. With traditional consensus mechanisms such as Proof-of-Work (PoW) and Proof-of-Stake (PoS), all the nodes will have to communicate with each other to establish that time has passed.
For a decentralized blockchain with thousands of nodes all over the world, discrepancies between the nodes’ local system clocks are bound to surface, resulting in the timestamps of transactions differing between nodes. This emerges as a problem when nodes have to reach a consensus with regards to which transactions have taken place and the order of these transactions in the block. This is known as the timestamp synchronization problem and becomes more severe and complex when a network enhances its decentralization by increasing the number of nodes.
Eventually, this creates a possible path for malicious attacks. The discrepancy in time allows malicious actors to broadcast fake transactions that are similar to the real timestamps in an attempt to take over the network. To prevent this manipulation of transactions, a lot of time and processing power need to be spent to verify the timestamp accuracy. This can potentially result in a delay in block confirmation or even block rejection (nodes might vote for the block to be invalid because of the different timestamps).
Proof-of-History (PoH) is used in Solana to prove that transactions are placed in the correct sequence, and this can be easily verified by validators in the network.
Contrary to what was mentioned in section 1, where nodes have their individual clocks, PoH can be thought of as a global block that all nodes use to verify the passage of time between two events. With this universal clock, nodes view the same historical record of transactions, abstracting away any potential disagreement on transaction ordering. This allows for consensus to be reached quickly and significantly reduces the time taken for a transaction to be verified and added to the blockchain.
PoH relies on a cryptographic method to create a continuous, chronological record of transactions. Let’s dive a bit deeper into this.
Each transaction is processed through SHA-256, a cryptographic hash function known for its ability to take any input and produce a unique, unpredictable output. When a transaction is hashed, its output becomes the input for the next transaction's hash. This process results in an inbuilt order of transactions within the hashed outputs, creating a long, continuous chain.
PoH leverages Verifiable Delay Functions (VDFs), which are essential in verifying the passage of time within the blockchain. VDFs are computationally intensive functions that not only depend on the previous hash but also incorporate the time elapsed. This mechanism allows Solana to demonstrate, cryptographically, that real time has passed in generating sequential outputs. As a result, there's a clear, verifiable order of transactions, ensuring one consistent timeline of events. Validators can thus easily verify how much time has passed, 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 necessitate recalculating all subsequent hashes, an effort-intensive endeavor that safeguards the network against alterations.
PoH significantly reduces the amount of information validators need to process per block. By using hashed versions of transactions' latest state, block confirmation times are drastically shortened. When validators (or replicator nodes) receive a block, the PoH sequence provides them with a cryptographically reliable transaction order, which they can trust without re-verification. This efficiency is vital in expediting the consensus mechanism, as the network can swiftly select and move on to the next validator for block validation.
With a better understanding of PoH, this section explains how PoH is utilized in Solana’s consensus mechanism - DPoS.
In DPoS, every validator that stakes $SOL will be able to participate network governance - voting on the validity of blocks and whether it should be added to the blockchain. $SOL holders (me and you) who prefer not to directly engage in the staking process can delegate their tokens to other validators, effectively making them delegators. This delegation process allocates delegators’ voting rights (proportional to the amount of $SOL they have) to these validators. In return for staking $SOL, the delegators will receive a portion of the block reward.
The DPoS system operates on the principle that nodes with larger stakes have a higher likelihood of being chosen to validate transactions and add them to the blockchain. This opportunity to earn block rewards incentivizes nodes to maintain a high level of performance and integrity.
Given an understanding of both DPoS and PoH, let’s put the knowledge together to get an overview of what a typical block confirmation will look like on Solana.
Selection of a Leader Node
The leader node will be responsible for generating a PoH sequence (ordering transactions) and creating blocks.
This selection process is based on the stake weight a node has, which is increased by having token holders delegate to them. The leader role will be rotated among validators.
Timestamping Transactions
The leader node will receive transactions, and timestamp them using PoH to give rise to a transaction order.
Block Creation
With the sequence from PoH, the leader node then proceeds to create a block
Block Propagation
The newly created block will be sent to replicator nodes (the other validators within the decentralized network)
Transaction Validity Verification
Replicator nodes will verify the following two components:
Transaction Order: Verify that the transactions are in the right order by using the PoH sequence. Since it is an universal clock, this verification does not require back-and-forth communication between nodes (as with common consensus mechanisms like PoW and PoS).
Transaction Validity: Check that transactions adhere to network rules and are valid.
Block Finalization
Upon verification of both transaction order and validity, the block will be added to the blockchain. The next leader node will be selected, and the process starts again.
Solana has been working tirelessly to improve the architecture of its blockchain, with recent developments including QUIC, stake-weighted QoS and localized fee markets. In addition, the ecosystem is anticipating a significant improvement to its efficiency with the launch of Firedancer. It is worth keeping a lookout for the new use cases that can be built on top of Solana with its unique architecture - OPOS (Only Possible on Solana).
In the meantime, do check out the protocols built on Solana here and try interacting with them!
Table of Contents:
Traditional Consensus Mechanisms
What is Proof-of-History (PoH)
Technical Dive into PoH
Delegated Proof-of-Stake (DPoS)
High Level Overview of Solana’s Consensus Mechanism
Conclusion
A blockchain’s consensus mechanism is responsible for validating transactions’ validity and adding them to the blockchain in an accurate sequence. Depending on the consensus mechanism chosen, the efficiency of the validation and ordering processes differs, resulting in different levels of throughput. In the realm of blockchains, Solana is a high-performing chain, with a 400ms block time and transactions per second (TPS) averaging between 2,000 to 3,000, with a theoretical peak TPS of 65,000 (for reference, Ethereum’s TPS is roughly 12).
This article aims to highlight a couple of Solana’s architectures that play a critical role in contributing to it’s high throughput, namely it’s Delegated Proof-of-Stake (DPoS) consensus mechanism and Proof-of-History (PoH) mechanism.
Let’s begin by understanding one of the key existing bottlenecks of blockchains: scalability.
Each node in a decentralized blockchain network has its own internal clock that it operates by. When a transaction occurs, nodes will timestamp the transaction according to this local system clock.
The eventual confirmation or rejection of the transactions will also be timestamped according to this local system block. With traditional consensus mechanisms such as Proof-of-Work (PoW) and Proof-of-Stake (PoS), all the nodes will have to communicate with each other to establish that time has passed.
For a decentralized blockchain with thousands of nodes all over the world, discrepancies between the nodes’ local system clocks are bound to surface, resulting in the timestamps of transactions differing between nodes. This emerges as a problem when nodes have to reach a consensus with regards to which transactions have taken place and the order of these transactions in the block. This is known as the timestamp synchronization problem and becomes more severe and complex when a network enhances its decentralization by increasing the number of nodes.
Eventually, this creates a possible path for malicious attacks. The discrepancy in time allows malicious actors to broadcast fake transactions that are similar to the real timestamps in an attempt to take over the network. To prevent this manipulation of transactions, a lot of time and processing power need to be spent to verify the timestamp accuracy. This can potentially result in a delay in block confirmation or even block rejection (nodes might vote for the block to be invalid because of the different timestamps).
Proof-of-History (PoH) is used in Solana to prove that transactions are placed in the correct sequence, and this can be easily verified by validators in the network.
Contrary to what was mentioned in section 1, where nodes have their individual clocks, PoH can be thought of as a global block that all nodes use to verify the passage of time between two events. With this universal clock, nodes view the same historical record of transactions, abstracting away any potential disagreement on transaction ordering. This allows for consensus to be reached quickly and significantly reduces the time taken for a transaction to be verified and added to the blockchain.
PoH relies on a cryptographic method to create a continuous, chronological record of transactions. Let’s dive a bit deeper into this.
Each transaction is processed through SHA-256, a cryptographic hash function known for its ability to take any input and produce a unique, unpredictable output. When a transaction is hashed, its output becomes the input for the next transaction's hash. This process results in an inbuilt order of transactions within the hashed outputs, creating a long, continuous chain.
PoH leverages Verifiable Delay Functions (VDFs), which are essential in verifying the passage of time within the blockchain. VDFs are computationally intensive functions that not only depend on the previous hash but also incorporate the time elapsed. This mechanism allows Solana to demonstrate, cryptographically, that real time has passed in generating sequential outputs. As a result, there's a clear, verifiable order of transactions, ensuring one consistent timeline of events. Validators can thus easily verify how much time has passed, 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 necessitate recalculating all subsequent hashes, an effort-intensive endeavor that safeguards the network against alterations.
PoH significantly reduces the amount of information validators need to process per block. By using hashed versions of transactions' latest state, block confirmation times are drastically shortened. When validators (or replicator nodes) receive a block, the PoH sequence provides them with a cryptographically reliable transaction order, which they can trust without re-verification. This efficiency is vital in expediting the consensus mechanism, as the network can swiftly select and move on to the next validator for block validation.
With a better understanding of PoH, this section explains how PoH is utilized in Solana’s consensus mechanism - DPoS.
In DPoS, every validator that stakes $SOL will be able to participate network governance - voting on the validity of blocks and whether it should be added to the blockchain. $SOL holders (me and you) who prefer not to directly engage in the staking process can delegate their tokens to other validators, effectively making them delegators. This delegation process allocates delegators’ voting rights (proportional to the amount of $SOL they have) to these validators. In return for staking $SOL, the delegators will receive a portion of the block reward.
The DPoS system operates on the principle that nodes with larger stakes have a higher likelihood of being chosen to validate transactions and add them to the blockchain. This opportunity to earn block rewards incentivizes nodes to maintain a high level of performance and integrity.
Given an understanding of both DPoS and PoH, let’s put the knowledge together to get an overview of what a typical block confirmation will look like on Solana.
Selection of a Leader Node
The leader node will be responsible for generating a PoH sequence (ordering transactions) and creating blocks.
This selection process is based on the stake weight a node has, which is increased by having token holders delegate to them. The leader role will be rotated among validators.
Timestamping Transactions
The leader node will receive transactions, and timestamp them using PoH to give rise to a transaction order.
Block Creation
With the sequence from PoH, the leader node then proceeds to create a block
Block Propagation
The newly created block will be sent to replicator nodes (the other validators within the decentralized network)
Transaction Validity Verification
Replicator nodes will verify the following two components:
Transaction Order: Verify that the transactions are in the right order by using the PoH sequence. Since it is an universal clock, this verification does not require back-and-forth communication between nodes (as with common consensus mechanisms like PoW and PoS).
Transaction Validity: Check that transactions adhere to network rules and are valid.
Block Finalization
Upon verification of both transaction order and validity, the block will be added to the blockchain. The next leader node will be selected, and the process starts again.
Solana has been working tirelessly to improve the architecture of its blockchain, with recent developments including QUIC, stake-weighted QoS and localized fee markets. In addition, the ecosystem is anticipating a significant improvement to its efficiency with the launch of Firedancer. It is worth keeping a lookout for the new use cases that can be built on top of Solana with its unique architecture - OPOS (Only Possible on Solana).
In the meantime, do check out the protocols built on Solana here and try interacting with them!
No comments yet