Can Ethereum 2.0 Solve the MEV Conundrum?

Eth2 will have MEV too, and how will verifier revenue be affected?

Originally written by Alex Obadia & Taarush Vblockquotepapalp

Unitimes is the era of independence

Ethereum will soon transition from PoW to PoS consensus protocol. Developers have been working on this transition for several years, in several steps. The first step was to launch the beacon chain in December 2020. The current beacon chain is now online, and at the time of writing, there are over 160,000 vapdators on the beacon chain, equivalent to about 5 million ETH being pledged.

The second step, a "grand merger", could take place in early 2022. While there are many details to be worked out beyond this step, enough details have been worked out about POS Ethereum (i.e. ETH2) to allow us to infer the maximum Extractable Value (MEV, Maximal Extractable Value), Formerly known as "miner extractable value") in ETH2.

In this article, we will examine transaction sequencing in ETH2 and analyze the verifier revenue growth resulting from MEV value extraction. We found that MEV would significantly increase the rewards received by verifiers, but could also exacerbate inequality among ETH2 participants. We will also discuss the qualitative aspects of MEV in ETH2, such as the underlying dynamics between the largest stakeholders such as the trading platform and the verifier pool (i.e., the pledge pool).

This article was written by Alex Obadia and Taarush VBlockquotepapalp. For complete analysis documentation, see:

https://github.com/flashbots/eth2-research‍

01. For eth2 overview

The current consensus on Ethereum is implemented by miners running mining hardware optimized to better address PoW challenges. The shift from PoW consensus to PoS consensus means that the Ethereum network will be protected by verifiers (rather than miners), with each verifier node having to pledge a deposit of 32 ETH and vote to reach consensus on the status of the beacon chain. There is an economic incentive for the verifier to do so, with the verifier being rewarded for good behavior and punished for offline or malicious behavior (forfeiture).

Currently, the beacon chain operates in parallel with the ETH1 chain and has been successfully operational since December 2020. The "Big Merge" merges the beacon chain with the current ETH1 chain. In this article, we'll use "eth1" to refer to the Ethereum execution engine that contains blocks and transactions; Using a "beacon chain" to represent the new underlying POS consensus mechanism in ETH2; Use "eth2" to represent the merged Ethereum authority chain, which includes the eth1 execution engine and the beacon chain for consensus implementation.

ETH2 reached consensus in increments of 6.4 minutes (called an epoch). Each epoch contains 32 slots, each of which is 12 seconds long, and each slot represents an opportunity for a block to be added to the beacon chain. Under normal operation, each slot generates one block, but reasons such as the verifier being offline may cause some Slots to produce zero blocks.

For each epoch, all verifiers are pseudo randomly assigned to propose blocks or attest to blocks proposed by other verifiers, called "proposers". The verifier who proves the block is called the "demonstrator". There is only one proposer and multiple protestors during each slot, and these protestors are responsible for certifying all information in the block, including data from eth1 and data from the beacon chain. Proofers are rewarded by correctly voting on the current values of the "three aspects" of the beacon chain: the head of the blockchain (the top block), the proven checkpoint, and the confirmed checkpoint.

Note: The last slot of each epoch is called a checkpoint. When two successive epochs were justified, the first epoch was finapzed. For more information, see Ethereum 2.0: How to Achieving Finality. .

02. MEV in eth2

The MEV (Maximum Extractable Value) is the total possible value that a block proposer can obtain by reordering, reviewing, or blocking transactions within their proposed block. To understand transaction sorting in eth2, let's first look at the inner workings of the software used to sort transactions (that is, the eth2 client).

1. The eth2 client

Since eth2 is essentially two chains merged together (that is, the eth1 chain and the beacon chain), it is not surprising that the eth2 client consists of two "sub-cpents" : one is the execution engine client and the other is the consensus client. It is important to note that the current POW Ethereum client (i.e., the ETH1 client) will continue to exist in ETH2 and run alongside the beacon client, with a different division of labor.

