Written by: Mike, Ethereum Researcher; Pranav Garimidi, Tim Roughgarden, a16z Researcher
Compiled by: 0XNATALIE
"On block-space distribution mechanisms", co-authored by Ethereum researcher Mike and a16z researchers Pranav Garimidi and Tim Roughgarden, systematically explores how block space distribution mechanisms affect MEV. First, it explains the necessity of introducing an intra-protocol mechanism to handle block space allocation, and then evaluates and compares existing distribution schemes through the "Who, What, When, Where, How" (W^4H) framework, and further analyzes how the execution ticket model (execution tickets) can strike a balance between improving MEV perception and distribution fairness. The following is the translation of the article.
TL;DR: Blockspace, or the capacity for transactions, is the primary resource derived from blockchains. As the crypto ecosystem expands and professionalizes, the value generated by the efficient use of blockspace (MEV) plays an important role in the economics of permissionless consensus mechanisms. The research community has written a lot of articles exploring how protocols should deal with MEV (see related work). The discussion over the past few years has resembled the storyline of the "blind men and the elephant", with many different perspectives, solutions, and theories proposed, but each angle seems fragmented and difficult to compare with each other. The first half of this article aims to present a macro picture of the "MEV elephant" by distilling a series of core issues and exploring how existing proposals deal with these issues. The second half focuses on the allocation mechanism enabled by execution tickets, showing an important new insight - there is a trade-off between the quality of the MEV oracle within the protocol and the fairness of the mechanism.
Article Organization: Section 1 explains why an in-protocol mechanism is needed to handle block space allocation as part of the “finality” of Proof-of-Stake. Section 2 lists five dimensions along which block space allocation mechanisms can be measured, using a familiar set of questions: who, what, when, where, how (W^4H questions for short). Section 3 explores how block builders are selected, focusing on the execution ticket model. Section 4 opens up the discussion by summarizing and raising follow-up open questions.
Note: This is a long article with some technical elements. We encourage readers to focus on the sections of the article that interest them most. Sections 1, 2, and 4 provide a broad view of existing proposals and our proposed analysis methods. Section 3 (~44% of the article, but 100% of the math) provides a detailed analysis of the allocation mechanism enabled by the execution ticket design. This section can be read in order, read independently, or skipped entirely - it's up to you!
(1) Motivation
Before we delve into this complex topic, let’s briefly explain the necessity of a block space allocation mechanism. In Proof-of-Stake, validators are tasked with generating and voting for blocks. The following picture from Barnabé’s article “More pictures about proposers and builders” describes these as proposing and attesting rights.
1) What
The block space allocation mechanism is the process by which the protocol determines the owner of the "proposal" or "block construction" rights. Proof-of-Stake protocols usually use one of the following rules:
Blockspace (Proposal) Rights – Randomly selects a validator as a leader and allows it to create the next block.
Voting (witness) power – All validators vote on the block they consider to be the canonical head within a certain time window.
Validators are rewarded for performing these tasks. We categorize them based on where the rewards come from as either consensus layer (protocol issuance, e.g., newly minted ETH) or execution layer (transaction fees and MEV):
Consensus Layer
a. Attestation deltas – (see attestation deltas).
b. Block Reward – (see get_proposer_reward).
Execution Layer
a. Transaction fees – (see gas tracker).
b. MEV (transaction ordering) – (see mevboost.pics).
Rewards 1a, 1b, and 2a are well known and “within the protocol’s view.” MEV rewards are more challenging because fully capturing the value realized through transaction ordering is difficult. Unlike other rewards, the amount of MEV in a block is effectively unknowable (as a permissionless and anonymous system, it is impossible to track the controller of each account and any off-chain activity that may be profitable in conjunction with it). MEV can also vary wildly over time (e.g., with price fluctuations), causing execution layer rewards to have greater variance than consensus layer rewards. Additionally, the Ethereum protocol has no insight into the MEV generated and extracted by its transactions at implementation time. To increase the protocol’s visibility into MEV, many mechanisms attempt to estimate the MEV in a given block, which we call MEV oracles. Block space allocation mechanisms are often capable of producing such oracles, making the protocol “MEV-aware.”
This begs the question, why does the protocol care about MEV awareness? One answer: MEV awareness might increase the protocol's ability to maintain reward parity when validators have varying levels of complexity. For example, if the protocol could accurately burn all MEV, then the validator incentives would be entirely within the protocol's horizon (as in 1a, 1b, and 2a above). Alternatively, a mechanism to share all MEV among validators regardless of their complexity (e.g., mev-smoothing) would seem to facilitate a larger, more diverse, and decentralized set of validators, while Keep MEV rewards as an additional staking incentive. Without MEV awareness, validators who are best able to extract or smooth MEV (e.g. due to relationships with block builders, proprietary algorithms/software, access to exclusive order flows, and economies of scale) may receive disproportionately high rewards , exerting significant centralization pressure on the protocol.
The Ethereum protocol design strives to maintain a decentralized validator set at all costs. It should go without saying, but for completeness: the protocol’s credible neutrality, censorship resistance, and permissionlessness directly depend on a decentralized validator set.
Current block space allocation
In Ethereum today, mev-boost accounts for about 90% of blocks. With mev-boost, proposers (randomly selected validator leaders) sell their block construction rights to the highest bidder through an auction. The following diagram shows this process (we exclude relays because they are actually extensions of the builders).
Proposers are incentivized to outsource their block building because builders (agents that specialize in ordering transactions to extract MEV) pay them more than they could earn by building blocks themselves. Going back to our goal of keeping validator rewards equal in the presence of MEV, we see that mev-boost allows all validators to enter the builder market, effectively keeping MEV rewards close to parity between independent stakers and professional staking service providers — great! But…
Of course, there are some issues with mev-boost that still bother some members of the Ethereum community. In short, here are some of the negative side effects of taking mev-boost:
Relays – These trusted third parties broker block sales between proposers and builders. Heavy reliance on relays increases the overall fragility of the protocol, as demonstrated by repeated, incidents involving, relays. Additionally, since relays have no inherent revenue stream, more (and closed-source) methods of capturing profits are being implemented (e.g., timing gaming and bid adjustment as a service).
Out-of-protocol software vulnerability – In addition to relaying, participating in the mev-boost market requires validators to run additional software. The standard suite of independent staking now involves running four binaries: (i) consensus beacon node, (ii) consensus validator client, (iii) execution client, and (iv) mev-boost. Not only does this add significant overhead for independent stakers, relying on this software also provides another potential point of failure during a hard fork. See the Shapella incident and the Dencun upgrade to understand the complexities caused by more out-of-protocol software.
Builder Centralization and Censorship - While this was probably inevitable, the mass adoption of mev-boost has accelerated builder centralization. Three builders account for approximately 95% of mev-boost blocks (85% of all Ethereum blocks). mev-boost implements an open outcry, first-price, winner-takes-all auction, leading to high levels of builder centralization and strategic bidding. Inclusion lists or other censorship resistance tools have not yet been implemented, and builders have outsized influence over the inclusion and exclusion of transactions - (see censorship.pics).
Timing Games – While timing games are considered a fundamental problem with Proof-of-Stake protocols, mev-boost drives staking service providers to compete on thin margins. Furthermore, relayers (who conduct mev-boost auctions on behalf of proposers) act as complex middlemen that facilitate timing games. As a result, we see marketing incentives to increase yields by staking with a specific provider.
(2) Enumeration
Having set the necessary stage, let’s take a closer look at the nature of the block space allocation mechanism.
Elements of Block Space Allocation
Consider the game of acquiring block space; MEV incentivizes agents to participate, and the combination of in-protocol and out-of-protocol software defines the rules. What factors should be considered when designing this game? To answer this question, we use the familiar rhetorical pattern of "who, what, when, where, how" (hopefully Section 1 answered the "why"), which we call the W^4H problem.
Who controls the outcome of the game?
What is the commodity that players fight over?
When does the game take place?
Where does the MEV oracle come from?
How to choose a block builder?
These questions may seem overly simplistic, but when considered individually, each can be seen as an axis to measure the space of mechanism designs. To demonstrate this, we highlight some different kinds of block space allocation mechanisms that have been explored in the past. While they may seem unrelated, their relationship becomes clear by understanding how they answer the W^4H question.
Execution Tickets and Other Methods
We present a rundown of many different proposed mechanisms. Note that this is only a subset of the rather large literature around these designs — (see infinite buffet). For each below, we only summarize the key ideas (see related work for details).
Execution Ticket
Key idea: Block construction and proposal rights are sold directly through "tickets" issued by the protocol. Ticket holders are randomly sampled as block builders and notified in advance. Ticket holders have the right to produce blocks in the allocated time period.
Blockchain Auction PBS (Proposer-Builder Separation)
Key idea: The protocol grants block production rights through a randomized leader election process. Selected validators can sell their blocks directly to the builder market or build locally. Builders must commit to a specific block in an auction. mev-boost is an out-of-protocol instantiation of block auction PBS; ePBS, as originally proposed, is the in-protocol equivalent.
MEV Burn / MEV Smoothing
Key idea: A committee is responsible for setting a minimum value on the bids chosen by proposers in the auction. By requiring proposers 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 commitment 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 Auction
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 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 bids are large enough.
By comparing the responses of these proposals on the W^4H problem, we can see that they are different parts of the same design space.
Applying W^4H: 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 the situation of each problem corresponding to 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 ticket holders.
In block auction PBS, the proposer (the leader elected by the protocol) unilaterally chooses 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 are you competing for?
In a block auction PBS, entire blocks are sold, but bids must commit to the block contents.
In slot auctions, PBS, entire blocks are sold, but no commitment to specific block contents is required.
In a partial block PBS, a portion of the block is sold.
When does the game take place?
In block auction PBS, auctions are conducted during slots.
In slot auction PBS, the auction can be conducted ahead of many slots (e.g., 32) because there is no commitment to the contents of the block.
In the execution ticket mechanism, tickets are assigned to slots with fixed lead times.
Where does the MEV oracle come from?
In the MEV burning/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 acts as an oracle.
How to choose a block builder?
In the block auction PBS, any outsourced block production is a winner-takes-all allocation, and the highest bidder obtains the block construction rights.
In the execution ticket mechanism, many different allocation mechanisms can be implemented. For example, in the original proposal, tickets are randomly selected and the mechanism is "allocated in proportion to the number of tickets"; in this case, the highest bidder (the one holding the most tickets) only has the highest probability of being selected, and is not guaranteed to obtain the right to build a block.
Don’t worry if the above seems confusing. The following sections will dive deeper into these different allocation mechanisms.
Motivation Review
Before we go on, let's revisit our original motivation:
The block space allocation mechanism is designed to maintain homogeneity of validator rewards in the presence of MEV.
This is a great foundation, but if that is our only goal, why not just stick 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 the block space allocation mechanism:
Encourage competition from a wider range of builders.
Allows trusted interaction between validators and builders.
Incorporate MEV awareness into base layer protocols.
Completely remove MEV from validator rewards.
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 questions such as staking macroeconomics and protocol issuance - a more political discussion. On the other hand, MEV rewards are a byproduct of network usage; MEV can be seen 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 align with these expectations? As mentioned above, there are many trade-offs to consider, but in the next 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.
Partial Objective: Show the quantitative trade-off between MEV oracle quality and mechanism fairness between the two most familiar methods of distributing block proposal rights (which we call “Proportional-all-pay” and “Winner-take-all”).
We intend to achieve this goal through the following sub-parts:
Basics
Before we dive into the possible distribution mechanism of execution tickets, we must first build a model. Consider a protocol where the rules for selling execution tickets are as follows:
The price is fixed at 1 WEI, and
Unlimited amounts of notes can be bought and sold.
Note: This version of execution tickets effectively creates two separate staking mechanisms - one for proofs and one for proposals. Small changes in design, such as not allowing tickets to be resold to the protocol, could have large impacts on market operation, but this is not the focus of this article. We are narrowly exploring the problem of allocating block space given an existing set of ticket holders.
It is important to note that from the perspective of the protocol, block producers and attesters are separate entities - individuals must choose which part of the protocol to participate in, by deciding whether to stake or buy notes. A secondary note market may develop as a venue for selling build rights in a timely auction market (much like mev-boost does today).
Additionally, builders may choose to interact with the protocol directly and purchase execution tickets, but their capital may be better suited to serve 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 and unlimited supply? Two reasons:
1. It’s not clear if a complex market can be implemented at the consensus layer. Client optimizations enable 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 (meta-MEV?!) included in the on-chain ticket sale, 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”.
2. 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 huge. 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 the execution ticket, in which the complexity internalized by the protocol is minimal. With this framework, we can ask a question that may be burning your heart, "given a set of execution ticket holders, how to 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 where you earn MEV rewards by purchasing execution tickets:
Each cycle, each player submits a bid, indicating the number of tickets they want to buy. 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. Let us denote the valuations by a vector v, where vi is the valuation of the i-th player.
At each time step, an allocation mechanism determines the allocation of each player based on the bid vector. Assuming that 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, the mapping that implements the allocation mechanism is represented by x: b →[0,1]^n, where xi(b) is the allocation of the i-th player, under the constraint that ∑ixi(b)=1 (i.e., the mechanism fully allocates).
Each player’s payment is collected in each round. Let p: b →Rn≥0 denote the payment rule determined from the bid set, where pi(b) is the payment of the i-th player.
The game utility function of each player is defined as Ui(b) = vi xi(b) - pi(b), that is, the player's utility is equal to the value of the block he won multiplied by the part he got minus the amount he paid
Familiar allocation mechanism
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 vector b.
The probability of a bid winning the game is the bid value divided by the sum of all bid values
Each player pays his or her bid regardless of the outcome of the game (hence the term "full pay"), pi(b) = bi.
Winner Takes All (Current PBS Implementation)
During each round, all players submit bids. The bids are represented by vector b.
The highest bidder wins the game, so x_i(b) = 1 if max(b) = bi and xi(b) = 0 (i.e., in case of a tie, the player with the lower bid is given priority).
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 illustrate the different outcomes of these two mechanisms, consider a game with two players where player 1 has a valuation v1 = 4 and player 2 has a valuation v2 = 2 (we consider a perfect information setting where individual valuations are common sense.).
Proportional full payment results:
Equilibrium bid: b1 = 8/9, b2 = 4/9
Balanced distribution: x1 = 2/3, x2 = 1/3
Equilibrium payoff: 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 Takes All Results:
Equilibrium bid: b1 = 2+ϵ, b2 = 2
Balanced distribution: 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 denote it by a small amount), and receives the entire allocation. Player 2 gets and pays nothing.
Now consider the “income” (or sum of bids) collected by the mechanism in each case:
Proportional full-payment income: b1 + b2 = 4/3
Winner-takes-all income: b1 = 2+ϵ
Winner-take-all has higher revenue, equivalent to a more accurate MEV oracle (and thus more MEV burned or smoothed by the protocol), than proportional payout. Intuitively, by assigning block production rights to lower-value players (as proportional payout does), we forgo revenue that would have been earned if the entire right had been assigned 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 if the sum of x1 + x2 is fixed, the geometric mean is maximum when x1 = x2, and is zero if any x1 or x2 is zero). Now, let’s look at the fairness results of two candidate mechanisms:
Proportional full payment fairness: √1/3⋅2/3≈0.471
Winner-takes-all fairness: √1⋅0=0
Here, the “performance” of the two mechanisms is flipped — winner-take-all is not as fair as paying in full proportion, because “Player 2” does not receive any allocation. This demonstrates the quantitative trade-off between MEV oracle quality and mechanism fairness when allocating block proposal rights.
This small example reveals a key conclusion: there is a fundamental trade-off between the quality and fairness of the MEV oracle. The Proportional Full Payment mechanism (the original execution ticket proposal) is fairer because both players have a certain probability of winning the game, which encourages each player (especially high-value players) to adjust their bids accordingly, reducing the revenue of the mechanism 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, thereby increasing revenue, but this winner-take-all dynamic makes the distribution unfair.
Open Question: Is Proportional Full Payment the "best" Sybil-resistant mechanism? In a permissionless setting, we only consider Sybil-resistant mechanisms where players do not benefit by splitting their bids across multiple identities. We believe that Proportional Full Payment is in the ideal range of Sybil-resistant mechanisms, performing well in terms of both revenue/MEV oracle accuracy and fairness. We leave as an interesting open question the degree to which Proportional Full Payment is "optimal" (e.g., we fail to find another Sybil-resistant mechanism that outperforms it on both revenue and fairness).
(For side notes#1and#2related to the specific calculations, please see the original text)
(4) Inference
Let’s 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. Furthermore, using the model to derive equilibrium bids helps us understand how agents might react when faced with various allocation and payment rules.
Further questions (back to our three W^4 problems):
What are the players competing for? Can we expand the model to allow different players to place different values on different parts of the block (e.g., an arbitrageur may place particular value on the top of the block, but place no value on the rest)?
When does the game take place? How does the accuracy of the MEV oracle change if the game takes place far in advance rather than during the slot (e.g. pricing future expected MEV vs. currently achievable MEV)?
How are block builders selected? Are there Sybil-resistant mechanisms that outperform proportional full payments in terms of both revenue and fairness? Can we more formally describe the fundamental trade-off between revenue and fairness? Given Sybil-resistant constraints, what alternative allocation and payment rules should be explored (e.g., the Tollock competition, 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 collusion might occur in a committee-enforced version of the mechanism? If instant block auctions continue to take place outside the protocol, should we explicitly describe a secondary market?
When does the game take place? How critical is network latency when considering selling block space in advance vs same-slot sales? Is it worth modeling a partially synchronous environment? How would valuations change for block builders if multi-slot MEV were feasible?
Where does the MEV oracle come from? If it comes from a committee, do committee members have incentives to behave dishonestly? Do these incentives depend on whether the 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 will help expand our understanding of block space allocation mechanisms, and (b) a deeper exploration of allocation mechanisms will help us understand the potential design space of execution tickets.
