What centralization issues does MEV bring to Ethereum? How to improve it?

Improvements include proposer-builder separation and partial block auctions.

By Simon Brown

Compiled by: 0x11, Foresight News

How did MEV become a centralizing force in PoS Ethereum? This article is the second part of an exploration of this question. The first part was written before the merger and aimed to speculate how Ethereum became more centralized due to the impact of MEV. The second part was written after the merger and looks at what actually happened in the months after the merger, the state of the ecosystem today, and the future direction of development.

The citations in this article are all public information collected by a group of smart, hardworking and honest people. If you are interested in this topic, please check out the various data sources I cited.

Validator Centralization

Recall that the original rationale behind MEV-Boost was to try to mitigate the scale effects of large staking pools on MEV extraction, which would inevitably lead to centralization. MEV-Boost is designed to allow any validator to earn as much MEV as possible from the blocks they propose, meaning that independent stakers have the same chance of earning MEV as large staking pools, thereby maintaining a level playing field.

Although MEV-Boost has provided some relief, there is still a clear centralization problem among validators. The following is a snapshot of the validator set taken from Etherscan on November 25:

Beacon chain deposit details, source: Etherscan

Lido accounts for 29.8% of the staking share, which is close to the consensus threshold, which is worrying.

There are misconceptions though, as Lido itself is a DAO, which means it is decentralized by definition. Lido has transparent policies around the distribution of its node operators, which you can read more about in their post on decentralization.

If we split Lido into its node operators, rather than just treating it as a single entity, the composition of the validator set looks different:

Depositors by entity (including Lido split nodes), Source: Etherscan

The situation is still not optimistic, especially considering that Coinbase and Kraken (two US registered companies) have a total of more than 21% of the staked shares. In addition, Danny Ryan believes that any liquidity staking derivative protocol is risky, even if the protocol itself is decentralized, there is a risk of obtaining a validator share that exceeds the consensus threshold. You can read more about this in his article The Risks of LSD — HackMD.

How much of this centralization is driven by MEV though? Given that MEV-Boost provides all validators with fair access to all MEV, this centralization must be due to other factors. Remember, the more validators you have, the more often you will have validators selected as proposers. The probability of being selected as a proposer at least once a week is currently 10%:

slots_per_week = seconds_per_week / seconds_per_slot = (60*60*24*7) / 12

(1 / number_validators) * slots_per_week = (1 / 479652) * 50400 = 0.1

For a staking pool with 30% of validators, this probability increases to 315%, which means you get at least three proposed blocks per week and are three times more likely to get an intermittent high-value MEV block. You can see Flashbots' analysis of this phenomenon here.

Given that validators do not start accessing MEV until they are able to earn Exec Tier rewards (i.e., after the merge), we hypothesized that if MEV was the driving force behind validator centralization, then we would see an increase in centralization after the merge. Looking at the actual data, this does not appear to be the case. While the amount of staked ETH has generally been increasing over time, the relative shares between major players have not changed much since the merge.

Changes to Beacon Chain Deposits

This suggests that MEV-Boost is working and distributing MEV evenly across all validators in the set. Of course, we could argue that the lack of change in validator share since the merge could be due to low adoption of MEV-Boost or a truly low amount of MEV paid to validators. A closer look at these two metrics shows that neither of these is the case.

First, MEV-Boost adoption has clearly grown over time, with approximately 90% of the validator set having installed MEV-Boost and having registered one or more relays, suggesting that the share of staking pools has remained almost unchanged after the merger and is not due to low MEV-Boost adoption.

MEV-Boost adoption rate changes, source: https://dune.com/queries/1279670/2192739

Second, we can look at how validator execution layer rewards have changed over time. The following chart shows the total execution layer rewards paid to validators, including MEV. This data is taken from Chainsight Analytics’ MEV-Boost Dashboard.

Rewards paid to validators, source: https://dune.com/queries/1279670/2192739

