jakiro
author:Jon Charbonneau,DBA Lianchuang Source: X, @jon_charb Translation: Shan Oppa, Bitchain Vision
existEdge CityAfter attending a few days of workshops, I had some short thoughts on the following questions:
-
Proofreader Proposer Separation (APS)–A common market structure design concept that separates witness roles from proposed roles.Current Ethereum validators are currently doing these two things at the same time.
-
Execution Auction (EA)– A specific allocation mechanism for APS can be implemented.The beacon proposer of the N slot number will sell the rights of the N + 32 slot number (or other number) to the executive proposer.
-
Execution ticket (ET)-Application of (different) specific allocation mechanisms for APS.The agreement sells “tickets” to the execution proposals, which gives them a certain probability that they will eventually be able to redeemed their tickets at some uncertain point in the future to obtain the right to execute proposals.
-
Timer Game– Proposers have the incentive to postpone their block proposals as much 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 MEVs.
-
Include list (IL)– There are proposals that allow validators to force builders to include certain transactions into their blocks.The imposition of these restrictions is intended to increase the resistance to review.
-
Preconfs——L1 proposers are able to provide pre-confirmation to L1 txs or rollup txs based on rollup txs.
Design goals
An important question to understand here is that there are multiple independent goals in these proposals, such as EA and ET, which have been confusing:
1) Isolation timer game: Ethereum validators are incentivized to participate in timed game, they are doing this today.This may have a centralized effect on validators, so the goal is to isolate it to experienced participants, just as PBS isolates the complexity of block building/transaction sorting to experienced participants.The goal is to keep validators decentralized.
2)Destroy MEV: MEV destruction just perfectly embodies these designs, cleaner than previous MEV destruction ideas.It should be noted that I personally believe that the ability to do so is a potential by-product, not the motivation for these proposals.I don’t care much about whether we destroy the MEV.
Some people are also very concerned about preconfiguration, and EA is doing better in this regard (I personally don’t really care about that).
Slot time and timer game
In a timed game, there is a certain offset effect on centralization in a period length, and its size depends on different assumptions, thus complicating the analysis.Both are correct:
-
Shorter slots can reduce MEV (e.g., lower LVR) because MEVs grow hyper-linearly with slot time, thereby reducing centralized excitation.
-
Shorter periods can amplify the effects of the timing game, thereby increasing centralized incentives.This is true regardless of the type of transactions that exist (for example, you can include more transactions that do not exist before the end of slot).
APS and multiple MEVs
Multi-block MEV refers to the fact that continuously controlling multiple slots can bring hyper-linear rewards.(For example, a reward with continuous proposal rights for blocks N and N+1 > a reward for independent proposal block N + a reward for independent proposal block N + 1).
This doesn’t happen in practice these days, just because companies like Lido and Coinbase are good.They don’t manipulate oracles for a few blocks (even if they own a large stake and therefore always get many consecutive blocks) because we’re all angry and it will ruin their business.Again, for the same reason, they will not sell these rights to builders outside the agreement.
However, if we explicitly create a market where anyone can buy a large number of slots in a row, it will be easy and inexpensive for anyone to do multiple MEVs.They will be able to bid higher than anyone who is unwilling to do so.We leave this decision to profit maximizers, not the big validators of alliances, and we make it a breeze.
Included on the list
Can we use include lists to prevent multiple blocks of MEVs?Well, it’s kinda OK, but it’s not.If these were the finite ILs envisioned today, they would force only include certain subsets of transactions, and they would forcefully include transactions but not sorted.Execution proposers holding a large number of slots can still create problems and extract multiple MEVs.
To make IL more powerful and prevent multiple MEVs, you can make IL the full current view of the memory pool for each IL committee member (rather than just a few transactions they think are being reviewed for a while), and they also forceSort, not just include (e.g. sort by priority).You need to merge these lists to create a block.Well, now we have turned IL into a full-block multi-block proposal scheme and sorted by priority fees in batches.(Some people might say we are all building the same thing.)
You can also impose a larger penalty on missed slots to mitigate multiple MEVs, but this is still incomplete.Therefore, basically, it is not entirely clear whether these problems are practically resolved.
Furthermore, there is still concern that the proposer will not use IL at all.What if we implement them and validators are afraid to use them?We need a design that motivates everyone to use them, and a possible reasonable denial of what they contain.This is easier said than done.If the proposer can’t/will not enforce CR through IL, it’s not clear why we really need so many validators.
