Thanks to Thomas Thiery, Anders Elowsson and Barnabé Monnot for reviewing this post. Also, thanks to everyone in the Robust Incentives Group and the ePBS Breakout Call #9 attendees for discussions. This post’s argument was presented during the ePBS Breakout Call #9 (recording; slides).
ePBS facilitates the fair exchange between a beacon proposer and a block producer. A block producer is the party that constructs the execution payload, which could be a sophisticated builder or a proposer. The beacon proposer sells the rights to build an execution payload to a block producer in exchange for a bid. The Unconditional Payment and Honest Builder Safety are two desiderata of this fair exchange. The former means that a proposer must receive the bid’s value regardless of the block producer’s actions. The latter roughly implies the block producer must receive the execution payload rights if it paid for them. The final desideratum is that there is No Trusted Advantage. In this context, we define this final desideratum as follows.
(Definition) No Trusted Advantage: The beacon proposer is incentivized to use the in-protocol commitment to commit to the block producer whose in-protocol bid value maximizes the beacon proposer’s utility.
Since most beacon proposers run MEV-Boost, it has become apparent that they want to outsource block building to sophisticated block producers. The No Trusted Advantage desideratum ensures that the commitment that beacon proposers use to outsource to block producers benefits from the Unconditional Payment and Honest Builder Safety guarantees that ePBS provides. Suppose an ePBS design does not satisfy No Trusted Advantage, then a rational beacon proposer may be incentivized to sell the execution payload construction rights or to receive payment for the sale via other commitments that do not have the trustless fair exchange properties of ePBS. The trust a rational beacon proposer must then pose in a third party hurts the credible neutrality of the network and defeats the purpose of ePBS.
This post argues that the slot auction Payload-timeliness committee (PTC) ePBS design does not satisfy No Trusted Advantage. We will present an informal model in which a rational proposer outsources execution payload construction via another commitment than the commitment facilitated via ePBS. In practice, this attack means that a proposer will not use ePBS as intended. Instead, the beacon proposer waits until the execution payload must be revealed and sells the execution payload construction rights via an out-of-protocol block auction, like how MEV-Boost currently works.
In the slot auction Payload-timeliness committee (PTC) ePBS design, a beacon proposer commits to a block producer at the beginning of the slot (t = 0). The block producer must reveal its execution payload halfway into the slot (t = 6). This time difference exists because a block producer must be able to observe attestations for the beacon block so that it knows that the beacon block will likely become canonical, ensuring Honest Builder Safety.
Consider a proposer that decides whether to sell the execution payload construction rights Early (t = 0) or Late (t = 6). The proposer must decide which auction it will use at time t = 0, and it can only choose one auction format. If the proposer is incentivized to sell Early, slot auction ePBS satisfies No Trusted Advantage. If the proposer is incentivized to sell Late, No Trusted Advantage is violated since the proposer would commit to itself in the beacon block and run a MEV-Boost-like auction just before t = 6. Assume the proposer maximizes its payoff.
Builders also bid to maximize payoffs. At the beginning of the block, builders only know the distribution of values they could extract by building the execution payload. Just before t = 6, builders learn the precise value they could extract by building an execution payload called the realized value.
If the proposer were to host an auction Early, builders would bid based on their distribution of values; specifically, risk-neutral builders would bid according to the expected value. If the proposer hosts an auction Late, builders bid based on their realized value. This post assumes bids are monotonically increasing in value. The critical insight is that the expected auction revenue is likely higher based on realized value than expected values under many circumstances. This is because only the highest-order statistics of realized values are relevant.
Considering an ascending-bid first-price auction, the winning builder should pay the builder’s value with the second-highest valuation. Hence, if the second-highest expected value in the Early auction is lower than the expectation of the second-highest realized value, then the proposer will choose to sell via the Late auction.
(Main Result) Slot Auction ePBS does not satisfy No Trusted Advantage: In an ascending-bid first-price auction, a rational beacon proposer will auction the execution payload construction rights via the Late auction if the second-highest expected value (Early auction revenue) is lower than the expectation of the second-highest realized value (Late auction expected revenue). In this case, slot auction ePBS does not satisfy No Trusted Advantage.
This result relies on two key assumptions:
- The beacon proposer has access to a secondary market to sell the execution payload construction rights to block producers in the Late auction.
- Block producers have less access to a secondary market for selling the execution payload construction rights to other block producers in the Late auction than the beacon proposer.
If the first assumption does not hold, then the beacon proposer effectively has no option to sell in the Late auction. A secondary market will likely be available to the beacon proposer since this market already exists via MEV-Boost. On the other hand, Terence has argued that ePBS makes same-slot unbundling attacks easier if a beacon proposer were to sell Late because a beacon proposer could release equivocation execution payloads without losing fork-choice weight or being slashed.
The second assumption could be motivated by the complexity of facilitating trust between two sophisticated parties. Perhaps relays are less willing to facilitate fair exchange between two sophisticated parties. Perhaps block producers will continuously request bids from bidders in the secondary market, whereas today, proposers do not. Perhaps adverse selection is worse if the auctioneer is sophisticated.
Suppose the second assumption does not hold, and the beacon proposer and builders have equal access to the secondary market. In that case, the beacon proposer’s decision to sell in the Early or the Late auction is a risk-reward trade-off. This is because a block producer would then incorporate the value it could get by reselling the item in the secondary market in its bid, which would be equivalent to the value a beacon proposer could get. If the beacon proposer is less risk-averse than builders, it will sell in the Late auction; otherwise, it will sell in the Early auction.
The key point is that whether ePBS is used—whether No Trusted Advantage is satisfied—depends on the risk appetite of beacon proposers and the state of the secondary market if ePBS were deployed with slot auctions. Yet it is entirely unclear what these proposers’ risk appetite or the secondary market’s state will be. In contrast, MEV-Boost has given the ecosystem a lot of information on how block auctions work, providing confidence in it satisfying No Trusted Advantage.
Satisfying No Trusted Advantage in slot auction ePBS is challenging. This desideratum could be achieved by forcing a sale in the early auction, for example, using MEV-Burn. Execution Auctions use MEV-Burn. Whether MEV-Burn is sufficient to satisfy the No Trusted Advantage is still understudied.
This argument could be pivotal in whether ePBS is deployed with block or slot auctions. The difference between the two is huge in terms of market structure. Therefore, it would be very valuable to have numerical validation of the theoretical argument presented here. If you want to create a simulation that tests this theory, please get in touch with Julian Ma ([email protected])