Comparison: Ethereum PoS and PoW security

This article will introduce the consensus level attacks that may occur after the Ethereum merger.

ETH PoS Security

This section mainly discusses the consensus level attacks that may occur after Ethereum adopts the PoS consensus mechanism.

From jmbook on Mirror Eth's reference:  https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs

Attacks of Small Pledgors

Short range reorganization

This is an attack against beacon chain. Usually, the attacker hides some information from other verifiers, and then releases this information at a specific time, so as to achieve double blossom or extract MEV through large pre run transactions. This attack can also be extended to multiple blocks, but the probability of success will decrease as the reorganization length increases.

This attack is essentially a block reorganization, which can be divided into two types: pre reorganization and post reorganization. Pre reorganization means that an attacker replaces an unconstructed block from the main chain, while post reorganization means that an attacker deletes an authenticated block from the main chain. In the case of PoS Ethereum, attackers must have more than 2/3 of the blocks to perform post reorganization. At the same time, some studies show that even if the attacker has 65% of the shares, the probability of successful attack is less than 0.05%.

The short-range reorganization attack is realized through pre reorganization. Attackers can achieve this without controlling most of the pledged ETH, and the probability of success will increase with the increase of the proportion of pledged under control.

Bounce and balance

Balanced attack refers to the specific means taken by attackers, who divide the set of honest verifiers into discrete groups with different views on blocks. Specifically, attackers wait for an opportunity to propose a block. When the opportunity comes, they propose two blocks in the same slot. They send one block to half of the set of honest verifiers and another block to the other half. The fork selection algorithm will detect this conflict, and the block supporters will be confiscated and expelled from the network. However, the two blocks mentioned above still exist, and there will be about half of the verifier set to prove each fork. Attackers successfully split the blockchain in two at the cost of losing a verifier. At the same time, the remaining malicious verifiers retain their certificates. Then, during the execution of the fork selection algorithm, the proofs in favor of one or another fork are selectively released to enough verifiers, which allows them to generate any fork with the most cumulative proofs. This situation can continue indefinitely, and the attacker can maintain the uniform distribution of the verifiers on the two forks. Since both bifurcations cannot attract an absolute majority of 2/3, the beacon chain will not be finalized.

In this type of attack, the greater the percentage of total pledge controlled by the attack verifier, the greater the possibility of attack at any given moment, because they are more likely to choose the verifier to propose a block in each slot. Even if it is only 1%, the chance of launching a balanced attack will occur once every 100 epochs on average, which does not require a long wait.

A similar attack is the bounce attack, which only accounts for a small part. In this case, the attack verifier again refused to vote. This time, they did not issue a vote to maintain the average distribution between the two forks, but used their votes to prove that the alternate checkpoint between fork A and fork B was reasonable when appropriate. The reversal of proofs between these two forks prevents a reasonable source and target checkpoint pair that can be completed on any chain, thus terminating the final certainty.

Avalanche attack

Another type of attack is called avalanche attack, which is described in a paper in March 2022. The author believes that the proposer's enhancement cannot prevent some variants from avalanche attacks. However, the authors only demonstrated the attack on the highly idealized version of Ethereum fork selection algorithm (they used GHOST without LMD). Among them, GHOST fork selection algorithm accumulates the votes obtained by the first fork block and all its corresponding descendant blocks, and selects the fork with the highest number of votes as the main chain.

In order to launch an avalanche attack, the attacker needs to control several consecutive block proponents. In each block proposal slot, attackers retain their blocks and collect them until the honest chain and the reserved blocks reach the same subtree weight. Then, the reserved blocks are released to blur them as much as possible. This means, for example, for six reserved blocks, the first honest block n competes with the rival block n to create a fork, and then all the remaining five rival blocks compete with the honest block at n+1. This means that the forks built on the rival blocks n and n+1 now attract honest verification, because the blocks are released when the weight of the truly honest chain is equal to the weight of the confrontation chain. Now this operation can be repeated for reserved blocks that have not been built on it, allowing attackers to prevent honest verifiers from following honest chain headers until their fuzzy blocks are used up. If attackers have more opportunities to propose blocks during the attack, they can use them to expand the attack. In this way, the more verifiers participate in the attack, the longer it can last, and more honest blocks can be removed from the specification chain.

Source: Two Attacks on Proof of Rights GHOST/Ethereum

