$25M MEV Exploit Teaches a Valuable Lesson About Relay Providers
Sometimes less is more, at least when it comes to relay providers
Fer Gregory/Shutterstock modified by Blockworks
It’s like an episode of the long-running TV crime drama series, CSI.
Gathered in a research facility – usually set to an energetic rock anthem that belies the boredom of lab work — a forensics team busily fills test tubes and draws samples from the latest victim of some horrific event. The researchers gather to share complicated theories and argue about how the perpetrators must have performed this episode’s terrible deed.
Constructing a complex story, they work their way back through the evidence and continue debating possibilities. But soon, in a span of about 40 minutes plus commercials, following some investigative work, a few plot twists – and perhaps a car chase – the team arrives at a dramatic conclusion and solves the crime, learning a valuable lesson in the process.
No car chases came to fruition during a recent episode of Bell Curve. Nevertheless, Hasu, strategy lead at Flashbots, and Matt Cutler, CEO and co-founder of Blocknative, had their hands full with an investigation into the forensics of an MEV exploit that seized $25 million in funds from bots on the Ethereum network.
In this particular case, the evidence pointed squarely at the exploitation of a flaw in the MEV relay mechanism – and punctuated the fact that only one little bug in the relay system can potentially put the entire system at risk.
Hasu broke down the details of the exploit. The way it was supposed to work, he says, “is that the relay shows the block header to the proposer. And then the proposer selects the highest block header and signs it.” After receiving the signature, “the relay reveals the block body to the proposer and the proposer can then publish the full block.”
“In this case,” Hasu explains, there was a bug “that caused the relay not to check whether a particular part of the validator signature was actually valid.”
The validator sent an invalid signature, failing to make a full block, “so the relay couldn’t publish the block to the network.”
The inevitable plot twist
When the relay released information about the MEV transactions to the proposer, “the proposer had all of the transactions,” Hasu says, so “they could construct their own block and steal the MEV.”
This heist alone, however, would have only resulted in a trivial amount of funds being stolen, Hasu explained. What takes this scheme to the epic level is the next step in the story arc.
The exploiters placed “very specifically parameterized traits,” Hasu says, “in very low liquidity Uniswap pools that baited very specific sandwich bots to make very risky trades.” They then re-sandwiched these particular trades to drain the sandwich spots of a fortune.
“You had this explosive cocktail where four sandwich bots lost, collectively, around 20 million dollars in that transaction.”
“Clearly, whoever did this,” Cutler comments, “it was well-orchestrated. It required some time to set up and test. And they had a very deep understanding of how this stuff actually worked and where there were gaps.”
Case closed?
Upon solving the mystery, the pair then discussed the lesson to be learned from this exploit episode.
Cutler points out that the centralization of relay providers is partly at fault for the incident. “These are the sorts of things that happen when you have a small number of actors who are responsible for large sets of the network, handling lots of value, and you have very clever adversarial actors out there who are looking to gain an advantage, right?”
Because of the need for searchers to trust relay providers, Cutler argues, “they can sometimes maybe not be as careful as they should be.”
“And that trust, when it gets pierced,” he says, “there can be significant economic consequences of that, which is why we all go for trustless, permissionless systems.”
“That reduces the likelihood of any of these sorts of situations happening.”
Hasu counters Cutler’s argument saying that a larger number of relay providers does not, in fact, reduce risk.
The validator, he explains, is free to choose from any available relay provider, so it only takes one faulty relay to successfully attack the entire system. Adding more relay providers could do the opposite, he says, actually increasing the probability of vulnerabilities.
A social layer must be considered, Cutler retorts. In an “alternate timeline” of many relay code producers, Cutler suggests, “perhaps one of those code producers says, ‘Hey, I noticed that we’re not checking everything here.’”
“Hey, everybody, this strikes me as something that’s vulnerable.”
“And we all go, ‘Oh, good catch. Thanks.’”
It’s a case of getting more eyes on the subject, Cutler says. “The more people who are thinking about it, the more likely gaps are to be spotted.”
Or, Cutler jokes, “Just write code that doesn’t have bugs. We’ve been saying that for 60 years now, right?”
But it’s never as simple as it seems in any forensic drama. “The reality is, Cutler concludes, “this stuff is complicated.”
Don’t miss the next big story – join our free daily newsletter.
