tl;dr
- A new mev-boost feature allows validators to maximize Ethereum’s censorship resistance by building low-MEV blocks locally while still outsourcing the building of high-MEV blocks.
- Using this feature carries an opportunity cost—the price of resilience.
- As most blocks are actually low-MEV, however, forfeiting a little profit goes a long way in increasing resilience!
- This is a breakthrough in the tradeoff between maximizing MEV extraction and maximizing censorship resistance.
Network Resilience
Flashbots has recently become a target of public scrutiny after OFAC broadened the set of sanctioned addresses to include smart contracts for the first time, affecting many users of the Ethereum network. While Flashbots has tried to navigate both the risk and ambiguity around the application of OFAC sanctions to data and communications infrastructure in web3 since the beginning, this was less fraught before the merge, when relays were sending bundles to mining pools, who were then responsible of assembling full blocks locally. The market moving to full block submission established the full separation between block builders and validators, who can no longer add individual transactions to a block.
Today, most blocks in Ethereum are OFAC compatible, and although in practice this means that offending transactions only get throttled by a small amount, ensuring robust decentralization and resilience at the protocol level is critical for Ethereum's success as neutral infrastructure. Unfortunately, changes to mev-boost alone do not suffice to provide these guarantees. In order for consensus clients to profit-switch between blocks coming from a (potentially selective) market of builders and the local mempool, deep changes to both the Execution and Consensus Clients need to take place. While the community is in agreement that this is an important issue, client teams have different priorities they need to balance. Other long-term proposals like Inclusion Lists and Partial Block Auctions are part of the core Proposer-Builder Separation research track.
The question then arises of what can we do to address the issue today, while deferring a robust, protocol-level solution. It has been suggested that Flashbots self-limits their share of relayed blocks, but we ultimately believe that market distortions like this won't achieve much, as we cannot really predict how other relays will behave. Flashbots charging a small fee was also proposed, as establishing this standard would encourage other entities to run independent relays. While this seems like a sensible proposal, it risks entrenching the relay role, which we only view as a temporary solution until SUAVE is deployed—a fully trustless building network.
Fortunately, other builders and relays have started to emerge and take increasingly larger shares of the market, and we are actively providing support to teams interested in running other relays. As of last week, we have open sourced our builder, so anyone can now easily run a builder too. From the validators’ perspective, however, the question remains: run mev-boost and comply with the regulations that their trusted relays adopt, or build blocks only locally, potentially forfeiting 100+ ETH profit opportunities?
The Solution
Now, validators can sidestep this question by running mev-boost with the new min-bid parameter. What this parameter does is only accept blocks from relays if they bid above a chosen value, otherwise a locally-built block is proposed. This leverages the fact that the profit increase coming from mev-boost is not that large for most blocks. Validators can thus forfeit a small amount of profit in exchange for making the network more resilient, while keeping the door open for high-MEV opportunities.
As depicted, the new min-bid parameter allows validators to escape the tradeoff between profit maximization and network resilience. In what follows, we explore the cost that validators incur by opting into this feature.
Block Profit Distribution
We start by looking at the cumulative distribution of block profits, for both blocks coming from the Flashbots relay, and locally built blocks, all data post-merge1:
As expected, the mev-boost distribution has a longer tail. We can look at the data in a different way by displaying the profit difference between both kinds of blocks, as follows:
The asymmetry in this distribution again shows us how mev-boost blocks are generally more valuable than mempool blocks. However, we also see that a sizeable amount of blocks lie close to having no difference in value. Looking at the profit bucket of 0.05 ETH as an example, historically 35% of the mev-boost blocks have a profit of or below 0.05 ETH. By setting the minimum bid value to 0.05 ETH, the proposer will choose to build local blocks approximately a third of the time.
The question now is how much profit would validators be forfeiting by choosing to set a positive value for the min-bid parameter.
Opportunity Cost
The opportunity cost of setting a minimum bid value is the cumulative difference in block profit between blocks using Flashbots mev-boost relay and blocks built locally. The larger the minimum bid, the more blocks will be locally built, and the larger the opportunity cost:
As we see from the graph, the opportunity cost can get quite high for large values of the min-bid parameter, which means that most blocks would be built locally. However, as we pointed out, we are mostly concerned with low-profit blocks, which can get us a long way towards network resilience. Looking at only block profits below 0.11 ETH, which account for ~73% of all mev-boost blocks, we see the following opportunity cost, together with the implied approximate APR for each setting of the parameter:
We see again how the opportunity cost increases with the value of min-bid, but at the same time the projected APR falls only very slowly. This leads to the question of whether forfeiting a small amount of profit can make a difference in terms of transaction inclusion, which we look at next.
Effects on Transaction Inclusion
Around 72% of Ethereum blocks are now built in an OFAC-compatible way. This means that some transactions experience delays in getting included on chain. In particular, the probability of one of these transactions to be included after one block is around 28%, corresponding to the validators who either build blocks locally or get profitable blocks from non-OFAC compatible relays. If all validators were using mev-boost and connecting only to OFAC-compatible relays, the inclusion rate would of course fall down to 0.
Let's look at the inclusion rate of these transactions for different values of min-bid, focusing only on mev-boost instances connected to OFAC-compatible relays:
As mentioned, the default value of 0 would prevent any transaction from being included. For relatively small values of min-bid, however, we see how non-OFAC compatible transactions have a large chance of inclusion even after very few blocks. As an example, setting a value of min-bid of 0.05 ETH would bring the inclusion probability after one block from 0 to 35%. Clearly, a majority of validators opting into this feature would go a long way towards increasing the network's resilience.
The following table summarizes our results for different values of the min-bid parameter:
| Minimum bid value | 0 ETH | 0.02 ETH | 0.05 ETH | 0.10 ETH | 0.24 ETH |
|---|---|---|---|---|---|
| Cumulative % of blocks ≤ min bid value | n.a. | 5% | 35% | 70% | 90% |
| Opportunity cost per block | 0 ETH | 0.003 ETH | 0.007 ETH | 0.01 ETH | 0.01 ETH |
| Approximate proposer APR % | 6.5% | 6.4% | 6.3% | 6.3% | 6.2% |
| non-OFAC inclusion rate after 1 block | 0% | 5% | 35% | 70% | 90% |
Wat Do?
While censorship resistance ultimately needs to be tackled at the protocol level, we can today leverage the fact that most blocks are low-profit, such that the difference in profit between local and relay-built blocks is not that large.
If you run an Ethereum validator and are willing to incur a small opportunity cost in exchange for making the network more resilient, run mev-boost with:
mev-boost -min-bid <x> -relay ...where x is the minimum accepted ETH-denominated profit amount from blocks coming from the relays. As we saw on the table in the previous section, setting x = 0.05 incurs a per-block opportunity cost of 0.011 ETH, which decreases the annual return for proposer by only 0.1% in APR. This small decrease in yield has a sizeable effect in network resilience: if all validators connecting to OFAC-compatible relays adopted this threshold, the 1 block inclusion probability for non-OFAC compatible transactions would increase from the current 28% to coarsely 53%. Larger voluntary forfeitures of profit would of course entail even greater increases in network resilience.
We encourage validators to update mev-boost and help reinforce Flashbots ongoing commitment to building open and decentralized infrastructure in line with Ethereum's goals.
Thank you to metachris, Kailin, and Xin for contributions to this post :)
1 Two data sources are used in in this analysis: payloads delivered through the Flashbots MEV-Boost relay and included on chain ranging from block number 15537940 to 15947320, and the Flashbots mempool builder (0xa1defa..), which provides reference mempool block values.
2 The combined data with block value from mempool and from MEV-Boost can be downloaded from here.