The Future of Ethereum’s Supply Chain: An Interpretation of the Mainstream Proposals

Author: Jon Charbonneau, DBA Lianchuang Source: X, @jon_charb Translation: Shan Ouba, Golden Finance

After attending a few days of workshops at Edge City, I have some brief thoughts on the following issues:

• Attester Proposer Separation (APS) - A general market structure design concept that separates the witness role from the proposal role. Current Ethereum validators currently do both at the same time.

• Execution Auction (EA) - A specific allocation mechanism that can implement APS. The beacon proposer of slot N will sell the right to be the execution proposer of slot N+32 (or other number).

• Execution Tickets (ETs) - (Different) specific allocation mechanisms that can implement APS. The protocol sells "tickets" to execution proposers, which give them a certain probability of eventually being able to redeem their tickets for execution proposal rights at some undetermined point in the future.

• Timing Game - Proposers have an incentive to delay their block proposals as long as possible to earn more dollars. This is a zero-sum strategy that requires complexity and can degrade protocol performance (e.g., missed time slots).

• MEV Destruction - Enable the Ethereum protocol to capture and destroy MEV.

• Inclusion Lists (IL) - There are proposals to allow validators to force builders to include certain transactions in their blocks. Imposing these restrictions is intended to increase censorship resistance.

• Preconfs — L1 proposers are able to provide pre-confirmations for L1 txs or rollup-based txs.

Design Goals

An important thing to understand here is that there are multiple separate goals in these proposals, such as EA and ET, which have been confused:

1) Isolate the Timing Game: Ethereum validators are incentivized to participate in the timing game, which they are doing today. This can have centralizing effects on validators, so the goal is to isolate it to experienced participants, just as PBS isolates the complexity of block construction/transaction ordering to experienced participants. The goal is to keep validators decentralized. 2) MEV Destruction: MEV destruction happens to embody these designs perfectly, and is much cleaner than previous MEV destruction ideas. To be clear, I personally view the ability to do this as a potential byproduct, rather than a motivation for these proposals. I don't really care if we destroy MEV. Some people also care a lot about pre-provisioning, and EAs are better at this (I personally don't really care about that). Slot Machine Timing and Timed Games In timed games, there is a somewhat offsetting effect of session length on centralization, the size of which depends on different assumptions, so this complicates the analysis. Both are correct:

• Shorter slots can reduce MEV (e.g., reduce LVR) because MEV grows superlinearly with slot time, thus reducing centralization incentives.

• Shorter slots can amplify the effects of timing games, thus increasing centralization incentives. This is true regardless of the types of transactions present (e.g., you can include more transactions that didn't exist before the end of the slot).  

APS and Multi-Block MEV

Multi-Block MEV refers to the fact that controlling multiple slots in a row can bring superlinear rewards. (e.g. reward for having consecutive proposal rights for blocks N and N+1 > reward for independently proposing block N + reward for independently proposing block N+1).

Today, this doesn’t happen in practice simply because companies like Lido and Coinbase are nice. They won’t manipulate the oracle for a few blocks (even if they own a large stake and therefore always get many consecutive blocks) because we’d all be pissed and it would ruin their business. Likewise, they won’t sell these rights to builders outside of the protocol for the same reason.

However, if we explicitly create a market where anyone can buy a large number of slots consecutively, it will become easy and cheap for anyone to do multi-block MEV. They will be able to outbid anyone who isn’t willing to do so. We put this decision in the hands of profit maximizers, not aligned large validators, and we make it easy to do so.

Inclusion Lists

Can we use inclusion lists to prevent multi-block MEVs? Well, kind of, but not really. If these were limited ILs as envisioned today, then they would only enforce inclusion of a certain subset of transactions, and they would enforce inclusion of transactions but not ordering. An execution proposer holding a large number of slots could still cause problems and extract multi-block MEVs.

To make ILs more robust and prevent multi-block MEVs, you could have the ILs be each IL committee member's full current view of the mempool (not just the handful of transactions they think are being censored for a while), and they would also enforce ordering, not just inclusion (e.g. sort by priority fee). You need to merge these lists to create a block. OK, now we've turned ILs into a full-block multi-block proposer scheme, with ordering by priority fee within batches. (Some might say we're all building the same thing.)

You could also impose larger penalties for missed slots to mitigate multi-block MEV, but that's still imperfect. So basically, it's not entirely clear whether these problems are actually solvable.

Also, there's still the concern that proposers won't use IL at all. What if we implement them, and validators are afraid to use them? We need a design that incentivizes everyone to use them, as well as possible plausible deniability about what they contain. This is easier said than done. If proposers can't/won't enforce CRs via IL, then it's less clear why we really need so many validators.