Partnered With:

Why attacks against DeFi will be more difficult to execute after the Ethereum 2.0 merger

Read this article in 23 Minutes

After the merger, reorganization verification will become a smaller problem, because a single validator or a small group of attesters cannot reorganize a block on their own. A successful reorganization attack requires solving the coordination problem of getting a majority of validators to participate at the same time.

Original source: Paradigm

Original author: Georgios Konstantopoulos, Vitalik Buterin

Original translation: ETH Chinese website

Recently, there has been discussion about the possibility of miners using a modified Ethereum client that does not yet exist, mainly to allow miners to accept bribes and perform short-range reorganizations of the blockchain (the main use case for creating such bribes is to attack DeFi protocols).

In this post, we will explain why this attack vector is more difficult to execute after the Ethereum 2.0 merge.

What is the fork choice rule and why it matters

The fork choice rule is a function evaluated by the client that takes as input a set of blocks and other messages it has seen, and outputs the contents of the "canonical chain" to the client. A fork choice rule is needed because there may be multiple valid chains to choose from (i.e. if two competing child blocks of the same parent are published at the same time).

A reorg is an event where a block that was originally part of the canonical chain is no longer part of the canonical chain because a competing block beat it out. Finality is a situation where the fork choice rule strongly favors a block so that it is mathematically impossible (or at least economically infeasible) to reorg.

In some fork choice rules (e.g. Tendermint), reorgs are impossible; the fork choice rule simply extends the existing chain by adding any blocks that have been finalized by BFT consensus. In other fork choice rules, reorgs are common.

What is the current situation of Ethereum?

In PoW blockchains such as Ethereum, we usually see the "longest chain rule" (or more accurately, the "highest total mining difficulty rule"). This means that when a client sees two blockchains, it will choose the one with the highest total difficulty (that is, the sum of the difficulties of all blocks in the chain).

For the sake of example, assuming that the block difficulty can be 100 or 110, imagine the following scenario:

1. We start syncing from block 1 with a difficulty of 100.

2. Blocks 2a and 3a both arrive with a difficulty of 100, and we embed them into our blockchain, forming a fork with a total difficulty of 300.

3. Block 3b arrives with a difficulty of 110 and claims that 2a is its parent block, forming a fork with a total difficulty of 310. The fork choice rule will see that the "heaviest" chain is the second fork, and will switch to it. This is a 1-block reorg, since only block 3a has been changed. Note that the block is not simply discarded, since newly arrived blocks could cause the fork choice to switch back to the first fork.

4. Blocks 2b and 3c both arrive with difficulty 110, forming a new fork with a total difficulty of 320. This means that the fork choice rule will now use 2b instead of 2a, and 3c instead of 3b, both of which were in the previous canonical chain. This is a 2-block reorg.

The reader should be able to see how the logic works. If a new block 4a arrives and claims 3a as its parent, the fork choice rule switches to choose the first fork, and so on.

Effects of Chain Reorganizations

Short reorganizations often occur due to latency. Miner A and miner B may find a valid block at the same time, but because blocks are broadcast across the p2p network, part of the network may see miner A's block first, while another part sees miner B's block first. If two blocks have the same difficulty, there is a tie, and the client either chooses randomly or chooses the block it saw first. Often, when a third miner C builds a block on top of the block built by miner A or B, the other block is forgotten. Occasionally, bad luck can lead to a 2-5 block reorganization. Reorganizations longer than that are almost always due to extreme network failures, client vulnerabilities, or malicious attacks.

Short-range reorgs are not fatal, but they do still have some serious detrimental consequences for the network:

· Node overhead: When a reorg occurs, nodes will have some memory and disk overhead because they need to switch to the new fork and may need to re-execute transactions or state edits.

· Degraded user experience: Possible reorgs mean that users will need to wait longer before they can safely process transactions that need to be "confirmed". An important sub-use case of this is that businesses such as trading platforms need to wait longer before accepting deposits.

