MEV-boost and layer-1’s censorship resistance

Our understanding on the role of transactions fees was wrong all along

The OFAC sanctions for Tornado cash alongside more than 51% of Validators enforcing the sanctions (thanks to the enablement by Flashbots) has sparked a heated discussion on how blockchain systems can defend and recover from censorship attacks. In this article, we provide an overview of MEV-boost before discussing whether it is truly enabling censorship on Ethereum and how we may defend against it as a community. 

Flashbots and the rise of MEV-boost

A validator, who controls the ordering of transactions, can earn more coins than what is expected from the protocol by extracting value from user-generated transactions. If left unchecked, it enables a few validators (who are the best at extracting MEV) to earn significant profits compared to the majority of validators and over time this allows their influence on the proof of stake protocol to grow until they eventually dominate it. 

What is MEV-boost?

Figure 1: An overview of MEV-boosts and how a bundle flows through from a searcher to the Validator. 

MEV-boost (and more generally, Flashbots) was conjured to fight back against the centralisation nature of MEV and protect the ability for solo validators to compete. It focuses on measuring the potential MEV that can be extracted and, as much as possible, evenly distributing it back to the majority of the validators such that no single validator can continuously earn significant rewards compared to others.

The overall flow for MEV-boost is presented in Figure 1. At a high level, searchers submit their bundles to block builders, the block builders form profitable blocks, and it is up to the Relay to decide which block is forwarded to the Validator. Profits from MEV are re-distributed from searchers to Validators via a first-price sealed bid auction. The process requires block builders to include a reward transaction that pays the validator and it is this transaction which acts as a bid in the auction. The Relay picks the block with the highest bid and it is the Validator that receives the bid. 

If you want to learn more about how MEV-boost works under the hood, then we recommend reading Flashbot's documentation. 

Relay and Validator fair-exchange protocol

A fair-exchange protocol is implemented between the Relay and the Validator. The protocol compels a Validator to publish the Relay’s selected block and make it impossible for the Validator to publish an alternative block that steals its MEV. If stealing was possible, then there is no incentive for searchers to participate. 

In a nutshell, the fair-exchange protocol works as follows:

• Relay sends the Validator a block header,

• Validator signs the block header and returns signature to the Relay,

• Relay checks signature before sending the block’s content. 

By signing the block header, the Validator cannot: 

• Independently learn about its list of transactions,

• Sign a second block header and publish it without getting slashed by the proof of stake protocol for double-voting.

Essentially, the Validator is forced to publish the Relay’s selected block in its entirety and the Validator must trust the relay to reveal the block content. This fair-exchange protocol is considered necessary due to the open membership of the Validator set. This is very different to proof of work Ethereum as less than 10 entities controlled the block proposing process and it was possible for the Relay to build a trusted relationship with most of them. 

There is a special irony that decentralisation of the Validator set has led to potential censorship of transactions. 

Can Relays filter transactions? 

Figure 2: Over 65% of Validators have signed up to an OFAC-enforcing Relay. 

Some Relays censor transactions that interact with Tornado Cash contracts in the belief that this is required by the OFAC sanctions regulations. It is still an outstanding question whether compliance is necessary, especially as Relays play a nearly identical role as “Pool Masters” from mining pools who dictate the block template before sending it off to the pool’s workers. 

To maintain compliance, Relays are rejecting blocks from builders if it contains an OFAC-sanctioned transaction. Although, it is worth noting that Relays have the power to single-handedly filter transactions from the proposed blocks before passing it on. The fair-exchange protocol exaggerates the issue as Validators cannot forcefully include the filtered transaction. 

By October 2022, around 65% of validators have signed up and are using an OFAC-enforcing Relay. Figure 2 highlights that the percentage of Validators using MEV-boost is only increasing. The popularity is driven by the financial incentive to receive the distributed MEV. 

Is MEV-boost leading to censorship? 

Yes, and, no.

It depends how censorship is defined and the actions taken by a Validator to hinder the inclusion of a transaction. Let’s consider both in turn. 

Honest majority assumption

A blockchain system like Ethereum assumes that a majority of the block proposers (Validators) are honestly following the protocol (“the honest majority”). In terms of honest behaviour, we can assume a block proposer will adhere to the following two rules:

