Not all Frontrunning is MEV

This issue addresses concerns about §3.7 MEV (Maliciously Extracted Value) of the EEA EthTrust Security Levels Specification. The current version might mislead developers into thinking that MEV covers all kinds of attacks that rely on malicious transaction reordering, inclusion, or suppression.

There exist different attack strategies, which exploit blockbuilding capabilities, including Front(-)running, Back(-)running, Sandwich Attacks, and Suppression/Censorship Attacks. These strategies are also grouped under the term "Frontrunning".

MEV (Miner/Maliciously/Maximal-Extractable Value) was introduced to describe the impact of these attack strategies. Our main objective with this issue is to raise awareness that MEV does not cover all of these attacks and to work on improving the security specification to describe a broader spectrum of "frontrunning" dubbed attacks.

It might be worth spelling out the differences between "frontrunning" as an attack class and "frontrunning" as an attack strategy in the specification as well.

Issue Summary: MEV is not capturing all Frontrunning Attacks

The notion of MEV suffers from two major limitations:

Limitation 1: MEV can only capture local frontrunning attacks, i.e., attacks that are solely based on the current mempool and have an immediate effect. Attacks involving multiple stages or incurring effects that only manifest over time are not covered.

Limitation 2: MEV captures only monetary attacks. Other non-monetary objectives (such as denial-of-service attacks) are not covered, even though they can cause major harm to honest users.

Empirical results An analysis of 287 smart contract audits (sourced from eight professional smart contract auditors listed by the Ethereum Foundation) shows that the MEV definition only captures 45\% of the investigated frontrunning. Limitation 1 (resp. Limitation 2) accounted for 34\% (resp. 40\%) of the cases where MEV could not capture frontrunning instances. Moreover, 26\% of the vulnerabilities could not be captured by MEV due to Limitations 1 and 2 combined. Full details of the analysis (allowing its full reproducibility) will be publicly released in the coming few months.

Minimal Examples

The following paid voting contract is used to sketch minimal vulnerable examples for both limitations of MEV: PaidVoting is a contract where users can buy votes and propose new candidates. The owner can specify the maximum number of votes per person.

Paid voting contract

contract PaidVoting {
    // User functions
    function buyVote(Id id) payable  {/* 1. User can buy votes */}
    function proposeCandidate(Id id, Prop p)  {/* 2. Users can propose new candidates */}
    // ...

    // Admin function
    function setMaxPurchasedVotes(uint mPV) ownerOnly {/* 3. Admins can set the maximum number of votes  */}
    // ...
}

The setMaxPurchasedVotes function (proposeCandidate function) is vulnerable to a standard frontrunning attack but would not be captured by MEV, which is a prime example for Limitation 1 (resp. Limitation 2).

Limitation 1 - Example: Attacker frontruns settings changes to benefit from old settings

uint maxPaidVotes = 0;

// Non-Local Settings Frontrunning
function setMaxPurchasedVotes(uint mPV) ownerOnly {
    maxPaidVotes = mPV;
}

The owner's intention to decrease the maximum number of votes purchased by a user (with a call to setMaxPurchasedVotes) can be undermined by a frontrunning attacker by scheduling calls to the buyVote function before. This can lead to the adversary obtaining an unfair advantage in determining the winner of the election, potentially enabling later payouts. Such payouts, however, cannot be enforced within the attacker scheduling window and would only become effective after the election process is completed.

According to the MEV definition, the Voting contract would not exhibit any extractable value for mempools that include calls to the setMaxPurchasedVotes() functions, enabling the described non-local attacks.

Limitations 2 - Example: Attacker prevents a user from proposing a new candidate

mapping (Id => Proposal) proposals;

// DOS Frontrunning
function proposeCandidate(Id id, Proposal prop) {
    require(proposals[id] == null);
    proposals[id] = prop;
}

An attacker can prevent a new candidate from being proposed by frontrunning every proposeCandidate call with their own call that uses the same identifier. The attacker call will reserve the candidate identifier id for a dummy proposal, thereby causing the intentionally user-proposed candidate to be dropped. Any re-submission of the candidate with a new identifier could be frontrun again.

EntEthAlliance / EthTrust-public

Not all Frontrunning is MEV #4

Issue Summary: MEV is not capturing all Frontrunning Attacks

Minimal Examples