What are APS, EA, and ET? An article explaining the mainstream MEV solution of Ethereum

Compiled by: Tia, Techub News

After attending a few days of seminars at Edge City, I have some new understanding of some mainstream proposals in Ethereum. These proposals are mainly used to solve the MEV problem:

• Prover Proposer Separation (APS): A common market structure design concept that separates witnesses (Attester) from proposals (Proposer). Attest This proposal was proposed by Ethereum researcher Justin Drake and is mainly used to solve the validator centralization problem caused by multi-block MEV. (When a validator has a high probability of being continuously selected as a proposer, 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 a validator center ization issue.) Currently, Ethereum validators have not separated these two functions.
• Execution Auction (EA): Aliased as APS-Burn, it is the 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 execution proposal rights in a predetermined manner. In this way, the ability of the executing proposer to "freeze" the state or manipulate transactions by controlling several consecutive slots is reduced.
• Execution Ticket (ET): is another mechanism to implement APS. Currently, the Beacon proposer and Execution proposer are the same validator. When a validator is selected as a Beacon proposer, they are responsible not only 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 the dynamically priced execution ticket market. Execution tickets are issued by the Beacon chain, and validators need to obtain Execution proposal rights by purchasing execution tickets.
• Timing Games: Timing Games refer to the tendency of validators to obtain additional market incentives by delaying block proposals. The sequential game is a zero-sum game. When a proposer delays proposing a block for 1 second, the next (honest) proposer loses 1 second. The profit gained by the previous proposer is the loss of the next block proposer. If all validators start playing the timing game, no one will win.
• MEV destruction: Capture and destroy MEV through the Ethereum protocol.
• Inclusion List (IL): This proposal allows validators to force builders to include certain transactions in their blocks. These restrictions are imposed to increase censorship resistance.
• Preconfs: L1 proposers are able to provide pre-confirmations for L1 txs or rollup-based transactions.

Design Goals

For different proposals, the detailed goals are different, such as:

1) Isolation Timing Game: In order to obtain additional benefits, Ethereum validators will tend to participate in timing games. This could exacerbate validator centralization, so the solution could be to cede it to experienced players, much like PBS ceded the complexity of block building/transaction ordering to experienced players to keep Decentralization of validators.

2) Destroy MEV: MEV destruction is a more thorough idea. To be clear, I personally believe this is a by-product of the proposal, not a motive. I don't really care if we destroy MEV.

Some people also care a lot about pre-confirmation, and EA is better at that (I personally don't really care about that).

Slot time and timing game

In the timing game, slot length has a certain offset effect on centralization:

• Shorter slots can reduce MEV (for example, reduce LVR), because MEV will increase with the slot Increases with time.
• Shorter slots can amplify the effect of timing games, thereby increasing centralized incentives. This is true regardless of the transaction (for example, you can wait until the end of the slot to include a transaction that doesn't exist).

APS and multi-block MEV

Multi-block MEV means that continuously controlling multiple slots can bring super-linear rewards. (For example, the reward for having consecutive proposal rights for blocks N and N+1 > the reward for independently proposing block N + the reward for independently proposing block N + 1).

Today, the reason this doesn’t happen in reality is simply because of the ethical constraints on companies like Lido and Coinbase. They will not manipulate the oracles for a few blocks (even if they have a large share, they will always get many consecutive blocks), because doing so will damage their reputation, which is not good for their business . For the same reason, they also won't sell these rights to builders outside of the agreement.

However, if we create a market where anyone can buy a large number of slots in a row, then multi-block MEV will become easy and cheap. At this point, the power to build the slot is given to the higher bidder. We marketize this power and give it to those with the highest profits, rather than aligned validators.

Inclusion Lists (IL)

Can we use include lists to prevent multi-block MEV? Well, it seems like it could, but it actually doesn't. If these were the limited ILs envisioned today, they would only enforce inclusion of certain subsets of transactions, and they would simply enforce inclusion of transactions but not ordering. Execution proposers holding a large number of slots can still cause problems and extract multi-block MEV.

To make IL more robust and prevent multi-block MEV, you can have IL act as a mempool view for each IL committee member (rather than just the few transactions they think are being reviewed for a certain period of time), and they will also Force sorting instead of just including transactions (e.g. sort by priority fee). You need to include these lists to create a block. Well, in this case we have turned IL into a full-block multi-block proposer scheme, sorted by priority fees within the batch. (Some might say we're all building the same thing.)

You could also impose a larger penalty on missed slots to mitigate multi-block MEV, but that's still not perfect. So basically, it's not entirely clear whether these problems can actually be solved.

Also, there are still concerns that the proposer 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 and enables reasonable denial of what the IL contains. This is easier said than done. If proposers can't/won't enforce CR via IL, then we don't know why so many validators are needed.

The above is the detailed content of What are APS, EA, and ET? An article explaining the mainstream MEV solution of Ethereum. For more information, please follow other related articles on the PHP Chinese website!