The eth1 client in eth2 is stripped of its consensus responsibilities to the current POW Ethereum client and only focuses on the trading pool of the eth1 chain, eth1 execution, and EVM; The beacon client, on the other hand, is responsible for consensus and assigning verifier responsibilities (such as proofs and proposals for beacon blocks). The two clients run in parallel and each maintains its own P2P network stack (the beacon client maintains PBP2P and the eth1 client maintains DevP2P).

The eth2 client might look like this modified schematic below (from the article by Danny Ryan [1])

Figure 1

2. Block Proposal for ETH1

As in current POW Ethereum, the eth1 client in eth2 will maintain a local transaction pool (MBlockQuotePool) containing the transactions received from its P2P network. As described in the Rayonism specification [2], the beacon client will interact with the eth1 client to form an eth1 block. While the details of the communication path in the specification may change in production, the general pattern is likely to remain the same:

After several rounds, the beacon client queries the eth1 client for a certain eth1 block formed through the eth1 trading pool to check whether the block meets various validity conditions;

Once this eth1 block is received by the beacon client, and various validity checks have been met, then this eth1 block is bundled up with the proposers in the current beacon block, and becomes a part of the data that the certifying party wants to vote on (attesters).

The beacon client will then ask the eth1 client to update the eth1 chain's header (the top block) to the latest bundled eth1 block;

After an interval, the epoch containing the beacon block is determined (finapzed), and the beacon client notifies the ETH1 client that the ETH2 block has been determined at the consensus layer.

Figure 2

Although the way consensus is reached in ETH2 has changed, the sorting of transactions within each ETH1 block in ETH2 is the same as it is today, implemented in the software that sorts transactions (such as POW Ethereum client Geth) and in the P2P trading network.

3. Is there Mev in eth2?

Since the transaction sorting process in ETH2 will be the same as in current POW Ethereum, it is reasonable to assume that MEV opportunities will still exist in ETH2, as we see today in POW Ethereum. The difference is who has ultimate control over the ordering, that is, in eth2, the verifier (not the miner) will have control over the transaction ordering, and the verifier is selected to propose the beacon block, which will contain a new eth1 block that is queried from the eth1 client.

Figure 3

This means that technologies such as Flashbots' mev-geth, a modified eth1 client software designed to optimize the extraction of MEVs, will still exist that allow eth1 transaction senders to sort their desired transactions by tipping the block proposer (and the transaction sequester). With that proposition in mind, we can now think about how much money verifiers can make by running software like Flashbots.

03. Rewards for verifiers

Although MEV is notoriously difficult to measure, we used Flashbots data [3] as a floor for the minimum additional revenue that ETH2 block proposers can get through MEV. This is a lower bound because only a small percentage of MEV activity takes place on Flashbots.

One caveats to this analysis is that this article considers MEV based on staking benefits as provided by ETH2, but does not include the transaction fee incentive that the block proposer might receive. The main reason these transaction fees are not included is that it is difficult to predict how much the proposer will earn from the transaction fees after EIP-1559 (which will introduce the destructing mechanism of BaseFee).

1. The ideal situation

Let's first consider an ideal situation in which all validators participate perfectly and get the largest possible agreement reward (that is, there is no wholesale confiscation), and all staking rewards are evenly distributed because all validators are proposing the same number of blocks on an infinite time scale.

Figure 4: The Y axis represents the return rate and the X axis represents the number of verifiers. The blue line shows the verifier annual return rate in the ideal case without considering MEV; The yellow line represents the verifier annual rate of return in the ideal case, taking MEV into account. The blue vertical line indicates the number of verifiers at the time of the article (about 160,000).

Based on the current number of validators (160,000 validators), we find that MEV can increase the validator reward by 75.3%, or provide an APR of 12.83% (annualized rate), which is higher than the 7.35% APR return from pledgings of ETH with MEV in mind. One conclusion that can be drawn from this is that higher verifier rewards mean that more ETH holders will be attracted to become verifiers, which in turn means that Ethereum is more secure with a larger set of verifiers.

