Co-authored by Ethereum researcher and a16z researcher: Block space allocation mechanism

< 755eb34c-0f91-416c-adf5-28ef74f84b52_718x1420.png","srcnowatermark":null,"fullscreen":null,"imagesize":null,"height":1420,"width":718,"resizewidth":262,"bytes":65796,"alt":null,"title":null,"type":"image="" png","href":null,"belowthefold":true,"topimage":false,"internalredirect":null}"="" class="sizing-normal" alt="" srcset="https://substackcdn.com/image/fetch/w_424,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F755eb34c-0f91-416c-adf5-28ef74f84b52_718x1420.png 424w, https://substackcdn.com/image/fetch/w_848,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F755eb34c-0f91-416c-adf5-28ef74f84b52_718x1420.png 848w, https://substackcdn.com/image/fetch/w_1272,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F755eb34c-0f91-416c-adf5-28ef74f84b52_718x1420.png 1272w, https://img.jinse.cn/7241166_watermarknone.png 1456w" sizes="100vw" loading="lazy">

< alt="upload_cdbf47258422c2a96ea2903ce113a113" class="sizing-normal" alt="upload_cdbf47258422c2a96ea2903ce113a113" title="upload_cdbf47258422c2a96ea2903ce113a113" srcset="https://substackcdn.com/image/fetch/w_424,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F7f1ca08a-f1eb-4b96-acdf-a17adac0e5c6_552x367.jpeg 424w, https://substackcdn.com/image/fetch/w_848,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F7f1ca08a-f1eb-4b96-acdf-a17adac0e5c6_552x367.jpeg 848w, https://substackcdn.com/image/fetch/w_1272,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F7f1ca08a-f1eb-4b96-acdf-a17adac0e5c6_552x367.jpeg 1272w, https://img.jinse.cn/7241167_watermarknone.png 1456w" sizes="100vw" loading="lazy">

< bb25d978-9246-4898-999b-182d5d5de458_328x500.jpeg","srcnowatermark":null,"fullscreen":null,"imagesize":null,"height":500,"width":328,"resizewidth":null,"bytes":null,"alt":"upload_23e73e8aae1d7223973af83053d41ebc","title":null,"type":null,"href":null,"belowthefold":true,"topimage":false,"internalredirect":null}"="" class="sizing-normal" alt="upload_23e73e8aae1d7223973af83053d41ebc" title="upload_23e73e8aae1d7223973af83053d41ebc" srcset="https://substackcdn.com/image/fetch/w_424,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fbb25d978-9246-4898-999b-182d5d5de458_328x500.jpeg 424w, https://substackcdn.com/image/fetch/w_848,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fbb25d978-9246-4898-999b-182d5d5de458_328x500.jpeg 848w, We present an outline of a number of different proposed mechanisms. Note that this is only a subset of the rather large literature around these designs — (see infinite buffet). For each of the following, we only summarize the key ideas (see Related Work for details).

• Execution Tickets

• Key Idea: Block construction and proposal rights are sold directly through "tickets" issued by the protocol. Ticket holders are randomly sampled as block builders, with advance notice. Ticket holders are entitled to produce blocks during an allotted time period.

• Block Auction PBS (Proposer-Builder Separation)

• Key idea: The protocol grants block production rights through a random leader election process. Selected validators can sell their blocks directly to the builder market or build them locally. Builders must commit to specific blocks in an auction. mev-boost is an out-of-protocol instantiation of block auction PBS; ePBS is the in-protocol equivalent, as originally proposed.

• MEV Burning / MEV Smoothing

• Key idea: A committee is responsible for setting a floor on the bid chosen by the proposer in the auction. By requiring the proposer to choose a "large enough" bid, a MEV oracle is created. MEV is either smoothed among committee members or burned (smoothed to all ETH holders).

• Slot Auction PBS

• Key idea: Similar to block auction PBS, but instead of selling slots to builders, the market does not require them to commit to specific blocks - sometimes called block space futures. By not requiring builders to commit to specific blocks, future slots can be auctioned in advance, rather than waiting for the slot itself.

• Partial Block Auctions

• Key idea: Allows for more flexible units of block space to be sold. Instead of selling entire blocks or slots, allow proposers to sell a portion of their block, e.g. the top of the block (most valuable to arbitrageurs), while keeping the rest of the block for construction. Runs in other Proof-of-Stake networks, such as Jito's block engine and Skip's MEV lane.

• APS Burning is Execution Auction

