MD-7: Prevent Suzuka MEV Exploits and Censorship

  • Description: Provide an account of possible Suzuka MEV attacks and censorship vulnerabilities, and propose solutions to mitigate these risks.
  • Authors: Liam Monninger

Overview

The Suzuka Network is known to be subject to MEV exploits in the form of manipulating block size and order. That is, while transactions within a block are ordered deterministically, full nodes are currently given freedom to chose which transactions to include in a block and when to send those blocks to the network. Execution-level validation will only assert that the sequence numbers are appropriate and other dApp-specific logic. There are no penalties for being to have withheld a transaction.

The desiderata presented herein request a complete model of MEV in the Suzuka Network. They also make some provisional requests based on surmised ways to prevent certain MEV attacks.

Most of the account of MEV attacks should be based on the model of transaction fairness given in MD-6.

Many of MEV attacks addressed can also be classed as censorship attacks. That is, a miner can choose to not include a transaction in a block. This is a form of censorship. As such, the desiderata herein also address censorship attacks.

Desiderata

D1: Model Suzuka MEV Attacks

User Journey: A researcher or protocol implementer can understand the game theory of MEV attacks in the Suzuka Network.

Justification: Suzuka MEV attacks are a significant risk to the network. Understanding them is the first step to preventing them.

Recommendations:

  • Begin be enumerating all of placers where a single entity has control over transaction inclusion or ordering.
  • Assess how transaction provenance can be formed.

D2: Merge Blocks and Assign Deterministic Cut-points

User Journey: An honest Suzuka Full Node can only form the final blocks needed for execution by (a) merging blocks in a given DA height range, (b) ordering transactions deterministically, and (c) assigning deterministic cut-points for block formation.

Justification: If the blocks from a given DA height range are merged and then split with deterministic cut-points, a Suzuka Proposer would only be able to manipulate the inclusion or exclusion of a transaction in a given DA height range–no longer the order of blocks therein. This limitation of the action space could render most MEV attacks implausible–particularly if it increases the latency of an attack held across two block height ranges beyond the window in which the client would notice the failure and submit a transaction to an honest Suzuka Full Node.

D3: Induced Proposer Races for Fair Provenance

User Journey: Suzuka Proposers are subject to a potentially race on each transaction whereby if each

Justification: This will disincentivize validators from producing unfair blocks.

Recommendations:

  • This involves two primary innovations (1) making the transaction dataflow amenable to duplicate transactions and (2) providing reward or penalization controls applicable to the Proposer function similar to those referenced in MD-6.
  • A simple protocol could provide a provocative start:
    1. The Client submits a signed transaction to a Suzuka Full Node.
    2. The Suzuka Full Node signs this transaction and sends it back as confirmation to the Client.
    3. The Client MAY optionally have submitted the same transaction to another Suzuka Full Node.
    4. The DA records where the transaction was included and by which Proposer. The first propose to have submitted wins the race. Subsequent duplicates are ignored.
    5. The state computed by the transactions in a block is eventually settled along with a set of signers who won their respective races.
    6. The settlement contract rewards the winning Proposer.

Errata