| jmcph4 |

MEV Unbundling

If thou seest the oppression of the poor, and violent perverting of judgment and justice in a province, marvel not at the matter: for he that is higher than the highest regardeth; and there be higher than they.
— Ecclesiastes 5:8 KJV

MEV unbundling attacks are a family of attacks that violate the atomicity guarantees provided by PBS protocols. In all such attacks, malicious proposers seek to steal MEV from honest searchers by pulling apart their bundles — making them the ultimate victims of all attacks in this family1. Whilst not strictly necessary, most realistic deployments of such attack strategies will induce atypically large MEV opportunities in an effort to both maximise attacker payoff and improve the execution of the exploit (by increasing the confidence in the viability conditions holding and improving the speed of which they arise).

To date, all documented MEV unbundling attacks are instances of so-called double-signing attacks[1]: attacks that necessitate the malicious proposer violating the Ethereum consensus protocol by equivocating. Such attacks have received a great deal of attention amongst client developers, relay operators, and the broader Ethereum research community[1][2][3][4][5][6][7][10].

Original Attack

This is the original attack that occurred on April 2nd 2023 as described by Flashbots themselves[2].

Exploit Description

Agents

Procedure

  1. Mallory broadcasts "bait" transactions — transactions that result in large MEV opportunities — in order to induce searchers to capture the generated MEV
  2. Mallory initiates the protocol by requesting an execution payload from Alice — submitting a commitment (i.e., a correctly signed, but invalid block header) as part of this request3
  3. Alice assembles a block using this bogus block header and the block body she always had and broadcasts this bogus block to the rest of the CL network
  4. Alice submits the legitimate block body (containing the transactions Alice has assembled from the downstream builders) to Mallory
  5. Mallory uses these transactions to steal the MEV contained within them by unbundling them (i.e., violating the atomicity guarantees provided by PBS protocols)
  6. Mallory broadcasts this new block to the CL network
  7. Because Alice received a bogus block header (in step 2), when Alice broadcasts her block, it is (correctly) rejected by the other BNs in the network
  8. Consequently, Mallory's legitimate (but ill-gotten) block she broadcasted (in step 6) is then left uncontested and is canonicalised
  9. Mallory is then slashed due to having equivocated in step 8
Timing

Mallory must ensure that they initiate the protocol as the victim transactions are in-flight. This is because the searchers (overwhelmingly sandwich bots) are essentially being sandwiched themselves. In Ethereum, validators have one epoch's (so approximately six minutes') worth of advance notice of their becoming eligible for proposal.

Viability

The attack is economically viable iff. the cumulative MEV value stolen is greater than the cost of being slashed for equivocation.

Attack Analysis

Only one known exploit of this vulnerability is known in the wild. It's also certainly the most notable as well.

Attack on April 2nd

This sequence is largely reproduced from the source material[2].

In this attack, the attacker successfully exploited the Ultra Sound Money relay in order to extract around $20,000,000 USD from victim sandwich bots.

On , nearly two weeks prior to the attack, the attacker registered validator #552061. This was financed via Aztec in 0x6ac3d258077ca8330ede7e4323329e2f629d88639b25975796239d6219cc0083.

  1. In block 16964665, the attacker deploys two bait transactions: 0xd534c46ba5a444e886feedeb4dbe698b68be74a65356b5cc46c49f2dd07f7edf and 0xd7bb6353f03a7ee1bf20d553e2df77a2cef44717dbe4afc38737540189d0c305. The bait took the form of infinite slippage token swaps. These got detected by the victim searchers and they submitted sandwich bundles to the Builder0x69 builder. Builder0x69 then forwarded these onto the Ultra Sound Money relay.
  2. The attacker then requests an execution payload from the Ultra Sound Money relay. The attacker formed an invalid block header by setting both the state and parent roots to zero and committing to these.
  3. The Ultra Sound Money relay used this bogus header together with its exection payload to publish a bogus block.
  4. The Ultra Sound Money relay (incorrectly) reveals the execution payload to the attacker
  5. The attacker assembles its own block using the revealed execution payload in such a way that it steals all of the victim searcher' MEV for themselves
  6. The attacker proposes this block in slot #6137846
  7. The Ultra Sound relay's local Beacon Nodes correctly reject the bogus block that it derived from the attacker's initial block header
  8. The attacker's block is left uncontested
  9. In slot #6142320, the attacker is then slashed for equivocating by validator #1385754

Mitigation

The crux of the vulnerability is Step 4. The relay should only reveal if the proposer has committed to a legitimate block. This involves checking whether or not the block is:

Currently, Lighthouse handles this by a hotfix applied in rapid response to the initial, aforementioned exploit. Prysm maintained a similar branch as well.

