After the Ethereum merge, the changes and constants of MEV

Author: Jiawei, IOSG Ventures

Introduction

According to the definition provided by the Ethereum community: MEV refers to the maximum value extracted from block production that exceeds the standard block reward and Gas fees through the inclusion/exclusion/ordering of transactions within blocks.

On-chain financial activities are becoming increasingly complex, and MEV is continuously accumulating. According to incomplete statistics, MEV is currently approaching 700 million USD. This is only in the context of Ethereum Layer 1 during the PoW period; if we consider the period after The Merge, as well as various Layer 2 and Alt-L1, it is conservatively estimated that the total amount of MEV will exceed 1 billion USD.

In the lifecycle of Ethereum transactions, we can abstract the MEV supply chain. This article mainly discusses the roles of Builders and Validators (Proposers).

Proposer-Builder Separation (PBS)

In the current design of Ethereum's protocol layer, block Builders and block Proposers are the same entity—under PoS, they are primarily a subset of Validators. This entity is pseudo-randomly selected from a broad Validator Set to construct blocks and propose them to the PoS network.

The above diagram basically illustrates the process of block construction. Builders obtain transactions from three main sources: public transaction pools (mempool), private transaction channels (such as Flashbots Protect), and bundles submitted by MEV searchers. Builders construct these transactions into a block and submit it along with bids to the Relay.

As the trend of increasing MEV continues, the design of having Builders and Proposers as the same entity is gradually showing its drawbacks: compared to ordinary Validators, large Validator Pools have more opportunities to realize MEV; moreover, they clearly have stronger MEV capture capabilities than ordinary Validators, leading to serious centralization issues. Thus, PBS (Proposer-Builder Separation) proposes to separate Builders and Proposers.

After the separation, whether ordinary Validators or large Validator Pools, they outsource block construction to specialized Builders to maximize profits, while they only need to focus on the "proposal" aspect.

Currently, PBS is divided into protocol layer and non-protocol layer implementations. The difference between the two is that the former is embedded within Ethereum itself and is technically mandatory, while the latter refers to PBS as an optional, non-mandatory feature.

• Protocol Layer PBS (Danksharding): Protocol layer PBS (In-protocol PBS or Enshrined PBS) will be introduced in the implementation of Ethereum Danksharding, making PBS a design at the protocol layer. At that time, Builders will need to compute KZG polynomial commitments for 32MB of data within about 1 second, in addition to constructing blocks, and distribute them in the P2P network.

• Non-Protocol Layer PBS (MEV-Boost): Flashbots has proposed an open-source software called MEV-Boost as a non-protocol layer implementation of PBS. This is an open market where Builders focus on constructing blocks to maximize the benefits of each block. After participating in the auction, the most profitable block is submitted to the Proposer. The latter only needs to simply propose this block, effectively selling its block space. In return, the Proposer of that block can receive fees paid by the block Builder. It is estimated that running MEV-Boost will increase Validators' staking income by over 60%.

The above is a rough workflow of MEV-Boost.

First, Validators need to run three software components: the Validator client, consensus client, and execution client, in addition to running MEV-Boost.

Builders obtain transactions and bundles from the transaction order flow and construct blocks according to their respective strategies.

Relay serves as a bidirectional communication channel between Builders and Proposers, connecting to one or more Builders and verifying the validity and bids of the blocks submitted by Builders, submitting the highest valid bid to the Proposer.

Proposers can aggregate one or more Relays to select the most profitable block and make a proposal.

There are some interesting topics derived from the non-protocol layer PBS and block construction, which will be discussed one by one below.

Market Supply and Demand and Transformation

In terms of supply and demand, Proposers and Builders have actually achieved a certain degree of separation early on.

The complexity of on-chain activities has made MEV opportunities increasingly apparent. In PoW, miners with strong computing power held the block production rights, but their ability to search for MEV was generally limited, mostly just choosing transactions with higher Gas fees to generate blocks; on the other hand, searchers had a strong ability to capture MEV opportunities, but did not hold block production rights.

Initially, there was no definitive way for miners to include transactions submitted by these searchers; searchers could only try to raise the Gas fees paid to have their submitted transactions included. However, this was a public "auction," akin to a Gas War, where even if bidders ultimately failed, they still had to pay fees, leading to network congestion and increased Gas prices, resulting in serious negative externalities.

Thus, in response to the above supply and demand issues, Flashbots proposed Flashbots Auction, introducing an auction and communication channel between miners and searchers. Searchers send transactions to miners through Flashbots Auction and pay additional fees.

In summary, the supply and demand relationship has created an open market.

This was the scenario in PoW. However, when Ethereum transitioned to PoS, participating in the validation network only required staking 32 ETH and meeting simple hardware requirements, which meant a broader distribution of block production rights, significantly increasing the number of participants who could produce blocks. However, compared to miners, these Validators lack the ability to construct blocks.

The open market of supply and demand still exists, but some changes have occurred: previously, miners could choose to construct blocks themselves or outsource block construction—Flashbots Relay sends transactions or blocks to miners, who can choose to accept them; whereas now, for Validators, block construction incurs additional computational overhead, and most do not have sufficient capacity to capture MEV, so Validators need to request blocks from Flashbots Relay.

Regulation, Anti-Censorship, and Decentralization

Regulation and censorship are, to some extent, the same issue. Anti-censorship and decentralization are the narrative pillars of blockchain, and the relationship between the two is inseparable.

First, on the regulatory level, after the Merge, centralized exchanges, staking service providers, and actual operators occupy a significant proportion of Validators across the network. These entities operate within specific legal jurisdictions and thus need to weigh the compliance risks brought by their business. Ethereum faces invisible regulatory pressure.