• Key idea: New proposal from Barnabé forces proposers to auction block construction and proposal rights in advance. Slots are sold in advance (fixed time), without committing to a specific block; committees (like MEV burning/smoothing) ensure that bids are large enough.

By comparing these proposals’ answers to the W^4H problem, we can see that they are different pieces of the same design space.

Applying W^4H: A Comparative Analysis

For each W^4H problem, we describe the different trade-offs in the above proposals. For the sake of brevity, we will not analyze each problem against each proposal, but instead focus on highlighting the key differences brought by each problem line.

• Who controls the outcome of the game?

• In the execution ticket mechanism, the protocol determines the winner of the game by randomly selecting the ticket holder.

• In the block auction PBS, the proposer (the leader selected by the protocol) unilaterally selects the winner of the game.

• In the MEV burning mechanism, the proposer still chooses the winner, but the winning bid is constrained by the committee, reducing the proposer's autonomy.

• What is being competed for?

• In block auction PBS, entire blocks are sold, but bids must commit to block contents.

• In slot auction PBS, entire blocks are sold, but no commitment to specific block contents is required.

• In partial block PBS, a portion of a block is sold.

• When does the game take place?

• In block auction PBS, auctions take place during slots.

• In slot auction PBS, auctions can take place many slots (e.g., 32) in advance, since there are no commitments to block contents.

• In an execution ticket mechanism, tickets are assigned to slots with a fixed lead time.

• Where does the MEV oracle come from?

• In the MEV burn/smoothing mechanism, the committee enforces that the selected bid is large enough, and this bid is the oracle.

• In the execution ticket mechanism, the total cost of the ticket serves as the oracle.

• How are block builders selected?

• In the block auction PBS, any outsourced block production is a winner-takes-all allocation, and the highest bidder gets the right to build the block.

• In the execution ticket mechanism, many different allocation mechanisms can be implemented. For example, in the original proposal, tickets were chosen randomly and the mechanism was “proportional to the number of tickets”; in this case, the highest bidder (the one holding the most tickets) simply had the highest probability of being selected, but was not guaranteed to get the right to build a block.

If the above seems cryptic, don’t worry. The following sections will dive deeper into these different allocation mechanisms.

Motivation Recap

Before moving on, let’s recap our original motivations:

The block space allocation mechanism is designed to keep validator rewards homogeneous in the presence of MEV.

This is a great foundation, but if that’s our only goal, why not just continue with mev-boost? Keep in mind that mev-boost has some negative side effects that we may need to design our final protocol to be resistant to. We highlight four other potential design goals for blockspace allocation mechanisms:

1. Encourage broader competition among builders.

2. Allow trusted interactions between validators and builders.

3. Incorporate MEV awareness into base-layer protocols.

4. Remove MEV from validator rewards entirely.

Note that while (1, 2, 3) are relatively uncontroversial, (4) is more controversial (and requires (3) as a prerequisite). Protocols may want to ensure that consensus layer rewards (the part controlled by the protocol) more accurately reflect the incentives of the entire system by eliminating MEV rewards. This also gets into the question of staking macroeconomics and protocol issuance—a more political discussion. On the other hand, MEV rewards are a byproduct of network usage; MEV can be viewed as a value capture mechanism for the native token. We do not attempt to resolve these issues here, but rather explore how different answers affect mechanism design.

What can we do at the protocol design level to meet these expectations? As mentioned above, there are many trade-offs to consider, but in the following section we will explore "How are block builders selected?" to improve on some of these aspects.

(3) Questioning

Editor's Note: As mentioned before, this section is longer and more technical than the others - if you have limited time (or interest), feel free to skip to Section 4.

Section Objectives: Show the quantitative trade-offs between MEV oracle quality and mechanism fairness between the two most familiar methods of allocating block proposal rights (which we call "Proportional-all-pay" and "Winner-take-all").

We intend to achieve this goal through the following subsections:

The Basics

Before diving into the possible allocation mechanisms implemented by execution tickets, we must first establish the model. Consider a protocol where the rules for selling execution tickets are as follows:

1. The price is fixed at 1 WEI, and

2. An unlimited amount of tickets can be bought and sold.

Note: This version of execution tickets effectively creates two separate staking mechanisms - one for attestation, and one for proposals. Small changes in design, such as not allowing tickets to be resold to the protocol, could have huge impacts on market operation, but this is not the focus of this article. We are narrowly exploring the problem of block space allocation in the presence of a pre-existing set of ticket holders.