At the protocol-level, the Beacon API specification was updated to include additional endpoints that facilitate such block validation prior to broadcast. Namely:

Lighthouse support for these new Beacon API routes landed with release Priest Witherspoon. The associated PR contains various test cases and other context in its notes.

One difficulty with the realistic deployment of such mitigations is that of performance. Honest proposers may be uncessarily penalised due to the implementation of relatively aggressive cutoff times for payload receipt[2][7][8][9]. Despite this, the overwhelming majority of traffic occurs within the first four seconds into any given slot (see Figure 1).

Figure 1: Distribution of getPayload arrival times to (presumably honest) proposers[1]

RPC-based Attack

This variant exploits the attacker's superior peering compared to the target relay and is due to Sproul[3].

Agents

Procedure

This sequence is largely reproduced from the source material[3].

  1. Mallory broadcasts "bait" transactions — transactions that result in large MEV opportunities — in order to induce searchers to capture the generated MEV
  2. Mallory initiates the protocol by requesting an execution payload from Alice. This time, as opposed to the original attack, submitting a completely legitimate commitment.
  3. Alice validates and propogates the genuine block, $\text{block0}$
  4. Using the execution payload Alice revealed (in step 2), Mallory builds a separate block, $\text{block1}$, using the transactions included in the revealed payload. This is where the actual unbundling occurs.
  5. Mallory attests to $\text{block1}$ via the gossip network but does not publish it.
  6. Mallory floods with their attestation to $\text{block1}$. As the peers don't know about $\text{block1}$, they perform lookups to other peers — specifically via the BlocksByRoot RPC.
  7. Mallory responds to many such requests with $\text{block1}$
  8. Provided Mallory is fast enough, $\text{block1}$ receives the proposer boost rather than $\text{block0}$
  9. Validators now acknowledge $\text{block1}$ as the new head and canonicalise it

Attack Analysis

There are no known exploits of this vulnerability in the wild[7].

Mitigation

For Lighthouse, the entire mitigation comprises three PRs:

Full support ultimately landed in release Uncle Steve.

References

  1. F. D'Amato and M. Neuder. "Equivocation attacks in mev-boost and ePBS" Ethereum Research. https://ethresear.ch/t/equivocation-attacks-in-mev-boost-and-epbs/15338 (accessed May 15, 2023).
  2. R. Miller. "Post mortem: April 3rd, 2023 mev-boost relay incident and related timing issue." The Flashbots Collective. https://collective.flashbots.net/t/post-mortem-april-3rd-2023-mev-boost-relay-incident-and-related-timing-issue/1540 (accessed May 15, 2023).
  3. M. Sproul. "Unbundling attacks on MEV relays using RPC" Lighthouse Blog. https://lighthouse-blog.sigmaprime.io/mev-unbundling-rpc.html (accessed May 11, 2023).
  4. D. Marzec and L. Thibault. "Subverting the total eclipse (of the heart)" HackMD. https://hackmd.io/@dmarz/total-eclipse-of-the-relay (accessed May 21, 2023).
  5. G. Konstantopoulos and M. Neuder. "Time, slots, and the ordering of events in Ethereum Proof-of-Stake" Paradigm Blog. https://www.paradigm.xyz/2023/04/mev-boost-ethereum-consensus (accessed May 25, 2023).
  6. PBS Developer Calls. MEV Boost Community Call #3. (Apr. 23, 2023). Accessed: May 25, 2022. [Online video]. Available: https://www.youtube.com/watch?v=U3ncYq60A2U.
  7. M. Sproul, private communication, May 2023.
  8. R. Miller et. al. private communication, May 2023.
  9. L. Thibault et. al. private communication, May 2023.
  10. M. Neuder and J. Drake. "Why enshrine Proposer-Builder Separation? A viable path to ePBS" Ethereum Research. https://ethresear.ch/t/why-enshrine-proposer-builder-separation-a-viable-path-to-epbs/15710 (accessed May 26, 2023).
1

The terms "malicious", "honest", and "victim" are used here within the context of MEV unbundling attacks (as the title of this page would suggest) and not in a broader ethical sense. Some people hold negative views of the practice of MEV generally — these are considered strictly out-of-scope for the purposes of this entry.

2

In principle, there could be multiple victim searchers; only the searchers within the target block are vulnerable to the attack

3

This is not strictly true in that there are multiple individual requests involved in the protocol between the relay and the proposer, but the nuances of the actual API can be easily abstracted away. All that matters is that the proposer starts the interaction and that the relay (eventually) reveals the execution payload to the proposer.

4

The invalid state and parent roots can be seen in the first header on the BeaconScan entry for the slot (as of the time of writing, there are ongoing discussions amongst client and block explorer developers about how to better represent slashings from a user interface perspective).