The LMD part of LMD ghost fork selection algorithm can mitigate avalanche attacks. LMD means "last message driven". It refers to a table saved by each verifier, which contains the latest messages received from other verifiers. This field is updated only when the new message comes from the slot after the existing slot in a specific verifier table. In practice, this means that in each slot, the first message received is the message it receives, and any other message is an ambiguous message to be ignored. In other words, consensus clients do not compute ambiguities - they use the first arriving message from each verifier, and ambiguities are discarded to prevent avalanche attacks.

Remote attack

Remote attack is also a specific type of attack under the proof of equity (PoS) consensus mechanism, including two main scenarios: in the first scenario, the attacker, as the verifier participating in the original block, maintains a separate blockchain fork next to the original blockchain, and ultimately persuades the honest verifier set to switch to it at an appropriate time in a long time. However, this attack is unlikely to occur on the beacon chain, because the "finality gadget" ensures that all verifiers regularly agree on the status of the honest chain ("checkpoint"), and the blocks after the checkpoint cannot be reorganized.

In the second case, when a new node joins the network, it will obtain information from the nearest node (called weak subjectivity checkpoint) to build a blockchain as a pseudo originator block. This creates a "trust gateway" for the new node before it can start to validate the block itself. However, collecting the trusted block information needed to build checkpoints from clients (such as block browsers) does not increase the credibility of the client itself, so subjectivity is "weak". Because the checkpoint definition is shared by all nodes on the network, dishonest checkpoints are in the consensus failure state.

The verifier controls most of the situation

33%

The pledge share of 33% is the benchmark for attackers, because if it exceeds this amount, they will be able to prevent the beacon chain from completing, and do not need to carefully control the behavior of other verifiers. They can simply disappear together. This is because to complete the beacon chain, the checkpoint must be verified by 2/3 of the pledged Ethernet. If 1/3 or more pledge ethers are maliciously verified or not verified, the absolute majority of 2/3 cannot exist. The way to prevent this is to leak the inactive beacon chain. This is an emergency security measure that is triggered when the beacon chain fails to complete four epochs. Inactive disclosure identifies those verifiers who have not verified or whose verification results are contrary to most. The pledged ether coins owned by these non verified verifiers will gradually drain until they together account for less than 1/3 of the total, so the chain can be completed again.

50% and 51%

In theory, if the malicious verifier controls 50% of the pledged ETH, he can divide the Ethereum blockchain into two equal sized forks. Similar to the balance attack mentioned earlier, attackers can maintain two forks and prevent final certainty by proposing two blocks for the same slot and then simply using 50% of their control to vote against the honest verifier set. After four epochs, the inactive leak mechanism on the two forks will be activated, because each fork will see that half of its verifiers cannot verify. Each fork will extract the pledge of the other half of the verifier set, resulting in two chains represented by two thirds of the absolute majority by different verifiers. At this point, the only choice is to rely on community recovery.

In contrast, when attackers control more than 51%, they can control the fork selection algorithm. In this case, attackers will be able to verify through a majority vote, so that they have sufficient control to conduct a brief reorganization without cheating honest customers. The 51% share does not allow attackers to change history, but they have the ability to influence the future by applying their majority vote favorable bifurcation and/or restructuring inconvenient unreasonable blocks. Honest verifiers will follow suit, because their fork selection algorithm will also regard the chain favored by attackers as the heaviest chain, so the chain can be finally determined. This allows attackers to review certain transactions, carry out short-term reorganization, and extract the maximum MEV through favorable reordering of blocks. The defensive measure against this situation is that the attacker puts most of the pledges at risk, because the social layer is likely to intervene and use honest few pledges, which will greatly devalue the attacker's pledge.

66%

Attackers with 66% or more pledged ethers can complete their preferred chain, and they do not have to force any honest verifiers. Attackers can simply vote for the fork they like, and then complete it. They can vote with an absolute majority of dishonest votes. As an absolute majority pledge, attackers will always control the content of the final block, and have the power to consume, roll back and consume again, review certain transactions and restructure the chain at will. The attacker is actually buying the ability to reorganize after the event and restore finally (that is, change the past and control the future). The only real defense here is to go back to the social layer to coordinate the adoption of alternative forks.

