High-level view

We begin by presenting the design in its most distilled form. The execution ticket mechanism can be succinctly described as:

We decompose the slot into the beacon round and the execution round during which the beacon block and execution block are proposed respectively. Each of the two blocks has an associated attesting committee that casts votes used to determine the head of the chain.

Buying tickets versus staking – Examining today’s consensus mechanism using the ticket framework, an existing validator effectively owns a perpetual ticket. They can be selected at any time to be a proposer for a given slot and they retain this right as long as they are in the validator set. With execution tickets, future block proposal rights must be explicitly purchased from the protocol; validators are not given any tickets by default.

To put some hypothetical numbers on what validators today pay for the right to produce blocks, let’s do a bit of back-of-the-napkin math. These numbers are constructed to demonstrate the point, not to be perfectly realistic. Consider a validator today and let the cost of money be 3% per year while the rewards from issuance are 2% per year. The validator then has an opportunity cost of 1% per year on the 32 ETH they have staked. With 2,628,000 slots in a year and 890,000 validators, a validator should be selected about three times a year. Thus the “cost of being a proposer” is about 0.33% of 32 ETH, or about 0.11 ETH. In this hypothetical, this value represents the “price of being a block proposer,” or in other words, the approximate price of an execution ticket.

Relationship to PBS/ePBS – While the concepts feel similar, execution tickets are orthogonal to PBS. Execution tickets create a primary market for future block space (e.g., a future-looking slot auction 2), but the JIT block auction 2 of mev-boost will still exist as a secondary market once the tickets are assigned to specific slots. It might ~still be worth~ enshrining a PBS auction in addition to execution tickets. More on this in the analysis section.

Why execution tickets – The current block proposal process elects a single proposer from the validator set to produce the beacon block and the execution payload. Because of MEV, there are large incentives to outsource the execution payload construction to an external market of builders. This reality continues to place centralizing pressure on the validator set, as vertical integration, colocation, and pooling directly translate to more rewards. Execution tickets aim to detangle the MEV rewards from the beacon block production to “firewall off” the decentralized validator set from these centralizing forces.

Definitions

To add some more details, let’s examine the slot construction in depth.

upload_c897b96b12a7cda52df6b25e3a873d371490×1348 269 KB

Design

We call this mechanism “execution tickets” because the execution proposers directly purchase tickets for the lottery from the protocol, rather than being granted block proposal rights as beacon proposers (the case today).

The basic flow for one slot is:

The figure below shows this process unfolding for 3 slots.

upload_cba9a1d4f175136579d040f224b697591920×1365 180 KB

A few takeaways from the figure:

Analysis

Let’s explore some of the downstream effects of execution tickets.

Validating & staking

This design significantly changes the role of being a validator in Ethereum.

Roadmap compatibility

As the roadmap 1 continues to evolve, let’s consider how execution tickets fit into the endgame vision 2. From “Endgame,”

“Block production is centralized, block validation is trustless and highly decentralized, and censorship is still prevented.” – Vitalik

Execution tickets embrace this concept fully and aim to decouple block proposing and block validation while preserving censorship resistance.

upload_918fffb939a915b51cb156020fa8bd231608×1424 249 KB

Secondary market

We define the primary market of tickets as buying and selling directly from the beacon chain. Each of these unused tickets is fungible. Once assigned to a slot, they are no longer resellable on the primary market, and the secondary market emerges. The figure below outlines some secondary market features we expect would evolve.

upload_f3a198f7d2ff3ddfb56381b49571838c1190×1450 168 KB

The “fence” we draw in the protocol is the primary market for unused ticket sales, which are dynamically priced. However, the non-fungible ticket sales on the secondary market are out of view of the protocol, just as they are in mev-boost today. Enshrining PBS extends the execution tickets design to protocolize and constrain a portion of the secondary market (e.g., the JIT block auction).

Multi-slot MEV considerations

While there are many benefits from execution tickets as expressed above, multi-slot MEV must be explored as it relates to the design.

