Relay-Builders and Vertical Integration in MEV-Boost
The following post is adapted from a Reddit post to the r/ethfinance daily thread by /u/austonst, one of the Aestus team members. It has been updated and adapted for this format.
Introduction
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. Almost all existing relays are running their own builders for profit. For a fun exercise, check out the Builders -> Relayers chart on mevboost.pics, pick a relay from the drop-down menu, and see for yourself how dominant relay-builders are.
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.
Relay-Builder Attacks
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.
This vertical integration is a known concern, but hasn’t gained widespread awareness among the Ethereum community. The best reference for the different types of vertical integration in MEV-Boost was compiled by chayoterabit on the Flashbots Collective forum. It is often mentioned in comprehensive analyses of the flaws in the MEV-Boost space, such as this post by SajZ. It is occasionally discussed on Twitter as well.
Let’s list out some potential attacks that relay-builders could carry out. These have names I’m making up on the spot, with “you” being the relay-builder:
MEV Copying
Third-party builders have submitted blocks to your relay with lots of tasty, juicy MEV. Simply copy the most valuable transactions from the third-party builders’ blocks, but make it so you keep any value that is not sent to the proposer. Make sure your bid to the proposer will legitimately win the auction, but keep the rest of the MEV for yourself.
Done naively like this would be immediately detectable by the third-party builders, who would notice the blatant copying or inclusion of transactions that they had received from private order flow. You can be more subtle by implementing fuzzing to make the transactions less obviously copied, and only copying a set of recognized searcher strategies using transactions from the public mempool. Done properly, third-party builders may only catch the attack through long-term analysis.
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. A more blatant version of this attack, in which you simply ignore other builders’ bids if they happen to be more valuable than your own, would be more easily caught.
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. A current mev-boost-relay PR would add additional timing information to provide more transparency here, assuming relays report this information honestly.
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.
Conclusion
I want to be clear that 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). Our mission with Aestus is not just to provide a neutral relay, but to push the community and space as a whole towards greater neutrality, so we will continue to try to hold relay-builders accountable and hope others do the same for us.
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.