Of course, the execution layer reward includes the priority fees of all transactions in the block and any MEV captured on top of that. In order to determine whether the lack of change in validator concentration after the merger is due to the lower amount of MEV, we need to separate MEV from the priority fees. Fortunately, our good friends at Flashbots have already done that. Their data analysis shows that MEV accounts for 73% of all rewards paid to validators.

Putting all of these metrics together paints a picture of MEV being fairly evenly distributed across the validator set, which mitigates centralization.

How will withdrawals affect the allocation of stakes?

This is an interesting question. Will we see stakers moving from one staking provider to another? Currently, all stakers are locked in. Once withdrawals are enabled, competition between staking pools will increase. At this point, we may see a spontaneous redistribution of staked shares.

If and how this will happen is a matter of speculation, but we may well see many people moving funds based solely on the APR, or we may see more market share attracted to liquid collateralized derivatives protocols. When withdrawals are enabled on Ethereum, we may see distributed validator technology up and running, see Obol or the SSV network.

Relay Centralization

As of November 23, 2022, Flashbots' relays processed approximately 80% of MEV-Boost blocks, while BloXroute's relays processed approximately 14% of blocks.

Distribution of blocks processed by relayers, source: https://www.mevboost.org

This clearly demonstrates a high level of centralization in a very critical component of Ethereum infrastructure. This is less than ideal, and the potential problems with this level of centralization came into focus in August when the US Treasury (specifically OFAC) imposed sanctions on Tornado Cash. They added a large number of smart contract addresses associated with Tornado Cash to their SDN list. This had a chilling effect and caused many organizations to remove their dapp’s UI, GitHub repositories, and of course RPC endpoint providers to censor any transactions sent to Tornado Cash.

It’s unclear whether OFAC actually realized that they couldn’t actually block access to Tornado Cash (spoiler alert: it’s still actively used), but putting these contract addresses on the SDN list had the intended chilling effect. Many MEV-Boost relays began censoring Tornado transactions (rather than risk going to jail or paying a huge fine), and one of those relays was a Flashbots relay. This means that at the time of writing, 75% of all blocks on Ethereum are being censored.

It is important to note that this censorship does not prevent access to Tornado Cash (or any other contract that happens to be censored), it simply delays routing to Tornado Cash by a few blocks. Justin Drake calls this "weak censorship", as opposed to "strong censorship" which completely blocks access. However, using Tornado Cash is not really a problem at the moment, the problem is that if Ethereum were to execute the edicts of an authoritarian government, it could not claim to be a reliably neutral platform. This makes the centralization of the MEV-Boost relay a problem.

So what leads to the centralization of MEV-Boost relays?

Recall that in Part 1 I described the phenomenon of mev-hiding and how it might lead to trust relationships between staking pools and relays? Staking pools typically prefer their node operators to connect to specific relays so that they can track the amount of MEV paid to their validators. This is to identify any potential payments to node operators that were not passed on to validators. This is of course a contributing factor to relay centralization, as it is easier for builders to use established and trusted relays once they have produced valuable blocks.

Centralization of Block Builders

Surprisingly, the distribution of blocks proposed to the network by third-party block builders is actually quite even. I had predicted that network effects would only drive the emergence of a few dominant block builders, and in fact, I didn’t even completely rule out the possibility of a single block builder emerging.

Instead, what we are seeing is the emergence of a large number of block builders. There is still some centralization, as 50% of MEV-Boost blocks were created by 2 builders: Flashbots and 0x69. There are about 8 or 9 active block builders, and dozens of smaller long-tail builders, all of which have less than 2% of the market share.

Block builder distribution as of November 21-28. Source: https://www.relayscan.io/

This can still be improved, but it’s not much worse than the centralization of PoW, where there are two major mining pool operators producing the majority of blocks.

Interestingly, there was an initial period after the merger where a single dominant block builder emerged, as I and others had predicted, but this changed over time. The following graph shows the distribution of the share of blocks proposed by different builders over time.

Distribution of block shares proposed to the network, source: https://dune.com/queries/1306635/2237247

