This chapter mainly introduces the consensus-level attacks that may be faced after Ethereum merges with the PoS consensus mechanism.
*The following is only security technology research and does not constitute investment advice. Part of the content of this article is translated from the article published by jmcook.eth on mirror, and the detailed content can be consulted by yourself.
Today is the last article of the “Ethereum Merger” series. In the first two articles, we introduced why Ethereum will be upgraded, and what regulatory and application layer problems Ethereum will face.
This chapter mainly introduces the consensus-level attacks that may be faced after Ethereum merges with the PoS consensus mechanism .
1. Attack of small stakers
Short range re-orgs
This is an attack on the beacon chain, where the attacker usually hides part of the information from other validators, and then publishes it at a specific moment to achieve double-spending or front-running large transactions to extract MEV. This attack can also be extended to multiple blocks, but the probability of success decreases as the length of the reorganization increases.
This attack is essentially a block reorganization, which can be divided into two types: ex ante reorg and ex post reorg. Among them, pre-reorganization refers to the attacker replacing the block from the main chain before it has been created; post-reorganization refers to the attacker deleting the verified block in the main chain. In PoS Ethereum, if you want to reorganize after the fact, you must own more than 2/3 of its equity. At the same time, studies have shown that even if the attacker owns 65% of the equity of Ethereum, the probability of successful attack is less than 0.05%.
The short-range reorganization attack is achieved by reorganization beforehand, and the attacker does not need to control the majority of the pledged ETH in Ethereum to achieve, and the chance of success increases with the increase of the control pledge ratio.
Bouncing and Balancing
A Bouncing and Balancing attack refers to an attacker taking specific measures to split the set of honest validators into discrete groups that disagree on a 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 half of the set of honest validators and another block to the other half. The fork-choice algorithm will detect this conflicting situation, and the block proposer will be slashed and ejected from the network. But the above two blocks still exist, and there will be about half of the validator set attesting to each of these forks.
At the cost of a single validator slashing cost, the attacker successfully split the blockchain in two. Meanwhile, the remaining malicious validators withheld their proofs. Proofs in favor of one or the other fork are then selectively issued to enough validators when executing the fork-choice algorithm, which enables them to generate whichever fork has the most accumulated proofs. This can continue indefinitely, with the attacker maintaining an even distribution of validators across the two forks. Since neither fork can attract a 2/3 supermajority, the beacon chain cannot finally reach a consensus and produce a block.
In this style of attack, the greater the proportion of stake stake controlled by the attacking validator, the more likely it is to attack at any given epoch, as the more likely they are to choose a validator to propose a block in each slot . Even with only 1% of the stake controlled, the opportunity to launch a balancing attack occurs on average every 100 epochs, which doesn’t take too long.
A similar attack, called a bouncing attack, also requires control over a small portion of the stake. In this case, the attacker’s validators will decline to vote. In this approach, instead of issuing votes to maintain an even split between the two forks, attackers use their votes to justify alternate checkpoints between fork A and fork B when appropriate . This flip between two forks stops finality.
A March 2022 paper describes another type of attack called avalanche attacks. The authors of the paper argue that the proposer-weight boosting scheme fails to prevent some variants of avalanche attacks. However, the authors of the paper also only demonstrated an attack on a highly idealized version of Ethereum’s fork-choice algorithm (they used GHOST without LMD). Among them, the GHOST fork selection algorithm will accumulate the votes of the first fork block and all its corresponding descendant blocks, and select the fork with the most votes as the main chain.
Suppose to launch an avalanche attack, the premise is that the attacker can control the proposers of multiple consecutive blocks. When proposers propose for a slot, attackers will withhold and collect their blocks until the withheld block reaches an accumulated weight equal to that of the main chain block. Then, the attacker will release all the blocks that have been withheld. At this time, since the main chain and the sub-chain have the same weight, the blockchain will be forked, causing the sequence of subsequent blocks to be confused. For example, the attacker withholds 6 blocks, the first honest block n competes with the first hostile block n at the same time, at this time a fork is generated in the system. The attacker then connects all the remaining 5 hostile blocks in parallel at n+1 after the first hostile block.
As shown in the figure below, due to the characteristics of the GHOST fork selection algorithm, the weights accumulated by the hostile block n and all 5 subsequent forks and the 6 blocks in the original chain are equal, which means that the seventh block in the system has the same weight. There is a certain probability that each block will choose to connect after the fork created by the attacker. In this case, the attacker can repeat this for the remaining withheld blocks, preventing honest validators from continuing to follow the main chain after validating until the attacker has exhausted all reserved blocks. If attackers have more opportunities to come up with blocks during the attack, they can use those blocks to scale the attack, so that the more validators participate in the collusion attack, the longer the attack lasts, and the more Honest blocks are removed from the main chain.
Image from “Two Attacks On Proof-of-Stake GHOST/Ethereum”
While the LMD part of the LMD-GHOST fork choice algorithm mitigates avalanche attacks, LMD, or “last message driven”, refers to a table saved by each validator containing the latest messages received from other validators. This field is updated only when a new message comes from a later slot than the one already existing in the particular validator table. In practice, this means that in each slot, the first message received is the one it accepts, other messages will be ignored. In other words, the consensus client uses the message from each validator that arrives first, and conflicting messages are simply discarded to prevent avalanche attacks.
long range attacks
Long-range attack is also a specific attack method under the Proof of Stake (PoS) consensus mechanism, which mainly includes the following two situations:
In the first case, the attacker, as a validator participating in the genesis block, maintains a separate blockchain fork next to the original blockchain, and eventually convinces honest validators to switch at some point much later past . But this attack is impossible on the beacon chain, because the “finality gadget” ensures that all validators periodically agree on the state of the honest chain (“checkpoint”), after which blocks after the checkpoint can no longer be reorganized.
The second case is that when a new node joins the network, the blockchain will be constructed from the information obtained from the node closest to it (called a weak subjectivity checkpoint) as a pseudo genesis block. This will create a “gateway of trust” for new nodes joining the network before they can start validating blocks themselves. However, collecting trusted block information needed to build checkpoints from clients such as block explorers does not increase the credibility of the client itself, so the subjectivity is “weak”. Because, by definition, checkpoints are shared by all nodes on the network, a dishonest checkpoint is a state of consensus failure.
2. Attack of large stakers
The 33% staked ETH amount is a benchmark for attackers, and if it exceeds this amount, they have the ability to prevent the beacon chain from finalizing without fine-grained control over the actions of other validators. This is because to finalize the beacon chain, 2/3 of ETH must be staked to prove pairs of checkpoints.
If 1/3 or more of the staked ETH is maliciously proven or failed to prove, then a 2/3 supermajority cannot exist. The defense against this is the beacon chain’s inactivity leak mechanism, which is an emergency safety measure that is triggered when the beacon chain fails to finalize after 4 epochs. Negative penalties identify validators who fail to prove or prove the opposite of the majority. The staked ETH owned by these non-proof validators will gradually drain until eventually they make up less than 1/3 of the total, so that the blockchain can be finalized again.
50% and 51%
In theory, with 50% of the staked ETH controlled by a malicious validator, he could split the Ethereum blockchain into two equally sized forks. Similar to the balance attack described earlier, an attacker can maintain both forks by proposing two blocks for the same slot and then simply using their full 50% stake to vote against the set of honest validators and prevent finality.
After four epochs, the inactivity leak mechanism on both forks will activate, as each fork will see half its validators fail to prove. Each fork will reduce the other half of the validator set’s pledged equity, and eventually both chains will not be able to reach 2/3 of the majority of validators. At this point, the only option is to rely on community recovery.
When the pledged equity controlled by the attacker accounts for more than 51%, the fork selection algorithm can be controlled. In this case, attackers will be able to testify with a majority vote, giving them enough control to perform short-term reorganizations without tricking honest clients. Controlling 51% of the stake does not allow attackers to change history, but they have the ability to influence the future by applying majority votes to forks in their favor, or reorganizing blocks.
Honest validators will follow suit, as their fork-choice algorithm will also consider the attacker-chosen chain as the heaviest chain, so that attack chain can be finalized. This enables attackers to censor certain transactions, perform short-range reorgs, and extract maximum MEV by reordering blocks in their favor. The defense against this problem is the huge cost of majority staking, which exposes the attacker to huge risks, as the social layer may step in and adopt an honest minority fork that drastically reduces the attacker’s staking stake .
An attacker who controls 66% or more of staked ETH can determine their preferred chain without controlling other honest validators. Attackers can simply vote on the fork they want to choose and then finalize it. As a supermajority staker, the attacker will always control the content of the final block, with the power to spend, rollback and spend again, he can also censor certain transactions and reorganize the blockchain at will, when the attacker actually Possesses the ability to reorganize and ultimately reverse (ie, change the past and control the future) after the fact. The only defense is to coordinate the adoption of alternative forks through the involvement of the social layer.
In general, despite these potential attack vectors, the risk of beacon chains is low, even lower than that of proof-of-work equivalent chains. This is because attackers need to put at risk the huge cost of staking ETH in order to overwhelm honest validators with voting power. The built-in “carrot and stick” incentive layer prevents most malicious behavior, especially for low-stake attackers. More subtle bouncing and balancing attacks are also less likely to be successful, as real network conditions make it difficult to achieve fine-grained control over message delivery for a specific subset of validators, and client teams have quickly fixed known ones with simple patches bouncing attack, balance attack, and avalanche attack problems.
But a 34%, 51% or 66% attack may require a community vote to resolve, so effective governance of the community is a powerful disincentive for attackers. For attackers, a technically successful attack still runs the risk of being blocked by the community, which reduces the likelihood of attackers profiting enough to act as an effective deterrent. This is why maintaining an effective community with aligned values is so important to investing.
3. ETH PoW security
Miners have played an important role in Ethereum since its inception, but an Ethereum merger will break that. According to Bitpro estimates, GPU miners will need to shut down about 95% of their GPUs in order to remain profitable in the combined crypto ecosystem. But so many GPUs are unlikely to be shut down immediately after the merge, so miners may try to do a PoW fork after the merge. In fact, some miners have indeed expressed their support for the ETHPoW fork. And if some exchanges also support the fork at the same time, the life of the fork will be longer than expected.
In addition, the official website of the Ethereum fork project Ethereum Pow has been established and has begun to take action:
On August 15, 2022, the Ethereum fork project Ethereum Pow tweeted that the initial version of ETHW Core has been released on GitHub. The main features are: 1. Disable the difficulty bomb; 2. Change EIP-1559 and change the base fee A multi-signature wallet jointly managed by miners and the community; 3. Adjusted the initial mining difficulty of ETHW.
On August 26, 2022, the Ethereum fork project EthereumPoW tweeted that ETHW’s first test network “Iceberg” was released. With it comes a blockchain explorer and an RPC server. We welcome all potential partners in the community (exchanges, pools, wallet providers, bridges, builders, etc.) to join us in building a true PoW-driven Ethereum ecosystem.
Then, after the merger and upgrade of Ethereum, what security problems may the hard fork ETHPoW face, we will analyze in detail below.
1. Hash attack
The 51% computing power attack is a potential attack on the blockchain network. When a malicious single entity or organization in the system can control most of the computing power, that is, when the entire network exceeds 51% of the computing power, the consensus in the PoW algorithm is determined by the computing power. , which allows attackers to use computing power to tamper with the ledger, resulting in malicious attacks on the system. After the merger of Ethereum, miners who can no longer obtain income through mining will shut down their mining machines, which leads to the PoW-based ETH fork that may lose some computing power. For example, Ethermine, the largest mining pool at present, has announced that it will stop supporting ETH PoW mining.
Image courtesy of ethermine.org
And once the computing power supporting ETHPoW drops, it will reduce the cost of the attacker launching a computing power attack. Then the attacker can rent a large amount of mining pool computing power to make its computing power reach more than 51%. At this time, the block can be generated faster by taking advantage of the computing power. When the generated block becomes the longest chain in the system, the Block transactions can be rolled back, data tampering can be achieved, causing great harm, such as double spending, transactions that control any address, etc. The following will be introduced separately:
A double-spending attack refers to an attack in which an attacker attempts to spend the same digital token owned by his account repeatedly. for example:
Assuming that A has 51% of the computing power, when the block height is 1000, A transfers an ETH to B, and the transfer transaction is packaged by the miners.
After the transaction is confirmed, A relies on the 51% computing power advantage to regenerate a “longer chain” after block height 999, and re-transfers the ETH to C at block height 1000 and the transaction record is deleted. Packaging, that is, the chain contains a record of A transferring an ETH to C.
According to the “Longest Chain Consensus”, the chain containing the transfer record to C becomes the main chain, and an ETH transferred from A to B is an “invalid payment”.
Control transactions from any address
If it has 51% of the computing power, the attacker can arbitrarily package or not package the transaction of a certain address, and can also prevent the block from confirming any transaction, and even prevent some miners from obtaining effective accounting rights, so as to control transactions at any address. the goal of.
However, having 51% of the computing power is not omnipotent. For example, it cannot modify other people’s transaction records, nor can it prevent the issuance of transactions, and it cannot generate ETH out of thin air.
2. Replay attack
In traditional computer terminology, Replay Attacks, also known as replay attacks and replay attacks, refer to the attacker sending a data packet that has been received by the target host to deceive the system. In the blockchain field, replay attacks usually appear when the blockchain is hard forked, referring to “transactions on one chain are often legal on another chain”.
On the evening of July 20, 2016, Ethereum had a hard fork at the 1.92 millionth block height, resulting in two chains, called ETH chain and ETH Classic chain, and the corresponding tokens were ETH and ETC.
Since the addresses and private keys on the two chains are the same, and the transaction formats are exactly the same, transactions on one chain are completely legal on the other. So a transaction you initiate on one chain, replay it on the other chain, may also be confirmed. Since there is no plan in advance, many people use this loophole to continuously perform ETH deposit and withdrawal operations on the exchange to obtain additional ETC. So far, “replay attack” has been redefined in the blockchain world.
The hard fork ETHPoW that is likely to appear in the merger and upgrade of Ethereum this time may also have the above problems in theory.
How to prevent replay attacks? In fact, it is easy to achieve a fork for 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, in order to avoid “illegal transactions” of the old client (not malicious transactions, but the version number is too low to be recognized by other nodes), miners usually reject transactions before a certain version number to ensure that it is difficult for malicious attackers to Steal funds through replay attacks during hard fork upgrades.
On August 23, 2022, the Ethereum fork project EthereumPoW officially issued a document saying that ETHW Core released the second code update to enforce EIP-155. After this update, all transactions must be signed with the 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 titled “Simple Replay Attack Protection”. The proposal states: If block.number >= FORK_BLKNUM and CHAIN_ID is available, then when computing the hash of the transaction for signing, instead of just encoding the previous six rlp elements (nonce, gasprice, startgas, to, value, data), the nine rlp encoded elements (nonce, gasprice, startgas, to, value, data, chainid, 0, 0) should be hashed instead. At this point, the v value in the signature is no longer recid, but recid+ chainID*2+ 35.
Therefore, in short, when signing a transaction, you need to provide a signer (Signer) and a private key (PrivateKey). Singer is needed because after EIP-155 fixes the simple repeat attack vulnerability, the signature method of the old blockchain needs to be kept unchanged, but a new version of the signature method needs to be provided. Therefore, the new and old signature methods are implemented through the interface, and different signers are created according to the block height. The main purpose of the new hash algorithm implemented in EIP-155 is to obtain the hash value TxSignHash used for signing transactions. Compared with the old way, the chain ID and two null values are mixed in the hash calculation. Note that this hash TxSignHash is not equivalent to the transaction hash in EIP155.
The picture is from “Blockchain Technology and Implementation”
In this way, a signed transaction can only belong to a uniquely determined blockchain.
In addition, in order to ensure the security of the project, it is recommended that when the project party performs offline signature verification in the contract, the Chain ID should be included in the signature data to avoid asset loss due to cross-chain signature reuse.
3. Application layer project
In fact, a conventional fork requires computing power to make a choice, and the protagonist of the choice is the miner. If there are two Ethereum chains appearing at the same time in this Ethereum upgrade, it is the overall Ethereum that needs to make a choice. The ecology is the project party, the user, and the investor.
Compared with the hard fork in 2016, Ethereum today is far from what it used to be. DeFi projects have accounted for half of the Ethereum ecosystem, but the foundation of DeFi projects is the assets on the chain, so the project side mainly follows the asset side. go. The so-called asset side refers to stable assets on the chain such as USDT and USDC. The mortgage lending ecology of DeFi is basically based on the asset side.
For the issuers of these stable assets (mainly stablecoins here), if the Ethereum network forks, they suddenly face a dangerous problem: there are two versions of stablecoins. As a stablecoin issuer, you suddenly have two debt obligations for every stablecoin issued.
While most people believe that stablecoin issuers will treat the new PoS chain as a “true” Ethereum network, what if they want to support a PoW chain? After all, they have enough financial incentives to do it.
For example, they can short PoS Ethereum tokens, announce redemptions on the PoW network, and make billions of dollars. This could disrupt the new Ethereum network, resulting in the liquidation of loans and the shutdown of protocols, exchanges, and related DeFi projects. This will create a huge mess and could destroy the cryptocurrency market on a large scale.
Similarly, the Ethereum fork project EthereumPow tweeted on August 17 that ETHW Core will introduce liquidity pool freezing technology to protect user assets, that is, after the Ethereum PoW hard fork, especially the first few blocks, users ETHW tokens deposited in liquidity pools, such as Uniswap, Susiswap, Aave, Compound, will be exchanged or lent for USDT, USDC, WBTC by hackers and scientists using deprecated or valueless methods, which will affect the entire network and The community caused huge chaos. Therefore, ETHW Core temporarily freezes 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 staking contracts that only involve a single asset (such as ETH2.0 deposit contracts and Wrapped Ether). ETHW Core recommends that everyone withdraw their ETH from LPs (such as DEXs and lending protocols) before the hard fork.
《Ethereum PoS Attack and Defense》
“What is a replay attack on the blockchain”
“Blockchain Technology and Implementation”
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/what-consensus-level-attacks-will-ethereum-face-after-switching-to-pos/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.