Blockchain infrastructure and consensus protocol security

Goal

Blockchains are sold as secure, private, and immutable. In practice they still get attacked. These notes summarize long-range attacks on Proof-of-Stake protocols — forks that can seize the main chain and rewrite history — and the PoW/PoS background needed to see why weak subjectivity and costless simulation make those attacks sharper on stake-based chains than on work-based ones.

Reference

These notes follow A Survey on Long-Range Attacks for Proof of Stake Protocols by Evangelos Deirmentzoglou, Georgios Papakyriakopoulos, and Constantinos Patsakis:

• Evangelos Deirmentzoglou (Department of Informatics, University of Piraeus)
• Georgios Papakyriakopoulos (Cisco Security Services, Marousi)
• Constantinos Patsakis (Department of Informatics, University of Piraeus)

Paper: https://ieeexplore.ieee.org/document/8653269/

Consensus methods

Blockchains exist to order transactions and stop double-spends without a trusted middle party. The usual design is a peer-to-peer append-only chain of blocks, bound with cryptography, that anyone can verify.

In Bitcoin-style Proof-of-Work (PoW), miners race on a hard, easy-to-check puzzle. The winner proposes a block and earns a coin reward. Trust here is mostly "someone burned real compute." In Proof-of-Stake (PoS), validators are chosen by stake. Coins bootstrap the set, and validators earn fees (and often issuance) for committing blocks. Trust here is "someone locked capital that can be slashed."

Ethereum's Transition to POS Protocol

More chains, including Ethereum, have moved or are moving from Proof-of-Work toward Proof-of-Stake. That shift can be hybrid (PoW/PoS) or a full cutover to PoS.

Why move?

Energy is the headline reason: mining is compute-heavy. Bitcoin mining already burns a large share of electricity by some estimates, and malware mining on infected machines pushes the real total higher.

Privacy is not automatic

Calling a chain "inherently private" oversells the model. Plenty of attacks leak or correlate identity; some are chain-specific and technical. A lot of newcomers still treat the ledger as a black box, which is why survey papers like this one matter.

Long-range attacks in PoS

The survey centers on Proof-of-Stake attacks, especially long-range attacks. Weak subjectivity and costless simulation make those forks sharper on stake chains than on work chains. A long-range attack grows an alternate history that can overtake the canonical chain (a history-revision attack).

On PoW, rebuilding enough past work to overtake the main chain is usually impractical. A short-range attack only reorganizes a few days to months of blocks. A long-range attack aims further: it can start from genesis and rewrite deep history, not just recent tips.

Related reading

• https://github.com/ZhangZhuoSJTU/Web3Bugs

• https://www.nevillegrech.com/madmax-oopsla18.pdf

• https://arxiv.org/abs/1703.03779

Blockchain infrastructure

A blockchain is a distributed, append-only, timestamped structure. Untrusted peers can verify each other's history without a central institution.

Transactions are signed by at least one party and can move assets or change state. A node broadcasts a transaction into the mempool. Full nodes decide validity, pack accepted transactions into a block, and append that block by hashing the previous block header.

Valid transactions that miss a block stay eligible for later ones. The chain is the audit trail of those accepted changes.

Block,Transaction flow

Genesis Block

• 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.

Steps to create a block on a blockchain

1. create a transaction that stores transaction history or data using an asymmetric key

2. Propagate the created transaction

3. Create a block by combining the transactions propagated using the asymmetric key.

4. Propagate the created block

5. all users receive the block and synchronize (repeat periodically from step 1)

Blockchain Nodes

3 types of blockchain nodes

1. Mining Node that generates blocks and has all the data.

2. Full Node that does not generate blocks but only verifies and synchronizes all blocks.

3. 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).

Multiple Transactions Exploitation

• 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.

Consensus Protocols

Transaction Verification in POW and POS

• 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.

Verification Sequence

• 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.

Proof of Work (POW) computation

• A strong cryptographic graphical or mathematical problem whose difficulty dynamically varies with the computing power of the entire network, 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.

Proof of Stake Protocols (POS)

• 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.

PoS block generation

• 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.

Long-term viability of POS

• 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.

Transaction and block finality

• Transaction semantics and block finality are the hinge between the two consensus styles.

• 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.

Byzantine Fault Tolerant-Based Proof-Of-Stake

• 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.

BFT consensus protocol 4 main steps when implementing actual BFT in a blockchain network

1. the client node sends a work request (transaction) to the currently designated leader node.

2. The leader node broadcasts the request to all other participating validator nodes.

3. Each node independently executes the task and sends a response to the initiating client node with the results of the task.

4. The result sent by at least 2/3 of all validator nodes is considered the final result of the job.

PoW protocols implement the BFT approach to ensure that the network is always in a consistent state.

• 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

BFT-based Proof of Stake Consensus Protocol Characteristics

1. fault tolerance up to 1/3 of the total number of validators in the network per block voting/confirmation cycle

2. requirement for synchronous validator nodes (since finalization occurs in place)

3. prioritizes consistency over all other properties of the blockchain

4. consensus safety

5. immediate and absolute finality of blocks

6. supports both public and private chain models

Chain Based Proof-Of-Stake

• 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.

Chain-Based Proof of Stake Consensus Protocol Characteristics.

• Ensures the availability of the network even under high failure rates.

• Accommodate asynchronous validators with customizable safety thresholds and individual safety threshold guarantees.

Next

The follow-up note covers consensus-protocol attacks, long-range techniques, and mitigations in more detail.

https://mirror.xyz/zer0luck.eth/alYiEbYHPxFaFu8T90ohy5AYLWDHVMdmpYmd_4xJuiM