It is worth noting that from the perspective of the protocol, block producers and attesters are separate individuals - individuals must choose which part of the protocol to participate in, by deciding whether to stake or buy tickets. The secondary note market could develop into a venue where structuring rights are sold in a timely manner in the auction market (much as mev-boost does today).

Alternatively, builders may choose to interact with the protocol directly and purchase execution tickets, but their capital may be better suited as active liquidity, capturing arbitrage between trading venues. Therefore, they may prefer to purchase block space at auction on the secondary market.

Why are we limited to this mechanism of publishing prices with an infinite supply? Two reasons:

1. It’s not clear that a complex market can be implemented at the consensus layer. Client optimizations make it possible for any validator with consumer-grade hardware to participate in the network. This requirement may be incompatible with fast auctions, bonding curves, or other possible ticket sale mechanisms. Questions about the number of tickets sold, the MEV included in the on-chain ticket sale (meta-MEV?!), and the timing (and timing games) of ticket sales seem closer to the concerns of the execution layer than to what Ethereum consensus can reasonably implement while keeping hardware requirements limited.

“It is conceivable that the inclusion of ET market-related transactions could trigger MEV, regardless of whether these transactions are included in the beacon block or the execution payload.” - Barnabé said in More pictures about proposers and builders.

1. Even if (a big assumption) the protocol is able to implement a more rigorous market for ticket sales, the design space for that mechanism is enormous.  Many potential pricing mechanisms have been discussed, e.g., bonding curves, 1559-style dynamic pricing, auctions, etc.; making general statements about these is beyond the scope of this article.

Therefore, we focus on the "unlimited, 1 WEI fixed price" version of exercise tickets, where the protocol internalizes the least complexity. With this framework, we can ask a question that may be burning you, "Given a set of exercise ticket holders, how do you choose the winner?"... Sounds simple, right? It turns out that there is a lot to say about even such a seemingly simple question; let's explore a few different options.

x:b→[0,1]n ∑ixi(b)=1 p:b→Rn≥0

Model

Consider a repeated game of obtaining MEV rewards by purchasing execution tickets:

• Each cycle, each player submits a bid, indicating the number of tickets they purchased. The bids are represented by the vector  b , where bi is the bid of the i-th player.

• Each player has a valuation for winning the right to produce a block. The valuations are represented by the vector  v, where vi is the valuation of the i-th player.

• 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 of them is assigned a "portion of the block", which can also be interpreted as "the probability of winning a certain block". In a game with n players, denote by x:b →[0,1]^n the mapping that implements the allocation mechanism, where xi(b) is the allocation to the ith player, subject to the constraint that ∑ixi(b)=1 (i.e. the mechanism fully allocates).

• Each player's payment is collected at each round. Denote by p:b →Rn≥0 the payment rule determined from the set of bids, where pi(b) is the payment to the ith player.

• Each player's game utility function is defined as Ui(b)= vi xi(b) - pi(b), i.e., a player's utility is equal to the value of the block they won times the portion they won minus the amount they paid

Familiar Allocation Mechanisms

Consider two (completely different) possible mechanisms.

Proportional Full Payment (a slight modification of the original execution ticket proposal)

• During each round, all players submit bids. The bids are represented by the vector b.

• The probability of a bid winning the game is the bid value divided by the sum of all bid values

• 

  b) = bi.
  

Winner Takes All (Current PBS Implementation)

• During each round, all players submit bids. Use the vector b to represent the bids.

• The highest bidder wins the game, so x_i(b) = 1 if max(b) = bi and xi(b) = 0 (e.g., in case of a tie, preference is given to the player with the lower bid).

• Only the winning player pays his bid, so pi(b) = bi if max(b) = bi and pi(b) = 0 (same treatment for ties).

Comparing Results

To demonstrate the different outcomes of the two mechanisms, consider a game with two players, where Player 1 has valuation v1 = 4 and Player 2 has valuation v2 = 2 (we consider a perfect information setting where individual valuations are common sense).

• Proportional Full Payment Result:

• Equilibrium bids: b1 = 8/9, b2 = 4/9

• Equilibrium splits: 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 bids, receives, and pays twice as much as Player 2.

• Winner-take-all outcome:

• Equilibrium bid: b1 = 2+ϵ, b2 = 2

• Equilibrium allocation: x1 = 1, x2 = 0

• Equilibrium payoff: p1 = 2+ϵ, p2 = 0

