## Supplementing Censorship Resistance Today

[Data Always](https://twitter.com/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`](https://writings.flashbots.net/the-cost-of-resilience) and [`localBlockValueBoost`](https://docs.prylabs.network/docs/advanced/builder#prioritizing-local-blocks) work. You are aware of the low level of [`min-bid` adoption](https://hackmd.io/@dataalways/resilience) by proposers and the [state of censorship](https://censorship.pics/) 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](https://x.com/TimBeiko/status/1778500704996634638), 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](https://notes.ethereum.org/@fradamt/forward-inclusion-lists),[2](https://ethresear.ch/t/no-free-lunch-a-new-inclusion-list-design/16389),[3](https://ethresear.ch/t/cumulative-non-expiring-inclusion-lists/16520),[4](https://ethresear.ch/t/fun-and-games-with-inclusion-lists/16557/1),[5](https://ethresear.ch/t/resistance-is-not-futile-cr-in-mev-boost/16762),[6](https://ethresear.ch/t/unconditional-inclusion-lists/18500),[7](https://ethresear.ch/t/the-more-the-less-censored-introducing-committee-enforced-inclusion-sets-comis-on-ethereum/18835),[8](https://ethresear.ch/t/uncrowdable-inclusion-lists-the-tension-between-chain-neutrality-preconfirmations-and-proposer-commitments/19372),[9](https://ethresear.ch/t/anonymous-inclusion-lists-anon-ils/19627),[10](https://ethresear.ch/t/one-bit-per-attester-inclusion-lists/19797),[11](https://ethresear.ch/t/fork-choice-enforced-inclusion-lists-focil-a-simple-committee-based-inclusion-list-proposal/19870)].


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](https://hackmd.io/@ttsao/building-blks-competitions) 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](https://mempool-dumpster.flashbots.net/index.html), extracted using [Dune Analytics](https://dune.com/queries/3874489/6518584), 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](https://github.com/flashbots/mev-boost/pull/635) 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](https://hackmd.io/@dataalways/resilience#Theoretical-Impact) 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](https://hackmd.io/_uploads/BkoRqkKCp.png) 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](https://writings.flashbots.net/the-cost-of-resilience#effects-on-transaction-inclusion).

> 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](https://dune.com/data_always/staking) or 1.5% of their [total rewards](https://dune.com/queries/3598014/6062101).

> 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 to`localBlockValueBoost` as a stopgap. The value proposed by [Fredrik Svantes](https://github.com/fredriksvantes) and implemented by [Prysm](https://github.com/prysmaticlabs/prysm/releases/tag/v5.0.2), [Teku](https://github.com/Consensys/teku/releases/tag/24.3.1), and [Lodestar](https://github.com/ChainSafe/lodestar/releases/tag/v1.18.0) was 10%—a value chosen without presenting empirical analysis of its reversion rates or efficacy as a tool for censorship resistance.

> [Lighthouse](https://github.com/sigp/lighthouse/pull/5441) and [Nimbus](https://github.com/status-im/nimbus-eth2/pull/6103) 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%](https://clientdiversity.org/#distribution), 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.

<iframe src="https://dune.com/embeds/3798898/6497710/" width = 100%, height = 400/></iframe>

> 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](https://x.com/fiiiu_) for prompting further optimizations).
- Since May, the network has seen a large rise in [private order flow](https://x.com/mcutler/status/1808281859463565361), particularly amongst [DEX transactions](https://x.com/Data_Always/status/1808290059264643187). How large of an impact does this have on reversion rates?

---

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