Mev Smoothing

Background

Resources

• MEV Smoothing

Motivation

• Variance of MEV is dangerous (i.e. some miners getting majority of extraction compared to others), not the size alone

Assumptions

1. Accessibility - all validators have equal access to block headers
2. Maximality - miner payment is sufficiently high that no proposer can substantially profit off the difference (i.e. miner payout = 95%). Therefore, utilizing blocks from the market is not less profitable than running a private MEV extraction operation, or accessing some other private MEV market.

Both properties simply ensure that sophisticated proposers do not have substantially higher profits than unsophisticated proposers.

~MEV Smoothing

Approach

Add a condition as part of the attestation that requires the block being proposed to make a payment (p) that is ≥ p_i (the maximal payment; i.e. this block is the highest paying block to the validators and that’s the one being chosen). We’d need a majority of the published attestations for the newly proposed block to become the canonical head of the chain. If they are outnumbered by attestations to the previous head of the chain, the slot should be skipped.

What we need is instead that a block becomes the new head of the chain only if it receives a majority of the published attestations. Basically, we need a proposed block to be in competition with the empty block. In the diagram below, B is proposed at slot 1 with predecessor A, but it gets fewer attestations than the ones against it, and the canonical chain becomes the one with an empty slot 1.

Builds upon proposer-builder-separation, with the following changes,

1. Smooth payments. Approaches,
   1. Payment is split equally amongst all committee members (and proposer)
   2. Committee members who attested correctly are paid, rest is burnt(?)
2. Add an additional attestation constraint that the builder’s block payment (i.e. payment to proposed/validator) ≥ the current maximal payment (e.g. MEV is 100, maximal payment sent is 95, so builder keeps 5)
3. If the all the attestation constraints are not met, validators attest the previous head of the chain
4. Updated fork-choice-rules for a 51% consensus requirement to reorg chain vs a 34%)
   1. How it is today, attesting an absence of a new block counts as the previous block applied to the new slot (i.e. [A, 0], [A, 1]). Because Gasper doesn’t consider the slot a 34% attack would be sufficient in breaking finality: “The idea is just to not publish a block B built on A, wait for C to be built on A, then release two rounds of attestations for B, so 34+34=68% of one committee, which beats the maximum of 66% that C can get. This is possible because attestations against B currently just count as attestations for A, which do not help C against B, since they are both built on A.”
5. Add a deadline for builders’ block headers to be considered by attesters in their assessment of the maximal payment
   1. Without one, one could always publish block headers with high payments that are too late to be seen and chosen by the proposer, but still cause attesters to update their view of the maximal payment.