With more verifiers coming online in the near future, the increase in MEV-based verifier revenue will be less significant, such as a 60% increase in rewards for 250,000 verifiers (i.e., 8 million ETH pledged). As mentioned above, this analysis does not take into account how much transaction fees the verifier will earn, as this will reduce the relative impact of MEV on earnings. However, this data is still useful when compared to the additional MEV rewards currently earned by POW miners through Flashbots (currently around 5.6%). This apparent difference is due to the significant decline in POS issuance rate. This suggests that the MEV extraction will be more worthwhile in ETH2 than in ETH1, and that stakers are likely to push the pledge gains through MEV heavily.

2. Take the time factor & The REV allocation is taken into account

On any limited time scale, the verifier's reward is variable, because proposed blocks have a specific protocol reward, and because some verifiers will be lucky enough to propose a larger than average number of blocks, while some less fortunate verifiers will propose fewer blocks.

For example, if there are 100,000 validators in the network, the average number of blocks proposed per validator per year is 26 blocks, while the least fortunate 1% of validators have a chance to propose up to 15 blocks and the luckiest 1% of validators propose at least 39 blocks. See below:

Figure 5

Based on this logic, we can plot the variability of the demonstrator reward based on 3 different levels of block proposal "luck" (that is, the luckiest 1% of verifiers, the unluckiest 1% of verifiers, and the average verifier) :

Figure 6: The Y axis represents the return rate and the X axis represents the number of verifiers. The green line represents the annual rate of return the luckiest 1% of verifiers would get regardless of MEV. The red line stands for the annual yield that the least fortunate 1% of verifiers would get without MEV; The yellow line represents the average annual yield the verifier would get without MEV. The blue vertical line indicates the number of verifiers at the time of the article (about 160,000).

Now we add the average REV (i.e. Reapzed Extractable Value) of each block recorded on Flashbots [4], We can compare the prover yield of these three different levels of block proposal "luck" with and without MEV value:

Figure 7: The green line shows the annual rate of return for the luckiest 1% of verifiers with MEV value extraction; The red line shows the annual rate of return that the least fortunate 1% of verifiers can get with MEV value extraction; The yellow line represents the average annual rate of return the verifier can obtain with MEV value extraction included. The bottom bold line is the annual rate of return that the demonstrator would get in 3 block proposals "luck" without MEV, but because the differences between the three lines are so small in the figure above, they are stacked together.

The three curves in the figure above (Figure 7) for staking the annual verifier yield for the three "luck" levels that do not take into account the value of MEV are almost indistinguishable from each other. This suggests that the extraction of MEV value widens the inequality of the benefits between verifiers due to the "luck" of block proposals.

Furthermore, the distribution of REVs is uneven and can be viewed as a second dimension of "luck", where some blocks have larger MEV rewards than others. For example, here is the (long tail) distribution of REV rewards earned by miners using Flashbots' MEV-geth in the most recent Ethereum 100,000 contiGUous blocks (starting at the height of 11600000 blocks) :

Figure 8.

In the figure above (Figure 8), we truncated the X-axis (the actual REV value earned by the miners in each block) to 3 ETH, but in reality the miners in our sample could get up to 101 ETH. Using this distribution of Flashbots miner rewards to represent the distribution of REVs, we can define and plot the annual yield curve for three luck levels based on the returns from MEV rewards for the unluckiest 1% of verifiers, the average verifier, and the luckiest 1% of verifiers:

Figure 9: The green line represents the annual return of the luckiest 1% of verifiers with MEV value extraction included. The red line represents the annual return that the least fortunate 1% of verifiers would get if MEV value extraction was included; The yellow line represents the average annual return the verifier can earn with MEV value extraction included. The blue vertical line indicates the number of verifiers at the time of the article (about 160,000).