• Transaction inclusion rule. A valid transaction, that pays the appropriate fee, should be included in the blockchain in a timely manner (regardless of its content).

• Follow the fork-choice rule. A block proposer votes and extends the canonical chain that satisfies a predefined fork-choice rule.

In an ideal world, both rules bolster a blockchain system’s neutrality. They guarantee that all transactions are eventually included regardless of its content and that all block proposers will eventually converge on a single chain of blocks (and transactions). The “timely manner” condition determines whether a transaction was censored and it is configurable based on the current expectations of a blockchain system. 

Hinder inclusion of a transaction

If a block proposer ignores the above rules, for whatever reason, then it is safe to assume they are acting adversarially (“the adversary”). It is often assumed an adversary will break the rules in the pursuit of delaying or censoring a transaction. They can take the following actions: 

• Transaction filtering. The adversary does not include a censored transaction in their block,

• Block filtering. The adversary does not extend parent blocks that include a censored transaction. 

Each action breaks one of the rules defined by honest behaviour. If the adversary is filtering transactions, then they are no longer respecting the transaction inclusion rule. If the adversary is filtering blocks, then they are trying to control the fork-choice rule and ultimately decide the canonical chain of blocks. 

The transaction may be suppressed for a limited period or time or indefinitely depending on which rule is violated:

• Delayed inclusion. An adversary that performs transaction filtering can only delay the inclusion of a user’s transaction. As long as there is one honest block proposer, then the victim transaction will eventually be included in the blockchain.

• Forcefully excluded. An adversary that performs block filtering wants to indefinitely exclude the transaction from the blockchain. This will only be successful if they can represent 51% or more of the voting power to control the fork-choice rule. 

MEV-boost censorship is debatable

The debate amongst the community is whether the impact of transaction filtering should be classified as censorship. 

At first glance, the fact that ⅔ of all Validators are filtering transactions may suggest the honest majority assumption is broken and transactions are indeed being censored by MEV-boost. Yet, the devil is in the details. The Relay is only violating the transaction inclusion rule, but they are not attempting to control the fork-choice rule or filter already proposed blocks. As a result, a Relay can only delay the inclusion of a transaction and only one honest Validator is required to include the victim’s transaction. 

This brings us to the “timely manner” condition of the transaction inclusion rule. Even with ⅔ of all Validators filtering transactions, a victim’s transaction will still be included in 1 out of every 3 blocks. It is difficult to argue that waiting three blocks represents a significant delay, but it does lead to an issue on where to “draw the line” before wide-spread adoption of transaction filtering is effectively censoring. 

For example, in the worst case scenario, we can assume there is only 1 honest validator out of 455,708 Validators. It will take at least ~63 days until the honest validator is selected and the censored transaction is included, but over this time period the accumulation of censored transactions may exceed the block gas limit and add additional time until all censored transactions can be confirmed. 

Even with the one honest party assumption, it is not reasonable to wait at least two months for inclusion of a transaction and it implies the blockchain’s neutrality has been compromised. 

What can we learn from the MEV-boost debacle? 

The debate about MEV-boost’s impact on censorship demonstrates a clear difference between the expected and actual behaviour of Validators. 

Transaction fee market does not guarantee censorship-resistance 

In nearly all blockchain models, it is assumed that honest Validators will prioritise transactions based on the offered fee and this should give rise to a fair fee market.

The idea emerged from Bitcoin as the fee market is expected, at some point in the future, to dominate the income for miners. All miners will fight for “scraps” as mining becomes a tight-margin competition and a zero-sum game. In Ethereum, the situation is very different as EIP-1559 assumes that transaction fees will not dominate the income for validators (‘minimal viable security’). Instead a transaction is picked up by Validators because there is always space to include it and it is essentially free money to collect the tips.  

Remarkably, censorship-resistance via the transaction fee market ignores the desire for Validators to pick transactions based on their own individual preferences, even if it impacts their profitability. It is even more strange as there have been several occasions when block proposers ignored the fee market for their own personal reason. The earliest example I can recall was in 2013 when Luke-Jr tried to censor Satoshi Dice as it was “spamming” the blockchain. 

The fact that Validators have signed up to OFAC-enforcing Relays and have agreed to filter transactions in return for MEV is clear empirical evidence that the fee market assumption for censorship-resistance is categorically wrong. The fee market does NOT guarantee that a transaction will be included in the blockchain and there are many good reasons for Validators to ignore transactions. For example, if they can make more money by employing a competing strategy or if there is a legal reason to do so (i.e., avoid imprisonment). 