· Uncertainty in transaction context: When a user sends a transaction, they are less certain about the context in which the transaction will be executed (e.g., will the latest N blocks be rolled back). Obviously, this will make DeFi transactions more prone to unexpected failures, worse-than-expected transaction results, or harmful MEV extraction.

· More vulnerable to 51% attacks: In a system with the longest chain as the fork selection rule, if the blockchain switches from choosing B1 to B2 for reorganization, then the difficulty of B1 no longer provides security for the chain. The attacker no longer needs to defeat all honest miners, they only need to defeat the honest miners that have not been reorganized. If the reorganization is frequent, this will make the attack much easier.

The worst case scenario

In the worst case, frequent reorganizations will completely invalidate the settlement guarantee of the blockchain and prevent it from continuing. Normally, the "incentive compatible" strategy for block producers should be to extend the longest chain. But what if the state after a block is executed is abnormally profitable (for example, the transaction fee is high, or MEV can only be extracted by building a new block directly after the block). This issue has been discussed in the past in discussions of "Bitcoin without block rewards" and selfish mining, and is also discussed today in the issue of "MEV related to DeFi in the Ethereum ecosystem".

In both of these situations, there is a strong incentive to try to "steal" fees by competing with other blocks, rather than extending the authoritative chain. In the example below, the post-execution state of block 1 is very profitable, and block 2a has been mined. However, not one, but three block producers have chosen to continue mining on block 1 instead of block 2a (to obtain the MEV revealed after block 1), and this can be extended to any number of block producers.

Obviously, this pattern opens the door to a malicious 51% attack. We call the situation where miners participate in this reorganization mining strategy "short-sighted rationality" because the decision to do so may be rational in the short term. However, they are all either explicitly (stakers) or implicitly (miners) bullish on ETH (because transaction fees and block rewards are denominated in ETH), which means that this attack that reduces user trust in Ethereum is in conflict with their best interests and is therefore irrational in the long run.

Merged PoS Ethereum

In the Nakamoto PoW consensus algorithm, blocks are "continuously" finalized in the fork choice. First, when a block is mined, a competing block may be able to reorganize it. If a block is successfully packaged into the authoritative chain, (on average) 13 Seconds later, another miner will build a second block on top of that block. At this point, a chain needs two competing blocks to be reorganized. As more and more blocks are built, the difficulty of reorganizing the chain will continue to rise, but slowly.

The Ethereum beacon chain implements a proof-of-stake protocol called Gasper, whose fork selection rule is called LMD-GHOST. Unlike Nakamoto PoW, in Gasper, there are two roles involved in block production:

· Proposer: A validator who is responsible for proposing blocks

· Attestor: A group of validators who vote on the block that should become the head of the authoritative chain. The attestor's vote is called an "attestation", which is the "weight" they give to the block. Controlling the attestor means controlling the fork selection rule.

Every 12 seconds there is a slot, which represents an opportunity to propose a block. In each slot, a shuffle algorithm pseudo-randomly selects a committee consisting of approximately 1/32 of the total number of validators, where one validator in each committee acts as the proposer and the rest of the validators act as attesters. Attesters also vote on the blocks they think should be included in the canonical chain. Because the committee is formed by pseudo-random sampling, there is no way for an attacker to concentrate all their validators in a single slot.

Currently, the beacon chain has about 196,000 validators, which means that the number of committee members in each slot is about 6125. Therefore, even a reorganization of a block is extremely difficult, because an attacker who only controls a few validators cannot defeat the honest majority of thousands of validators.

To better understand why this is the case, let’s look at the following example: there are 2 slots and 24 validators, 9 of which are malicious. The validators are divided into 2 committees, and after random shuffling, it is unlikely that an adversary can control 50% of the committees they are assigned to, let alone achieve a reorganization.