In general, despite these potential attack vectors, the risk of beacon chain is very low, even lower than their workload proving equivalents. This is because attackers need to risk the huge cost of pledging ETH to overwhelm the honest verifiers with voting rights. The built-in incentive layer can prevent most malicious behaviors, especially for low-risk attackers. More subtle bounce and balance attacks are unlikely to succeed, because real network conditions are difficult to achieve fine-grained control over the message delivery of a specific subset of verifiers, and the client team has quickly fixed known bounce, balance and avalanche attacks with simple patches.

However, 33%, 51%, or 66% of attacks may require community votes to resolve, so effective community governance is a strong disincentive for attackers. For attackers, technically successful attacks still have the risk of being stopped by the community, which reduces the possibility that attackers can earn enough profits to act as effective deterrents. This is why maintaining an effective community with consistent values is so important for investment.

ETHPoW security

Miners have been playing an important role since the establishment of Ethereum, but the merger of Ethereum will break this situation. Bitpro estimates that GPU miners need to close about 95% of their GPUs to remain profitable in the combined crypto ecosystem. However, since it is unlikely to close so many GPUs immediately after the merger, the miners will try PoW bifurcation after the merger. If some exchanges also support bifurcation, the life of the bifurcation will be longer than expected. So far, some institutions have supported ETHPoW hard branching, including Gate, OKX, f2pool, Matcha, BitMEX and Justin Sun.

On August 15, 2022, Ethereum Pow announced on Twitter that the initial version of ETHW Core has been released on GitHub, with the following main functions: 1. Disable difficulty bombs; 2. EIP-1559 was changed, and the basic cost was changed to a multi signature wallet jointly managed by the miners and the community; 3. Adjust the initial mining difficulty of ETHW.

On August 26, 2022, Ethereum PoW released ETHW's first test network "iceberg" on Twitter. The following are blockchain browsers and RPC servers. They welcome all potential partners in the community (exchanges, pools, wallet providers, bridges, builders, etc.) to join in building a real POW driven Ethereum ecosystem.

So, what security problems might ETHPoW face after Ethereum merger? We will analyze in detail below.

Algorithmic attack

When a malicious single entity or organization in the system can control most (i.e. more than 51%) of the whole network algorithms, 51% of the algorithm attacks are potential attacks on the blockchain network. Since the consensus in the PoW algorithm is determined by the algorithm, an attacker can use the algorithm to tamper with the ledger, thus causing a malicious attack on the system. After the merger of Ethereum, miners who can no longer earn income from mining will close their mining machines, which may cause the POW based ETH bifurcation to lose some computing power. For example, Ethermine, the largest mining pool at present, has announced that it will stop supporting ETH PoW mining.

Once the computing power of ETHPoW is reduced, the cost of an attacker launching an algorithm attack will be reduced. Then the attacker can rent a large amount of computing power of the ore pool to make its computing power reach more than 51%. At this time, it can use its computing power to generate blocks more quickly. When the generated blocks become the longest chain in the system, it can roll back block transactions to achieve data tampering, which will cause great harm, such as: Shuanghua, arbitrary address control transactions, etc.

honeysuckle

Double flower attack refers to the attacker's attempt to repeatedly consume the same digital token owned by his account. One example:

Assume that A has 51% calculation force at block height 1000. A transfers one ETH to B, and the transfer transaction is packaged by the miner.

After the transaction is confirmed, A relies on 51% of its computing power to regenerate a "longer chain" after the block height is 999, and transfers ETH to C again when the block height is 1000, and packages the transaction records, that is, the chain contains records of transferring ETH from A to C.

According to the "longest chain consensus", the chain containing records transferred to C becomes the main chain, and an ETH transferred from A to B is "invalid payment".

Control transactions at any address

With 51% computing power, attackers can package or unpack transactions at any address, prevent block confirmation of arbitrary transactions, and even prevent some miners from obtaining effective accounting rights, so as to achieve the purpose of controlling transactions at any address.

However, 51% of computing power is not omnipotent. For example, it cannot modify other people's transaction records, prevent the sending of transactions, or generate ETH out of thin air.

Replay attack

In traditional terms, replay attack refers to that an attacker sends a packet that has been received by the target host to cheat the system. In the blockchain field, replay attacks usually occur when the blockchain is hard forked, which means that "transactions on one chain are usually legal on the other".

On July 20, 2016, Ethereum hard forked at the height of 1.92 million blocks, generating two chains, called ETH Chain and ETH Classic Chain, and the corresponding tokens are ETH and ETC.