As you can see, at one point Flashbots were building over 60% of all MEV-Boost blocks. If you combine these numbers with the total adoption of MEV-Boost by validators, you can see that at one point Flashbots were producing around 30% of all blocks on Ethereum. This was somewhat expected, but also worrisome because at that point it looked like this trend would continue.

The following graph shows the percentage share of MEV-Boost blocks proposed to the network that were built by Flashbots, represented by the blue line. The red line represents the overall adoption of MEV-Boost by the validator set, and the yellow line represents the percentage of blocks built by Flashbots that have adopted MEV-Boost overall.

Flashbots’ share of MEV-Boost blocks compared to overall MEV-Boost adoption.

Source: https://dune.com/queries/1306635/2237247

Hopefully, the trend of builders accelerating into the space and winning more proposed block shares continues over time. To their credit, Flashbots decided to encourage this by open sourcing their block builder, which should make it easier for block builders to compete.

Changes in the number of block builders, source: mevboost.org

What is the future of Ethereum?

It is clear that MEV-Boost is more than just a piece of software, it is a critical part of Ethereum infrastructure. What Flashbots has created fundamentally changes the design philosophy of the network. Looking ahead, Flashbots hopes that the management and governance of MEV-Boost will be in the hands of the community.

In early October, Flashbots called for more community involvement and the response was overwhelming. Many organizations have stepped forward to contribute to the ongoing management and development of MEV-Boost.

Future decisions will be made around how to implement partial block auctions, transaction inclusion lists, new transaction types, etc. Hopefully we’ll see more people participating and contributing to this process.

There are many innovations in this space that aim to mitigate the risk of MEV as a centralizing force on Ethereum, and many of them are expected to be quite successful. In fact, MEV mitigation has its own swim lane in the Ethereum roadmap, labeled “Acts of God.” At the center of this swim lane on the roadmap is “In-Protocol PBS.”

Ethereum roadmap, source: https://twitter.com/vitalikbuterin/status/1588669782471368704

In-protocol PBS (proposer-builder separation)

PBS is a design concept. There are many ways to implement PBS and many reasons to study it.

PBS was originally proposed as a way to mitigate the centralization effects of MEV. The idea is that if we outsource MEV extraction to experienced experts and give every validator equal access to the outsourced service, this will prevent staking pools from benefiting from economies of scale to gain a larger and larger share of the validator set.

PBS also has an impact on scalability - namely danksharding. Making a danksharding large block is not something that all validators can do. Without PBS, the number of validators on the network could be significantly reduced, so PBS is seen as key to enabling danksharding.

MEV-Boost can be thought of as a “proto-PBS,” or a PBS that exists outside of the protocol. In a way, it can be seen as a great test of the idea. However, the problem with this approach is that it puts MEV-Boost relayers in a trusted position, trusted by both block builders and proposers. Without some kind of protected PBS, there is no trustless way for proposers to be confident that builders’ blocks will be released and they will receive payment, and there is no trustless way for builders to be confident that the MEV in their blocks has not been stolen.

It seems likely, therefore, that PBS will be included in the agreement in some way, but as of now, it is unclear how this will happen, as there are many proposals to do so.

For more information on current thinking on how PBS is implemented in protocols, see the ideas described in these threads:

• Proposer/Builder Separation Fee Market Design

• Dual-slot proposer/builder separation

• Single-slot PBS using provers as distributed availability oracles

Other directions: auction of some blocks

As we have seen, outsourcing the entire content construction of a block to a third-party block builder can lead to inconsistent preferences for block content, for example, where the builder seeks to avoid any potential issues with the US government censoring certain transactions.

The solution seems to be to outsource the construction of only some of the block contents, an idea often referred to as partial block auctions.

There are many ways to solve this problem, but they all seem to revolve around the idea that the proposer creates the block prefix or suffix containing the transactions, and the rest of the transactions in the block come from the block builders. Currently, we have not seen any proposals that allow multiple block builders to contribute transactions to a single block.