This is quite different. Player 1's bid just exceeds Player 2's value (we'll use ϵ to represent a small amount), and receives the full allocation. Player 2 gets nothing and pays nothing.

Now consider the “revenue” (or sum of bids) collected by the mechanism in each case:

• Proportional all-in revenue: b1 + b2 = 4/3

• Winner-take-all revenue: b1 = 2+ϵ

Winner-take-all revenue is higher, equating to a more accurate MEV oracle (and thus more MEV burned or smoothed by the protocol) than Proportional all-in. Intuitively, by allocating block production rights to lower-value players (as Proportional all-in does), we give up revenue that we would have received if the entire right had been allocated to the highest-value player. For a more complete treatment, see Appendix 1.

Another factor to consider is the “fairness” or “distribution” of the allocation mechanism. For example, suppose we agree on the following metric: √x1⋅x2 (we use the geometric mean because it is maximal when x1 = x2 if the sum of x1 + x2 is fixed, and is zero if either x1 or x2 is zero). Now, let’s look at the fairness results for the two candidate mechanisms:

• Proportional Full Payout Fairness: √1/3⋅2/3≈0.471

• Winner Takes All Fairness: √1⋅0=0

Here, the “performance” of the two mechanisms is flipped — winner-takes-all is not as fair as proportional full payout, because “Player 2” does not receive any allocation. This demonstrates the quantitative tradeoff 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 tradeoff between the quality and fairness of the MEV oracle. The Proportional Full Payment mechanism (aka the original Execution Ticket proposal) is fairer because both players have some probability of winning the game, which encourages each player (especially high-value players) to adjust their bids accordingly, which reduces the mechanism's revenue and the accuracy of the MEV oracle. The First Price mechanism induces higher bids because bidders only pay if they win the entire block production right, which increases revenue, but this winner-take-all dynamic makes the distribution unfair.

Open Question: Is the Proportional Full Payment mechanism the "best" Sybil-resistant mechanism? In the permissionless setting, we only consider Sybil-resistant mechanisms, i.e., players do not benefit by splitting their bids into multiple identities. We believe that the Proportional Full Payment mechanism is in the ideal range of Sybil-resistant mechanisms, performing well in terms of both revenue/MEV oracle accuracy and fairness. We leave it as an interesting open question to determine the degree of "optimality" of the Proportional Full Payment mechanism (e.g., we fail to find another Sybil-resistant mechanism that outperforms it in both revenue and fairness).

(Notes #1 and #2 related to the specific calculations can be found in the original text)

(4) Corollary

Let us summarize what we have learned. Section 3 demonstrated the fundamental trade-off between MEV oracle accuracy and fairness in the context of the execution ticket mechanism. A protocol may be willing to pay for more allocation and entropy (in the form of reduced revenue) to improve and maintain the protocol's credible neutrality. Moreover, using the model to derive equilibrium bids helps us understand how agents might react when faced with various allocation and payment rules.

Further questions (returning to our three W^4 questions):

What are the players competing for? Can we extend the model dimensionality to allow different players to place different values ​​on different parts of the block (e.g., arbitrageurs may place particular value on the top of the block, but place no value on the rest)?

When is the game played?  How does the accuracy of MEV oracles change if the game is played far in advance rather than during the slot (e.g., pricing future expected MEV vs. currently achievable MEV)?

How are block builders selected?  Is there a Sybil-resistant mechanism that outperforms pro rata full payouts in terms of both revenue and fairness? Can we more formally characterize the fundamental tradeoff between revenue and fairness? Given the Sybil-resistant constraint, what alternative allocation and payout rules should be explored (e.g., the Tulloch tournament, where the allocation rule is determined by a parameter α>1, as i=bi^α/∑jbj^α), and can we identify the optimal choice?

Returning to the broader perspective, other versions of the W^4H problem may require different models to reason about.

Who controls the outcome of the game?  What kind of collusive behavior might emerge in a committee-enforced version of the mechanism? If instant block auctions continue to take place outside the protocol, should we explicitly characterize a secondary market?

When do games take place?  How critical is network latency when considering early vs. same-slot sales of block space? Is it worth modeling a partially synchronous environment? If multi-slot MEV is feasible, how does the valuation of block builders change?

Where do MEV oracles come from?  If from a committee, do committee members have incentives to behave dishonestly? Do these incentives depend on whether MEV captured by the protocol is burned or smoothed?

As always, there are many open questions, but we hope that (a) the W^4H problem helps expand our understanding of block space allocation mechanisms, and (b) a deeper exploration of allocation mechanisms helps us understand the potential design space for execution tickets.