September 13, 2022
Ethereum PoS and PoW Security
In our last two articles, we mainly talked about the reasons, route, current progress, impact, and regulation issues of Ethereum merge. Today we will introduce the consensus-level attacks that may occur after Ethereum merge.
ETH PoS Security
This section focuses on the possible consensus-level attacks on Ethereum after adopting the PoS consensus mechanism.
Reference from jmcook.eth on Mirror:
Attacks by small stakeholders
Short range re-orgs
This is an attack on Beacon chain that typically consists of an attacker hiding part of the information from other validators and then releasing it at a specific moment to enable double-spending or extracting MEV through front-running large transactions. This attack can also scale to multiple blocks, but the likelihood of success decreases as the length of the re-orgs increases.
This attack is essentially a block reorg, which is divided into two types: ex ante reorg and ex post reorg. Ex ante reorg means that the attacker replaces a block from the main chain while it has not yet been created, while ex post reorg means that the attacker removes a verified block from the main chain. In the case of PoS Ethereum, an attacker must own more than 2/3 of the block in order to perform an ex-post reorg. At the same time, some studies show that even if an attacker owns 65% of stake, the chance of a successful attack is less than 0.05%.
Short-range re-orgs attacks are achieved through ex ante reorgs, where the attacker does not need to control most of the staked ETH to achieve it, and the chance of success increases as the percentage of stake controlled increases.
Bouncing and Balancing
Balancing attack refers to the specific means that an attacker takes to split the honest validator set into discrete groups that have different views about the block. Specifically, attackers wait for an opportunity to propose a block, and when it arrives, they propose two blocks in the same slot. They send one block to one half of the set of honest validators and the other block to the other half. The fork selection algorithm will detect this conflicting situation and the block proponent will be forfeited and ejected from the network. However, the two blocks mentioned above still exist and there will be about half of the validator set proving each of these forks. At the cost of a single validator forfeit, the attacker successfully splits the blockchain in two. Meanwhile, the remaining malicious validators withhold their proofs. The proofs in favor of one or the other fork are then selectively released to enough validators during the execution of the fork selection algorithm, which allows them to generate any fork with the most accumulated proofs. This can continue indefinitely, with the attacker maintaining an even distribution of verifiers on both forks. Since neither fork can attract a 2/3 supermajority the Beacon Chain would not finalize.
In this type of attack, the larger the percentage the total stake controlled by the attacking validators, the more likely it is to attack at any given epoch, as they are more likely to choose the validator to propose a block in each slot. Even with only 1% of the total stake, the opportunity to launch a balancing attack would arise on average once every 100 epochs, which does not require a long wait.
A similar attack, also possible with a small percentage of the total stake is a bouncing attack. In this case, votes are again withheld by the attacking validators. This time, instead of releasing the votes to keep an even split between two forks, they use their votes at opportune moments to justify checkpoints that alternate between fork A and fork B. This flip-flopping of justification between two forks prevents there from being pairs of justified source and target checkpoints that can be finalized on either chain, halting finality.
Another class of attack, called avalanche attacks, was described in a March 2022 paper. The authors suggest that proposer boosting - the primary defense against balancing and bouncing attacks - does not protect against some variants of avalanche attack. However, the authors also only demonstrated the attack on a highly idealized version of Ethereum’s fork-choice algorithm (they used GHOST without LMD). Among them, the GHOST fork selection algorithm accumulates the votes received by the first forked block and all its corresponding descendant blocks, and selects the fork with the highest number of votes as the main chain.
To mount an avalanche attack, the attacker needs to control several consecutive block proposers. In each of the block proposal slots, the attacker withholds their block, collecting them up until the honest chain reaches an equal subtree weight with the withheld blocks. Then, the withheld blocks are released so that they equivocate maximally. This means that for, for example, 6 withheld blocks, the first honest block n competes with adversarial block n creating a fork, then all 5 remaining adversarial blocks all compete with the honest block at n+1. This means the fork building off adversarial blocks n and n+1 now attracts honest attestations, because the blocks were released at the moment the weight of the truly honest chain equaled the weight of the adversarial chain. This can now be repeated with the withheld blocks that haven’t yet been built on top of, allowing the attacker to prevent the honest validators from following the honest head of the chain until their equivocating blocks are used up. If the attacker has more opportunities to propose blocks while the attack is underway they can use them to extend the attack, such that the more validators collude on the attack, the longer it can persist and the more honest blocks can be displaced from the canonical chain.
Source: Two Attacks On Proof-of-Stake GHOST/Ethereum
The avalanche attack is mitigated by the LMD portion of the LMD-GHOST fork choice algorithm. LMD means “last-message-driven” and it refers to a table kept by each validator containing the latest message received from other validators. That field is only updated if the new message is from a later slot than the one already in the table for a particular validator. In practice, this means that in each slot, the first message received is the one that it accepted and any additional messages are equivocations to be ignored. Put another way, the consensus clients don’t count equivocations - they use the first-arriving message from each validator and equivocations are simply discarded, preventing avalanche attacks.
Long range attacks
Long-range attacks are also a specific type of attack under the proof-of-stake (PoS) consensus mechanism and consist of two main scenarios: in the first scenario, the attacker, as a validator participating in the original block, maintains a separate blockchain fork next to the original blockchain and eventually convincing the honest validator set to switch over to it at some opportune time much later. However, this attack is not possible on Beacon chains because the "finality gadget" ensures that all validators agree on the state of the honest chain ("checkpoint") at regular intervals, after which blocks after the checkpoint cannot re-org.
In the second case, when a new node joins the network, it will take information from the nearest node (called weak subjectivity checkpoints) to build a blockchain as a pseudo-founding block. This creates a "trust gateway" for the new node joining the network before it can start verifying blocks on its own. However, collecting the trusted block information needed to build a checkpoint from a client such as a block browser does not increase the trustworthiness of the client itself, so subjectivity is "weak". Because checkpoints are by definition shared by all nodes on the network, dishonest checkpoints are a consensus failure state.
Validators controlling large portion of the total stake
33% of the staked ether is a benchmark for an attacker because with anything greater than this amount they have the ability to prevent the Beacon Chain from finalizing without having to finely control the actions of the other validators. They can simply all disappear together. This is because for the Beacon Chain to finalize, pairs of checkpoints must be attested by 2/3 of the staked ether. If 1/3 or more of the staked ether is maliciously attesting or failing to attest, then a 2/3 supermajority cannot exist. The defense against this is the Beacon Chain’s inactivity leak. This is an emergency security measure that triggers after the Beacon Chain fails to finalize for four epochs. The inactivity leak identifies those validators that are failing to attest or attesting contrary to the majority. The staked ether owned by these non-attesting validators is gradually bled-away until eventually they collectively represent less than 1/3 of the total so that the chain can finalize again.
50% and 51%
In theory, with a malicious validator controlling 50% of the staked ETH, he could split the Ethereum blockchain into two forks of equal size. Similar to the balancing attack described earlier, an attacker can maintain two forks and prevent eventual determinism by proposing two blocks for the same slot and then simply using his full 50% stake to vote against the honest set of validators. After four epochs, the inactivity leak mechanism on both forks will activate, as each fork will see half of its validators fail to prove. Each fork decimates the other half of the validator set stake, eventually resulting in both chains finalizing with different validators representing a 2/3 supermajority. At this point, the only option is to rely on community recovery.
In contrast, when the attacker controls more than 51% of the total stake, they can control the fork choice algorithm. In this case, the attacker would be able to attest with the majority vote, giving them sufficient control to do short reorgs without needing to fool honest clients. 51% of the stake does not allow the attacker to change history, but they have the ability to influence the future by applying their majority votes to favorable forks and/or reorging inconvenient non-justified blocks out of the chain. The honest validators would follow suit because their fork choice algorithm would also see the attacker’s favored chain as the heaviest, so the chain could finalize. This enables the attacker to censor certain transactions, do short-range reorgs and extract maximum MEV by reordering blocks in their favor. The defense against this is the huge cost of a majority stake which is put at risk by an attacker because the social layer is likely to step in and adopt an honest minority fork, devaluing the attacker’s stake dramatically.
An attacker with 66% or more of the total staked ether can finalize their preferred chain without having to coerce any honest validators. The attacker can simply vote for their preferred fork and then finalize it, simply because they can vote with a dishonest supermajority. As the supermajority stakeholder, the attacker would always control the contents of the finalized blocks, with the power to spend, rewind and spend again, censor certain transactions and reorg the chain at will. The attacker is effectively buying the ability to do ex post reorgs and finality reversions (i.e. change the past as well as control the future). The only real defense here is to fall back to the social layer to coordinate adoption of an alternative fork.
Overall, despite these potential attack vectors, Beacon chains are low-risk, even lower than their proof-of-work equivalents. This is because an attacker needs to put at risk the significant cost of staking ETH in order to overwhelm an honest validator with voting power. The built-in incentive layer prevents most malicious behavior, especially for low stake attackers. More subtle bounce and balancing attacks are also unlikely to succeed, as real network conditions make it difficult to achieve fine-grained control over messaging for a specific subset of validators, and client teams have quickly fixed known bounce, balancing, and avalanche attack issues with simple patches.
However, a 34%, 51%, or 66% attack may require a community vote to resolve, so effective community governance is a strong disincentive for attackers. For an attacker, a technically successful attack still risks being blocked by the community, which reduces the likelihood that the attacker will profit enough to act as an effective deterrent. This is why maintaining an effective community with consistent values is so important for investment.
Miners have played an important role in Ethereum since its inception, but the Ethereum merge will break that. Bitpro estimates that GPU miners would need to shut down about 95 percent of their GPUs to remain profitable in the post-merge crypto ecosystem. But with so many GPUs unlikely to shut down immediately after the merge, miners may attempt a PoW fork after the merge. Indeed, there are already some miners who have explicitly expressed support for an ETHPoW fork. If some of the exchanges also support the fork, the fork will have a longer life than expected. So far, some institutions have already supported the ETHPoW hard fork, including Gate, Gate, OKX, f2pool, Matcha, BitMEX, and Justin Sun.
In addition, the official website of Ethereum Pow, an Ethereum fork project, has now been set up and is already making moves.
On August 15, 2022, Ethereum Pow tweeted that the initial version of ETHW Core has been released on GitHub, with the following main features: 1. Disabling the difficulty bomb; 2. EIP-1559 changes, with the base fee changed to a multi-signature wallet jointly managed by miners and the community; 3. Adjusting the starting mining difficulty of ETHW.
On August 26, 2022, EthereumPoW tweeted that the first testnet "iceberg" of ETHW was released. Along with it came the Blockchain explorer and RPC server. They welcome all potential partners in the community (exchanges, pools, wallet providers, bridges, builders, etc.) to join in building a true PoW-powered Ethereum ecosystem.
So, what security issues may be faced by the hard fork ETHPoW after the Ethereum merge? We will analyze in detail below.
1. Algorithm attack
The 51% algorithm attack is a potential attack against blockchain networks when a malicious single entity or organization in the system is able to control the majority, i.e. more than 51%, of the network-wide arithmetic. Since the consensus in the PoW algorithm is determined by the arithmetic, this allows attackers to use the arithmetic to tamper with the ledger, leading to malicious attacks on the system. After the Ethereum merge, miners who can no longer gain revenue through mining will shut down their mining machines, which leads to the PoW-based ETH fork may lose some of its arithmetic power, for example, Ethermine, currently the largest mining pool, has issued an announcement that it will stop supporting ETH PoW mining.
Once the arithmetic power supporting ETHPoW drops, it will reduce the cost for attackers to launch algorithm attacks. Then the attacker can rent a large amount of arithmetic power of the mining pool, making its arithmetic power reach more than 51%, at this time, it can use the arithmetic power advantage to generate blocks faster, when the generated blocks become the longest chain in the system, it can roll back block transactions to achieve data tampering and cause great harm, such as: double-spending, controlling transactions at any address, etc.
A double-spending attack is an attack in which an attacker attempts to repeatedly spend the same digital token owned by their account. An example:
Assuming A has 51% of the arithmetic power, at block height 1000. A transfers one ETH to B. The transfer transaction is packaged by the miner.
After the transaction is confirmed, A relies on the 51% arithmetic power advantage to regenerate a "longer chain" after block height 999 and re-transfers the ETH to C at block height 1,000 and the transaction record is packaged, i.e. the chain contains a record of A transferring an ETH to C.
According to the "longest chain consensus", the chain containing the record of the transfer to C becomes the main chain, and the transfer of one ETH from A to B is an "invalid payment".
Controlling transactions at any address
With 51% arithmetic power, an attacker can pack or unpack transactions at any address, prevent blocks from confirming arbitrary transactions, or even prevent some miners from obtaining valid bookkeeping rights, thus achieving the goal of controlling transactions at any address.
However, having 51% arithmetic power is not a panacea, for example, it cannot modify other people's transaction records, nor can it prevent transactions from being issued, nor can it generate ETH out of thin air.
2. Replay attacks
In traditional terminology, Replay Attack refers to an attacker sending a packet that has already been received by the target host for the purpose of spoofing the system. In the blockchain field, replay attacks usually occur when the blockchain is hard forked, which means "transactions on one chain are often legitimate on the other chain".
On July 20, 2016, a hard fork occurred in Ethereum at the height of the 1.92 millionth block, resulting in two chains, called ETH chain and ETH Classic chain, with corresponding tokens of ETH and ETC respectively.
Since the addresses and private keys on these two chains are the same, and the transaction formats are exactly the same, transactions on one of the chains are also perfectly legal on the other. So a transaction initiated on one chain maybe confirmed as well if replayed on the other chain. Since there is no proper planning in advance, many people take advantage of this vulnerability and keep depositing and withdrawing in exchanges to get extra ETC. Thus, "replay attack" has been redefined in the blockchain world.
The hard fork ETHPoW, which is likely to appear in the current Ethereum merge, may also have the above-mentioned problems in theory.
What should be done to prevent replay attacks? In fact, it is easy to reach for the fork with the purpose of upgrading, because the hard fork upgrade will use different client versions, and the prefix of the transaction usually contains the version information of the client that initiated the transaction. After the fork, miners will usually reject transactions before a certain version in order to avoid packing "illegal transactions" from old clients (not malicious transactions, but simply low version numbers that are not recognized by other nodes), making it difficult for malicious attackers to steal funds through replay attacks during the hard fork upgrade.
And on August 23, 2022, EthereumPoW officially posted that ETHW Core released a second code update to enforce EIP-155. After this update, all transactions must be signed with a chain ID. This will protect ETHW users from replay attacks from ETHPoS and other forked tokens.
Here is a brief introduction to EIP-155:
The proposal is called "Simple Replay Attack Protection". The proposal states that if block.number >= FORK_BLKNUM and CHAIN_ID is available, then instead of hashing only the previous six rlp-encoded elements (nonce, gasprice, startgas, to, value, data) when computing the hash of the transaction for signing, nine rlp-encoded elements (nonce, gasprice, startgas, to, value, data, chainid, 0, 0) should be hashed. At this point, the value of v in the signature is no longer recid , but recid+ chainID*2+ 35.
Therefore, in short, a Signer and a PrivateKey are required when signing a transaction. Singer is needed because after EIP-155 fixes the replay attack vulnerability, it is necessary to keep the old blockchain signature method unchanged, but need to provide the new version of the signature method. Therefore, the old and new signature methods are implemented through an interface to create different signers based on the block height. The main purpose of the new hash algorithm implemented in EIP-155 is to obtain the hash value TxSignHash that the transaction uses for signing. Compared to the old way, the hash calculation is mixed with the chain ID and two null values. Note that this hash value TxSignHash is not equivalent to the transaction hash value in EIP155.
Source：Blockchain technology and implementation
In this way, a signed transaction may only belong to a uniquely identified blockchain.
In addition, to ensure project security, it is recommended that when project perform offline signature verification in contracts, the signature data should include the Chain ID to avoid loss of assets due to cross-chain signature reuse.
2. Application-layer projects
In fact, the conventional fork is required to make a choice with arithmetic power, and the main character of the choice is miners, while this time, if there are really two Ethereum chains at the same time, the one who needs to make a choice is the overall ecosystem of Ethereum. The project side here are the users and the investors.
Today's Ethereum is not what it used to be when compared with the hard fork in 2016, DeFi projects have accounted for the majority of Ethereum ecosystem, but the basis of DeFi is the assets on the chain, so the projects are mainly following the asset side. The asset side is the stable assets such as USDT and USDC, and DeFi's staking or lending projects are basically based on the asset side.
For the issuers of these stable assets (here mainly refers to stablecoins), if the Ethereum fork occurs, they will suddenly face a problem - two versions of stablecoins. As an issuer of stablecoins, for every stablecoin issued, there would suddenly be two debt obligations.
While most people think that stablecoin issuers will see the new PoS chain as the "real" Ethereum network, what if they want to support the PoW chain? After all, they have enough financial incentive to do so.
For example, they could short PoS Ethereum tokens, announce redemptions on the PoW network, and rake in billions of dollars. This could disrupt the new Ethereum network, causing loans to be liquidated and protocols, exchanges, and related amounts of DeFi projects to be shut down. This would create a huge chaos and potentially destroy the cryptocurrency market on a large scale.
Similarly, EthereumPow, an Ethereum fork project, tweeted on August 17 that ETHW Core will introduce liquidity pool freezing technology to protect user assets, i.e. after the hard fork of Ethereum PoW, especially the first few blocks, ETHW tokens deposited by users in the liquidity pool, such as Uniswap, Susiswap, Aave, and Compound, will be used by hackers to swap or borrow USDT, USDC, WBTC in abandoned or worthless ways, which will cause huge disruptions to the entire network and community.
Therefore, ETHW Core is temporarily freezing certain LP contracts to protect users' ETHW tokens until the controller of the protocol or the community finds a better way to return users' assets. The freeze will not apply to stake contracts involving only a single asset (e.g. ETH2.0 deposit contracts and Wrapped Ether). ETHW Core recommends that everyone withdraw their ETH from LPs (e.g. DEX and lending agreements) prior to a hard fork.
Related Project Secure Score
Guess you like
All Web3 Events You Need to Know in Singapore This September!
September 13, 2022
Introduction of EIP-3523: Semi-Fungible Token
September 14, 2022
Beosin and XT.COM have entered into a strategic partnership
September 20, 2022
Beosin: $160 Million Lost in Wintermute’s Exploit from Using Profanity
September 21, 2022