An approach that seems to be gaining popularity was proposed by Eigenlayer, who use a rehypothesis mechanism.

Auction of partial blocks through re-mortgage

The idea of ​​re-bonding is pretty simple. When a validator registers with the protocol, they deposit 32 ETH into the deposit contract and provide their withdrawal voucher, specifying an address to withdraw funds from in case the validator wants to unbond.

Re-staking builds on the idea of ​​providing a smart contract address as a withdrawal address. Once a validator unstakes, they withdraw their balance into this re-staking smart contract, which must then be exited to receive their stake and validator rewards.

This allows smart contracts to impose additional penalties on validators, so in order to receive their stake and full validator rewards, they will need to fulfill the commitments they made as validators. In fact, Eigenlayer allows for the enactment of various re-staking contracts and calls them "middleware". In this way, Eigenlayer can be thought of as a "programmable slashing protocol".

An example of a commitment that a validator can sign is a partial block auction, where a validator can create part of a block themselves and allow another part to be created by a block builder. A validator can allow a block builder to create an arbitrarily sized part of a block and propose the rest themselves.

In this setup, the MEV-Boost relay stores the builder's portion of the transaction and forwards the Merkle root of the transaction to the validators. The described setup still relies on a central trusted relay, but the validators maintain a backup block that they can propose if anything goes wrong. Furthermore, Eigenlayer can eliminate trusted relayers entirely using another middleware that is designed as a data availability layer.

Using this data availability middleware, builders send their parts of the block to a “data availability arbitrator”. They do this by secretly sharing their block with the nodes in the DA arbitrator so that no single node has access to any information about the block. The arbitrator nodes sign the secret block they receive and return it to the builder, who then creates a “certificate” in the form of an aggregate signature and includes it in their bid to the proposer. The proposer selects the highest bid among all bids with valid certificates and signs the block header included in that bid. The proposer then sends this signed block header to the DA arbitrator, who publishes the respective secret block to the proposer, who can now reassemble the builder’s part of the block.

This approach is interesting for two reasons: it means proposers can construct parts of the blocks themselves, which will help alleviate censorship issues currently affecting Ethereum, and it will also help decentralize the MEV-Boost infrastructure and remove reliance on centralized relayers.

Auction of some blocks through PEPC

Note that there is also an exploration by Barnabé Monnot that embodies a form of re-staking at the protocol level. This would allow validators to make any type of general commitment with any third party and have this commitment enforced at the protocol level by the attestation committee, without the need for the Eigenlayers re-staking contract/middleware. This idea is called Protocol Enforced Proposer Commitment, or "PEPC". The main rationale behind this approach is that, as Barnabé said, it could ultimately destabilize consensus when the protocol no longer knows how many validators are effectively at risk (although I believe Eigenlayer has another idea to mitigate this, including programmatically triggering validator exits).

PEPC facilitates partial block auctions in much the same way as re-staking, except that it allows the protocol to track which validators are slashed and to what extent. This assumes, of course, that the proposer commitments enforced by the protocol are more attractive to validators and third parties than re-staking smart contracts.

Protocol-level partial block auction

This form of partial block auctions was proposed as an alternative to crLists (censorship-resistant lists) in PBS, which I will dive deeper into later. In this scheme, partial block auctions would be facilitated by the protocol itself. With this idea, proposers could provide a prefix or suffix, basically meaning that the builder would provide a portion of the block and the proposer would provide the rest. Vitalik talked about the trade-offs between the two approaches, such as the additional burden it puts on proposers, which could hinder progress towards eventual statelessness.

Transaction contains list /crLists/ mixed PBS

Transaction inclusion lists, crLists, are a way to mitigate censorship of transactions by block builders without requiring the proposer to actually provide any part of the block themselves.

At a high level, the idea is to allow proposers to create a list of valid transactions they have observed in the public mempool (i.e. valid nonce, signature, balance, maxFeePerGas, etc.) that should be included in a block based on Gas Price.

