Despite the general argument for the adoption of blockchain technology in terms of security, privacy, and immutability, various attacks can occur on blockchain technology in reality. This article summarizes systematic details on Long-Range attacks for Proof-of-Stake protocols. If successful, these attacks can seize the main chain and partially or completely rewrite transaction records stored on the blockchain. To do this, we will explain blockchain, consensus protocol methods (POS, POW, ...), basic properties, disadvantages, and attack vectors.
The purpose of this article is to review and study the paper "A Survey on Long-Range Attacks for Proof of Stake Protocols" after reading it. The paper was written by:
Evangelos Deirmentzoglou (Department of Informatics, University of Piraeus, Piraeus, Greece)
Georgios Papakyriakopoulos (Cisco Security Services, Marousi, Greece)
Constantinos Patsakis (Department of Informatics, University of Piraeus, Piraeus, Greece)
The paper can be found at
https://ieeexplore.ieee.org/document/8653269/
Various security issues have been raised in the blockchain ecosystem. To solve the problem of maintaining transaction order and preventing Bitcoin's double spending, an immutable public ledger that everyone can see and cannot change was needed. To address these issues, the distributed P2P linked-structure blockchain technology was introduced using powerful cryptographic primitives. This structure groups transactions into blocks that are validated by the blockchain user group.
In traditional blockchains like Bitcoin, users compete to solve difficult cryptographic/mathematical problems that are easy to verify. (This process is called mining.) The winner receives new coins as a reward for their service. Therefore, these blockchains are based on the Proof-of-Work (POW) concept. In practice, it is considered trustworthy because users have invested a considerable amount of computational effort to validate some transactions. On the other hand, in Proof-of-Stake (POS) protocols, users who validate transactions are chosen based on their stake. Therefore, coins are generated to initialize and incentivize validators of the blockchain, and validators receive a share of each transaction fee they validate as a reward. In this context, users are considered trustworthy because they "stake" a portion of their assets to validate blocks.
As more and more famous blockchains, including Ethereum, attempt to transition from Proof-of-Work protocols to Proof-of-Stake, Proof-of-Stake is receiving some attention. This transition can take the form of a hybrid system (POW/POS) or a complete transition to pure Proof-of-Work implementation.
It is to reduce energy consumption as mining is very computationally intensive. Bitcoin mining is statistically consuming more power worldwide, and the actual power consumption can be much higher as many malware perform mining on infected devices without users knowing.
While blockchain is considered inherently very safe and secure for protecting personal information, this is an inaccurate assessment as there are many attacks that can exploit it in various ways. Some of these attacks are somewhat technical and may only be applicable to specific blockchains. It is important to note that many people have treated blockchain as a black box because they have only recently come across it in many cases.
The transition to Proof of Stake focuses on investigating attacks targeting the Proof of Stake protocol, with a particular emphasis on the long-range attack, one of the biggest threats. Weak subjectivity and costless simulation amplify the impact of these attacks in the Proof of Stake protocol compared to the Proof of Work protocol. A long-range attack creates a branch in the original blockchain that can include other transactions and blocks and overtakes the main chain (revision attack).
In the Proof of Work protocol, it is impossible to achieve the effort required to create previous blocks and overtake the main chain. Conversely, an attack on a small number of blocks is considered a short-range attack, which aims to reorganize blocks from a few days to a maximum of several months. The goal of a long-range attack is to rewrite the previous record of the blockchain. To perform this action, it is possible to create forks from the Genesis block of the blockchain, not only targeting recent transactions.
https://github.com/ZhangZhuoSJTU/Web3Bugs
https://www.nevillegrech.com/madmax-oopsla18.pdf
https://arxiv.org/abs/1703.03779
Blockchain can be considered a distributed append-only timestamped data structure. In this way, blockchain provides a distributed P2P network that allows untrusted members to interact in a verifiable way without relying on trusted institutions.
In principle, blockchain stores transactions between participants that are signed by at least one of the participants. Transactions can include physical, digital assets, or state transitions.
When a node, which is a participant in the blockchain, performs a transaction, the transaction is propagated to peer nodes and added to the transaction pool. Some nodes may have higher authority than other nodes and are called full nodes, which are responsible for deciding whether transactions are valid and should be stored on the blockchain. They group transactions into blocks, and all blocks are added to the end of the chain and linked to the previous block by including the hash of the previous block as part of the stored data.
Transactions that are not included in a block are not deleted if they are valid. If a transaction is valid, it will be included in future blocks along with other transactions. This creates a blockchain that can track all possible changes.
The chain has an initial block called the genesis block.
By its very nature, the genesis block can be used to validate all additional blocks and is the only block that all nodes blindly trust. Therefore, when a new node is added to the network, it always comes with a genesis block.
Starting with this block, the node can retrieve all the currently published branches of that blockchain.
In a pure PoS protocol, the genesis block also contains information about the set of validators.
Since there are many nodes and no centralized database, it is possible to exploit the platform by performing multiple transactions, such as fooling peers that the current balance allows them to perform transactions.
create a transaction that stores transaction history or data using an asymmetric key
Propagate the created transaction
Create a block by combining the transactions propagated using the asymmetric key.
Propagate the created block
all users receive the block and synchronize (repeat periodically from step 1)
Mining Node that generates blocks and has all the data.
Full Node that does not generate blocks but only verifies and synchronizes all blocks.
Light Node that does not have all blocks but only some block data and verifies through neighboring nodes.
There is no fixed block generation method, but the most widely used method is the first-come-first-served problem-solving method called Proof of Work (PoW), which is used in Bitcoin. The node that solves the problem first generates a block and receives a block generation reward.
Subsequently, it was improved by giving the block generation rights to nodes that put up a deposit, called Proof of Stake (PoS).
Full nodes are expected to encounter transactions that have been received in different orders and consolidated results may exist.
Nodes must reach a consensus called Consensus.
According to this consensus, transactions must be stored in the blockchain, but there may be damaged branches, which users can track and ignore.
The way nodes reach a consensus is a differentiating factor for most blockchain implementations.
The traditional method introduced with Bitcoin is called Proof of Work (PoW).
In this case, the node must solve complex calculation problems such as hash puzzles based on hashing and contribute a lot of computational effort. In return, it can expect verification of the block.
In the Proof of Stake (PoS) protocol, the trust of the network is limited by digital assets, or the value of each protocol.
The Proof of Stake protocol uses the terms miner or validator instead of a miner.
At any point in the protocol operation, a static or dynamic validator can stake its assets on the network to create blocks and verify value.
Byzantine Fault Tolerance (BFT) and its variations are another approach to consensus.
Since there is no unique central repository and a complete summary of all transactions that nodes pass is not available, nodes have different blockchain branches until they reach consensus.
Therefore, nodes compete to make their point the main branch of the blockchain.
Summary of Consensus Methods
Typically, in public chain block generation methods, all blockchain nodes compete in a mining format using hash power through Proof of Work (PoW), Proof of Stake (PoS), etc.
PoW: All nodes attempt mining using CPU and GPU, and nodes with low performance may not generate blocks at all.
PoS: Nodes that have staked generate blocks, and each node's selection must be made.
Due to the inefficiency of these block generation methods, in internal trusted networks without competition, block generation methods are configured as follows:
POA: A predetermined central node generates blocks periodically.
RAFT: Nodes vote to select a block producer, and if there is no block producer, they vote again to select one.
PBFT: Similar to RAFT, but with different voting methods or numbers of selections.
In principle, all participants in a blockchain network submit their transactions to the transaction pool. For these transactions to be added to the blockchain, they must be verified and mined (in the case of proof-of-work).
In proof-of-work, nodes must invest their processing power to earn the mining reward.
Only the node that completes the task first can receive the reward, and the rest of the nodes waste time and computing power.
Network rewards can be provided by the blockchain system itself in the form of block rewards that mine a certain amount of tokens and pay miners for their efforts.
Another form of reward is transaction fees. Due to congestion in the blockchain network, users can add additional costs to transactions, which are paid as rewards to miners to ensure that the transaction is processed with higher priority.
In both consensus protocols, miners have complete control over their blocks.
Using the transaction pool, miners can fill the block with transactions and prioritize them as they wish.
In addition, since the block size is finite, the priority of transactions is usually determined by transaction fees.
Ethereum miner reward: transaction fees
Bitcoin miner reward: block reward + transaction fees
Therefore, in the blockchain system, miners or validators select some transactions from the transaction pool to add to their blocks.
In a POS system, validators only need to post the block, but in a POW system, miners need to go one step further and solve a hashing puzzle.
Willing miners must pay the cost, and they must perform the work without knowing whether it will be a waste or will result in a financial reward.
Block data is processed through connected nodes.
Verify that the block data has been generated correctly.
Check if it is a new block that refers to the final block.
Verify the nonce and appropriate creator of the block.
Verify the hash value of the Merkle tree containing the transaction data.
Verify the Merkle tree value and block denier value to derive the hash value of the block data.
Check the integrity of the hash value of the processed block data.
Once the verification of the block data is completed, it is recognized as a valid block and propagated to the connected nodes.
After confirming the synchronization of the entire network, prepare to receive and verify new block data.
A strong cryptographic graphical or mathematical problem whose difficulty dynamically varies with the computing power of the entire netwok, usually to keep the block generation rate stable (Bitcoin generates one block every 10 minutes on average).
For example, in Bitcoin, the problem is to find a subthreshold hash.
More precisely, we generate a block whose block header consists of a hash of the previous block, a network difference, a timestamp, a block version number, a merkle proof of the transaction we think should be added to the blockchain, and a nonce.
Using different nonces, it tries to find a hash that is lower than a threshold set by the network difficulty.
When a node finds such a nonce, it propagates it, and when other nodes validate it, the block is added to the blockchain.
Unlike POW protocols like Bitcoin, this concept does not rely on hashing or computing power to distribute "ownership" among peers in the network.
The 'ownership' between network peers stems from their ownership of a 'stake' in the form of an underlying currency (coin) recognized and supported by the blockchain network.
These coins give them the right to vote on the creation and/or validation of blocks on the underlying network.
Users must participate in the staking system as validators. Network users who wish to participate in the staking system must purchase tokens and stake them.
The staking system is usually weighted.
Validators with a larger stake in the system have more voting power as a result.
In a POW system, a cryptographic puzzle exists to define the block generation rate, while in a POS system, this rate is defined in terms of time intervals.
For example, every 10 minutes, one validator is elected to generate a block. Typically, the validator election is done via a pseudo-random generator.
Candidate nodes with more stake are more likely to be elected as block validators.
Once the validators have finished selecting transactions for the block, the block containing all the approved transactions is forged.
The block is then added to the blockchain or delegated to another validator, depending on the type of proof-of-stake protocol in use.
Is it possible to achieve the same level of security (regarding consensus and voting) that Bitcoin-like networks can achieve without depleting the physical resources that are by definition scarce in Bitcoin?
The first implementations of the POS protocol were based on naive assumptions and lacked additional safeguards, leading to problems with many potential adversarial attacks.
To solve the above problem, we devised two main approaches for securing consensus protocols: Byzantine fault-tolerant proof-of-stake and chain-based proof-of-stake algorithms.
It is important to understand the concepts of transactions and block finality, which are directly related to the difference between the two consensus methods.
In a blockchain-based transaction platform, block finality basically refers to the guarantee provided by the blockchain that a well-formed block committed to the blockchain will not be revoked at some future point in time, and thus the transactions it contains will be finalized and can be trusted.
What is Bitcoin's finality guarantee?
In a traditional POW-based system like the Nakamoto consensus implemented in Bitcoin, this type of finality is not immediately guaranteed.
Instead, it relies on the concept of probabilistic finality, which is typically associated with chain-based protocols (regardless of POS or POW proofs).
This type of finality is achieved by continuously reducing the probability that a transaction or block is altered or reversed.
The deeper the block is located within the blockchain, the higher the probability.
For example, when using Bitcoin, most major Bitcoin trading platforms typically wait until at least five blocks have been created on top of the original transaction block before validating the transaction and approving it as trustworthy.
Of course, this approach creates a different problem. Generating six blocks on the Bitcoin chain (the original block and the five subsequent blocks) is typically prohibitively time-consuming, as it can take minutes or even hours for networks that support real-time transactions.
POS based on chain The probabilistic finality principle of the network applies, but the disadvantage is much less because only minimal computing power is required to generate the blocks (the generation of the six-block chain required to validate transactions is much faster).
BFT Proof of Stake Based Network
Take a very different approach to transaction finality in order to confirm and authorize transactions in near real-time on the blockchain.
This type of finality is commonly referred to as absolute finality and is achieved by definition in BFT-based networks based on basic consensus principles.
The idea is that a randomly selected validator proposes a block of transactions.
The remaining validators then vote on whether to accept the block and commit it to the chain, and if a majority of validators vote for the block, the block is committed to the blockchain without reverting.
There are slight variations on absolute finality implemented in various BFT-based Proof of Stake blockchains, but the result is that the immediate and absolute finality of a committed block can always be guaranteed without the risk of a future majority reverting or changing parts of the blockchain.
It is impossible for any implementation of the PoS protocol to achieve absolute finality without sacrificing the availability of the network itself!
In an ideal scenario where we can achieve absolute finality, where no transaction or block can be reverted, all validators registered in the network must reach a single consensus to validate a block.
To do this, they must all vote on the same specific block on the main chain, and they must not vote on different blocks on any fork.
Due to these strict requirements, the network fails to validate blocks most of the time. This is because connectivity issues, node desynchronization, and the downtime of a single validator can interrupt the validation process.
To overcome this limitation, most BFT-based PoS networks use a concept called "Economic Finality", which provides near absolute finality for validated blocks.
The Byzantine Fault Tolerance (BFT) problem is very relevant to distributed computing because it describes many of the problems that nodes face when trying to achieve reliable and secure consensus in an untrusted network.
In such hostile environments, in addition to inherent errors in the communication channel, a group of nodes can maliciously attempt to subvert the process as long as the number of trusted nodes exceeds a certain majority.
In such an implementation, the network follows a round-robin approach, randomly designating a validator node as the leader to propose a new block.
A majority, exceeding 2/3 of all validators in the network, must then agree to accept the proposed block and immediately integrate it as part of the blockchain.
Reaching 2/3 consensus is almost absolute finality.
In practice, this means that the BFT Proof of Stake protocol can tolerate an error rate of up to 1/3 of all participating validator nodes in validating a given block (regardless of whether these errors are due to network errors or malicious behavior), and guarantees that a transaction signed by more than 2/3 of the validator nodes is finalized and cannot be reversed under any future circumstances.
the client node sends a work request (transaction) to the currently designated leader node.
The leader node broadcasts the request to all other participating validator nodes.
Each node independently executes the task and sends a response to the initiating client node with the results of the task.
The result sent by at least 2/3 of all validator nodes is considered the final result of the job.
In the latter case, there may be temporary unavailability or high network latency while recovering from errors that occur when more than 1/3 of validators do not respond.
One of the de facto state engines that implements and delivers BFT Proof-of-Stake blockchain consensus is the Tendermint state-machine (Tendermint Core)
https://docs.tendermint.com/v0.34/introduction/what-is-tendermint.html
fault tolerance up to 1/3 of the total number of validators in the network per block voting/confirmation cycle
requirement for synchronous validator nodes (since finalization occurs in place)
prioritizes consistency over all other properties of the blockchain
consensus safety
immediate and absolute finality of blocks
supports both public and private chain models
Chain-based Proof-of-Stake frameworks take a more conservative approach to defining a secure consensus protocol by mimicking the well-established Proof-of-Work paradigm for achieving consensus.
They do this by linking newly created committed blocks to previous blocks via a hash link to the parent block belonging to the longest previously established chain (generally recognized as a valid chain).
This connection is considered unique and unidirectional, and can be used to validate all subsequent blocks in the longest chain by tracing the connection back from the first block in the chain to the current block.
Verification is done using standard cryptographic signature concepts.
There is no guarantee of finalization during the chaining of a newly created block, instead finalization is achieved probabilistically after enough child blocks are chained to that block and the block is chained 'deep enough' in the chain to be considered 'probabilistically finalized'.
In practice, chain-based proof-of-stake blockchains are not considered consensus-safe, and there is no guarantee that the blockchain will always remain secure.
Rather, they prioritize the availability of the network and can continue to operate even if only some validators are active.
To prevent the blockchain from reaching a finalization bottleneck, the network must ensure that block generation at the chain head is always slightly faster than block finalization progress, so that "depth" - a safety requirement for committed blocks - is routinely reached.
How POW differs from block finalization
While POW consensus protocols require a fixed number of block iterations to have block finalization (6 for Bitcoin), chain-based POS protocols typically allow each validator node to customize the finalization threshold. This allows the network to individually choose a degree of safety while keeping the performance overhead typically incurred by POW protocols low.
Ensures the availability of the network even under high failure rates.
Accommodate asynchronous validators with customizable safety thresholds and individual safety threshold guarantees.
while blockchain technology offers many benefits in terms of security, privacy, and immutability, it is not invulnerable to attacks. This article specifically highlights the potential for Long-Range attacks on Proof-of-Stake protocols, which could compromise the integrity of the blockchain and alter transaction records. It is important for blockchain developers and users to be aware of these attack vectors and take steps to mitigate the risks associated with them. Overall, continued research and development in the field of blockchain security will be critical in ensuring the long-term viability and adoption of this technology.
In the next article, we'll cover various consensus protocol attacks, long-range attack techniques, and mitigations.
https://mirror.xyz/zer0luck.eth/alYiEbYHPxFaFu8T90ohy5AYLWDHVMdmpYmd_4xJuiM
Despite the general argument for the adoption of blockchain technology in terms of security, privacy, and immutability, various attacks can occur on blockchain technology in reality. This article summarizes systematic details on Long-Range attacks for Proof-of-Stake protocols. If successful, these attacks can seize the main chain and partially or completely rewrite transaction records stored on the blockchain. To do this, we will explain blockchain, consensus protocol methods (POS, POW, ...), basic properties, disadvantages, and attack vectors.
The purpose of this article is to review and study the paper "A Survey on Long-Range Attacks for Proof of Stake Protocols" after reading it. The paper was written by:
Evangelos Deirmentzoglou (Department of Informatics, University of Piraeus, Piraeus, Greece)
Georgios Papakyriakopoulos (Cisco Security Services, Marousi, Greece)
Constantinos Patsakis (Department of Informatics, University of Piraeus, Piraeus, Greece)
The paper can be found at
https://ieeexplore.ieee.org/document/8653269/
Various security issues have been raised in the blockchain ecosystem. To solve the problem of maintaining transaction order and preventing Bitcoin's double spending, an immutable public ledger that everyone can see and cannot change was needed. To address these issues, the distributed P2P linked-structure blockchain technology was introduced using powerful cryptographic primitives. This structure groups transactions into blocks that are validated by the blockchain user group.
In traditional blockchains like Bitcoin, users compete to solve difficult cryptographic/mathematical problems that are easy to verify. (This process is called mining.) The winner receives new coins as a reward for their service. Therefore, these blockchains are based on the Proof-of-Work (POW) concept. In practice, it is considered trustworthy because users have invested a considerable amount of computational effort to validate some transactions. On the other hand, in Proof-of-Stake (POS) protocols, users who validate transactions are chosen based on their stake. Therefore, coins are generated to initialize and incentivize validators of the blockchain, and validators receive a share of each transaction fee they validate as a reward. In this context, users are considered trustworthy because they "stake" a portion of their assets to validate blocks.
As more and more famous blockchains, including Ethereum, attempt to transition from Proof-of-Work protocols to Proof-of-Stake, Proof-of-Stake is receiving some attention. This transition can take the form of a hybrid system (POW/POS) or a complete transition to pure Proof-of-Work implementation.
It is to reduce energy consumption as mining is very computationally intensive. Bitcoin mining is statistically consuming more power worldwide, and the actual power consumption can be much higher as many malware perform mining on infected devices without users knowing.
While blockchain is considered inherently very safe and secure for protecting personal information, this is an inaccurate assessment as there are many attacks that can exploit it in various ways. Some of these attacks are somewhat technical and may only be applicable to specific blockchains. It is important to note that many people have treated blockchain as a black box because they have only recently come across it in many cases.
The transition to Proof of Stake focuses on investigating attacks targeting the Proof of Stake protocol, with a particular emphasis on the long-range attack, one of the biggest threats. Weak subjectivity and costless simulation amplify the impact of these attacks in the Proof of Stake protocol compared to the Proof of Work protocol. A long-range attack creates a branch in the original blockchain that can include other transactions and blocks and overtakes the main chain (revision attack).
In the Proof of Work protocol, it is impossible to achieve the effort required to create previous blocks and overtake the main chain. Conversely, an attack on a small number of blocks is considered a short-range attack, which aims to reorganize blocks from a few days to a maximum of several months. The goal of a long-range attack is to rewrite the previous record of the blockchain. To perform this action, it is possible to create forks from the Genesis block of the blockchain, not only targeting recent transactions.
https://github.com/ZhangZhuoSJTU/Web3Bugs
https://www.nevillegrech.com/madmax-oopsla18.pdf
https://arxiv.org/abs/1703.03779
Blockchain can be considered a distributed append-only timestamped data structure. In this way, blockchain provides a distributed P2P network that allows untrusted members to interact in a verifiable way without relying on trusted institutions.
In principle, blockchain stores transactions between participants that are signed by at least one of the participants. Transactions can include physical, digital assets, or state transitions.
When a node, which is a participant in the blockchain, performs a transaction, the transaction is propagated to peer nodes and added to the transaction pool. Some nodes may have higher authority than other nodes and are called full nodes, which are responsible for deciding whether transactions are valid and should be stored on the blockchain. They group transactions into blocks, and all blocks are added to the end of the chain and linked to the previous block by including the hash of the previous block as part of the stored data.
Transactions that are not included in a block are not deleted if they are valid. If a transaction is valid, it will be included in future blocks along with other transactions. This creates a blockchain that can track all possible changes.
The chain has an initial block called the genesis block.
By its very nature, the genesis block can be used to validate all additional blocks and is the only block that all nodes blindly trust. Therefore, when a new node is added to the network, it always comes with a genesis block.
Starting with this block, the node can retrieve all the currently published branches of that blockchain.
In a pure PoS protocol, the genesis block also contains information about the set of validators.
Since there are many nodes and no centralized database, it is possible to exploit the platform by performing multiple transactions, such as fooling peers that the current balance allows them to perform transactions.
create a transaction that stores transaction history or data using an asymmetric key
Propagate the created transaction
Create a block by combining the transactions propagated using the asymmetric key.
Propagate the created block
all users receive the block and synchronize (repeat periodically from step 1)
Mining Node that generates blocks and has all the data.
Full Node that does not generate blocks but only verifies and synchronizes all blocks.
Light Node that does not have all blocks but only some block data and verifies through neighboring nodes.
There is no fixed block generation method, but the most widely used method is the first-come-first-served problem-solving method called Proof of Work (PoW), which is used in Bitcoin. The node that solves the problem first generates a block and receives a block generation reward.
Subsequently, it was improved by giving the block generation rights to nodes that put up a deposit, called Proof of Stake (PoS).
Full nodes are expected to encounter transactions that have been received in different orders and consolidated results may exist.
Nodes must reach a consensus called Consensus.
According to this consensus, transactions must be stored in the blockchain, but there may be damaged branches, which users can track and ignore.
The way nodes reach a consensus is a differentiating factor for most blockchain implementations.
The traditional method introduced with Bitcoin is called Proof of Work (PoW).
In this case, the node must solve complex calculation problems such as hash puzzles based on hashing and contribute a lot of computational effort. In return, it can expect verification of the block.
In the Proof of Stake (PoS) protocol, the trust of the network is limited by digital assets, or the value of each protocol.
The Proof of Stake protocol uses the terms miner or validator instead of a miner.
At any point in the protocol operation, a static or dynamic validator can stake its assets on the network to create blocks and verify value.
Byzantine Fault Tolerance (BFT) and its variations are another approach to consensus.
Since there is no unique central repository and a complete summary of all transactions that nodes pass is not available, nodes have different blockchain branches until they reach consensus.
Therefore, nodes compete to make their point the main branch of the blockchain.
Summary of Consensus Methods
Typically, in public chain block generation methods, all blockchain nodes compete in a mining format using hash power through Proof of Work (PoW), Proof of Stake (PoS), etc.
PoW: All nodes attempt mining using CPU and GPU, and nodes with low performance may not generate blocks at all.
PoS: Nodes that have staked generate blocks, and each node's selection must be made.
Due to the inefficiency of these block generation methods, in internal trusted networks without competition, block generation methods are configured as follows:
POA: A predetermined central node generates blocks periodically.
RAFT: Nodes vote to select a block producer, and if there is no block producer, they vote again to select one.
PBFT: Similar to RAFT, but with different voting methods or numbers of selections.
In principle, all participants in a blockchain network submit their transactions to the transaction pool. For these transactions to be added to the blockchain, they must be verified and mined (in the case of proof-of-work).
In proof-of-work, nodes must invest their processing power to earn the mining reward.
Only the node that completes the task first can receive the reward, and the rest of the nodes waste time and computing power.
Network rewards can be provided by the blockchain system itself in the form of block rewards that mine a certain amount of tokens and pay miners for their efforts.
Another form of reward is transaction fees. Due to congestion in the blockchain network, users can add additional costs to transactions, which are paid as rewards to miners to ensure that the transaction is processed with higher priority.
In both consensus protocols, miners have complete control over their blocks.
Using the transaction pool, miners can fill the block with transactions and prioritize them as they wish.
In addition, since the block size is finite, the priority of transactions is usually determined by transaction fees.
Ethereum miner reward: transaction fees
Bitcoin miner reward: block reward + transaction fees
Therefore, in the blockchain system, miners or validators select some transactions from the transaction pool to add to their blocks.
In a POS system, validators only need to post the block, but in a POW system, miners need to go one step further and solve a hashing puzzle.
Willing miners must pay the cost, and they must perform the work without knowing whether it will be a waste or will result in a financial reward.
Block data is processed through connected nodes.
Verify that the block data has been generated correctly.
Check if it is a new block that refers to the final block.
Verify the nonce and appropriate creator of the block.
Verify the hash value of the Merkle tree containing the transaction data.
Verify the Merkle tree value and block denier value to derive the hash value of the block data.
Check the integrity of the hash value of the processed block data.
Once the verification of the block data is completed, it is recognized as a valid block and propagated to the connected nodes.
After confirming the synchronization of the entire network, prepare to receive and verify new block data.
A strong cryptographic graphical or mathematical problem whose difficulty dynamically varies with the computing power of the entire netwok, usually to keep the block generation rate stable (Bitcoin generates one block every 10 minutes on average).
For example, in Bitcoin, the problem is to find a subthreshold hash.
More precisely, we generate a block whose block header consists of a hash of the previous block, a network difference, a timestamp, a block version number, a merkle proof of the transaction we think should be added to the blockchain, and a nonce.
Using different nonces, it tries to find a hash that is lower than a threshold set by the network difficulty.
When a node finds such a nonce, it propagates it, and when other nodes validate it, the block is added to the blockchain.
Unlike POW protocols like Bitcoin, this concept does not rely on hashing or computing power to distribute "ownership" among peers in the network.
The 'ownership' between network peers stems from their ownership of a 'stake' in the form of an underlying currency (coin) recognized and supported by the blockchain network.
These coins give them the right to vote on the creation and/or validation of blocks on the underlying network.
Users must participate in the staking system as validators. Network users who wish to participate in the staking system must purchase tokens and stake them.
The staking system is usually weighted.
Validators with a larger stake in the system have more voting power as a result.
In a POW system, a cryptographic puzzle exists to define the block generation rate, while in a POS system, this rate is defined in terms of time intervals.
For example, every 10 minutes, one validator is elected to generate a block. Typically, the validator election is done via a pseudo-random generator.
Candidate nodes with more stake are more likely to be elected as block validators.
Once the validators have finished selecting transactions for the block, the block containing all the approved transactions is forged.
The block is then added to the blockchain or delegated to another validator, depending on the type of proof-of-stake protocol in use.
Is it possible to achieve the same level of security (regarding consensus and voting) that Bitcoin-like networks can achieve without depleting the physical resources that are by definition scarce in Bitcoin?
The first implementations of the POS protocol were based on naive assumptions and lacked additional safeguards, leading to problems with many potential adversarial attacks.
To solve the above problem, we devised two main approaches for securing consensus protocols: Byzantine fault-tolerant proof-of-stake and chain-based proof-of-stake algorithms.
It is important to understand the concepts of transactions and block finality, which are directly related to the difference between the two consensus methods.
In a blockchain-based transaction platform, block finality basically refers to the guarantee provided by the blockchain that a well-formed block committed to the blockchain will not be revoked at some future point in time, and thus the transactions it contains will be finalized and can be trusted.
What is Bitcoin's finality guarantee?
In a traditional POW-based system like the Nakamoto consensus implemented in Bitcoin, this type of finality is not immediately guaranteed.
Instead, it relies on the concept of probabilistic finality, which is typically associated with chain-based protocols (regardless of POS or POW proofs).
This type of finality is achieved by continuously reducing the probability that a transaction or block is altered or reversed.
The deeper the block is located within the blockchain, the higher the probability.
For example, when using Bitcoin, most major Bitcoin trading platforms typically wait until at least five blocks have been created on top of the original transaction block before validating the transaction and approving it as trustworthy.
Of course, this approach creates a different problem. Generating six blocks on the Bitcoin chain (the original block and the five subsequent blocks) is typically prohibitively time-consuming, as it can take minutes or even hours for networks that support real-time transactions.
POS based on chain The probabilistic finality principle of the network applies, but the disadvantage is much less because only minimal computing power is required to generate the blocks (the generation of the six-block chain required to validate transactions is much faster).
BFT Proof of Stake Based Network
Take a very different approach to transaction finality in order to confirm and authorize transactions in near real-time on the blockchain.
This type of finality is commonly referred to as absolute finality and is achieved by definition in BFT-based networks based on basic consensus principles.
The idea is that a randomly selected validator proposes a block of transactions.
The remaining validators then vote on whether to accept the block and commit it to the chain, and if a majority of validators vote for the block, the block is committed to the blockchain without reverting.
There are slight variations on absolute finality implemented in various BFT-based Proof of Stake blockchains, but the result is that the immediate and absolute finality of a committed block can always be guaranteed without the risk of a future majority reverting or changing parts of the blockchain.
It is impossible for any implementation of the PoS protocol to achieve absolute finality without sacrificing the availability of the network itself!
In an ideal scenario where we can achieve absolute finality, where no transaction or block can be reverted, all validators registered in the network must reach a single consensus to validate a block.
To do this, they must all vote on the same specific block on the main chain, and they must not vote on different blocks on any fork.
Due to these strict requirements, the network fails to validate blocks most of the time. This is because connectivity issues, node desynchronization, and the downtime of a single validator can interrupt the validation process.
To overcome this limitation, most BFT-based PoS networks use a concept called "Economic Finality", which provides near absolute finality for validated blocks.
The Byzantine Fault Tolerance (BFT) problem is very relevant to distributed computing because it describes many of the problems that nodes face when trying to achieve reliable and secure consensus in an untrusted network.
In such hostile environments, in addition to inherent errors in the communication channel, a group of nodes can maliciously attempt to subvert the process as long as the number of trusted nodes exceeds a certain majority.
In such an implementation, the network follows a round-robin approach, randomly designating a validator node as the leader to propose a new block.
A majority, exceeding 2/3 of all validators in the network, must then agree to accept the proposed block and immediately integrate it as part of the blockchain.
Reaching 2/3 consensus is almost absolute finality.
In practice, this means that the BFT Proof of Stake protocol can tolerate an error rate of up to 1/3 of all participating validator nodes in validating a given block (regardless of whether these errors are due to network errors or malicious behavior), and guarantees that a transaction signed by more than 2/3 of the validator nodes is finalized and cannot be reversed under any future circumstances.
the client node sends a work request (transaction) to the currently designated leader node.
The leader node broadcasts the request to all other participating validator nodes.
Each node independently executes the task and sends a response to the initiating client node with the results of the task.
The result sent by at least 2/3 of all validator nodes is considered the final result of the job.
In the latter case, there may be temporary unavailability or high network latency while recovering from errors that occur when more than 1/3 of validators do not respond.
One of the de facto state engines that implements and delivers BFT Proof-of-Stake blockchain consensus is the Tendermint state-machine (Tendermint Core)
https://docs.tendermint.com/v0.34/introduction/what-is-tendermint.html
fault tolerance up to 1/3 of the total number of validators in the network per block voting/confirmation cycle
requirement for synchronous validator nodes (since finalization occurs in place)
prioritizes consistency over all other properties of the blockchain
consensus safety
immediate and absolute finality of blocks
supports both public and private chain models
Chain-based Proof-of-Stake frameworks take a more conservative approach to defining a secure consensus protocol by mimicking the well-established Proof-of-Work paradigm for achieving consensus.
They do this by linking newly created committed blocks to previous blocks via a hash link to the parent block belonging to the longest previously established chain (generally recognized as a valid chain).
This connection is considered unique and unidirectional, and can be used to validate all subsequent blocks in the longest chain by tracing the connection back from the first block in the chain to the current block.
Verification is done using standard cryptographic signature concepts.
There is no guarantee of finalization during the chaining of a newly created block, instead finalization is achieved probabilistically after enough child blocks are chained to that block and the block is chained 'deep enough' in the chain to be considered 'probabilistically finalized'.
In practice, chain-based proof-of-stake blockchains are not considered consensus-safe, and there is no guarantee that the blockchain will always remain secure.
Rather, they prioritize the availability of the network and can continue to operate even if only some validators are active.
To prevent the blockchain from reaching a finalization bottleneck, the network must ensure that block generation at the chain head is always slightly faster than block finalization progress, so that "depth" - a safety requirement for committed blocks - is routinely reached.
How POW differs from block finalization
While POW consensus protocols require a fixed number of block iterations to have block finalization (6 for Bitcoin), chain-based POS protocols typically allow each validator node to customize the finalization threshold. This allows the network to individually choose a degree of safety while keeping the performance overhead typically incurred by POW protocols low.
Ensures the availability of the network even under high failure rates.
Accommodate asynchronous validators with customizable safety thresholds and individual safety threshold guarantees.
while blockchain technology offers many benefits in terms of security, privacy, and immutability, it is not invulnerable to attacks. This article specifically highlights the potential for Long-Range attacks on Proof-of-Stake protocols, which could compromise the integrity of the blockchain and alter transaction records. It is important for blockchain developers and users to be aware of these attack vectors and take steps to mitigate the risks associated with them. Overall, continued research and development in the field of blockchain security will be critical in ensuring the long-term viability and adoption of this technology.
In the next article, we'll cover various consensus protocol attacks, long-range attack techniques, and mitigations.
https://mirror.xyz/zer0luck.eth/alYiEbYHPxFaFu8T90ohy5AYLWDHVMdmpYmd_4xJuiM
Subscribe to Zer0Luck
Subscribe to Zer0Luck
<100 subscribers
<100 subscribers
Share Dialog
Share Dialog
No comments yet