Many thanks to Michael from Lighthouse for feedback.
Lots of things have changed since last attempting to explore and frame the landscape of stakers’ options for extracting Maximal Extractable Value (MEV) nearly 18 months ago, shortly after the merge. With the introduction of MEV-boost as an optional sidecar for processing blocks built by third parties, concerns have arisen primarily around trust assumptions related to relays acting as new intermediaries in block processing. Specifically, worries about their ability to censor transactions.
From today's perspective, these concerns extend not only to relays but also to external block builders. These highly specialized entities, often regulated, find themselves compelled to act in accordance with their respective national legislation. This may involve excluding certain addresses and transactions from block inclusion (e.g., OFAC compliance).
The Quest for Censorship Resistance
Censorship resistance is a fundamental promise of the Ethereum network. For the given article, the definition of censorship revolves around whether a transaction can or cannot be appended to the blockchain. The latter case may arise when a transaction deems invalid, a block happened to be full, or a slot remained empty. If a transaction has been publicly available but not included in a block, however, we may refer to it as temporary or weak censorship, which can last seconds or even minutes due to censoring block builders or relays refusing to process it further.
This situation undermines Ethereum's credible-neutrality pledge. The remaining neutral block space consists of either non-censoring external builders or of non-MEV-boost blocks produced by altruistic self-builders who construct blocks locally, per default without censoring.
Long-Term Solutions: Encrypted Mempools, Inclusion Lists, and MEV-Burn
To strengthen censorship resistance, comprehensive protocol-level solutions are essential. Encrypted mempools, inclusion lists, MEV-burn, or even enshrined Proposer-Builder-Separation (ePBS) are promising options. These mechanisms aim at increasing the costs of censorship for block builders or render relays obsolete altogether.
However, until these technologies are fully deployed or at least partially implemented, it seems worthwhile to continually refine transitional mechanisms for stakers to tackle censorship. While relying on altruistic actors is suboptimal in of itself, they should at least be provided with ways to minimize the costs of their altruism.
Enhancing Payload Preference Expressivity for Stakers
Until recently, stakers faced three practical choices:
Complete Abandonment of MEV-Boost: Some stakers opted to entirely forgo using MEV-boost, which means missing out on significantly higher additional returns, including the chance to propose rare lottery blocks.
Static Minimum Bid Threshold in MEV-Boost: Others set a static minimum threshold (
-min-bid) for processing external blocks (technically referred to as "payloads") within MEV-boost. For instance, they might choose a long-term median MEV reward value (typically around 0.04 - 0.06 ETH per payload).Leveraging client-specific parameters: Other stakers have ventured into the depths of client documentations and configured their client to allow for an individual preference to be set following the valuation comparison of external and local payloads (e.g. builder-bid-compare-factor in Teku, or prioritising local blocks in Prysm)
Chart shows the median proposer revenue per block over the last 30 days (15 Nov - 15 Dec).
47
With the introduction and rollout of a new standard beacon-API (blocksv3), the features specifically outlined in section (3) have been harmonized across all clients and are currently being deployed in recent client releases. The essence of this advancements lies in enabling a more nuanced and granular expression of payload preferences by stakers.
The Builder Boost Factor
The builder_boost_factor is a parameter that stakers can now select on a per-validator basis. For validators utilizing MEV-boost, this parameter offers increased granularity and control over whether to propose a local or external payload. Importantly, this represents a significant improvement over the static threshold set by the -min-bid flag in MEV-boost, as mentioned in (2).
In practical terms, the builder_boost_factor acts as a percentage multiplier applied to the external builder payload when comparing it to a local payload. If the builder_boost_factor is set to 0, the execution client payload is preferred unless an error renders it unviable. By default, clients use a builder_boost_factor of 100, which corresponds to profit maximization mode—choosing whichever payload pays more.
In other words: In the example illustrated above a staker is willing to altruistically give up on at max 30% of their average execution rewards in favor of censorship resistance.
Note: A specified -min-bid value in MEV-boost may lead to not providing the consensus client with an external payload at all.
Additionally, the new endpoint is capable of returning locally constructed payloads from all connected beacon nodes (not just one) in a much faster way. This essentially widens the local view of the mempool and thus the scope of potentially censored transactions. In cases where a user runs one or multiple failover nodes or uses Vouch, this feature ensures a more efficient selection of the most valuable (local) payload among several.
Overall, the harmonization of the above mentioned functions across all clients marks a valuable progression, especially when considering more complex multi-client setups such as those found in DVT clusters.
Related: Execution Layer Payload Selection Input
The recent addition of the should_override_builder field to the execution-APIs allows the execution client to monitor the mempool and look for signs of ongoing censorship from block builders. By employing certain heuristics, it is now possible to identify transactions that may potentially be censored. Depending on the client implementation, there is an increased flexibility to revert to local block production when necessary.
All this is to say that newly implemented client features allow for fine-tuning stakers’ subjective cost preference for providing credibly-neutral block space.