This is not as simple as it seems, and there are various different variations of the approach. All variations of the crLists approach seem to converge on the central principle that the protocol will force builders to produce either a complete block, or a block that accepts the proposer’s inclusion list.

The rationale for this is that if a builder creates a block that does not use all available block space despite there being transactions in the mempool that could be included, then can we assume that a rational builder is censoring transactions for some reason, as not including all available transactions is just leaving money on the table, which is irrational. If the block builder is generating blocks that do not use all available space, then there is no reason for the blocks they are generating not to include transactions in crList.

Under this scheme, builders who want to avoid censorship by including transactions from crLists need to fill a block up to the gas limit in order for their block to be accepted by the proposer and the network. In order to do this, they need to fill the block with random transactions themselves. This may be economically feasible for a block or two, but remember: under EIP-1559, once the block limit is reached, the base fee will increase, which means builders will need to pay more Gas for transactions to avoid having to include crLists. Over time, the increase in base fees will mean that most normal transactions will not be included in blocks, which in turn forces builders to "fill" a larger amount of space.

A more likely scenario is that block builders will abstain from producing blocks until crLists contain no sanctioned transactions, which should rebalance the block builder landscape in favor of non-censorship builders.

This approach all seems to rely on altruism. The various designs of crLists ensure that it is cheap for proposers to create crLists, so in theory it costs them nothing, but there is no clear incentive for them to create crLists.

If the proposer of the current slot is responsible for making the crList for that slot, then there is an incentive to create an empty list, as this will ensure that block builders will continue to build the most profitable blocks. This is especially true when the major block builders (who usually build the highest value blocks) are censoring.

Therefore, imagine creating crLists for future slots. For example, the proposer of the current slot 2n creates a crList for 2n+2. This is called a "forward inclusive list". This way, the proposer of the current slot does not risk incurring a financial disadvantage by creating a crList. This also has the nice property of being compatible with single secret leader election or SSLE, as proposers cannot cheat themselves by publishing a crList ahead of their position.

This document outlines a non-exhaustive list of variations of the crLists scheme design.

Open Questions

All of the ideas listed above are actively discussed, and I find some of them very promising. However, I have some questions: Why don't validators outsource 100% of blocks to builders? Are we just relying on altruism? What is the incentive for proposers to do any work in order to provide partial blocks? Why do validators go through the effort of creating crLists? If it's because Ethereum clients do it by default, can validators choose to disable it? I can imagine that node operators of certain staking pools will be reluctant to publish crLists or block prefixes/suffixes containing sanctioned transactions.

What about misaligned incentives? If a proposer contributes part of a block, does that take away valuable block space that builders can use to derive MEV? Even if there aren’t enough transactions to fill a block, proposers need to be careful to choose transactions that won’t conflict with builders’ bundles.

In terms of crLists, what happens if the proposer does not publish the crList on the P2P network? Can this be enforced by consensus? This has strong synchrony assumptions and adds complexity, which is already mentioned in some of the original material I linked to.

Additionally, how do crLists work with partial block auctions (i.e. block prefix/suffix)? For example, if many validators sign up for partial block auctions via re-staking, what happens when crLists is implemented?

in conclusion

The above are just a few of the questions that came to my mind while writing this article, and there are more challenging questions that have been asked by smarter people than me. So, as you can see, there are still many unanswered questions and potential concerns that need to be addressed before any specific direction or approach can be determined. In this regard, it may take several years before we see effective solutions emerge, and the entire MEV landscape may be very different by then.

The main conclusion I came to from researching this article is that I am more bullish on Ethereum since the merger because of the amount of innovative ideas that have emerged to solve the newly created centralization problems. Moreover, some of these ideas are clearly working. We are already seeing trends towards the gradual decentralization of various key parts of the ecosystem, and these trends look set to continue, which will put Ethereum in a stronger and more robust position in the future, giving confidence and encouragement to those who are building tools to improve people’s lives.