More formally, the probability that a malicious actor with p% of the stake controls more than 50% of a committee of size N validators follows a binomial distribution (with k = N/2):

Calculating the probabilities for multiple stake values gives us the following table:

Now we understand that an attacker would need to control 50% of the total validators in order to directly cause a reorg.

Some smaller attacks are still possible if the controller controls 25-49% of the attesters (see this paper, or here for an overview). However, there are fixes for these attacks that can be executed quietly, achieving unconditional security close to 50%.

Finally, long-range reorganizations are impossible because all blocks deeper than the past two epochs are considered "finalized", i.e., rolling them back is impossible. If an attacker causes two conflicting blocks to be finalized (e.g., controls 67% of the stake), the system needs to go back and recover through social intervention.

Game Theory of Reorg Strategies

Now that we understand how reorgs occur under different fork choice rules, let’s look at a simple game theory example to understand when it makes sense for a miner or validator to run software to perform a reorg for a profit.

We can informally describe each scenario using a payoff matrix, where "defection" means "downloading and using the software that performs the reorg". The payoff is "short-sighted" and does not consider long-term consequences.

Nakamoto PoW

In the longest chain PoW, even a small fraction of the validator set can achieve a short-range reorg. The post-execution state is that unusually profitable blocks will always appear occasionally, and even a 1-10% chance of success is worth trying to compete with existing children of that block.

Miners can form a medium-sized mining pool and wait for the opportunity to find 2-3 consecutive blocks in the future, or send part of their income to a contract that anyone can claim, in order to bribe other miners who also run the same software to build their blockchain and help it beat the existing authoritative chain.

Therefore, some miners may try to run a reorganization client.

Gasper

In Gasper, reorgs for 1-64 slots are possible, but require the attacker to control a large portion of the entire validator set (since they can't concentrate their stake in a specific slot, their stake needs to be large enough to be randomly selected in the slot they want to attack). Adopting the reorg mining software is not very useful unless a very large number of other validators also adopt it.

So if 51% of validators are slightly altruistic or lazy, it is almost certain that no one will run the reorg mining software.

Tendermint

In Tendermint, things are much simpler: reorgs are impossible, and any implementation that violates the finalization rule for a single slot requires more than one-third of the validators to be slashed. Similar to the case of Gasper, this also means that it is almost certain that no one will run the reorg mining software.

From the above, we can see that although "reorg geth" is possible in all three cases, the fork choice rule based on the idea of parallel proofs leads to a more stable honest equilibrium than the Nakamoto fork choice rule.

Conclusion

In the context of Ethereum, the most effective preventive measure is to further accelerate the work on merges, especially to quickly develop the ability to achieve acceptable "emergency merges" to convert Ethereum to a PoS mechanism. Rushing a merge carries high risk and can disrupt infrastructure, but a credible commitment is needed to defend against such behavior if many miners start to reorg the chain.

The risk is greatest close to the merge, as miners still dominate the system, but their time is running out. However, two factors mitigate this risk:

· Ethereum miners are often also (i) miners on other blockchains, and/or (ii) members of the Ethereum community in other capacities, so the incentive to behave well continues.

· The cost and risk of performing an emergency merge decreases as the merge approaches. Performing an emergency merge a few months before the expected merge date is very disruptive. Performing an emergency merge two weeks before the expected merge date provides the ability to set parameters for clients that validator operators have already downloaded.

After the merger, reorganization verification will become a smaller problem, because a single validator or a small group of provers cannot reorganize a block alone. A successful reorganization attack requires solving the coordination problem of getting most validators to participate at the same time. However, there are still some small risks. If you want to further improve security, Ethereum can either further adjust the fork selection rule to raise the requirement for reorganization attacks to a theoretical maximum of 50%; or switch to a single slot to achieve the finalized consensus.

Acknowledgements: Thanks to Dan Robinson, Anish Agnihotri, Kevin Pang, Dave White, and MEVIntern for comments on drafts of this post.