Unmasking the Ethereum Uncle Bandit
Last week on April 14th at 10:06am PST, I received a private Discord message from a long time Alchemy user Robert Miller.
Robert is a product manager on the Flashbots team, a project dedicated to exploring and understanding Miner Extractable Value (MEV). Because Robert and I had been Discord friends for quite some time, I knew that when he said “it’s really important”, it must have been really important.
A quick note on MEV and Flashbots: Miner Extractable Value is a measure of the profit a miner can make through their ability to include, exclude, or re-order transactions from the blocks they produce. The more conventional MEV is through transaction fees and block rewards while the unconventional MEV can be through transaction reordering, insertion and censorship. Flashbots is a research and development group that builds tools for understanding and executing unconventional MEV extraction.
So Robert continued on to explain to me what the situation was: his team needed to see all transactions that were included in this uncle block.
The first question you might be asking yourself is, what the heck is an “uncle” block?
Uncle blocks are created when two blocks are mined and broadcasted at the same time (with the same block number). Since only one of the blocks can enter the primary Ethereum chain, the block that gets validated across more nodes becomes the canonical block, and the other one becomes what is known as an uncle block. Uncle blocks are recorded and accessible from the chain, but they have no impact on the canonical chain and their transactions do not change any state. Unlike Bitcoin, in the Ethereum system, miners still receive a block reward for discovering the uncle block.
So if uncle blocks aren’t relevant to the main Ethereum chain, why would Robert and his team want to see all the transactions on this uncle block? Well, to put it in Robert’s own words “it’s a little sci-fi”.
What happened here was both a case of bad luck and savvy opportunism.
One of the Flashbots users sent a bundle of transactions, otherwise known as a sandwich. Sandwich transactions must be included in the order submitted and all transactions in the bundle must be included or none should be. This is (normally) guaranteed through miners that run MEV-Geth, a fork of Geth that allows users to submit bundle transactions directly to miners, avoiding the public mempool and risk of getting their transactions frontrun.
However, in this case, something a lot more complex happened.
The way sandwich transactions work is that Flashbots users, otherwise known as searchers, will send bundles of transactions directly to an MEV-Geth miner (it’s actually a bit more complex than this, involving MEV-Relay but those details aren’t super relevant for this story), in addition to a payout to the miner for including the transaction bundle on their block.
These bundles often include the searcher’s transactions in addition to other Ethereum user’s pending transactions picked up from the mempool.
You might be wondering, how can a searcher send someone else’s transactions? To put it in simple terms, the searcher is basically saying, “Hey miner, I’m giving you my transaction and this other transaction that’s already in the mempool and I want you to include them in your block in this exact order. In exchange, I’ll give you a cut of whatever I’m getting from this operation.” The searcher’s own transactions never get sent to the mempool.
Having guaranteed ordered transactions can result in extremely valuable arbitrage opportunities for the searcher, and these miners are incentivized to include the bundle because they often receive 80–90% of the profits gained by the searcher.
Okay so now that we understand a bit about how Flashbots and transaction bundles work, what exactly happened last Wednesday?
A Flashbots user was doing what they normally do, their bot picked up a large Uniswap transaction in the mempool and decided to bundle their transaction with that one in order to perform an arbitrage. The bundle looked like:
- Searcher buys AMP using WETH from the WETH/AMP Uniswap pool (driving up the price of AMP)
- Random Uniswap user buys AMP using WETH from the WETH/AMP Uniswap pool (further driving up the price of AMP)
- Searcher sells AMP to the WETH/AMP Uniswap pool (at a much higher price than they bought it for)
In an ideal world this is all fine and dandy and the searcher makes a profit from the price discrepancies and the miner who receives the bundle gets a cut from that profit. But instead the unlucky situation happened and the miner actually ended up mining an uncle block!
Since transactions included in an uncle block don’t actually get executed on the primary chain, they are essentially pseudo-mempools, containing transactions that are all valid but haven’t been mined yet.
And if you can connect the dots you know what this means: another arbitrage opportunity.
A third actor, who we’re calling the Uncle Bandit, saw the uncle block bundle transactions as an opportunity and decided to send a bundle of their own to the main Ethereum chain including these three transactions:
- Transaction #1 from the uncle block: Searcher buys AMP using WETH from the WETH/AMP Uniswap pool (driving up the price of AMP)
- Uncle Bandit buys AMP from Sushi Pool (where the price was not affected)
- Uncle Bandit sells AMP in Uniswap pool (at a much higher price than they bought it for)
So how did the Flashbots team figure it all out?
The roadblock in this discovery was not being able to see all the transactions contained in the uncle block. Unlike with normal blocks, Etherscan doesn’t display the transactions included in the uncle block (see uncle block screenshot above).
In order to verify that the original searchers bundle did indeed land on an uncle block, the Flashbots team needed to make a separate request to fetch the transactions. This is when I sent over an eth_getBlockByHash request using Alchemy’s Composer tool for the uncle block, revealing all three transactions from the initial searcher bundle.
Someone had actually pulled off an uncle block attack, likely for the first time in history!
And that’s the tale of the Uncle Bandit Attack.
As we all know from the infamous Ethereum as a Dark Forest piece, mempools have always been known to be vulnerable to frontrunning, arbitrage, and MEV operations. However, using uncle blocks is a novel strategy for these types of exploits, and one that we might see more of in the future.
Like most blockchain concepts, this space is fast moving, and Alchemy is excited to partner with teams like Flashbots to work on innovative solutions. Look out for more Alchemy products in the pipeline to help uncover the mysteries of the Dark Forest.
If you’re curious about learning more or getting involved, reach out in the Alchemy Discord or the Flashbots Discord. If you want to start playing around with stuff you can make an Alchemy account for free and check out the Flashbots Github.