From a data perspective, blocks compliant with OFAC regulations have accounted for as much as 67% daily; 74 out of every 100 blocks comply with OFAC regulations. This data remains high and is on an upward trend. If this value approaches 100%, transactions from addresses sanctioned by OFAC will be difficult to include in blocks.

Of course, so far, the addresses sanctioned by OFAC have all been hacker addresses, which seems to have some moral justification; however, whether this regulatory scope will expand is hard to predict. Faced with regulatory pressure, how should large Validator Pools choose between economic interests and the spirit of decentralization? Rather than attempting to answer this question, we may need to directly address the censorship issue from a technical perspective.

In addition to regulatory censorship, there is also the issue of Builder censorship in the current MEV-Boost. In the workflow described above, we see that Proposers can only passively accept complete blocks submitted by Builders and cannot include the transactions they want. They must either accept everything or not participate in MEV-Boost at all. In this case, Builders can effectively collude to intentionally exclude certain transactions and extort their transaction submitters.

In the protocol-level PBS of Danksharding, a crList (censorship-resistant list) is introduced to address the censorship issue, meaning Proposers have the right to specify a list of transactions that must be included by Builders; after winning the auction, Builders need to prove that all transactions in the crList have been included (or that the block is full), otherwise, the block will be deemed invalid.

In MEV-Boost++ proposed by EigenLayer, a Proposer Part is introduced, similar to the crList, allowing Proposers to participate in the construction of part of the block.

Further Decentralization

Through the non-protocol layer implementation of PBS, the issue of Validator centralization has been alleviated. In the previous discussion, we found that Builders currently also have centralization issues. In the past week, the top five Builders constructed 84.64% of the MEV-Boost blocks.

Flashbots has recently open-sourced its Builder API, hoping for multiple Builders to collaborate on block construction rather than having a single entity construct complete blocks.

Roughly speaking, because different Builders can cover different MEV searchers and private transaction channels, some Builders may have advantages in either the former or the latter. Currently, the blocks submitted by Builders are complete blocks, and if they want their constructed blocks to be selected, they must maximize the overall implementation benefits of block construction.

If multiple Builders collaborate, the Builder with an advantage can submit part of the block, while another Builder with a different advantage can submit other parts, making the overall Builder landscape more decentralized, and theoretically, Validators will ultimately benefit more. However, at the same time, this also clearly intensifies competition among Builders.

Flashbots proposes that all teams publicly develop their Builders, and the community should only trust those Builders whose actions align with transparency and free software standards. If each Builder adheres to this standard, it will make the roles of Builders and block construction more decentralized and transparent.

Thinking About Endgame from the Perspective of MEV

Vitalik describes the ultimate vision of Ethereum in his article "Endgame": block production is centralized, but block validation is trustless and highly decentralized, ensuring anti-censorship.

My personal speculation is that the logic of the first half of the sentence is based on the following three points:

• From the perspective of decentralization, Ethereum needs to make the hardware requirements or computational resources for becoming a Validator as low as possible. If Validators only need to simply propose a constructed block with the highest bid, without having to construct the block themselves, this can reduce some computational overhead.

• From the perspective of economic incentives, participants in this system are Economically Rational. If running MEV-Boost can increase staking returns by as much as 60%, then excluding regulatory and other objective factors, rational Validators will outsource block construction to Builders, leading to centralized block production.

• If Danksharding is confirmed for implementation in the future, the hardware and bandwidth requirements for Builders will significantly increase, inevitably leading to Builder centralization.

Although block production is centralized, Ethereum achieves further decentralization of the Validator Set by lowering the barriers to participating in network validation and implementing PBS, ensuring that block validation is trustless and highly decentralized based on a broad Validator Set and a pseudo-random voting process.

Of course, centralization and decentralization are a spectrum, not a matter of "yes" or "no."

Closing Thoughts

Block construction is a vast market, with MEV occurring at every moment, involving algorithmic competition and rivalries, with cash flow continuously flowing day and night. MEV is a rare pure on-chain native business model in the current crypto world, solid enough.

The current PBS is a non-protocol layer, and Validators can still choose to construct blocks themselves rather than outsourcing to specialized Builders. However, after Ethereum introduces Danksharding in the future, PBS will become a mandatory implementation in protocol design, and we will see the block construction market become even larger.

We focus on seeking "change" and pursuing "change" within the "unchanged" investment logic:

• Considering the future large-scale adoption and the increasing complexity of on-chain financial activities, we believe that MEV is the "unchanged" trend from a medium to long-term perspective.

• What has "changed" after the Merge? First, the supply and demand relationship between block proposals and block construction has changed. Second, the demand for anti-censorship and decentralization has begun to emerge. Finally, the trend of block construction becoming a specialized market is also slowly becoming apparent. These changes will guide us to the endgame of Ethereum.

There exists a two to three-year time window between non-protocol layer PBS (MEV-Boost) and protocol layer PBS (Danksharding). Furthermore, if we step outside the perspective of Ethereum Layer 1, there are also vast cross-domain MEV opportunities in the multi-chain ecosystem and multi-Rollup ecosystem.

IOSG will continue to conduct a series of directional and predictive research, uncovering hidden investment opportunities. Stay tuned!

References:

https://docs.flashbots.net/

https://boost.flashbots.net/

https://www.flashbots.net/mev-sbc-workshop

https://www.blocknative.com/blog/ethereum-block-building

https://www.blocknative.com/blog/web3-transaction-lifecycle