Transaction inclusion must be a collective, and not an individual, responsibility. 

The root issue exposed by MEV-boost is that the community does not fully understand how the network upholds censorship-resistance. The honest majority assumption only guarantees that block proposers will converge on a single blockchain and it has nothing to do with censorship-resistance. It is currently up to individual Validators to honestly follow the protocol and include all transactions that pay an appropriate fee.  

Unfortunately, MEV-boost empirically demonstrates that individual Validators are under no obligation to respect the transaction inclusion rule and it is a potential tragedy of the commons situation as Validators are not incentivised to work as a collective to guarantee transaction inclusion. 

We believe there are only two solutions to fix this problem:

• Indistinguishable blobs. A Relay cannot evaluate a transaction’s purpose and thus they cannot filter it.

• Honest collective. All honest block proposers work as a collective to enforce the inclusion of a transaction as part of the fork-choice rule. In the spirit of crList proposal.

We argue the latter option is preferred.

If the OFAC-enforced Validators attempt to censor a transaction and ignore the will of the honest validators, then their proposed blocks will not be accepted by the fork-choice rule and the tip of the chain will split into two competing forks. It is possible to implement a limited form of this option as part of MEV-boost today and it should be done as soon as possible.

If changed, it will lead to a situation where Validators “can't be evil” as opposed to “being evil”. 

Be prepared to defend the network with a User Activated Soft Fork (UASF)

There is currently no software fork that can be leveraged at a moment’s notice to fight back against censorship. This is problematic as software takes time to thoroughly test before it should be deployed on a >$100bn network. Throughout this time, censorship can be prolific for weeks/months before we as a community can do anything about it. 

The best defence that we can conjure as a community is to upgrade the network rules and forcefully remove the adversarial block proposer. This is called a User Activated Soft Fork as the consensus rules are changed by agreement of the users and not the block proposers. It is implemented differently for both proof of work and proof of stake:

• UASF in proof of work. The only option is to change the mining algorithm to make the ASIC hardware redundant. This is the nuclear option as it will hurt all honest miners alongside the adversary. Unfortunately, in the context of Ethereum, it is a useless option as a super-majority of miners only rely on GPUs and changing the algorithm does not hamper their ability to solve the new proof of work puzzle.

• UASF in proof of stake. The adversary can be surgically removed without harming any honest parties by updating the consensus rules to forcefully exit the adversarial block proposers from the proof of stake protocol. As an added bonus, the community can decide to slash a percentage of the adversary’s stake. 

Thankfully, proof of stake Ethereum is superior to proof of work for defending against censorship (and an adversarial block proposer) as it provides the tools to surgically remove them without harming any honest parties. It is now time for the community to take the threat seriously and prepare software that can be used as a moment’s notice. Until that software is ready, then there is no credible threat to prevent malicious Validators from censoring transactions on the network. 

Concluding remarks

We should thank the Flashbots team for bringing to the forefront our misconceptions on how the network upholds censorship-resistance. 

Even with ⅔ of Validators signed up to OFAC-enforcing Relays, it is still difficult to argue that Ethereum’s neutrality is compromised as a single honest Validator can forcefully include a censored transaction in a timely manner. At the same time, we must not become complacent. The rise of OFAC-enforcing Relays represents an early red-flag for censorship problems that must be solved in the short to medium term.If we are not cautious, there is a possibility that MEV-boost is upgraded (or another service emerges) that goes further to filter blocks and enact full censorship by forcefully excluding transactions. 

As a community, we must be prepared to fight against the threat and there are a few outstanding items to tackle:

• Define and measure censorship. Pick “the red line” when wide-spread transaction filtering is considered censorship and build tools to measure it in real-time,

• Collective enforcement. Implement crLists, or another solution, that ties censorship-resistance to the network’s fork-choice rule,

• Prepare our defence. Prepare User Activated Soft Fork (UASF) software that will forcefully exit and potentially penalise a list of censoring Validators. 

Thank you for reading and hopefully we can work together to help Ethereum remain a neutral platform for all.  

Thanks to Mike Golden, Ben Edgington and Simon Brown for feedback on the article.