The issues surrounding ticket sales, including MEV (what is MEV?!) and the timing of ticket sales (and time games), seem to be more aligned with concerns at the execution layer rather than questions about what the Ethereum consensus can reasonably achieve, while still maintaining limited hardware requirements.
Even if (a big assumption) a protocol could implement a stricter ticket sales market, the design space for such a mechanism is enormous. Many potential pricing mechanisms have been discussed, such as binding curves, 1559-style dynamic pricing, auctions, etc.; making general statements about these goes beyond the scope of this article. Therefore, we focus on the “unlimited, 1 WEI fixed price” version of the execution ticket, where the internal complexity is minimized. In this framework, we can ask a burning question, “Given a set of execution ticket holders, how do we choose the winners?”… Sounds simple, right? Well, even for such a seemingly straightforward question, there is much to be said; let’s explore several different choices.
Model:
Consider a repeated game where players earn MEV rewards by purchasing execution tickets:
– Each period, each player submits a bid representing the number of tickets they wish to purchase. Use vector b to denote bids, where bi is the bid of player i.
– Each player has a value for winning block production rights. Use vector v to represent values, where vi is the value of player i.
– In each time step, an allocation mechanism determines the allocation of each player based on the bid vector. Assuming bidders are risk-neutral, we can equivalently say that each person is assigned a “part of the block”, which can also be interpreted as the “probability of winning a particular block”. In a game with n players, use x: b → [0,1]^n to represent the mapping that implements the allocation mechanism, where xi(b) is the allocation of player i, subject to the constraint ∑i xi(b) = 1 (i.e., full allocation by the mechanism).
– Payments from each player are collected in each round. Use p: b → Rn≥0 to represent the payment rule determined based on the bid set, where pi(b) is the payment of player i.
– Each player’s game utility function is defined as Ui(b) = vi xi(b) – pi(b), where player utility equals the value of winning a block multiplied by the share obtained minus the amount paid.
Familiar Allocation Mechanisms:
Consider two (completely different) possible mechanisms.
– All-Pay Auction (a slight modification of the original execution ticket proposal):
– Each player submits bids during each round. Use vector b to represent bids.
– The probability of winning the game with a bid is the bid value divided by the total bid values.
– Each player must pay their bid regardless of the game outcome (hence called “all-pay”), pi(b) = bi.
– Winner-Takes-All (current PBS implementation):
– Each player submits bids during each round. Use vector b to represent bids.
– The highest bidder wins the game, so x_i(b) = 1 if max(b) = bi and xi(b) = 0 (e.g., in a tie, prioritize the lower bid player).
– Only the winning player pays their bid, so pi(b) = bi if max(b) = bi and pi(b) = 0 (same tie handling).
Comparison of Results:
To demonstrate the different outcomes of these two mechanisms, consider a game with two players where Player 1 has a value of v1 = 4 and Player 2 has a value of v2 = 2 (we consider a fully informed setting where individual values are common knowledge).
All-Pay Auction Results:
– Equilibrium bids: b1 = 8/9, b2 = 4/9
– Equilibrium allocation: x1 = 2/3, x2 = 1/3
– Equilibrium payments: p1 = 8/9, p2 = 4/9
This feels intuitively correct; when v1 = 2 * v2 (Player 1 values the block twice as much as Player 2), Player 1’s bid, receipt, and payment are twice that of Player 2.
Winner-Takes-All Results:
– Equilibrium bids: b1 = 2+ε, b2 = 2
– Equilibrium allocation: x1 = 1, x2 = 0
– Equilibrium payments: p1 = 2+ε, p2 = 0
This is quite different. Player 1’s bid just exceeds Player 2’s value (we use ε to represent a small amount), receiving the entire allocation. Player 2 receives nothing and pays nothing.
Now consider the “income” collected by each mechanism in each scenario (or total bids):
All-Pay Auction income: b1 + b2 = 4/3
Winner-Takes-All income: b1 = 2+ε
The income from the Winner-Takes-All mechanism is higher, equivalent to a more accurate MEV oracle (hence burning or smoothing more MEV) rather than the All-Pay Auction. Intuitively, by allocating block production rights to the player with lower value (as done by the All-Pay Auction), we sacrifice the income that could have been obtained if the entire right was allocated to the player with the highest value. For a more comprehensive treatment, see Appendix 1.
Another factor to consider is the “fairness” or “allocation” of the allocation mechanism. For example, assume we agree on the following metric: √x1⋅x2 (we use geometric mean because it maximizes when x1 + x2 is fixed, and is zero if either x1 or x2 is zero). Now, let’s look at the fairness results of the two candidate mechanisms:
All-Pay Auction fairness: √1/3⋅2/3 ≈ 0.471
Winner-Takes-All fairness: √1⋅0 = 0
Here, the performance of the two mechanisms is reversed – Winner-Takes-All is less fair than All-Pay Auction, as Player 2 does not receive any allocation. This demonstrates the quantitative trade-off between the quality of the MEV oracle and the fairness of the mechanism when allocating block proposal rights.
This small example reveals a key conclusion: there is a fundamental trade-off between the quality of the MEV oracle and fairness. The All-Pay Auction mechanism (the original execution ticket proposal) is fairer because both players have a chance to win the game, encouraging each player (especially high-value players) to adjust their bids accordingly, reducing the income of the mechanism and the accuracy of the MEV oracle. The first-price mechanism triggers higher bids because bidders only need to pay when winning the entire block production rights, increasing income, but this winner-takes-all dynamic makes the allocation unfair.
Open question: Is the All-Pay Auction mechanism the “optimal” defense against Sybil attacks? In a permissionless environment, we only consider mechanisms that guard against Sybil attacks, where players splitting their bids into multiple identities do not benefit. We believe the All-Pay Auction mechanism lies in the ideal range for defending against Sybil attacks, performing well in terms of income/MEV oracle accuracy and fairness. We leave an intriguing open question to determine the degree of “optimality” of the All-Pay Auction mechanism (e.g., we have not found another defense against Sybil attack mechanism that surpasses it in income and fairness).
(Intriguing notes #1 and #2 related to specific calculations can be found in the original text)
Conclusion:
Let’s summarize what we’ve learned. Section 3 demonstrates the fundamental trade-off between the accuracy of the MEV oracle and fairness in the example of the execution ticket mechanism. A protocol may be willing to sacrifice more allocation and entropy fees (in the form of reduced income) to improve and maintain the protocol’s credibility and neutrality. Additionally, deriving equilibrium bids using the model helps us understand how agents may react when faced with various allocation and payment rules.
Further questions (returning to our three W^4 questions):
– What are players competing for? Can we expand the dimensions of the model to allow different players to have different values for different parts of the block (e.g., arbitrageurs may value the top of the block highly but have no value for the rest)?
– When does the game take place? How would the accuracy of the MEV oracle change if the game were played much earlier than during slot time (e.g., pricing future expected MEV vs. current achievable MEV)?
– How to choose block builders? Are there defense mechanisms against Sybil attacks that are superior to All-Pay Auction in terms of income and fairness? Can we formally describe the fundamental trade-off between income and fairness? Given the constraints of defending against Sybil attacks, which alternative allocation and payment rules should be explored (e.g., Tullock contest, where the allocation rule is determined by parameter α>1, formula i=bi^α/∑jbj^α), can we determine the optimal choice?
From a broader perspective, other versions of W^4H questions may require different models for reasoning.
– Who controls the outcome of the game? What conspiracy behaviors may arise in the committee-enforced mechanism version? If instant block auctions continue to take place outside the protocol, should we explicitly describe the secondary market?
– When does the game take place? How critical is network latency when considering early sale of block space compared to sale during the same slot? Is it worth modeling a partially synchronous environment? If multi-slot MEV is feasible, how would the valuations of block builders change?
– Where does the MEV oracle come from? If it comes from the committee, do committee members have incentives for dishonest behavior? Do these incentives depend on whether the captured MEV by the protocol is burned or smoothed?
As always, there are endless open questions, but we hope that (a) W^4H questions contribute to expanding the understanding of block space allocation mechanisms, and (b) an in-depth exploration of allocation mechanisms helps understand the potential design space of execution tickets.
