APS was introduced in December 2023 as a proposed solution to the additional profits sophisticated beacon proposers can gain by playing timing games. Timing games allow beacon proposers that are well-connected with attesters to wait longer and capture more MEV. APS aims to remove all execution layer incentives from validators which also reduces the payoff variance validators have today since validators would no longer receive MEV which has high variance. These goals are desirable because they would allow better incentive management for validators and remove centralization vectors.

After roughly two years of exploration, it has become clear a trade-off must be made if APS were implemented today. Either an APS mechanism is implemented that allows continuous preconfirmations but leads to multi-slot MEV or an APS mechanism is implemented that completely prevents multi-slot MEV but preconfirmations cannot be continuously provided. In my opinion it is not worth making the trade-off at this time. Instead, we should wait for technology to improve that can help break the trade-off. Specifically, we need a good encrypted mempool proposal that would break the trade-off. In the remainder of this post I argue why this trade-off exists, what a choice in the trade-off would look like, how encrypted mempools would solve the trade-off, and what the reason may be Ethereum may still want to implement APS.

The ideal APS mechanism would look like Figure 1. In block N-k potential execution proposers may buy as many tickets as they want for a fixed price. Tickets are sold via a system contract on the execution layer. After block N a single execution proposer is randomly chosen with a probability proportional to the amount of tickets bought. This chosen execution proposer may then propose an execution block in slot N+1.

Unfortunately, there is no way to generate unbiasable randomness after the execution block of slot N has been released. That means that the execution proposer of slot N-1 would be able to bias the randomness in such a way that it is more likely to be chosen as the next execution proposer and it would be known to the execution proposer of slot N-1 whether or not it would be the next proposer which would allow it to extract multi-slot MEV. Since the builder market is very concentrated today, there would be multi-slot MEV frequently which is bad for applications since it makes application design much harder and has negative impacts on users. For example, it could be that users are prevented from adding margin to their loans so that searchers can benefit from liquidating them, there could be long-run oracle attacks, in the extreme fraud proofs games could even be prevented.

Execution Auctions, a different APS proposal from Barnabé, does not require randomness. The key issue, however, is that in the time interval between the execution block of slot N-1 and the beacon block of slot N it is unknown who would be the execution proposer of slot N and therefore there cannot be preconfirmations issued during a large portion of the slot. See Figure 2 for an illustration of this effect.

If it is acceptable to have multi-slot MEV and preconfirmations must be supported with APS, then the Execution Tickets mechanism could be implemented. Randomness is then generated in advance, e.g. with Ethereum’s current RANDAO. Tickets should be sold short enough in advance such that there are no beacon proposer timing games but no longer in advance than that to make bidding easier.

If it is acceptable that it is impossible to have preconfirmations for a large portion of the slot, Execution Auctions can be implemented.

The way to break the trade-off is to generate randomness after the last execution block as indicated in Figure 1. The most viable solution to this seems to be an encrypted mempool. An encrypted mempool either relies on a threshold committee that could compute randomness after the execution block by itself or the post-state root of the execution block could be used since it would be unknown to the execution proposer of the block as long as encrypted transactions are in the block that are decrypted afterwards.

There are a few encrypted mempool proposals (e.g. see here, here, here, and here) yet in my opinion none of them are quite a silver bullet. I think an encrypted mempool should be implemented that relies on a threshold committee. The problem is there is no threshold scheme that meets all of Ethereum’s requirements we identified for an encrypted mempool proposal. In particular, the public keys of threshold committee members are linear in the committee size. With a committee of 512 members that would lead to around 12 MB of keys which is too large. Public keys must be constant in committee size.

Besides encrypted mempools, randomness could be generated in other ways. For instance, randomness could be generated within a TEE such that its operator cannot view the generated randomness. TEEs are not viable for Ethereum L1 to depend on for core properties yet but may be so in the future.

APS was proposed in response to beacon proposer timing games. Today, the additional rewards sophisticated beacon proposers gain from timing games does not seem to be a large problem. Instead, the main reason APS would be pursued is a stepping stone for stake capping, a different network upgrade aimed at limiting the amount of ETH staked. APS is particularly important for this upgrade because issuance, the consensus layer rewards, are expected to go down whcih means that the execution layer rewards validators would receive without APS start to dominate validator behaviour which could be very centralizing.

Note that if APS is pursued for stake capping, it is very important no execution layer rewards accrue to beacon proposers. That means that even small timing games beacon proposers could play in Execution Auctions could be problematic as it would mean they gain some execution layer rewards.

Finally, APS could be pursued to make it easier to provide preconfirmations. Since innovation is still happening without APS that could lead to preconfirmations, APS is not a requirement for preconfirmations at this point.

The trade-off between no multi-slot MEV and preconfirmation friendliness can only be broken with a new source of randomness generated after the last execution block. This randomness could, for example, be sourced from encrypted mempools. Other methods of breaking this trade-off would be very valuable. Until the trade-off is broken, I think we should not implement APS.