The previous chart (Figure 7) shows that MEV widens the inequality of benefits between validators due to the "luck" of block proposals; The chart (Figure 9) shows that the uneven distribution of REVs is a much larger source of income inequality among verifiers, especially considering that the Y-axis in this chart (Figure 9) grows to 600%, while the Y-axis in Figure 7 is only 80%.

In reality, however, verifiers will eliminate the variance in verifier returns from uneven distribution of block proposal luck and REVs by pooling resources in vapdator pools (also known as pledge pools). However, this means that the impact of MEV on verifier revenue may discourage people from running verifier nodes independently, making it more financially attractive to join a pool of verifiers, and thus possibly leading to centralization of network validation.

Ultimately, we are concerned that MEV may exacerbate the oligopolistic dynamics in ETH2, as entities with the most ETH pledges grow faster than those with less ETH pledges (the verifier pool). This will make democratization of MEV extraction particularly important in ETH2 to keep consensus voting decentralized.

04. New consensus players

While the above quantitative analysis is important to start thinking about MEV in ETH2, this article would not be complete without qualitative analysis of the ETH2 consensus participants. As mentioned earlier, in ETH2, miners and pools are replaced by entities that control a large amount of ETH, such as trading platforms, pools of funds for protocols, investment funds, and pools of verifiers. This can already be seen by the distribution of the eth1 deposit addresses of the current eth2 verifier displayed on the beaconcha.in beaconcha.in:

Figure 10: Distribution of eth1 deposit addresses for all eth2 validators. As you can see, a large number of ETH2 verifiers are pledged through the addresses of entities such as several trading platforms and pledge pools, which means that these entities control a large percentage of ETH2's voting power.

It's worth noting that the pie chart doesn't distinguish between the ultimate entity that controls the voting power of the consensus and the infrastructure it operates on. While the centralization of the ETH2 consensus voting power is a concern, the centralization of infrastructure may not be, and the POS economic incentives encourage the decentralization of infrastructure to minimize the associated slashing risks.

Specifically, this means that a trading platform like Kraken, which controls a large amount of ETH, may be able to run the ETH2 nodes in different regions and on different hardware by spreading its pledge money across many infrastructure providers, rather than undertaking this massive infrastructure running task internally. Thereby reducing the risk of substantial forfeiture.

1. Trading platform

The most notable change in ETH2 is that the trading platform has become the largest holder of ETH, and therefore the largest verifier. Centralized enterprises such as Coinbase, Binance, and Kraken will probably control the largest number of Slots validators. These participants are subject to different rules than mine pools, with many implications for their reputations. This difference may have new implications for the pattern of verifiers as compared to the pattern of miners, and may affect the activities that verifiers engage in, such as the type of MEV they receive revenue from.

Interestingly, these entities are involved in a number of activities in addition to their involvement in ETH2 pledging, which may open up new opportunities for synergies between the existing services offered by these trading platforms and MEV value extraction. These activities include expediting transactions, providing private withdrawals before the withdrawals are packaged onto the chain, and reducing on-chain transaction fees through encrypted native payments to the order stream.

Such services may initially be cutting edge, and their benefits may mean that users migrate to the exchanges that offer them, potentially harming those that do not or cannot offer them for regulatory reasons. In addition, the potential vertical integration of trading platforms in MEV games, such as trading platforms running their own robots to submit trades to their own verifier nodes, is an issue of concern that we believe should be further investigated.

2. Verifier pool