What’s up with Multi-slot MEV – Mutli-slot MEV refers to the fact that controlling more than one slot in a row of block proposal rights may have outsized benefits compared to controlling the same number of non-contiguous slots. For example, a builder trying to perform CEX-DEX arbitrage over two slots could try to censor Uniswap transactions for the first slot to let the price on the CEX continue to diverge, capturing outsized value in the second slot.

Multi-slot MEV today – In the current system, large node operators are the entities positioned to capture multi-slot MEV. For example, a node operator controlling 10% of the stake will control two consecutive slots 1% of the time (72x per day) and will control three consecutive slots 0.1% of the time (7.2x per day). In the mev-boost market structure, slots are sold “JIT” (using the terminology of “When to sell your blocks” 2). As such, a builder who wants to buy multiple slots in a row would need to compete in an independent auction for every slot. However, a node operator may instead choose to use a modified version of mev-boost and offer to sell multi-slot bundles to a specific builder outright (while we haven’t seen this today, it may be taking place in the shadows). This could be rational if the expected value of selling multiple consecutive slots is higher than selling each individually. As we saw with the advent of timing games 1, the current status of the MEV markets can change quickly and we should expect node operators to be profit maximizing.

Multi-slot MEV with tickets – In the same way that staking pools today may have the incentive to auction off consecutive slots instead of using mev-boost JIT auctions, the (hypothetical) ticket holders who control multiple slots in a row could do the same. This would be part of a secondary market for tickets that would arise once they are assigned a slot in the execution proposer lookahead. This is not qualitatively different than the potential for multi-slot block sales today. In either case, the owners of the execution block proposing rights can sell multi-slot bundles either on their own or by cartelizing with other proposers.

Possible mitigation #1: randomness – Both the beacon and execution lotteries help mitigate the risk of multi-slot MEV. By randomizing the beacon proposer, there is a different validator constructing an inclusion list during each slot. This inclusion list constrains the action space of the execution proposer. Further, if we work towards SSLE, the randomly selected beacon proposer maintains privacy and is thus protected from attack (e.g., a network DDoS) by a multi-slot execution proposer and can safely construct and broadcast their inclusion list. The execution proposer selection is also random, so it is not possible to directly purchase consecutive slots from the protocol (though we acknowledge that a secondary market for this could evolve with or without execution tickets).

Possible mitigation #2: honest inclusion list usage – Under the execution tickets design, the existing beacon proposers build inclusion lists that enforce constraints on the execution block. The potential for multi-slot MEV is reduced greatly if all beacon proposers accurately fill their inclusion list based on their view of the mempool (though the rational beacon proposers may choose to accept a bribe to keep their list empty – see “Fun and games” 1). This could be rebranded as producing “template blocks”, where beacon proposers locally build a candidate block and the execution proposers can reorder and insert but must use all the transactions in the template.

Possible mitigation #3: block or inclusion list maximization – The “maximization” concept is explored in the mev-burn design, where we use the attesting committee to enforce some properties of the block that is proposed. Even with execution tickets as the primary market, we could consider enshrining PBS to bring some of the secondary market (the JIT block auction) into view of the protocol and using the committee-based enforcement of block maximization to limit the benefit of controlling multiple consecutive execution rounds. Similarly, inclusion list maximization or proposer multiplicity 4 could also be used to ensure that an inclusion list is sufficiently utilized.

Possible mitigation #4: encrypted mempools – The longer-term solution of encrypted mempools helps dramatically for multi-slot MEV. When combined with block maximization (enforcement by the attesting committee), encrypted mempools force the execution proposer to decide between leaving all transactions out or including all of them. This further reduces the action space of the execution proposer.

Possible mitigation #5: upfront charge of missed slot fee – The penalty for a missed slot could be charged as a minimum fee for the ticket itself. This value is refunded assuming the execution block lands onchain when the execution ticket is selected. This would increase the capital requirements of buying many tickets in a row (adding additional stake for execution proposing, with an offline slashing condition).

Open questions

As with any early research topic, many details need to be further explored. We include a (non-exhaustive) list of questions that need to be answered to flesh out the execution tickets design.