Outline of Problem
Currently, the single relay run by the FlashBots team is the most reliable and on average profitable of the available Ethereum relays. Its 80%+ dominance among externally-built blocks is a testament to this, and to the FlashBots team’s long-time presence and contributions to the MEV space.
However, a notable minority (somewhere in the vicinity of 1/5th) of proposers (validators with their operators) running MEV-Boost have elected to not connect to the FlashBots relay, and an unknown fraction of the proposers currently building locally may also be making a similar decision.
These proposers likely have a variety of reasons for this choice, but anecdotally, many are concerned about censorship at the relay level. FlashBots, with their relay, have chosen to respect the US OFAC sanctions list by rejecting all builder-submitted blocks containing transactions referencing sanctioned addresses, notably including Tornado Cash’s main smart contract address. It is likely that many proposers have chosen not to connect to the FlashBots relay, even though it means they are missing out on additional profit, because of this.
One might argue that simply connecting to all available relays, including FlashBots, would be a good solution to this issue of censorship, but in practice, FlashBots’ dominance in the profitability metric means that even when a variety of non-censored blocks are available to MEV-Boost, the most profitable block is often from FlashBots, and sometimes that is a censored block. So proposers concerned about censorship unfortunately must exclude all censoring relays from their relay lists.
The irony is that in practice, less than 1% of all blocks (at present) actually contain transactions that would be censored under these critieria. 99%+ of blocks are devoid of such transactions, and therefore would be “clean” of this type of censorship, and likely acceptable to many of these hesitant proposers.
To summarize: potentially upwards of 5-10% of the total validator pool has chosen to reduce their own profits because of censorship on less than 1% of blocks, and the FlashBots relay and its connected builders are missing out on access to, and profit from, the 5-10% of block slots controlled by those proposers as a result.
This is clearly suboptimal for all involved parties, and finding a quick solution could potentially be a win-win for everyone.
Proposal for Solution
We propose that FlashBots set up a second relay. All blocks submitted by builders to the existing relay would be immediately and automatically forwarded to this second relay as well. It would behave identically to the existing relay almost all of the time, except in one specific case. When the existing code that looks for OFAC-sanctioned transactions in all submitted blocks actually detects one, the normal behavior would be to exclude that block from consideration for being relayed to the proposer. This new relay would instead not submit anything to the proposer for that block slot.
To be clear: instead of rejecting blocks containing the censorable transaction and instead relaying another block (which might be intentionally censored) to the proposer, in this case (which, recall, currently happens less than 1% of the time), the relay would put on the brakes and submit nothing to the proposer.
While this might seem like an even more extreme form of censorship at first glance, in practice it would enable the proposer to select a block from a different, non-censoring relay, or build it locally.
Everyone is happy. FlashbBots is happy because they are still not relaying any OFAC-sanctioned transactions, but now have access to many additional proposers and their blockspace. Censorship-sensitive proposers are happy, because they can connect to the very profitable FlashBots relay, but with their MEV-Boost automatically failing over to non-censored blocks in the <1% of cases where the new FlashBots relay simply relays no block.
Importantly, this would also require no changes to APIs or the protocol, and would only require infrastructure work on FlashBots’ end, and adding the new relay on the proposers’ end. Many censorship-sensitive proposers would be happy to spread the word about such a new relay.
There is at least one potential issue with this setup which bears mentioning: this new relay would be vulnerable to DoS attacks, whereby an attacker spammed at least one valid, basefee-meeting, profitable-to-include transaction to an OFAC-sanctioned address per block slot. Such an attack would not be very expensive, and could result in the relay submitting no blocks for extended periods of time. In particular, competing relays could potentially be motivated by such an attack.
Nevertheless, the presence of such a relay, even if it suffers from such DoS attacks from time to time, would represent a strict improvement over the current situation for both FlashBots and censorship-sensitive proposers (assuming the infrastructure costs of such a relay are minimal compared to the added profits).
It also might be ideal for a neutral in-house builder to be stood up that always submits simple tip-ordered non-censored blocks directly to the new FlashBots relay, as a means of improving the chances of censorable transactions being detected, when present, by the new relay. This would avoid the case where all external builders connected to Flashbots were already censoring themselves, since they knew the main FlashBots relay would censor them entirely if they didn’t, resulting in no censorship being detected by the new relay when it was in fact happening. Such a ‘canary builder’ might or might not be necessary in practice.
We would love to hear everyone’s thoughts, especially any FlashBots team members. This seems like a fairly quick win that would be mutually beneficial for all parties, and would also help alleviate some of the criticisms FlashBots and Ethereum itself have recently been facing around censorship in general.
Thank you for your time!