Another important shift in ETH2 is the rise of vapdator pools, also known as "pledge pools," which provide requirements such as lowering the minimum number of ETH required to participate in ETH2 pledges (32 ETH required for users to run a single verifier node themselves, Joiningthe validator pool can provide less than 32 ETH because the validator pool will pool all users' ETH for pledge), build the validator node for customers, eliminate the variables due to the "luck" of the block proposal (which will affect MEV+ transaction fee earnings), And providing additional services, such as derivatives, that benefit from staking (thanks to the capital base they manage).

One interesting phenomenon is the emergence of meta-pools, such as the RocketPool and PDO. These entities are connected to a number of verifier pools and are likely to be a large source of pledge volume for these verifier pools, thus influencing the behavior of the verifier pools, such as the types of MEV extractions the verifier pools participate in and the profit sharing they provide to the pledger.

These meta-pools often provide collateral derivatives. One example of this is to offer users a liquid tokenised version of their ETH pledge deposit that they have locked up, which they can use across the (Ethereum) network using this derivative. This will further increase the verifier's revenue beyond the value of the MEV by allowing the user to re-use the locked ETH in the DEFI in the form of derivatives.

05. Open questions

Our exploration of MEV in ETH2 has uncovered a number of unanswered questions, which we plan to study in the coming months. Here are four of them:

1. ETH1 Block Proposer Market

Since eth2 actually has two clients to run (eth1 client + beacon client), it is likely that independent validators will choose to default their eth1 node to a service provider, such as Infura, since running eth1 node itself is very expensive. This may indicate that the eth1 and eth2 node runners are starting to separate. Given such a dynamic emergence, we can imagine a market of ETH1 node operators running high-performance hardware and MEV emulation software to meet the needs of ETH2 block proposers.

2. New limitations when optimizing MEV search

MEV opportunities such as price arbitrage and clearing still exist in ETH2, but the system that extracts these MEV values has new parameters that may modify or introduce constraints on MEV extraction.

For example, the block time of ETH2 is fixed at 12 seconds rather than variable like the current ETH1 block time, and the lots of block proposers are assigned at the beginning of each epoch, which means that proposers will have up to 6.4 minutes to calculate their tasks (of course, The proposer of Slots who was assigned at the beginning of Epoch didn't have that long). This not only provides potentially more time for the verifier to run calculations on the ETH1 client trading pool to get the best MEV extract, but also makes simulation and execution easier due to the predictability of the block time.

This means that there are longer, more predictable intervals to calculate and execute MEV extraction strategies, resulting in more complex and computationally intensive MEV extraction.

3. Changes in the mechanism of leader selection

Verifiers will know in advance if they need to propose a block (unless it's the first slot for a new epoch). They could even (albeit with low probability) propose multiple blocks within an epoch. How does the determination of block proposer identity change the dynamics of MEV value extraction? And if it is determined that multiple blocks will be proposed within one block, how will this affect the dynamics of MEV extraction? In particular, a large validator pool/trading platform is most likely to have (be assigned to) multiple consecutive slots within the same Epoch.

4. Layer 2s & shard

Most of this article assumes that the contents of eth1's blocks will remain as they are today. However, in reality, many of the transaction flows will be moved to L2S, Ethereum Layer 1 will be used as the data availability Layer, and ZK-rollups and optimistic rollups will be responsible for delivering the bulk packaged transaction data to Layer 1.

This will intuitively reduce the benefit that verifiers get from MEV. This is difficult to predict, however, because the world of multiple Layer 2s introduces additional complexity that may open up new forms of MEV (i.e., transactional across Layer 2, transactional across Layer 1-layer 2). Similarly, as ETH2 continues to evolve and sharding is put into production, sharding sequencing within beacon blocks could become significant, and MEV could become an incentive to implement VITAPK's proposal to "stagger sharded blocks to achieve faster block-out times" [5].

Thanks to Terence Tsao, Rap Jordan, Alejo Salles, Luke Youngblood, Tomasz Stanczak, Lakshman Sankar, Barnabe Monnot, Caspar S and Viktor Bunin's valuable contribution and editing to this article. Thanks also to the rest of the Flashbots team for the discussion.

Links involved in the text:

1:
https://ethresear.ch/t/eth1-eth2-cpent-relationship/7248

2:
https://github.com/ethereum/rayonism/blob/master/specs/merge.md#assblockquoteble-block

3:
https://dashboard.flashbots.net/

4:
https://hackmd.io/@flashbots/quantifying-REV

5:
https://ethresear.ch/t/simple-approach-to-incentivizing-shard-staggering/914

Source connection

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia