Request: A Full-Block-Censoring FlashBots Relay For Censorship-Sensitive Proposers

Relays
1

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!

2

Seems this wouldn’t work with permissionless builders, because a block builder could stop a relay from working by simply making a random block submission with an added OFAC transaction :thinking:

1 Like
3

Right, there’s a DoS attack vector (from the perspective of the relay - from everyone else’s perspective, just another opportunity for more profit) consisting of creating spurious OFAC transactions. The most likely opponent to do this would be a competing relay or individual builder, who wanted to disable this new relay in those cases where a proposer was connected to it but not the normal FB relay.

There are two possible ways to do this: in a continuous approach, or targeted.

For the continuous approach (spamming 1 OFAC tx per slot), the question becomes, is it worth someone’s time to include 7200 of these a day, to keep this relay down permanently?

A quick back-of-envelope calculation indicates this might cost ~3.6 Eth per day in gas under current gas conditions, or proportionally more/less under other conditions, if they made a single 0-Eth transfer to an OFAC EOA address once per slot (7200/day).

If we assume 5% of all blocks might be accessible to this relay but not the regular FB relay, that’s 360 blocks per day that a competing relay or builder might hope to have shut down. So breakeven would occur at around 0.01 Eth per block of MEV/tip profit; any competing entity which was consistently seeing more than that in profits per accepted block, but less than the average FB block, would be incentivized to conduct such an attack. And the lower that percentage of blocks, the higher the breakeven point.

There certainly are many block builders (and relays?) that consistently see 0.01 Eth < x < avg(FB) of profits per block, so you’re right that this attack seems likely to be worthwhile for some participants. But from a game theory perspective, FB would be spending presumably << $1k per day in infra costs to cause one of its competitors to spend at least ~$5k extra per day. Maybe that type of dynamic isn’t necessarily desirable to FB, but the attacker would fundamentally be doing it to themselves, and it would increase FB’s relative competitiveness versus not deploying this new relay.

For the targeted approach, a competitor might wait until it had a bid that was getting outbid by the new FB relay in an auction, and at that point, release its poison OFAC tx to the new FB relay to put it out of commission. This attack would be much cheaper than the continuous approach, but there would be a possible mitigation here:

The new relay would have already relayed at least one bid to the proposer (and everyone else watching the auction), in order for the competitor to know to do their targeted attack. So the poison tx, and a built block containing it, would be at a considerable disadvantage timing-wise. And more than that, I think it would be a fair stance for the new relay to not retroactively implement its self-censoring for the slot. I.e. it could make bids so long as it in good faith was not aware of any censorable tx for the current slot. As far as I know, bids are not retractable, so this would have to be the behavior in any case.

Basically, the relay would follow its usual procedure as long as it was unaware of any censorable tx for the current slot. The moment it heard about one from one of the submitted blocks, it would immediately stop accepting that or further blocks for the slot. But previous bids that it had placed before that point would still be in place, and perhaps could even continue to be bid up for that slot.

So unless the competitor genuinely had a more competitive block than that last bid block from the new relay at the moment it heard about the poison tx, it would still lose out to the new relay’s bid.

Of course, in some cases a censorable tx (poison or otherwise) would be known about from the beginning of the slot, and in those cases, the behavior would be as originally described (the relay does not submit a block for that slot.) But if it were a poison tx, it would certainly have to be of the ‘continuous and expensive’ variety, and not the ‘targeted’ variety.

Overall it still seems like this would be a worthwhile avenue to explore further, but you’re 100% right that the complexities in an adversarial environment are not trivial and would benefit from further thought.

4

If you’d set a very low transaction fee, the tx could stay around in the mempool for a long time, and wouldn’t need to be renewed for each slot.

Then the question becomes with which heuristics would the self-censoring relay decide whether the conditions to not deliver anything are met, and those wouldn’t be publicly auditable becaue in the end you still have to trust the relay :thinking: