This article explores what centralization problems MEV brings to Ethereum? How to improve?
Author: Simon Brown
Original compilation: 0x11, ForesightNews
How MEV became the centralizing force of PoS Ethereum? This article is the second part of an exploration of this issue. The first part was written before the merger to speculate on how Ethereum could become more centralized due to the impact of MEV. The second, written after the merger, looks at what actually happened in the months after the merger, the state of the ecosystem today, and where it's going in the future.
Centralization of validators
Centralization of validators
Recall that the original rationale behind MEV-Boost was an attempt to mitigate the scale effect of large staking pools on MEV withdrawals, 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, thus maintaining a level playing field.
image description
Beacon chain deposit details, source: Etherscan
Lido accounts for 29.8% of the stake, which is close to the consensus threshold, which is worrying.
There are misconceptions though, because Lido is itself a DAO, which means it is decentralized by definition. Lido has a transparent policy around the distribution of its node operators, which you can read more about in their post on decentralization.
image description
Depositors by entity (including Lido split nodes), source: Etherscan
The picture remains grim, especially considering that Coinbase and Kraken (two US-registered companies) collectively own more than 21% of staking. In addition, Danny Ryan believes that there is a risk in any liquidity staking derivative agreement, even if the agreement itself is decentralized, there is a risk of obtaining a validator share that exceeds the consensus threshold. You can find it in his articleThe Risks of LSD — HackMDRead more about it in .
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 choose validators as proposers. There is currently a 10% chance of being elected as a proposer at least once a week:
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
herehereCheck out Flashbots' analysis of this phenomenon.
image description
Changes to Beacon Chain Deposits
This shows that MEV-Boost is working and distributing MEV evenly across all validators in the ensemble. Of course, we could argue that the no change in validator share since the merger could be due to low adoption of MEV-Boost, or the fact that the amount of MEV paid to validators is really low. A closer look at these two indicators reveals that these are not the reasons.
image description
Adoption change of MEV-Boost, source: https://dune.com/queries/1279670/2192739
image description
Rewards paid to validators, source: https://dune.com/queries/1279670/2192739
Execution layer rewards, of course, include the preferred fees of all transactions in the block and any MEV captured on top of that. To determine whether the lack of change in validator concentration post-merger is due to the low number of MEVs, we need to look at MEVs separately from priority fees. Luckily, our good friends at Flashbotsalready done. Their data analysis shows that MEV accounts for 73% of all payment rewards for 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 distribution of stake?
This is an interesting question. Will we see stakers move from one staking provider to another? Currently, all stakers are locked. Once withdrawals are enabled, competition among staking pools intensifies. At this point, a spontaneous redistribution of staked shares may be seen.
Whether and how this will happen is just speculation, but it is likely that we will see many people move funds based on APR alone, or we may see more market share being attracted by liquid collateral derivatives agreements. We may see distributed validator technology up and running when withdrawals are enabled on Ethereum, seeObolorSSVnetwork.
Repeater centralization
image description
Block distribution processed by relayers, source: https://www.mevboost.org
This clearly demonstrates the high concentration of a very critical component of the Ethereum infrastructure. That's 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 Tornado Cash-related smart contract addresses to their SDN list. This had a chilling effect and caused many organizations to remove dapp UIs, GitHub repositories, and of course RPC endpoint providers to censor any transactions sent to Tornado Cash.
It's unclear if OFAC was actually aware that they couldn't actually block access to Tornado Cash (spoiler alert: it's still being actively used), but putting these contract addresses on the SDN list had the expected chilling effect. Many MEV-Boost relayers started vetting Tornado transactions (rather than risk going to jail or paying huge fines), one of which was the Flashbots relay. This means that at the time of writing, 75% of all blocks on Ethereum are being reviewed.
It's important to note that this censorship doesn't prevent access to Tornado Cash (or any other contract that happens to be censored), it just delays routing to Tornado Cash by a few blocks. Justin Drake calls this "theWeak censorship", as opposed to "strong censorship," which blocks access entirely. However, currently using Tornado Cash is not really a problem, the problem is that if Ethereum enforces the decree of an authoritarian government, it cannot claim to be a reliable neutral platform. This makes the centralization of the MEV-Boost relay a problem.
So what led to the centralization of the MEV-Boost relay?
Recall that in Part 1, I described the phenomenon of mev-hiding and how it might lead to trust relationships between staking pools and relayers? Staking pools generally prefer their node operators to connect to a specific relay so they can track the amount of MEV paid out 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, i.e. once builders produce valuable blocks, it becomes easier to use established and trusted relays.
Centralization of block builders
Surprisingly, the distribution of blocks proposed to the network by third-party block builders is actually fairly even. I had predicted that network effects would only drive the emergence of a few major block builders, and in fact, I didn’t even completely rule out the emergence of a single block builder.
image description
Distribution of block builders 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 main pool operators producing the majority of blocks.
image description
Distribution of block shares proposed to the network, source: https://dune.com/queries/1306635/2237247
As you can see, at one point Flashbots built more than 60% of the 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 produced about 30% of the blocks on Ethereum. That was somewhat expected, but also worrisome, because at the time it looked like the trend would continue.
image description
image description
Source: https://dune.com/queries/1306635/2237247
image description
Change in the number of block builders, source: mevboost.org
What is the future of Ethereum?
It is clear that MEV-Boost is not just a piece of software, it is a critical part of the Ethereum infrastructure. What Flashbots created fundamentally changed how the web was designed. Going forward, Flashbots wants the management and governance of MEV-Boost to be the responsibility of the community.
In early October, FlashbotsCall for greater community involvement, and received a positive response. Many organizations have come 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 will see more people participating and contributing to the process.
image description
Ethereum roadmap, source: https://twitter.com/vitalikbuterin/status/1588669782471368704
Intra-protocol PBS (proposer-builder separation)
PBS is a design philosophy, there are many ways to implement PBS, and there are many reasons to study it.
PBS was originally proposed as a way to mitigate the centralization effect of MEVs. 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 get larger and larger validators share of the set.
PBS also has an impact on scalability - i.e. danksharding. Making a large block of danksharding is not something all validators can do. Without PBS, the number of validators on the network may be significantly reduced, so PBS is seen as the key to enabling darksharding.
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 good test of the idea. However, the problem with this approach is that it puts MEV-Boost relayers in a trusted position, trusted by block builders and proposers. Without some sort of protected PBS, there is no trustless way for proposers to be sure that builders' blocks will be released and they will receive payment, and there is no trustless way for builders to be sure that they block The MEV in the block has not been stolen.
So it seems likely that PBS will be included in the agreement in some way, but as of now, it's unclear how that will happen as there are many proposals to do so.
For more information on current ideas on how to implement PBS in the protocol, see ideas described in these threads:
Other directions: partial block auction
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, e.g. builders trying to avoid any potential issues with the US government censoring certain transactions .
The solution appears to be to outsource the construction of only some of the block content, an idea often referred to as a partial block auction.
There are many ways to solve this problem, but they all seem to revolve around an idea: the proposer creates a block prefix or suffix containing transactions, and the rest of the transactions in the block come from the block builder. Currently, we have not seen a proposal to allow multiple block builders to contribute transactions to a single block.
Eigenlayer proposes an approach that seems to be gaining popularity, they use a restaking mechanism.
Partial block auction by remortgaging
The idea of remortgaging is very simple. When a validator registers with the protocol, they deposit 32 ETH into the deposit contract and provide their withdrawal credentials, specifying an address for withdrawal in case the validator wants to unstake.
Rehypothecation builds on the idea of providing smart contract addresses as withdrawal addresses. Once a validator unstakes, they withdraw their balance into this restaking smart contract, which they must then exit 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 the full rewards of validators, they will need to fulfill the promises they made as validators. In fact, Eigenlayer allows for the formulation of various restaking contracts, calling them "middleware". In this way, Eigenlayer can be thought of as a "programmable clipping 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 itself and allow another part to be created by a block builder. Validators can allow block builders to create arbitrarily sized portions of blocks and propose the rest themselves.
In this setup, the MEV-Boost relay stores the builder's part of the transaction and forwards the transaction's Merkle root to the validator. The described setup still relies on a central trusted relay, but validators maintain a backup block that they can propose if anything goes wrong. Additionally, Eigenlayer can completely eliminate trusted relayers using another middleware, designed as a data availability layer.
Using this data availability middleware, builders send their block parts to a "data availability arbiter". They do this by secretly sharing their blocks to the nodes in the DA quorum so that no single node has access to any information about the block. Quorum nodes sign the secret block they receive and return it to the builder, who then creates a "certificate" in the form of an aggregated signature and includes it in his bid to the proposer. The proposer chooses the highest bid among all bids with a valid certificate and signs the block header contained in that bid. The proposer then sends this signed block header to the DA arbitrators, who publish their respective secret blocks to the proposer, who can now reassemble the builder portion of the block.
This approach is interesting for two reasons: it means proposers can construct some blocks themselves, which will help alleviate the censorship issues currently affecting Ethereum, and it will also help decentralize the MEV-Boost infrastructure, eliminating the need for Dependence on centralized relayers.
Partial Block Auction via PEPC
Note that Barnabé Monnot also conductedan exploration, which embodies the form of re-staking at the protocol level. This will allow validators to make any type of general commitment with any third party, and have this commitment enforced at the protocol level by the proof committee, without requiring Eigenlayers to re-stake contracts/middleware. This idea is known as Protocol Enforced Proposer Commitment, or "PEPC". The main rationale behind this approach is that, as Barnabé says, it can end up destabilizing consensus when the protocol no longer knows how many validators are effectively at risk (although I believe Eigenlayer has another mitigation for this scenario, including programmatically triggering validator exits).
PEPC facilitates partial block auctions in much the same way as restaking, except that it allows the protocol to keep track of which validators are being slashed and to what extent. This is, of course, assuming that the protocol-enforced proposer commitments are more attractive to validators and third parties than restaking smart contracts.
Protocol level partial block auction
This form of fractional block auction is proposed as an alternative to crLists (censorship resistant lists) in PBS, which I will delve into later. In this scheme, partial block auctions would be facilitated by the protocol itself. With this idea, a proposer can provide a prefix or a suffix, basically meaning that the builder will provide a part of the block and the proposer will provide the rest. Vitaliktalked abouttradeoffs between the two approaches, e.g. it imposes an additional burden on the proposer, which may hinder progress toward eventual statelessness.
Transaction Containment Lists/crLists/ Hybrid PBS
Transaction inclusion lists, crLists, are a way to ease censorship of transactions by block builders without requiring the proposer to actually contribute any part of the block themselves.
At a high level, the idea is to allow proposers to create a list of valid transactions (i.e. valid nonces, signatures, balances, maxFeePerGas, etc.) block.
This is not as simple as it seems, and there are various variations of this method. All variants of the crLists approach seem to converge on a central principle that the protocol will force builders to produce a full block, or a block that accepts a proposer containing the list.
The rationale for this is that if a builder creates a block that doesn't use all the available block space, although there are transactions in the mempool that could contain it, then can we assume that a rational builder is censoring the transaction for some reason , because excluding all available deals just leaves money on the table, which is unreasonable. If the blocks produced by the block builders do not use all the available space, there is no reason for the blocks they produce not to contain transactions in the crList.
Under this scheme, to avoid censorship of transactions containing transactions from crList, builders need to fill a block up to the gas limit in order for their block to be accepted by proposers and the network. In order to do this, they need to fill blocks with random transactions themselves. This might be economically viable for a block or two, but remember: under EIP-1559, the base fee increases once the block limit is reached, meaning builders will need to pay for transactions Pay more Gas to avoid having to include crLists. Over time, an increase in the base fee will mean that most normal transactions will not be included in blocks, which in turn will require builders to "fill" a larger amount of space.
A more likely scenario is that block builders will forego producing blocks until the 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 not expensive for proposers to create crLists, so it theoretically costs them nothing, but there is also no clear incentive for them to create crLists.
If the proposer of the current slot is responsible for making the crList for that slot, 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 typically build the highest value blocks) are all censored.
So imagine creating crList for future slots. For example, the proposer of the current slot 2 n creates a crList for 2 n + 2 . This is called a "forward include list". This way, the proposer of the current slot does not risk financial disadvantage by creating the crList. This also has the nice property of being compatible with single-secret leader election or SSLE, since proposers don't fool themselves by publishing crLists ahead of their position.
documentdocumentA non-exhaustive list of variants outlining the crLists scheme design.
open question
All of the ideas listed above are under active discussion, and I've found some of them to be very promising. However, I have some questions: why don't validators outsource 100% of the blocks to builders? Are we just relying on altruism? What is the incentive for proposers to do any work in order to contribute partial blocks? Why would validators go to the trouble of creating crLists? If it's because the ethereum client does this by default, do validators have the option to disable it? I can imagine that node operators of some staking pools will be reluctant to publish crLists or block prefixes/suffixes containing sanctioned transactions.
What about misaligned incentives? If a proposer provides a portion of a block, does this take away valuable block space that builders can use to fork MEV? Even if there aren't enough transactions to fill a block, proposers need to be careful to choose transactions that don't collide with the builder's bundle.
As far as crLists are concerned, what happens if the proposer does not publish the crList on the P2P network? Can this be enforced by consensus? This has strong synchronization assumptions that add complexity, which is already mentioned in some of the original material I linked to.
in conclusion
in conclusion
These are just a few of the questions that came to mind while writing this article, there are more challenging questions from people smarter than me. So, as you can see, there are still many open questions and potential concerns that need to be addressed before any specific direction or approach can be set. In this regard, it may be several years before we see effective solutions emerge, and the entire MEV landscape may look very different by then.
Original link
