Supplementing Censorship Resistance Today

Data Always - July 10, 2024

tl;dr

The potential for significant missed income from localBlockValueBoost edge cases and the lack of empirical study of its efficacy has led consensus clients into making opinionated decisions for their users without meaningfully contributing to censorship resistance. In its current state, full network adoption of localBlockValueBoost would revert less than 1% of MEV-Boost blocks to local building, while concentrating over half of missed proposer income into less than 1% of those reversions.

To allow for localBlockValueBoost to be increased and to provide powerful censorship resistance, consensus clients should introduce a limit on missed proposer income to prevent the most expensive edge cases. With proper tuning, a capped local value boost can provide better resilience than min-bid at a lower cost and without modifying out-of-protocol software.

Assumed Audience: Ethereum researchers and core developers. You have a conceptual understanding of how min-bid and localBlockValueBoost work. You are aware of the low level of min-bid adoption by proposers and the state of censorship on Ethereum.

Conflicts of Interest: This research was entirely unfunded. The authors have exposure to bitcoin and ether, but declare no other meaningful conflicts of interest.

---

With inclusion lists no longer slated to arrive in the Pectra update, the Ethereum Network is set to remain without strong censorship resistance guarantees until late 2025 at the earliest. This situation only benefits two major entities in the space: Titan Builder and Ethereum Foundation researchers [1,2,3,4,5,6,7,8,9,10,11].

In the meantime, the Ethereum community has two main tools to combat censorship:

• the min-bid parameter built into MEV-Boost
• the localBlockValueBoost parameter built into consensus clients

Most discussions around censorship resistance tend to focus on min-bid, but since MEV-Boost is out-of-protocol software core developers are powerless to change the default value. In order to change the value, an interested party would need to convince Flashbots and the wider community that the change is justified, despite the obvious impact on market structure. By contrast, to change the default value of localBlockValueBoost core developers only need to come to consensus within individual client teams.

Note: the comparison factor built into consensus clients has various names.

• localBlockValueBoost in Prysm and Nimbus
• builder_boost_factor in Lighthouse
• builder-bid-compare-factor in Teku
• builderBoostFactor in Lodestar

This essay adopts Prysm's terminology of localBlockValueBoost and the analysis uses its methodology for comparing block values.

This essay aims to shed light on the strengths and weaknesses of the two tools. To date, discussions involving localBlockValueBoost have lacked empirical or even theoretical analysis and have often treated the two as interchangeable. However, as shown in Figure 1, the instances they cover differ dramatically.

Figure 1: diagram of the coverage of min-bid and localBlockValueBoost. The parametrizations are both set in order to revert approximately 10% of MEV-Boost blocks to local building.

Methodology

This analysis leverages Flashbots's mempool dumpster, extracted using Dune Analytics, to separate transactions into public and private order flow. We then calculate a theoretical value for blocks had they been built locally by summing the priority fees from the public order flow.

We chose to restrict the time domain of this analysis to October 2023 to February 2024. In mid-February go-ethereum began enforcing strict minimum tip policies; they have since dramatically weakened the policy. We chose not to include later data to avoid potential data poisoning.

The main limitation of this methodology occurs for blocks that approach the gas limit: in this subset, localBlockValueBoost comparisons will be underestimates. However, these blocks tend to have significant MEV and are less likely to be reverted. This limitation does not affect min-bid reversion rates but causes missed income metrics to slightly overestimate their true values. Some other notable limitations are:

• We do not account for execution clients that enforce minimum tip policies
• We do not account for potential shifts in searcher behavior (reversion to PGAs) if more blocks start being built locally
• Flashbots's mempool dumpster misses a small subset of public transactions
• The data analyzed here is all pre-Deneb and may have changed slightly due to blobs
• The results shift with market conditions and ecosystem developments, this analysis represents a snapshot in time, but may not be accurate extending permanently into the future

min-bid

The min-bid parameter built into MEV-Boost is capable of offering strong censorship resistance without large outlier losses for proposers. When it became clear that inclusion lists would not be included in the Pectra update, Tim Beiko opened a pull request to change the default value. However, lacking empirical support, the proposal was swiftly rejected. At present, changing the default value of min-bid and making it opt-out appears unlikely.

Encouraging large entities to use min-bid is the strongest action that can be taken by the social layer. In March, we tracked footprints in MEV data to show that min-bid usage is almost negligible–over half of usage coming from just four Lido node operators.

