"On block-space distribution mechanisms" co-authored by Ethereum researcher Mike and a16z researchers Pranav Garimidi and Tim Roughgarden systematically explores how the block space allocation mechanism affects MEV. First, the necessity of introducing an in-protocol mechanism to handle block space allocation is explained. Then, the existing allocation schemes are evaluated and compared through the framework of "Who, What, When, Where, How" (W^4H), and further in-depth analysis is made on how the execution ticket model can strike a balance between improving MEV perception and allocation fairness. The following is the translation of the article.
TL;DR: Block space, that is, the capacity contained in transactions, is the main resource derived from blockchains. As the crypto ecosystem expands and specializes, the value generated by the efficient use of block space (MEV) plays an important role in the economics of permissionless consensus mechanisms. The research community has written a lot of articles to explore how protocols should deal with MEV (see Related Work). The discussion over the past few years resembles the storyline of the blind men and the elephant, with many different viewpoints, solutions, and theories proposed, but each angle seems fragmented and difficult to compare. 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 address these issues. The second half focuses on the allocation mechanism enabled by the execution ticket, demonstrating an important new insight - there is a trade-off between the quality of the in-protocol MEV oracle 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 Proof-of-Stake "endgame". Section 2 lists five dimensions that can be used to measure the block space allocation mechanism, using a familiar set of questions: who, what, when, where, how (abbreviated as the W^4H problem). Section 3 explores how block builders are selected, focusing on the execution ticket model. Section 4 opens the discussion by summarizing and raising follow-up open questions.
Notes: 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. 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 sequence, as a standalone, or skipped entirely - it's up to you!
(1) Motivation
Before diving into this complex topic, let's briefly explain the need for a block space allocation mechanism. In Proof-of-Stake, validators are tasked with generating and voting on blocks. The picture below is from Barnabé’s article More pictures about proposers and builders, which describes these as proposing and attesting rights.
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 typically use one of the following rules:
Blockspace (Proposal) Rights – A validator is randomly selected as a leader and allowed to create the next block.
Voting (Witness) Rights – All validators vote on the block they believe to be the canonical head within a certain time window.
Validators are rewarded for performing these tasks. We categorize rewards based on where they come from, either as consensus layer (protocol issuance, e.g., newly minted ETH) or execution layer (transaction fees and MEV):
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 change wildly over time (e.g., due to price fluctuations), resulting in greater variance in execution layer rewards 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 raises the question, why should protocols care about MEV-awareness? One answer is that MEV-awareness may increase the protocol's ability to maintain reward parity when validators have different levels of sophistication. For example, if the protocol is able to accurately burn all MEV, then validators' incentives will be completely within the protocol's view (as in 1a, 1b, and 2a above). Alternatively, a mechanism that shares all MEV among validators regardless of validator complexity (e.g., mev-smoothing) would seem to promote a larger, more diverse, and decentralized validator set while maintaining MEV rewards as an additional staking incentive. Without MEV awareness, validators that are best able to extract or smooth MEV (e.g., due to relationships with block builders, proprietary algorithms/software, access to exclusive order flow, and economies of scale) could receive disproportionately high rewards and exert 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 credibly neutral, censorship-resistant, and permissionless nature directly depends on a decentralized validator set.
Current Blockspace Allocation
In Ethereum today, mev-boost accounts for about 90% of blocks. With mev-boost, proposers (randomly chosen validator leaders) sell their block construction rights to the highest bidder through an auction. The diagram below shows this flow (we excluded relays because they are effectively extensions of the builder).
Proposers are incentivized to outsource their block construction because builders (agents that specialize in ordering transactions to extract MEV) pay them more than they could earn by building blocks themselves. Coming 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 the mev-boost drug: Relays – These trusted third parties broker block sales between proposers and builders. The heavy reliance on relays increases the overall fragility of the protocol, as demonstrated by duplication, incidents, involvements, relays. Additionally, since relays have no inherent revenue stream, more (and closed-source) methods of capturing profits are being implemented (e.g., timing games as a service and bid adjustments).
Extra-protocol software is fragile – In addition to relays, participating in the mev-boost market requires validators to run additional software. The standard suite for standalone staking now involves running four binaries: (i) a consensus beacon node, (ii) a consensus validator client, (iii) an 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 for examples of the complications caused by more extra-protocol software.
Builder Centralization and Censorship – While this was probably inevitable, the mass adoption of mev-boost has accelerated the centralization of builders. 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 a large influence on the inclusion and exclusion of transactions - (see censorship.pics).
Timing Games – While timing games are considered a fundamental problem in Proof-of-Stake protocols, mev-boost pushes staking service providers to compete on thin margins. Furthermore, relayers (which conduct mev-boost auctions on behalf of proposers) act as complex middlemen that facilitate timing games. Thus, we see marketing that encourages higher yields by staking with a specific provider.
(2) Enumeration
After the necessary “setting the stage”, let’s take a closer look at the nature of the block space allocation mechanism.
Consider the game of acquiring blockspace; MEV incentivizes agents to participate, while a combination of in-protocol and out-of-protocol software defines the rules. What elements 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” enough), which we call the W^4H question.
Who controls the outcome of the game?
What is the commodity that players fight over?
When does the game take place?
Where here do the MEV oracles come from?
How are block builders selected?
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 varieties 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.
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:
Encourage broader competition among builders.
Allow trusted interactions between validators and builders.
Incorporate MEV awareness into base-layer protocols.
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:
The price is fixed at 1 WEI, and
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:
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.
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
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.
Gain a broader understanding of the crypto industry through informative reports, and engage in in-depth discussions with other like-minded authors and readers. You are welcome to join us in our growing Coinlive community:https://t.me/CoinliveSG
< 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 
< alt="upload_a24cdf5b513fb4e410700573687adcd6" class="sizing-normal" alt="upload_a24cdf5b513fb4e410700573687adcd6" title="upload_a24cdf5b513fb4e410700573687adcd6" 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%2Fd75e1ffe-34d7-4b6b-ae12-693de5049784_690x493.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%2Fd75e1ffe-34d7-4b6b-ae12-693de5049784_690x493.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%2Fd75e1ffe-34d7-4b6b-ae12-693de5049784_690x493.jpeg 1272w, https://img.jinse.cn/7241171_watermarknone.png 1456w" sizes="100vw" loading="lazy">
Weatherly
