Description
In MEV-Boost, the proposer commits to a builder by signing a block header; at the same time, the proposer thereby also commits to an execution payload. This is called a block auction. However, It is not evident that this is the auction format that a proposer prefers. A proposer could also commit to a builder for the execution payload of its slot without committing to a specific execution payload. This is called a slot auction. For ePBS, the decision on which auction format is preferred must be made. This note highlights in broad strokes the arguments in favor and against slot auctions compared to block auctions in ePBS.
Arguments in favor of slot auctions
- Proposer timing games are a centralizing force that erodes Ethereum's credible neutrality. Slot auctions decrease the incentive for proposer timing games since future increases in block value can be reflected in a bid beforehand.
- Slot auctions prevent the Free option problem. Consider ePBS with block auctions. If a builder wins the auction with a certain block, but it turns out not profitable to the builder at the time of reveal, it may choose not to reveal its block. In slot auctions, however, the builder could adjust the contents of its block so that it is always better for the builder to reveal its block.
- If the ecosystem wants to move to either Execution Auctions, Execution Tickets, or a different shape of true validator-proposer separation, slot auctions are one step closer than block auctions. Choosing slot auctions acknowledges that the ecosystem could go from ePBS to these mechanisms via an iterative approach.
- Slot auctions may increase a block's allocative efficiency. In this context, allocative efficiency means that the most valuable transactions are included in the block. Allocative efficiency may increase in two ways: 1) the builder can adjust the contents of the transactions, e.g., the amount of assets to swap in an arbitrage transaction, up until the last moment, increasing the price efficiency of DEXs. 2) the builder could extract cross-domain MEV atomically, decreasing frictions.
- Slot auctions decrease the average time to inclusion for a transaction since a transaction can also be included in the upcoming block even if the builder sees it after the beacon proposer commits to its beacon block.
- Block auction ePBS could leak free data availability. In block auction ePBS, the beacon block commits to an execution payload hash. An adversary could use this commitment to show that some data was available to the PTC, yet the data does not have to be a valid block. This means that the adversary would not have to pay the base fee needed to provide the data on-chain; it only has to pay the proposer to commit to its execution payload hash.
Arguments against slot auctions
- Slot auctions do not satisfy the ePBS No Trusted Advantage desideratum. Rational beacon proposers could likely choose to bypass the ePBS fair exchange and sell their execution payload construction rights out-of-band, thereby harming the network's credible neutrality and defeating the purpose of ePBS.
- While the incentive for proposer timing games is decreased, we open up a new can of worms: builder timing games. The builder of the execution payload is incentivized to delay its reveal as long as possible. Potentially, this is less of a problem than proposer timing games since builders are a sophisticated set of entities, and centralization amongst builders does not influence the credible neutrality of the validator set as long as builders and validators do not start integrating. It is unclear, however, whether builder timing games lead to more missed execution payloads than theFree option problem. Finally, an increased incentive for builder timing games will likely decrease the execution validation time.
- Proposers may want to base their decision on which builders they pick or whether they build locally on the value of the block they could build locally. The value of a local block at the time of reveal is harder to estimate in a slot auction than in a block auction. This could mean that fewer proposers use features like
local_block_value_boost (name differs per client), resulting in an increase in the average time for inclusion for transactions that the proposer may care about, keeping all other factors constant.
- If slot auctions were implemented, the protocol currently does not deal with equivocations of execution payloads, although it might do so if desired. What would be the effect on the protocol, and could it ensure honest builder and proposer safety?
- Slot auctions require builders to bid before they know the value of the most valuable execution payload they could construct. This may favor builders better at predicting the value than other builders, for example, because they have integrated searchers performing arbitrage.
Resources