Aside: Update on min-bid usage.
Since our previous essay, Sigma Prime has resumed using min-bid and Attestant has updated their parameter from 0.035 ETH to 0.07 ETH to match other Lido node operators. Stakin stopped using min-bid in early June. These changes can be seen in Figure 2. As a result, approximately 10% of Lido blocks now revert due to min-bid, or 3% of all blocks on the network.

Figure 2: diagram of the lowest MEV payments to Lido node operators. By monitoring the missing data in MEV distributions we can empirically monitor which operators do or do not use min-bid.

The only major non-Lido entities that currently use min-bid are Upbit and Daniel Wang. Together they revert 0.6% of blocks on the network, bringing tagged entity min-bid usage up to 3.6% of all blocks. This represent about 40% of all local block building on the network.

To gauge the effectiveness of min-bid settings, we transform the distribution of winning MEV bids to construct a profile of theoretical block reversions. In Figure 3, we see that for the often-quoted value of 0.05, between 45% and 55% of blocks would revert, which is 30–50% higher than at the time that min-bid was introduced.

Figure 3: monthly theoretical share of MEV-Boost blocks that would have been reverted if all proposers were using a given min-bid parameter.

The share of block reversions is a macroscopic metric that researchers and the network care about, but proposer sets are more concerned with the financial impact associated with opting into building their own blocks. Seen in Figure 4, at a ETH/USD rate of $4,000, the adoption of Beiko's proposal would cost the proposer set between 5 and 7 million dollars per month (60–84 million dollars annually). This is roughly equivalent to 60–80 USD annually per validator (0.05% APR) and represents about 10% of an average proposer's execution layer rewards or 1.5% of their total rewards.

Figure 4: theoretical monthly cost to the proposer set if min-bid were adopted by all validators.

The biggest advantage of min-bid is that it places firm constraints on the magnitude of missed income that can be suffered by each block proposer. This results in relatively equitable losses, seen in Figure 5, with the total cost distributed over the entire set of participating validators.

Figure 5: Lorenz curve of the distribution of missed income for select values of min-bid. Gini coefficients range from 0.27 (min-bid: 0.01) to 0.35 (min-bid: 0.07).

The weakness of min-bid is that relays do not have insight into the value of the block built by the proposer. As a result, blocks that derive the majority of their value from public order flow but exceed the value of the min-bid parameter will still be built through MEV-Boost even though the benefit may be minimal.

For example, with min-bid set to 0.05, we would see the reversion of a block with 0.045 ETH of private order flow and no public order flow, resulting in a loss of 0.045 ETH for the proposer. Meanwhile, a block with 0.01 ETH of private order flow and 1 ETH of public order flow would not be reverted, despite the loss only being 0.01 ETH and less than 1% of the block's value.

localBlockValueBoost

With no easy path to changing the min-bid default, core developers turned tolocalBlockValueBoost as a stopgap. The value proposed by Fredrik Svantes and implemented by Prysm, Teku, and Lodestar was 10%—a value chosen without presenting empirical analysis of its reversion rates or efficacy as a tool for censorship resistance.

Lighthouse and Nimbus are still discussing the possibility of changing the default but both seem unlikely to act.

To begin understanding whether localBlockValueBoost can be an effective tool, we must first understand the distribution of rewards that come from private vs. public order flow. Plotting the density of MEV-Boost block values against the value of the public order flow, we see in Figure 6 that a default boost of 10% misses the heart of the distribution and is unlikely to have a meaningful impact.

Figure 6: kernel density estimate of public order flow share for blocks built by MEV builders between October 2023 and February 2024.

In Figure 7, we mimic the analysis we used for min-bid by extracting the value of public order flow from MEV-Boost blocks, and create a theoretical reversion rate profile for different parametrizations of localBlockValueBoost. We find that full network adoption of a 10% default value would have caused approximately 0.75% of MEV-Boost blocks to revert to local building between October 2023 and February 2024.

Figure 7: monthly theoretical share of MEV-Boost blocks that would have been reverted if all proposers were using a given localBlockValueBoost parameter.

Teku and Prysm, with a combined market share of 57%, changed their default values in releases on March 26 and March 27. Since then, seen in Figure 8, the share of locally built blocks has trended down and fallen by as much as 40% as market dynamics have changed. It's clear that the status quo is not having the desired effect and that it is time to re-evaluate the default value.

Figure 8: finalized locally built blocks as a share of daily slots. We do not see any increase after the Teku and Prysm releases in late March suggesting, that any impact from changes to the default value of localBlockValueBoost has been overshadowed by changes in market conditions.
Source: https://dune.com/queries/3798898/6497710

