Ethereum researcher and a16z researcher co-authored: Block space allocation mechanism

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 allocation plans 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:Block space, i.e. the capacity of transactions, isBlockchainAs the crypto ecosystem expands and professionalizes, the value generated by the efficient use of block space (MEV) plays a major role in the economics of permissionless consensus mechanisms. ResearchCommunityA lot of articles have been written about how protocols should deal with MEV (see Related Work). The discussion over the past few years has been similar to 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 distribution 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 blockspace allocation as part of the Proof-of-Stake "finality". Section 2 lists five dimensions along which blockspace allocation mechanisms can be measured, using a familiar set of questions: who, what, when, where, how (abbreviated as the W^4H questions). 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.

illustrate: This is a long article with some technical elements. We encourage readers to focus on the parts 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 (about 44% of the full text, but 100% of all 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, the task of validators is to generate and vote on blocks. The following picture is from Barnab’s article “More pictures about proposers and builders”, which 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 Rewards – (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 it is difficult to fully capture the value realized through transaction ordering. 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 dramatically over time (e.g., with 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 begs 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 across validators of varying degrees of sophistication. For example, if the protocol was able to accurately burn all MEV, then validators’ incentives would be entirely within the protocol’s view (as in 1a, 1b, and 2a above). Alternatively, a mechanism that shares all MEV among validators regardless of their sophistication (e.g., mev-smoothing) would seem to promote a larger, more diverse, and decentralized set of validators while maintaining 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 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 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% 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 an extension of the builder).

Proposers are incentivized to outsource their block building because builders (agents that specialize in ordering transactions to extract MEV) pay them more than they would get for 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, mev-boost has some issues that still make EthereumCommunityIn short, here are some of the negative side effects of taking mev-boost drugs:

• 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 adjustments as a service).

• Fragile extra-protocol software – In addition to the relay, participating in the mev-boost market requires validators to run additional software. The standard suite for independent 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 to 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 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 anti-censorship 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 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 compendium 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 random 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 Burning / 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 that bids are large enough.

By comparing the responses of these proposals to 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 with each proposal, but focus onXiaobai NavigationPoints emphasize 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 allocated on a winner-takes-all basis, 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 resilient 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 wish 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 like 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 nativeTokenWe do not attempt to resolve these questions 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.

Some goals: We present 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.

Notice: 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 a huge impact on market operation, but this is not the focus of this article. We are narrowly exploring the issue of block space allocation given a set of existing 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 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 achieve while keeping hardware requirements limited.

“It is conceivable that the inclusion of ET market-related transactions could trigger MEV, regardless of whether those transactions are included in a beacon block or in an execution payload.” — Barnab 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)=1p: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 ith player.

• Each player has a valuation for winning the right to produce a block. Let the valuations be represented by a vector v, where vi is the valuation of the ith 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 ith 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 represent the payment rule determined from the bid set, where pi(b) is the payment of the ith 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 = 2v2 (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 use to represent a small amount), and receives the entire allocation. Player 2 gets nothing 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 more accurate MEV oracles (and thus more MEV burned or smoothed by the protocol), than proportional payouts. Intuitively, by assigning block production rights to lower-value players (as proportional payouts do), 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 it is maximal when x1 = x2 if the sum of x1 + x2 is fixed, and is zero if any x1 or x2 is zero). Now, let’s look at the fairness results for 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 (that is, 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, thereby reducing the revenue of the mechanism and the accuracy of the MEV oracle. The first price mechanism induces higher bids because bidders only need to pay if they win the entire block production right, thereby increasing revenue, but this winner-takes-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 #1 and #2 related to specific calculations, please refer to 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 are better than pro rata full payouts 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 payout 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 MEVs 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.

The article comes from the Internet:Ethereum researcher and a16z researcher co-authored: Block space allocation mechanism

Related recommendation: Ordinals Asia was successfully held to promote the prosperity and development of the Bitcoin ecosystem

With over 700 participants, this summit is the largest Bitcoin Ordinals event to date. Co-hosted by Xverse, Darewise, Ordz Games, and Ordzaar, with Waterdrip Capital as a strategic partner, Bitlayer, Merlin…