APS was introduced in December 2023 as a proposed solution to the additional profits sophisticated beacon proposers can gain by playing timing games. Timing games allow beacon proposers that are well-connected with attesters to wait longer and capture more MEV. APS aims to remove all execution layer incentives from validators which also reduces the payoff variance validators have today since validators would no longer receive MEV which has high variance. These goals are desirable because they would allow better incentive management for validators and remove centralization vectors.

After roughly two years of exploration, it has become clear a trade-off must be made if APS were implemented today. Either an APS mechanism is implemented that allows continuous preconfirmations but leads to multi-slot MEV or an APS mechanism is implemented that completely prevents multi-slot MEV but preconfirmations cannot be continuously provided. In my opinion it is not worth making the trade-off at this time. Instead, we should wait for technology to improve that can help break the trade-off. Specifically, we need a good encrypted mempool proposal that would break the trade-off. In the remainder of this post I argue why this trade-off exists, what a choice in the trade-off would look like, how encrypted mempools would solve the trade-off, and what the reason may be Ethereum may still want to implement APS.

The ideal APS mechanism would look like Figure 1. In block N-k potential execution proposers may buy as many tickets as they want for a fixed price. Tickets are sold via a system contract on the execution layer. After block N a single execution proposer is randomly chosen with a probability proportional to the amount of tickets bought. This chosen execution proposer may then propose an execution block in slot N+1.

Unfortunately, there is no way to generate unbiasable randomness after the execution block of slot N has been released. That means that the execution proposer of slot N-1 would be able to bias the randomness in such a way that it is more likely to be chosen as the next execution proposer and it would be known to the execution proposer of slot N-1 whether or not it would be the next proposer which would allow it to extract multi-slot MEV. Since the builder market is very concentrated today, there would be multi-slot MEV frequently which is bad for applications since it makes application design much harder and has negative impacts on users. For example, it could be that users are prevented from adding margin to their loans so that searchers can benefit from liquidating them, there could be long-run oracle attacks, in the extreme fraud proofs games could even be prevented.

Execution Auctions, a different APS proposal from Barnabé, does not require randomness. The key issue, however, is that in the time interval between the execution block of slot N-1 and the beacon block of slot N it is unknown who would be the execution proposer of slot N and therefore there cannot be preconfirmations issued during a large portion of the slot. See Figure 2 for an illustration of this effect.

If it is acceptable to have multi-slot MEV and preconfirmations must be supported with APS, then the Execution Tickets mechanism could be implemented. Randomness is then generated in advance, e.g. with Ethereum’s current RANDAO. Tickets should be sold short enough in advance such that there are no beacon proposer timing games but no longer in advance than that to make bidding easier.

If it is acceptable that it is impossible to have preconfirmations for a large portion of the slot, Execution Auctions can be implemented.

The way to break the trade-off is to generate randomness after the last execution block as indicated in Figure 1. The most viable solution to this seems to be an encrypted mempool. An encrypted mempool either relies on a threshold committee that could compute randomness after the execution block by itself or the post-state root of the execution block could be used since it would be unknown to the execution proposer of the block as long as encrypted transactions are in the block that are decrypted afterwards.

There are a few encrypted mempool proposals (e.g. see here, here, here, and here) yet in my opinion none of them are quite a silver bullet. I think an encrypted mempool should be implemented that relies on a threshold committee. The problem is there is no threshold scheme that meets all of Ethereum’s requirements we identified for an encrypted mempool proposal. In particular, the public keys of threshold committee members are linear in the committee size. With a committee of 512 members that would lead to around 12 MB of keys which is too large. Public keys must be constant in committee size.

Besides encrypted mempools, randomness could be generated in other ways. For instance, randomness could be generated within a TEE such that its operator cannot view the generated randomness. TEEs are not viable for Ethereum L1 to depend on for core properties yet but may be so in the future.

APS was proposed in response to beacon proposer timing games. Today, the additional rewards sophisticated beacon proposers gain from timing games does not seem to be a large problem. Instead, the main reason APS would be pursued is a stepping stone for stake capping, a different network upgrade aimed at limiting the amount of ETH staked. APS is particularly important for this upgrade because issuance, the consensus layer rewards, are expected to go down whcih means that the execution layer rewards validators would receive without APS start to dominate validator behaviour which could be very centralizing.

Note that if APS is pursued for stake capping, it is very important no execution layer rewards accrue to beacon proposers. That means that even small timing games beacon proposers could play in Execution Auctions could be problematic as it would mean they gain some execution layer rewards.

Finally, APS could be pursued to make it easier to provide preconfirmations. Since innovation is still happening without APS that could lead to preconfirmations, APS is not a requirement for preconfirmations at this point.

The trade-off between no multi-slot MEV and preconfirmation friendliness can only be broken with a new source of randomness generated after the last execution block. This randomness could, for example, be sourced from encrypted mempools. Other methods of breaking this trade-off would be very valuable. Until the trade-off is broken, I think we should not implement APS.