MEV-Burn is designed to burn the MEV extracted from the network, ensuring the reward doesn't return to a specific entity.
If MEV-Burn is introduced, anticipated outcomes include alterations to the economic incentive model, revenue leveling between validators, diminished motivation for attacks on the consensus layer, and increased resistance to censorship.
Ethereum and other rollup networks have been actively discussing how to distribute MEV (Maximal Extractable Value), for a few years. There have been many ideas on how to redistribute MEV in the Ethereum and Flashbot communities, including the currently popular MEV-Boost, MEV-Share, and MEV-smoothing. MEV burn is an idea to burn MEV extracted from Ethereum, first appearing on eth.research in October last year under the name MEV burn. Over the next few months, the protocol appears to have made strides within the Ethereum Foundation. Recently, EF researcher Justin Drake thrust the topic into the spotlight by unveiling a more fleshed-out design.
In this article, I will introduce the background of the emergence of MEV burn and how the introduced MEV burn operates specifically. Also, we will examine the potential effects that MEV burn can bring.
The process by which MEV is extracted from the Ethereum network is generally as follows. Users make transactions (e.g., swap); Searchers combine user transactions with their own transactions to create bundles of MEVs (e.g., arbitrage); Builders create a block containing the MEV bundles and send it to validators, or the validators creates the final block contents themselves.
The most basic difference between the main MEV redistribution designs discussed to date — MEV-Boost, MEV-Share, MEV smoothing, and MEV burn — is who gets how much of the extracted MEV.
Currently, the most common MEV-Boost structure is for Searchers to compete for bundles of MEVs and bid on them to Validators, so under MEV-Boost, Searchers and Validators get most of the MEVs (the amount of MEVs actually taken by Builders is negligible compared to Searchers and Validators, so we’ll ignore that). MEV-Boost is an out-of-protocol implementation of Proposer-Builder Separation (PBS), and in-protocol PBS (or enshrined PBS), which is an attempt to bring PBS into the Ethereum protocol, would have a similar flow of MEVs.
However, since the opportunity and amount of MEV always varies depending on the state of the Ethereum network and the demand of DeFi services, the variation of MEV from block to block is quite large. This creates a significant income gap between lucky and unlucky validators. MEV smoothing is designed to reduce this variation in MEV rewards. Similar to MEV-Boost, MEV smoothing can be understood as a structure where Searchers and Validators get most of the MEV.
On the other hand, the recently introduced MEV-Share is based on the idea of returning MEVs to users. It is the first design that intends to return MEV to users, and Searcher and Validator will of course get a share of the incentive structure. (See: “MEV-Share: The Evolving MEV Redistribution Mechanism”)
MEV burn is a design that allows the extracted MEV to be burned without going to a specific entity. A simple way to understand MEV burn is to have the builders that create the block compete to bid on the block, and then burn some of the highest bids. Burning MEV is equivalent to giving back MEV to the network as a whole. Another way to look at the concept of burning is that it’s a way to pay out ETH to all ETH holders in proportion to their stake. The idea is to reduce the amount of Ethereum in circulation, making it a little rarer, while maintaining each ETH holder’s share of the total market capitalization.
The way MEV burn operates, as introduced to the community, is detailed next. Given the current scarcity of information on MEV burn, some parts not clearly illuminated in the public descriptions have been supplemented with the author’s conjecture. Thus, there may be minor discrepancies between this account and the actual process.
The MEV burn design is very similar to the In-protocol PBS design, which brings MEV-Boost into the Ethereum consensus layer. Whereas MEV-Boost outsourced the block generation task to the builder, which has to be done through a trusted relay, In-protocol PBS brings the builder completely inside Ethereum’s protocol. So in the two-slot design, which is the in-protocol PBS design we’re discussing, there are two separate blocks, one from the builder and one from the proposer.
A slot in MEV burn can be divided into six steps, as shown in the figure below. Before we get into the examples, here’s the overview:
In the bidding phase, Builders create candidate blocks and bid on the right to create blocks to Proposers, offering a ‘payload base fee’ and a ‘tip’. The payload base fee is the amount of Ethereum they are willing to burn, and the tip is the amount of Ethereum they will pay to the Proposer.
Attesters observe this and consider the highest value of the base fee to be the payload base fee floor.
During the Proposal phase, when the Proposer selects blocks, it selects blocks with base fees above the minimum payload base fee floor.
Attesters can only attest to blocks that have a base fee above the payload base fee floor in step 3.
In the Reveal Payload step, the Builder that created the selected block propagates the contents of the previously presented block.
Finally, attesters validate it.
Let’s take a closer look at how MEV burn works with the example below.
In the bidding phase, four Builders (A, B, C, and D) submit bids for the right to create blocks, which include a payload base fee, the amount to be burned, and a tip to the Proposer. In EIP-1559, the base fee was set automatically by the network, but here it is specified by the Builders themselves.
Since the payload base fee and tip proposed by the builders are propagated throughout the Ethereum network (unlike MEV-Boost), they are visible to the attesters. Attesters set the highest payload base fee they observe as the payload base fee floor. In the illustration above, Builder C and Builder D have suggested a payload base fee floor of 0.71 ETH, so the attesters will set the payload base fee floor to 0.71 ETH. The payload base fee floor is the minimum amount of Ethereum that must be burned in this block.
The Proposer finally selects one of the blocks made by the Builders. In fact, from the Proposer’s point of view, they would want to minimize the amount to burn and maximize their income, so they would prefer to choose a block with a larger tip for themselves rather than a block with a large payload base fee. Therefore, it would be better to choose block A, which has the largest tip made by Builder A, but the fact that the attesters set the payload base fee floor in step 2 should also be considered. If the attesters set 0.71 ETH as the payload base fee floor, there is a risk of not receiving attestation from the attesters when they choose block A, so they have to choose a block between C and D, and they will choose D’s block with a higher tip. Here, since the payload base fee floor value is not a shared value, the Proposer does not exactly know how much the attesters have set this value.
Attesters validate the bid selected by the Proposer and make an attestation. A base fee greater than the payload base fee floor will be recognized as valid.
The Builder that created the selected block in step 3 releases the payload, which contains the actual transactions in the selected block. The reason for not disclosing the payload from the beginning is to prevent other nodes, including the Proposer, from copying the payload and stealing the MEV. In step 3, the fact that the Proposer only sees and selects the bid can be understood as a commitment to not steal the block contents.
Attesters create and propagate attestation for the payload that the Builder has disclosed. Even if the contents of the payload are not valid, the base fee suggested by the Builder is burned, which is to prevent the Builder from making a fake bid. This completes one block, and the bidding for the next block by the Builders would be underway again.
Perhaps the easiest change to anticipate with the introduction of MEV burn is the change in Ethereum supply. First of all, when looking at the network as a whole, an increase in the amount of Ethereum burned will lead to a decrease in supply. Trends to date (June 2023) show that deflation has been underway since The Merge due to high demand on the network, and burning up to MEV will likely accelerate this deflation.
However, from the Validator’s perspective, some (perhaps most) of the MEV rewards that would have come to them will be distributed across the network, which risks reducing their incentive to operate nodes.
MEV burn can play a role in reducing the income disparity among Validators. Currently, the three main incomes for Validators are attestation rewards, proposer rewards, and MEV rewards. If a certain percentage of the MEV income that was previously earned is burned, the proportion of income earned from the consensus layer among Validators’ income will increase. The attestation rewards and proposer rewards coming from the consensus layer, which do not vary much among Validators, are expected to make the total income similar to each other.
It might be a bit of a stretch, but let’s assume that from the perspective of a pool operating many Validator nodes, they could invalidate a particular block made by an individual Validator. The large pool could interfere with the p2p propagation of the block made by the individual Validator, or attempt a reorg attack known from several papers (Three attacks on proof-of-stake ethereum, Two More Attacks on Proof-of-Stake GHOST/Ethereum). Because the cost of protocol penalties and social risks can follow in case of attack failure, such intentional attacks have not been observed in Ethereum since The Merge. So, this assumption may feel theoretical and unrealistic. However, if the MEV extracted from the block is, for example, over 1,000 ETH and is huge, there may be an incentive to take on the risk and attack to intercept the MEV.
If a considerable proportion of MEV extracted from a block is burned through MEV burn, the MEV income earned by the Proposer will decrease significantly, and the incentive to attempt an attack to intercept the block will decrease as well.
Interestingly, MEV burn could enhance censorship resistance, which seems largely irrelevant. Looking back at the operation process introduced earlier, the Proposer and Attester verify the payload base fee and tip suggested by the Builder, and the Attesters consider the highest value among the payload base fees as the payload base fee floor. And they judge that the block made by the Proposer is invalid if it does not burn as much as the payload base fee floor.
In MEV-Boost, there was an issue mentioned about censorship resistance when some Proposers only received blocks from OFAC-compliant Builders. In MEV burn, if the Proposer does not receive blocks from some Builders, it would be hard to guess what the payload base fee floor is, and it means that the likelihood of their block being acknowledged would increase. Therefore, as the Proposer must listen to all Builders’ bids, MEV burn naturally enforces censorship resistance.
MEV burn is one of Ethereum’s long-term plans and a mechanism that distributes MEV to the entire network by burning it. In my personal opinion, there seems to be insufficient game-theoretic basis for the Builder’s incentive to bid quickly, and more discussion is needed for various attack situations.
Since MEV burn is likely to be the next step after PBS was introduced, it seems to take quite a long time. Both PBS and MEV burn are major upgrades that have to completely change the consensus layer, so they should naturally be designed cautiously and conservatively, and there should be sufficient social consensus within the community to minimize the risk of division.”
Thanks to Kate for designing the graphics for this article.
Sui
Story
Injective
