MEV in Ethereum after the merge

ETH-MEV Impact Post-Merge How Will Ethereum be Affected?

Author: Nic @ imToken Labs

Reading Tips

• Before reading this article, you need to have a basic understanding of MEV, know the role of Flashbot and the impact of Flashbot on MEV.

• You also need to know the basics of PoS mechanism and the changes brought about by the Ethereum merge (The Merge).

  • Exploring Layer 3 Blockchain and Its Significance for the Crypto Industry
  • Fraud Trial Against Sam Bankman-Fried Ends in Guilty Verdict
  • Bluzelle Empowers Content Creators in the Creator Economy with its Revolutionary Layer 1 Blockchain Expansion

MEV

First, let’s review what MEV is.

Miner Extractable Value, as the name implies, refers to the “value that block developers can extract”.

This value does not refer to the transaction fees that users pay to block developers to have their transactions included in the block. Giving a transaction fee is a voluntary action by the user, and the user can set the fee very low, which means it will take a long time for the transaction to be included. However, at least block developers cannot charge arbitrary fees for the transaction.

Reading Tip: MEV is now also referred to as Maximal Extractable Value, because MEV is no longer exclusive to block developers.

“The value that block developers can extract” refers to the benefits that block developers can obtain by changing the order of transactions or inserting their own transactions before (or after) the extracted transactions. So what kind of benefits can block developers extract?

For example, when there is a popular NFT that offers limited minting slots, and only the fastest 100 people can successfully mint, then Carol, who is a friend of the block developer or has reached some agreement with the block developer off-chain, can ensure that the block developer arranges the transaction order to place her mint transaction before others’ mint transactions.

△The block developer will put Carol’s mint transaction ahead of others’ mint transactions.

Another common MEV is sandwiching users’ AMM transactions, forcing users to receive the worst possible price within an acceptable range. The price difference between the expected price and the worst price is the profit extracted by the block developer.

In the example below, Alice expects to exchange 1 WBTC for 21500 USDT. But she knows that in the decentralized world, her transaction is not guaranteed to be executed first. When others perform WBTC/USDT transactions before her, the AMM price will change, and 1 WBTC may not be exchanged for 21500 USDT. So she sets the worst acceptable price at 20500 USDT:

△Alice expects to exchange 1 WBTC for 21500 USDT, but the worst acceptable price is 20500 USDT.

At this point, Eve discovers Alice’s transaction and decides to sell WBTC before Alice’s transaction, causing the WBTC price to drop to only 20500 USDT. Then Eve executes Alice’s transaction, and Alice is forced to transact at the price of 20500 USDT.

Finally, Eve takes the USDT obtained from selling WBTC and buys back WBTC. At this time, the WBTC price will be less than 20500 USDT, indicating that Eve has completed a buy low, sell high transaction (<20500 buy, 21500 sell) and made a profit from the price difference.

△ Blockchain developer Eve discovered a lucrative opportunity to sell WBTC before Alice’s transaction, and then buy back WBTC after Alice’s transaction is executed to profit from the price difference.

Decentralized systems will definitely have MEV

In centralized systems, you can choose to trust the roles responsible for sorting transactions (Operator, Sequencer) and believe that they will not do anything harmful to users for the sake of their reputation, or you can choose to leave that system. This is also the current situation for Layer 2 projects, as L2 project teams are unlikely to tarnish their reputation by extracting MEV.

However, in decentralized systems, anyone can become a blockchain developer, and we cannot easily and objectively prove that a blockchain developer’s behavior is “bad,” which means we cannot effectively prevent blockchain developers from extracting profits.

We should not expect blockchain developers to all be “good people”, but rather worry that if a blockchain developer earns more and more from MEV and uses it to invest in more blockchain development equipment to grow their scale, they may eliminate other competitors, resulting in a decentralized system with only one blockchain developer. Ultimately, this developer will be able to impose personal preference rules on users’ transactions. This is also the reason why Flashbot has emerged.

Flashbot

To mitigate the impact of MEV on the decentralization of blockchain developers, Flashbot turns MEV into a public market. Blockchain developers and professional MEV searchers cooperate and share MEV, while also competing against each other.

Through this competitive and cooperative relationship, blockchain developers and MEV searchers can focus on their respective specialties, and MEV searchers do not have to worry about blockchain developers taking away their arbitrage opportunities or intentionally not including their transactions.

△ Searchers find arbitrage opportunities from the public transaction pool, bid for income rights for their bundles, send them to Flashbot, and then the blockchain developers choose them.

Centralization risks

However, Flashbot still has its drawbacks. All MEV trading by searchers must go through Flashbot’s centralized server, which can seize arbitrage opportunities or censor arbitrage transactions.

In addition to Flashbot, projects like Eden Network have also emerged in the market. It has a similar architecture to Flashbot, with the addition of unnecessary staking, prioritized transaction order within a block, and additional bidding mechanisms. However, at least when Flashbot starts to behave badly, blockchain developers and searchers have other options.

