Dr. Reorg or: How I Learned to Stop Worrying and Love MEV
Before reading, I highly recommend checking out our last article on MEV, Flashbots launch article, and this podcast for background knowledge on the Flashbots ecosystem and MEV. This article discusses some of the more intricate details around Flashbots, MEV extraction, and their interplay with Ethereum consensus.
On June 29th, 2021, an interesting idea came up in the Flashbots Discord:
Using Flashbots to incentivize censorship is somewhat terrifying. It would also be antithetical to Flashbots’ mission to mitigate the negative externalities caused by MEV. Nonetheless, as another community member quickly noted, such censorship would be economically infeasible, as it would require paying more than the searchers or users who wanted to include the same transaction:
Crisis averted!
Well, not exactly. While Austin’s original idea may not have necessarily been cause for panic, a follow-up idea by another community member, Nathan Worsley a few days later posed a much more troubling question.
After a bit of discussion, this initial idea quickly evolved into this:
What followed these posts is a tale involving chaotic Twitter outrage, brilliant independent hackers, and some of the finest examples of why social consensus can be just as important as algorithmic consensus in crypto.
Let’s dive in.
GHOSTs and Time Traveling Uncles
Ethereum, in its current state, is a Proof-of-Work system using Nakomoto consensus; this means that network consensus between miners securing the network relies on raw computing power. This also means that transactions only have probabilistic finality; the longer it’s been since a transaction was included in a block, the less likely that transaction is likely to be reverted. Thus, it is usually recommended that users on Proof-of-Work blockchains wait before they can consider a transaction “finalized”. On Ethereum, it’s usually safe to assume that a transaction is finalized after 7 blocks.
In Proof-of-Work systems, it is possible that two miners both mine valid blocks and attempt to propagate those blocks to the network at around the same time. What ends up happening is the network is left with two valid blocks, but only one can be appended to the chain before the race to mine the next one begins. This means one must necessarily become “stale”- or discarded. This isn’t great for two reasons. First, the miner who produced the stale block wasted their resources for nothing! Second, this leaves networks prone to centralization risk as miners rush to make sure they have enough hashpower to avoid stale block production. For more on this, check this out.
On the Bitcoin network, the 10 minute block time and sub-minute propagation times makes the probability of stale blocks fairly low. However, on Ethereum, where block times are much shorter- around 12 to 13 seconds- the probability of producing stale blocks is far, far higher. This makes the aforementioned issues of resource waste and centralization far more relevant. Ethereum gets around this by using a modified version of the GHOST (Greediest Heavy Observed Sub-Tree) protocol. The GHOST protocol was designed in 2013 to solve the precise issue of stale blocks in fast block time chains and the basic premise is simple: the “longest” chain accepted by miners is the chain that has the highest cumulative Proof-of-Work difficulty including stale blocks that are descendants of the current block’s ancestors. Such blocks are referred to as “uncle blocks”. Ethereum uses a variant on GHOST that uses the same principle of selecting the chain with the longest difficulty but it does NOT include uncle blocks in difficulty calculations. It further allocates some block rewards to uncle blocks, leaving transactions in these blocks available to access but NOT including those transactions in the main chain. The process of adopting a new “longest” chain and disregarding stale blocks are called chain reorgs.
So how does this relate to MEV?
There are two primary ways in which network users might be incentivized to take advantage of the situations arising from uncle blocks and reorgs. The first, which already occurs in practice and is considerably less threatening, is what is referred to as an uncle bandit, uniquely enabled by Flashbots. As of mid-July 2021, Flashbots has around 86% of Ethereum’s hashrate using their MEV-Geth client; However, it remains possible that a Flashbots bundle gets included in an uncled block, creating the opportunity for an uncle bandit. This is originally detailed in a thread by Robert Miller. Since transactions included in uncle blocks do not change Ethereum state, but do remain visible to others and are valid transactions, a savvy MEV searcher can take a look at uncled Flashbots bundles and issue a new bundle with some of the transactions from the original bundle along with their own transactions to capture arbitrage opportunities on the main-chain,
Uncle bandits alone are not protocol-threatening; ultimately they’re the result of bundles getting probabilistically included in uncle blocks and someone else seizing the sidelined opportunity. However, the nastier older cousin of the uncle bandit is the time bandit, and it is more concerning. As detailed in MEV’s seminal research paper, time bandits are a theoretical attack that occur when rewards from MEV begin eclipsing block rewards. The premise of a time bandit attack is that a miner that can gain access to large amounts of Ethereum hashrate can turn back the clock on Ethereum by attempting to remine previous blocks, capture all the MEV in those blocks, and reorg the chain. The easiest way to do this is by renting out 51% of the hashrate; in doing so, attacker would go back a certain number of blocks, capture all MEV profit between now and those blocks in the past, and use that profit to subsidize the attack.
As shown above, MEV profits are becoming an increasingly large part of miner’s economic rewards, making the threat of time bandit attacks and reorgs more likely. It also means that it should theoretically be possible to actually bribe miners to reorg the chain. The strategy would be to wait for other users to submit profitable bundles, pay miners to reorg the chain, and then conduct an uncle or time bandit for profit. This is where our drama begins.
Chaos Magicians and the Nuclear Reorg
After Nathan’s initial ideas for a a modified MEV-Geth that would enable incentivizing reorgs for uncle/time bandits, searchers immediately took to developing the software, while crypto Twitter went into heated debate. Much of the community sentiment is accurately summed up by this meme:
Popular Twitter account MEV Intern raised concerns over the introduction of such software without the tools to defend against it; after all, while such incentivized reorgs were technically allowed within the bounds of consensus, they did also destabilize the protocol and perhaps stress tested Ethereum too much by creating scenarios in which security assumptions around miner behavior were challenged.
Nonetheless, Pandora’s Box was already opened.
It wasn’t long until two high profile MEV strategists and researchers — Edgar Arout and 0xbunnygirl — posted on their own individual versions for “requests for reorgs”.
Edgar’s repository for this was a fork of the MEV-Geth client created by Flashbots. The repository has since been made private but the codebase was a work in progress that would enable MEV searchers to request a reorg back a certain number of blocks, omit certain transactions and add new ones including payment to the miners.
This in turn inspired 0xbunnygirl to spin up a smart contract on Ethereum that would enable easy payment rails for this. The Request for Reorg contract would enable users to attach a request with an associated reward for a miner and the block to which they want to reorg back to. The miner would then perform a time-bandit and include the transaction that enables them to claim the reward in the reorg along with the desired omitted/included transactions, and slash the miner for dishonest behavior. Of course, this contract was similarly a proof-of-concept; the miner could decide to be dishonest and censor the slash transaction anyways when rolling back state, and there was no codification of including a specific transaction or censoring another transaction in the actual contract.
And then…
Nothing happened.
Even without functional tooling, people were not happy with these developments. Efforts to create reorg incentivization systems sparked outrage from many prominent researchers, developers and leaders in the space. Edgar would end up shelving the repo. Flashbots issued an official announcement denouncing reorgs as negative-sum, highlighting that they led to scenarios that lead to game-theoretic instability, systemic risk and potentially less long-term revenue for miners. In response to the assertion that a pool like Ethermine might just build their own request for reorg system, they responded with the following:
Social consensus, not algorithmic consensus, had halted the development of tools that seemingly jeopardized Ethereum, and that was that.
All quiet on the crypto front.
We Are All Going to Make It, Anon
While nothing threatening may have ended up coming from all the development and buzz around requests for reorgs, the question still remains: how much do we have to worry about time/uncle bandits, both now and in the future?
Well, it turns out, perhaps not much. Let’s look at why.
Economic Considerations
MEV Researcher 0x9116 did some great back-of-the-napkin expected value math for where reorgs might make sense. As a quick recap of the thread, assuming 30% of the hashrate (Ethermine has around this amount) would need to be over 3.3 times the total of fees, plus 0.58 ETH.
Let’s extend this example a bit further. Given that controlling 51% of the network in a Proof-of-Work system enables total network control (and thus maximal MEV), let’s look at how the calculus changes when we have just below this, or 50%. In this case, we can use the same framework as the thread above, with a few modifications. Instead of assuming that we (as a miner looking to time-bandit) can definitely capture the rewards from the next two blocks, as is originally assumed, we loosen the assumption and probabilistically weight these outcomes. The base block reward is 2 ETH.
Let there exist a block A that we haven’t mined, we have 50% of the hashrate, and represent the miner payments for A as X, and the expected MEV payments as Y. We’re looking to mine two blocks (either for the time bandit, or honestly). If we mine the next two blocks on top of A, we have a 50% chance of mining each independently, so the expected payoff is 0.5 * (4 ETH + 2Y) or 2 ETH + Y. If we attempt a time bandit (and, as 0x9116 originally assumed, quit if the next block B is mined):
- With 0.5 probability the next block B is mined before we can uncle A and replace it with A`. We’re then back at square one, where we just look to mine the next two blocks fairly. The expected payoff in this case is 0.5 * (0.5 * (4 + 2Y)), or 1 + 0.5Y.
- With 0.5 *0.5 = 0.25 probability A` is mined but B is then mined before we can mine B`. A` gets uncled to B, getting a 1.75 ETH reward, and you look to mine the block after B. The expected payoff in this case is 0.25 * (1.75 + 0.5 * (2 + Y)) or 0.6875 +0.125Y.
- With 0.25 probability, we mine both A` and C`. The expected payoff in this case is 0.25 * (4 + X + Y) or 1 + 0.25X + 0.25Y.
This leads to an expected payoff of 2.6875 + 0.875Y + 0.25X, which must necessarily be greater than the expected payoff of honestly mining the next two blocks. This results in the necessary condition that X > 0.5Y — 2.875 ETH. This means even with close to 51% of the hashrate, X greater than half the MEV captured in the current block minus 2.875 ETH. While this may occur occasionally, the cost of renting 51% of the network is about $1.1M for 1 hour, as of mid-July 2021. This means renting 50% of the hashrate (to maximize the likelihood of a time bandit without fully hijacking consensus) would cost around $1M. Thus for a reorg to be worth it, X > $1M USD or, at the time of writing this, around 550 ETH. As shown in the graph below, the daily total extracted MEV is usually in the few millions of dollars, so the cost of attempting to rent 50% to launch a time bandit would more than likely far outweigh the gains.
Of course, this isn’t to say there aren’t cases where there aren’t single blocks that can justify this cost. Events like the time where Justin Sun almost got liquidated on a $1B position in Liquity and had to pay $300M to avoid losing his position would prevent an opportunity for a reorg at the tip of the chain that would be profitable enough to subsidize renting 50% of the hashrate. However, it is also highly unlikely that a single attacker would be able to rent out 50% of the hashrate — as it stands, the amount of Ethereum hashrate available for rent at any given time on NiceHash is usually below 10%.
If you want to play around with the parametrization here, I made a tool that would let you determine the expected payoff of honestly mining two blocks versus attempting a time bandit on the most recent block, using the share of network hashrate available, the total miner payments in the block to be time-bandited, and the expected miner payments for future blocks:
On the flip side, if it is possible to economically incentivize reorgs, it should similarly be possible to disincentivize it.
Developer Daniel Goldman cheekily did just this by flipping 0xbunnygirl’s initial Request for Reorg contract on its head; called Deorg, it would allow any user to create bounties to be paid to miners at a block in the future, slashing the reward if they were found to be malicious (Deorg does in fact have codification of good behavior by requiring that the hash of a block at a certain height is invariant after a certain number of confirmations, which Daniel kindly pointed out), but it does illustrate that most economic incentives for reorgs can be reengineered.
Another potential way to mitigate the risk of reorg is to instead have a sort of “fee smoothing” approach (as mentioned by Ivan Bogatyy at the MEV.wtf Virtual Summit), where, as an honest miner, you pay MEV forward to whoever mines on top of you. The design space here is as plentiful as the one for incentivizing reorgs; as Tom put it in our last article on MEV, “For every footgun that is discovered, 1000 footgun salespeople and 1000 footgun body armor manufacturers will bloom.”
Finally, its worth noting that reorgs and selfish mining can devolve into recursive, negative-sum games that can actually cost miners, instead of lead to profit. If all miners are just waiting for others to find MEV and then reorg, networks can get stuck in a sort of limbo that creates long transaction finalization times and adversarial back-and-forth games that decrease profit as miners continue to attempt to time bandit opportunities already seized by other miners.
A paper from IC3 researchers that used reinforcement learning (RL)to simulate selfish mining on the Bitcoin network and pitted models together found that relative rewards went down when all agents were using selfish mining strategies (time bandits, sans the MEV portion to capture block rewards and fees).
Similar effects would most certainly be seen on Ethereum. It turns out that reorg strategies would only work so long as a few people were doing them; too many cooks spoils the broth! This doesn’t even encapsulate the reflexive price action that might occur should reorgs destabilize consensus. The PR fallout from a chain being exposed for constant reorgs and greedy miners would more than likely adversely impact that chain’s token price on market and potentially other assets both built on top of it and on other chains via beta. This only hurts miners — and the ecosystem — in the long run.
Proof-of-Stake and Social Consensus
As already mentioned, the outcry against development of the MEV-Geth Uncle Bandit Fork or Request for Reorgs were powerful examples of social consensus coming into play. Social consensus has always been part of crypto, with prominent examples such as Binance deciding not to incentivize the rollback Bitcoin to revert a hack or even more fundamentally, mining pools deciding to stay below 50% hashrate in the spirit of decentralization!
As Ethereum moves towards Proof-of-Stake with Ethereum 2.0, MEV doesn’t go away, and neither do the risk of reorgs. Although Proof-of-Stake does give absolute transaction finality, it only occurs after 2 epochs (6.4 minute long periods in which up to 32 blocks are proposed/attested, with proposers known 1 epoch before, and attesters 2), there are scenarios in which reorgs can happen within the ~13 minutes that it takes transactions to finalize. However, by restricting the time window, among other things, reorgs become much more difficult.
Yet, Proof-of-Stake’s greatest insulation against reorgs is arguably not the absolute finality after two epochs, but rather the notion of “identity”. Given that proposers are known, validators known to act in bad faith can be blacklisted from participation, the Flashbots network, etc. Furthermore, as larger existing miners move towards staking from mining assets, like Ethermine, and large exchanges and platforms like Lido and Kraken come to dominate the validator landscape, it becomes increasingly likely that such institutions will not risk the reputation damage that would arise from reorgs or even collection of MEV fees (both as a point of social and regulatory contention).
The MEV Endgame
It’s clear MEV isn’t going anywhere on Ethereum anytime soon. But, that also may not be a terrible thing. MEV, in all likelihood, is not going to lead to constant reorgs that blow up Ethereum, both now or in the future. What MEV has done, however, is push forward the design space around creating fairer, democratized financial systems. The creation of research collectives like Flashbots, advancements in fair sequencing for transactions, and the application of cryptographic techniques like zero-knowledge proofs and threshold decryption at both the protocol and application layer have all arisen in an attempt to mitigate and democratize MEV. In the long run, the cryptoeconomic systems that we know and love are all the more robust because of it. Events like the reorg drama are healthy reminders that the crypto community can never take the assumptions of our systems for granted as we build the future of finance, that we must continue to constantly innovate in pursuit of antifragility, and that we have the right community and talent to do so.
Many thanks to Haseeb Qureshi, Tom Schmidt, and Celia Wan from Dragonfly Capital and Stephane Gosselin from Flashbots for extensive feedback on this article.