The absolute cost of reversions through localBlockValueBoost is currently low because so few blocks are being reverted. Unfortunately, the distribution of losses is heavily skewed. Using January 2024 as an example, with 100% adoption the total loss to proposers would only have been 9.71 ETH, but 3.57 ETH (37%) would have come from only five blocks (0.3% of reversions). Generating Lorenz curves for various parametrizations, we see in Figure 9 that at lower boost values the majority of missed income is isolated in a small share of reversions.

Figure 9: Lorenz curve of the distribution of missed income for select values of localBlockValueBoost. Gini coefficients range from 0.81 (localBlockValueBoost: 10%) to 0.42 (localBlockValueBoost: 100%).

Direct Comparison

To compare the two tunables directly, we tabulate the values needed to trigger an equivalent number of reversions in Table 1. We find that obtaining resilience through localBlockValueBoost is 20%–30% more expensive than obtaining it through min-bid.

Reversion Rate	min-bid	localBlockValueBoost	Relative Cost
1%	0.0105 (0.0034)	12.1% (0.0063)	+85%
5%	0.0158 (0.0054)	33.3% (0.0071)	+31%
10%	0.0199 (0.0069)	52.5% (0.0089)	+29%
20%	0.0269 (0.0093)	88.9% (0.0118)	+27%
30%	0.0339 (0.0118)	129.0% (0.0147)	+25%
50%	0.0507 (0.0174)	235.8% (0.0213)	+22%

Table 1: parameters and average missed income (in parentheses) to revert an equivalent number of MEV-Boost blocks. We find localBlockValueBoost to be a significantly more expensive tool for censorship resistance. Based on data from October 1, 2023 to February 29, 2024.

Upon examining the cost of reverting an additional chunk of blocks, we see that localBlockValueBoost is strictly more expensive throughout the entire spectrum of blocks that might make sense to revert. In addition, the cost is also more volatile stemming from edge cases where expensive reversions take place.

Figure 10: comparative average cost per additional reversion for localBlockValueBoost and min-bid between October 2023 and February 2024. We find that localBlockValueBoost is more expensive and more variable throughout the domain of interest.

Fixing localBlockValueBoost

The problems with localBlockValueBoost all stem from high-value edge cases. These outliers inflate the statistical and emotional cost of reversions and make it impractical to raise the default value of the parameter high enough to achieve meaningful censorship resistance. One natural solution is to adopt an additional parameter, maxLocalBoostValue, that can be used to exclude these outliers and constrain the maximum missed income for a block proposal.

In Figure 11 we plot the change in reversion rates with the addition of a cap on losses. We find that for localBlockValueBoost defaults lower than 30%, a maxLocalBoostValue of 0.01 is large enough to eliminate edge cases without meaningfully affecting reversion rates. If consensus clients want to increase localBlockValueBoost significantly higher, maxLocalBoostValue needs to be set to 0.02 or 0.03 to revert 20% or more blocks to local building.

Figure 11: theoretical share of MEV-Boost blocks that would have been reverted between October 2023 and February 2024 if all proposers were using both localBlockValueBoost and maxLocalBoostValue parameters.

Once expensive outliers have been eliminated, the average cost of reversions can be brought in line with or below the theoretical cost per reversion of min-bid.

Figure 12: comparative average cost per additional reversion between October 2023 and February 2024. Adding a max loss per block to localBlockValueBoost can bring the cost down to match the theoretical cost of reversions through min-bid.

Open Questions

• Changing default values relies on the assumption that "defaults are sticky". Is there any empirical evidence that this is true?
• If min-bid were implemented in consensus clients instead of MEV-Boost, we could apply a similar cap on losses. How would this affect the loss profiles of min-bid?
• In the limit where localBlockValueBoost goes to infinity, maxLocalBoostValue becomes dominant in the whole domain, and we are left with an absolute (instead of relative) comparison of MEV block values vs. local block values. Would it be more effective to drop the relative comparison and simply rely on the absolute comparison?
• Is it worth adding more complexity to maxLocalBoostValue? The combination of localBlockValueBoost and maxLocalBoostValue is a piecewise function, but we could formulate a smooth transition between the two regimes that initially acts like vanilla localBlockValueBoost and in the limit approaches a direct comparison to maxLocalBoostValue (h/t Alejo Salles for prompting further optimizations).
• Since May, the network has seen a large rise in private order flow, particularly amongst DEX transactions. How large of an impact does this have on reversion rates?

---

Appendix A: Distribution of Losses with a Min-Bid of 0.07