Since the addresses and private keys on the two chains are the same, and the transaction formats are identical, the transactions on one chain are also completely legal on the other chain. Transactions initiated on one chain may also be confirmed if they are replayed on another chain. Because there is no proper plan in advance, many people take advantage of this loophole to continuously deposit and withdraw money in the exchange to obtain additional ETCs. Therefore, "replay attack" has been redefined in the blockchain world.

At present, the hard fork ETHPoW that may appear in the Ethereum merger may also have the above problems in theory.

What should be done to prevent replay attacks? In fact, it is easy to achieve the fork for upgrade, because 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 forking, miners usually reject transactions before a certain version to avoid packaging "illegal transactions" from old clients (not malicious transactions, but low version numbers that are not recognized by other nodes), which makes it difficult for malicious attackers to steal funds through replay attacks during the hard fork upgrade.

On August 23, 2022, Ethereum PoW officially 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.

The following is a brief introduction to EIP-155:

This proposal is called "simple replay attack protection". If block number >= FORK_ BLKNUM and CHAIN_ ID is available. When calculating the hash value of a signature transaction, do not hash only the first six rlp coded elements (nonce, gasprice, startgas, to, value, and data), but the nine rlp coded elements (nonce, gasprice, startgas, to, value, data, chain, 0, and 0). At this time, the value of v in the signature is no longer recid, but recid+chainID * 2+35.

Therefore, in short, Signer and PrivateKey are required when signing a transaction. Singer is required because after EIP-155 fixes the replay attack vulnerability, the original blockchain signature method needs to remain unchanged, but a new version of the signature method needs to be provided. Therefore, the old and new signature methods are implemented through one 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 of the transaction for signature. Compared with the old method, the hash calculation mixes the chain ID and two null values. Note that this hash value TxSignHash is not equal to the transaction hash value in EIP-155.

In this way, a signature transaction may only belong to the blockchain with unique identification.

In addition, to ensure the security of the project, it is recommended that the signature data should include the Chain ID when the project performs offline signature verification in the contract to avoid asset loss caused by cross chain signature reuse.

Application layer project

In fact, the traditional bifurcation requires calculation power to make a choice, and the protagonist of the choice is the miner. This time, if there are two Ethereum chains at the same time, it is the entire Ethereum ecosystem that needs to make a choice. The project parties here are users and investors.

Today's Ethereum is different from the hard bifurcation in 2016. The DeFi project has occupied most of the Ethereum ecosystem, but the foundation of DeFi is the assets on the chain, so the project is mainly along the asset side. The asset side is stable assets such as USDT and USDC, while the pledge or loan projects of DeFi are mainly asset side.

For the issuers of these stable assets (mainly referring to stable currency here), if Ethereum bifurcates, they will suddenly face a problem - two versions of stable currency. As the issuer of stable currency, for each stable currency issued, there will suddenly be two debt obligations.

Although most people think that stable currency issuers will regard the new PoS chain as a "real" Ethereum network, what if they want to support the PoW chain? After all, they have enough economic motivation to do so.

For example, they can short the PoS Ethereum token, announce redemption on the PoW network, and earn billions of dollars. This may damage the new Ethereum network, and the protocol, exchange and related DeFi projects will be closed. This will cause huge chaos and may destroy the cryptocurrency market on a large scale.

Similarly, Ethereum Pow, the Ethereum Fork project, tweeted on August 17 that ETHW Core would introduce liquidity pool freezing technology to protect user assets. Because after the hard fork of Ethereum PoW, especially in the first few blocks, the ETHW tokens stored in the mobility pool by users, such as Uniswap, Susisswap, Aave, Compound, will be used by hackers to exchange or borrow USDT, USDC, WBTC in an abandoned or worthless way, which will cause huge damage to the entire network and community. Therefore, ETHW Core temporarily froze some LP contracts to protect users' ETHW tokens until the controller of the agreement or the community found a better way to return users' assets. The freeze is not applicable to equity contracts involving only a single asset (such as ETH2.0 deposit contracts and packaged ether currencies). ETHW Core recommends that everyone withdraw ETH from LPs (such as DEX and loan agreements) before hard branching.

Source: https://medium.com/ @Beosin_ com/ethereum-pos-and-pow-security-fd52a6153b1e