MEV is an accepted fact

Both protocol designers and users must remain vigilant against MEV. If possible, incorporate MEV into protocol design and consider making MEV a beneficial tool in the design of mechanisms. The following articles will also discuss ways to effectively utilize MEV.

The Merge

Ethereum switches from PoW mechanism to PoS mechanism after The Merge. Instead of competing with mining machine computing power, block developers now stake ETH to become Validators and have the opportunity to propose blocks. This means that the threshold for block proposers to produce blocks is significantly lowered in PoS. However, the lower threshold for block proposers also affects the competitive and cooperative relationship among different roles in Flashbot.

Reading Tip: Here, “propose” is maintained in English to avoid confusion between “propose block” and “build block” due to their similar meanings in Chinese.

Change in Trust Relationship

Prior to PoS, a Searcher had to trust that a block developer would not snatch their bundle contents. Even if a block developer does snatch it, the Searcher can only resort to off-chain mechanisms to counter, such as providing evidence to ask Flashbot to blacklist the block developer or posting on Twitter to sever ties.

However, block developers generally cooperate because they have a long-term working relationship with Searchers. It wouldn’t be worth it for a block developer to snatch from a Searcher today for the sake of some MEV profit, as it would mean losing all future MEV opportunities.

But after PoS, the opportunity to produce blocks is obtained by staking ETH, and the threshold for block production is lowered. Consequently, many ordinary individuals join as Validators, causing the opportunity to produce blocks to gradually dilute.

Compared to PoW, where significant costs are required to establish and operate a few mining pools long term, in PoS, Validators occasionally have the chance to produce blocks. Even when considering the block rewards and MEV annualized at an average of 10%, Validators still have sufficient incentive to snatch MEV from Searchers.

Reading Tip: You can refer to Flashbot’s MEV leaderboard. Copy the link below and paste it into your browser to access the relevant content: https://explore.flashbots.net/leaderboard

△ If you seize the opportunity to snatch more than 3.2 ETH of MEV, it exceeds 10% annualized return.

Therefore, the architecture of Flashbot needs to be adjusted to accommodate this change in the trust relationship and the PoS mechanism, resulting in the current mev-boost.

mev-boost

In mev-boost, the original Relay role of Flashbot, mediating between Searchers and block developers, is divided into two roles: Builder and Relay (with different responsibilities).

Searchers hand over bundles to the Builder, who selects several bundles from multiple bundles to form a block and passes it to the Relay. The Validator then selects one block from multiple blocks submitted by the Relay.

△ Searchers compete with Searchers, Builders compete with Builders, and Validators pick the most favorable block from them.

The Builder’s responsibility is to find the most favorable bundle combination within the limited capacity of a block, hoping that the Validator will select their block.

What is the purpose of the Relay? As mentioned above, the trust relationship has changed, so the Searcher/Builder cannot trust the Validator. Therefore, in the mev-boost, the Validator needs to make a commitment to “I will propose your block” in order to receive the actual block content.

The Relay acts as an intermediary between the Builder and Validator to help coordinate: The Relay keeps the block content until it receives the commitment from the Validator, and then hands over the block created by the Builder to the Validator.

In the actual Ethereum Beacon Chain terminology, the block content created by the Builder is called the Execution Payload, and the Validator receives data called the Execution Payload Header from the Relay. The Header can be considered as the commitment of the Payload, and signing the Header represents signing the Payload.

When the Validator decides which block to propose from the Relay, they will include the Execution Payload Header of that block in the Beacon block and sign it. Then they provide the signed content to the Relay as proof, and finally the Relay can safely provide the block content to the Validator for them to propose the block.

△ Builder hands the block to the Relay, and the Relay gives the Header to the Validator

△ If the Validator selects the block, they will include the Header in the Beacon Block and sign it, then submit it to the Relay.

△ The Relay then provides the complete block content to the Validator.

If the Validator betrays the Relay in the end and chooses to propose a different block, the Relay can disclose the signed content provided by the Validator as evidence that the Validator proposed two different blocks. As a result, the Validator will be punished for violating the rules of the Ethereum Beacon Chain.

△ Eve proposes a different block and gets slashed (part of their staked ETH confiscated).

Trust Assumption

In mev-boost, the Validator actually needs to trust the Relay. If the block content revealed by the Relay is illegal, or if the money received by the Validator does not meet expectations, or even if the Relay refuses to disclose the block content, preventing the Validator from proposing a block, the Validator can only counteract through off-chain mechanisms, such as informing other Validators of the malicious behavior of the Relay.

Circuit Breaker

Validators cannot monitor and intervene 24 hours a day, so when the Validator software detects that one or more Relays are continuously breaking trust, they must be able to react and avoid losing profits due to a lack of block proposals.

For example, if a Validator notices that they haven’t proposed a block for more than five consecutive Slots, they should switch back to using their own node to create block contents.

Related documents can be referred to:

• https://hackmd.io/@ralexstokes/BJn9N6Thc

Relay Monitor

In order to reduce the impact of malicious behavior by the Relay role, the Flashbot community is also considering the design of monitoring for Relay behavior.

Related documents can be found at:

• https://hackmd.io/@ralexstokes/SynPJN_pq?

• https://github.com/flashbots/mev-boost/issues/142

Data Availability Committee

One way to prevent Relay from withholding block content is to hand over block data to a Committee composed of a group of nodes. They are responsible for safeguarding and ensuring the availability of block content, thereby decentralizing the responsibility for block content preservation.

What are the current Builders and Relays?

Here are the current Builders and Relays:

• MEV-Boost

  You can find more information at: https://mevboost.pics

Although Flashbot is the main development team behind mev-boost, they do not have dominant control over the Relay position. This is because Flashbot has been open-source from the beginning of mev-boost development and has not set itself as the default Relay in the mev-boost software.

Reading tip: For more information, please refer to https://twitter.com/bertcmiller/status/1577482319140913153

April 2, 2023, Attack on mev-boost Relay

A malicious validator discovered a vulnerability in Relay: Relay will send back the Bundle content to any validator that has a valid signature (regardless of whether the content is valid or not).

Therefore, the malicious validator signs an invalid content (with some fields in the Header having invalid values), and after Relay sends back the Bundle content, the validator steals the arbitrage transactions in the Bundle and then proposes another valid block.

Relay attempts to broadcast the Header signed by the validator, but it is rejected by other nodes due to its invalid content. Therefore, everyone only sees the valid block proposed by the validator. Afterwards, the validator is slashed and kicked out of the validator list because they signed two different Headers (one for Relay and one for self-proposed), but the damage has already been done.

The updated Relay now attempts to broadcast the Header signed by the validator. If other nodes successfully include it, it means that the content signed by the validator is valid, and other nodes will see the block broadcasted by Relay first. If the validator tries to steal the Bundle content and self-propose, it will be more difficult to outperform the block broadcasted by Relay (because many nodes have already seen it).

Reading tip 1: To explain this attack, thread, related evidence, and Relay patches, please refer to this thread: https://twitter.com/samczsun/status/1642848556590723075

Reading tip 2: Besides stealing arbitrage transactions from the Bundle, malicious validators can also attack arbitrageurs performing sandwich attacks. Sandwich attackers insert their own transactions before and after the victim’s transaction – buying in advance of the victim and selling after the victim buys – to profit from the price difference. However, for the sandwich attack to succeed, both transactions before and after must be executed; otherwise, if only the first transaction is executed, the arbitrageur will not only fail to make a profit but also risk losing their own funds.

But the patch made for this attack will increase the delay in block production, so after the attack, the re-org frequency of the PoS chain has significantly increased in the following days. Currently, several solutions are being designed and implemented to avoid the instability of the PoS network caused by the block delay from MEV-Boost.

Reading tip: For a detailed introduction, copy the link below and paste it into your browser to read more: https://www.paradigm.xyz/2023/04/mev-boost-ethereum-consensus

The Impact of Flashbot/MEV-Boost

Impact on Validator Voting Efficiency

Due to Flashbot/MEV-Boost, there are more hurdles in the process from block production to the actual proposal. This results in a delay in the time for Validators to propose blocks, causing other Validators responsible for voting to receive the blocks later. Consequently, their voting time is compressed, which affects the overall security of the PoS network.

Although it may not seem significant: the estimated decrease in voting rate is about 2%, and the number of Validators voting correctly decreases by approximately 1%. However, this data was recorded in October 2022 when only 1/3 of the Validators connected to MEV Relay.

Reading tip: For related information, refer to the article in the link below: https://www.attestant.io/posts/exploring-the-impact-of-mev-relays

Summary and Key Points

• MEV generation is inevitable, and block developers have the greatest advantage in mining MEV. Flashbot turns MEV mining into a public market, avoiding the centralization of miners that could impact the entire chain’s security.

• mev-boost was created in response to the changes brought by PoS and reverses the trust relationship between Searcher/Builder and Validator. It also promotes more open competition: multiple Builders compete with each other, multiple Relays compete with each other, further reducing the centralization risks of Flashbot.

The next article will introduce the Proposer-Builder SeLianGuairation (PBS), which directly integrates the mev-boost architecture into Ethereum’s protocol itself, rather than being a private collaboration between Validators, Builders, and Searchers. This will make the entire MEV ecosystem more decentralized and secure.

Reference data and recommended further reading

• https://docs.flashbots.net/

• Flashbots

• https://ethresear.ch/t/mev-boost-merge-ready-flashbots-architecture/11177

• https://writings.flashbots.net/searching-post-merge/

• https://writings.flashbots.net/why-run-mevboost

• https://writings.flashbots.net/beginners-guide-mevboost

• Data statistics: https://www.mevboost.org

• Data statistics: https://dune.com/ChainsightAnalytics/mev-after-ethereum-merge

We will continue to update Blocking; if you have any questions or suggestions, please contact us!