Ethereum Relay-Builders: Block Builder and MEV-Boost Relay Entities

This was originally posted by /u/austonst in the ETHFinance Daily thread, and was reposted here with permission.

MEV-Boost relay transaction censorship has gotten a good amount of attention since the Merge, and for good reason. Fortunately, word has gotten around and the trend is improving. So I think it’s time to emphasize another problem in the relay space: relays who also run builders. Relay-builders as opposed to independent relays? I need a better term for this.

This is informed by my time working on the Aestus relay, and while I believe our relay can help with this problem, I hope you can trust that my goal here is not marketing. We don’t make any money off this relay anyway. In a world without relays, proposers and builders would have to trust each other directly: depending on the implementation one would always be able to steal MEV from the other. Relays sit in the middle and take on all that trust. As long as the relay is trusted, proposers and builders each enter a trustless relationship with the other.

However, a malicious relay, working with one side or the other, can execute all the attacks they were supposed to prevent. A relay working with a builder can steal MEV from a proposer or the other builders, and likewise, a relay working with a proposer can steal MEV from a builder.

Now let’s bring relay-builders into this

An entity that is running both a relay and a builder has a clear conflict of interest. Compromising the relay’s neutrality by working together with their builder could immensely improve profitability. Let’s list out some potential attacks that relay-builders could carry out. These are in roughly increasing order of subtlety and with names I’m making up on the spot, with “you” being the relay-builder:

Single-Block Copying

Some third party builder has submitted a block to the relay that is more valuable than the block your builder made. Simply copy all the transactions from the third-party builder’s block, but make it so you keep any value that is not sent to the proposer. Send a bid to the proposer with your block instead of the other builder’s. A competent builder should be able to detect this and trash your reputation.

Ignoring Other Builders

A third-party builder submitted a block more valuable than your builder’s block. You should pass on the third-party bid to the proposer. Instead, pretend you didn’t see it. Submit your builder’s bid instead. Done naively like this, the third-party builder should be able to catch it.

Multi-Block Copying

Multiple builders have submitted blocks with valuable MEV. Build your block from the most valuable transactions from each of them. Make sure your bid to the proposer will legitimately win the auction, but keep the rest of the MEV for yourself. I don’t know if builders would detect this, might take some analysis and time.

Obfuscated MEV Copying

Same as with the first two copying attacks, but with intent to be subtle about it. For example, if a third-party builder/searcher has a truly novel source of MEV extraction that only they know how to do, they’d recognize if it were stolen, so only copy MEV that can be identified as a recognizable strategy and is unlikely to come from a private mempool. Implement some fuzzing, make your copied MEV transactions slightly different so as to give plausible deniability that maybe your builder found that MEV on their own. Might be hard to detect.

Auction Manipulation

Anyone can check the best current bid through the relay API, which is a problem in itself, but the relay has particularly low-latency access to this info. In case a third-party builder only very slightly outbids your builder, quickly create a new block with a winning bid and propose that instead. The relay has some wiggle room with timing to make sure your builder can always outbid. Catching this would require long-term analysis and may be covered by plausible deniability or obfuscation.

Block Timing Manipulation

A third-party builder submitted a block more valuable than the one made by your builder. Give your block priority in the relay’s block validation system, or better yet, don’t waste time validating it at all (you made it, you trust it). Make your competitor’s block low-priority for validation or otherwise stall it so it’s less likely to be ready when the proposer asks for the best bid. Hard to detect, covered by plausible deniability, and current data APIs don’t expose enough timing information to help with detection or can be manipulated. This could be an actual concern.

Builder Colocation

Most builders will make ~1 submission per second, with value increasing over time as more bundles and tx’s arrive. Builders that are geographically closer to the relay, with lower latency, will tend to have slightly higher-value blocks because of it. If a relay and builder are running in the same data center, under the same account/project, on a high-speed private LAN, that will give them a competitive edge. This maybe doesn’t quite qualify as an attack, but a neutrality concern at least.

I have no reason to believe existing relay-builders are malicious and carrying out these attacks

But why accept the possibility that they may some day occur? Why connect to relays that require extra trust assumptions when there are alternatives?

Right now, Ultrasound and Agnostic are the only relays not operating their own builders. Aestus is temporarily running a builder, but it doesn’t extract MEV, doesn’t take any profit, and only operates until we get a reliable set of third-party builders connected (otherwise we might not have any blocks for connected proposers). I would encourage everyone to direct their validators and builders to those relays and to ask existing relay-builders to consider only running one or the other. I’m grateful to the early relay-builders for getting us off the ground, but now we can start to hold the space to a higher standard.