By: Jon Charbonneau, DBA
Compiled by: Tia, Techub News
After attending a few days of workshops at Edge City, I have a new understanding of some of Ethereum’s mainstream proposals. These proposals are mainly used to solve the MEV problem:
Attester Proposer Separation (APS): A general market structure design concept that separates witnesses (Attester) from proposals (Proposers). Attest This proposal was proposed by Ethereum researcher Justin Drake, mainly to solve the problem of validator centralization caused by multi-block MEV. (When a validator has a high probability of being selected as a proposer continuously, it can extract MEV more efficiently and thus obtain more rewards. This will cause other validators to be more inclined to cooperate with large validators, leading to the problem of validator centralization.) Currently, Ethereum validators have not separated these two functions.
Execution Auction (EA): Also known as APS-Burn, it is a mechanism used to implement APS. It was proposed by Ethereum researcher Barnabé Monnot. The specific mechanism is that the beacon proposer of slot N determines the execution proposer of slot N +32 (i.e. the next epoch) through an auction. Its essence is to allocate the execution proposal right in a predetermined way. In this way, the ability of the execution proposer to "freeze" the state or manipulate transactions by controlling several consecutive slots can be reduced.
Execution Tickets (ET): Another mechanism to implement APS. Currently, the Beacon proposer and the Execution proposer are the same validator. When a validator is selected as a Beacon proposer, they are not only responsible for proposing the Beacon Block (consensus), but also for building the Execution Block (execution), which contains all transactions and status updates in the block. The Execution Tickets mechanism separates the roles between verification and execution through a dynamically priced execution ticket market. Execution tickets are issued by the Beacon chain, and validators need to purchase execution tickets to obtain the right to propose execution.
Timing Games: Timing games refer to validators' tendency to obtain additional market incentives by delaying block proposals. Timing games are a zero-sum game. When a proposer delays a block proposal by 1 second, the next (honest) proposer loses 1 second. The gain of the previous proposer is the loss of the next block proposer. If all validators start playing timing games, no one will win.
MEV destruction: MEV is captured and destroyed through the Ethereum protocol.
Inclusion List (IL): This proposal allows validators to force builders to include certain transactions in their blocks. Imposing these restrictions is intended to improve censorship resistance.
Preconfs: L1 proposers are able to provide preconfirmations for L1 txs or rollup-based transactions.
Design goals
For different proposals, the detailed objectives are different, for example:
1) Isolation of timing game: Ethereum validators tend to participate in timing games in order to obtain additional benefits. This may increase the centralization of validators, so the solution may be to transfer it to experienced participants, just as PBS transfers the complexity of block construction/transaction sorting to experienced participants to maintain the decentralization of validators.
2) Destroy MEV: MEV destruction is a more radical idea. It should be noted that I personally think this is a byproduct of the proposal, not a motivation. I don’t care too much whether we destroy MEV.
Some people also really care about pre-confirmation, and EA is better at this (I personally don’t really care about this).
Slot Time and Timing Game
In the timing game, slot length has a certain degree of offsetting effect on centralization:
Shorter slot times can reduce MEV (e.g., lower LVR) because MEV increases with longer slot times.
Shorter slots can amplify the effects of timing gaming, thus increasing centralization incentives. This is true regardless of the type of transaction (e.g. you can wait until the end of the slot to include a transaction that didn't exist otherwise).
APS and multi-block MEV
Multi-block MEV means that controlling multiple slots in a row can bring super-linear rewards. (For example, the reward for having the right to propose blocks N and N+1 in a row > the reward for independently proposing block N + the reward for independently proposing block N+1).
Today, this doesn’t happen in reality simply because companies like Lido and Coinbase have ethical constraints. They won’t manipulate the oracle for a few blocks (even if they have a large share and always get many consecutive blocks) because it would damage their reputation, which is not good for their business. For the same reason, they won’t sell these rights to builders outside of the protocol.
However, if we create a market where anyone can continuously buy a large number of slots, it will become easy and cheap to have multiple blocks of MEV. At this point, the power to build a slot is given to the one who bids the highest. We marketize this power and give it to those with the highest profit, rather than to the aligned validators.
Contains List (IL)
Can we use inclusion lists to prevent multi-block MEVs? Well, it seems like we can, but in practice, we can’t. If these were limited ILs as envisioned today, they would only enforce inclusion of a certain subset of transactions, and they simply enforce inclusion of transactions without ordering. An execution proposer holding a large number of slots could still create problems and extract multi-block MEVs.
To make IL more robust and prevent multi-block MEV, you could have IL be a view of the mempool for each IL committee member (rather than just the few transactions they think are being censored for a certain period of time), and they would also enforce ordering, not just inclusion of transactions (e.g. sorted by priority fee). You need to include these lists to create a block. Ok, so we've turned IL into a full 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 not perfect. So basically, it’s not entirely clear that these problems can actually be solved.
Additionally, there is still concern that proposers won't use ILs at all. What if we implement them and validators are afraid to use them? We need a design that incentivizes everyone to use them and enables plausible deniability about what the IL contains. This is easier said than done. If proposers can't/won't enforce CRs via IL, then we don't know why we need so many validators.
