^p.s. yes, we anthropomorphize the protocol as a ghost because Casper.
^^p.p.s. not sure why the auctioneer ghost looks like he is conducting an orchestra, but here we are ¯\_(ツ)_/¯.
^^^ p.p.p.s. by the way, if you haven't seen Maestro, it's great.
by Mike, Pranav, & Dr. Tim Roughgarden – June 8, 2024.
Acknowledgements
Special thanks to Barnabé, Julian, Jonah, Davide, Thomas, Terence, Potuz, & Nate for comments and discussions.
tl;dr; Block space, the capacity for transaction inclusion, is the principal resource exported by blockchains. As the crypto ecosystem scales up and professionalizes, the value produced by efficient usage of block space (MEV) has come to play a significant role in the economics of permissionless consensus mechanisms. An immense amount of ink has been spilled by the research community considering what, if anything, protocols should enshrine in response to MEV (see Related Work). Indeed, the past few years resemble a Blind Men and the Elephant narrative arc, where many different perspectives, solutions, and theories have been propounded, but each angle can feel disjoint and difficult to compare. The first half of this article aims to present a broad-strokes painting of the "MEV-ephant" by distilling the design space into a core set of questions and exploring how existing proposals answer them. The second half hones in specifically on allocation mechanisms enabled by execution tickets, 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.
Organization: Section 1 motivates the need for an in-protocol mechanism to handle block-space distribution as part of the "endgame" for Proof-of-Stake. Section 2 enumerates five axes along which block-space distribution mechanisms may be measured, using a familiar set of questions: who, what, when, where, how (abbr. the W^4H questions
). Section 3 interrogates how the block builder is selected, focusing on the execution tickets model. Section 4 extrapolates by concluding and raising open questions that follow from the framework established.
Structural note: This article is rather long for this format and has some technical elements. We encourage the reader to focus on the portion of the article they are most interested in:
Contents
mev-boost
Before descending into this murky rabbit hole, let's start by simply motivating the necessity of a block-space distribution mechanism. Validators in Proof-of-Stake protocols are tasked with producing and voting on blocks. The figure below, from Barnabé's excellent "More pictures about proposers and builders," describes these as "proposing" and "attesting" rights, respectively.
A block-space distribution mechanism is the process by which the protocol determines the owner of the "proposing" or "block construction" rights. Proof-of-Stake protocols typically use some version of the following rules:
Validators perform these tasks because they receive rewards for doing so. We categorize the rewards according to their origin in either the consensus layer (the issuance from the protocol – e.g., newly minted ETH
) or the execution layer (transaction fees and MEV):
get_proposer_reward
.Rewards 1a
, 1b
, & 2a
are well understood and "in the view" of the protocol. MEV rewards present a more serious challenge because fully capturing the value realized by transaction ordering is difficult. Unlike the other rewards, even the amount of MEV in a block is unknowable for all intents and purposes (as a permissionless and pseudonymous system, it's impossible to trace who controls each account and any corresponding offchain activity that may be profitable in tandem). MEV also changes dramatically over time (e.g., as a function of price volatility), resulting in execution layer rewards having a much higher variance than the consensus layer rewards. Further, the Ethereum protocol, as implemented, has no insight into the MEV being produced and extracted by its transactions. To improve protocol visibility into MEV, many mechanisms try to approximate the MEV in a given block; we refer to these as MEV oracles. Block-space distribution mechanisms generally have the potential to produce such an oracle, making the protocol "MEV-aware."
This suggests the question, why does the protocol care about being MEV-aware? One answer: MEV awareness may increase the protocol's ability to preserve the homogeneity of validator rewards, even if validators have varying degrees of sophistication. For example, if the protocol could accurately burn all MEV, then the validator incentives would be fully in the protocol's view (just like 1a
, 1b
, & 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 validator set, while keeping the MEV rewards as an extra incentivization to stake. Without MEV awareness, the validators best equipped to extract or smooth MEV (e.g., due to relationships with block builders, proprietary algorithms/software, access to exclusive order flow, & economies of scale) may earn disproportionately high rewards and exert significant centralization pressures on the protocol.
Ethereum protocol design strives to keep a decentralized validator set at all costs. It probably goes without saying, but for completeness: the protocol's credible neutrality, censorship resistance, and permissionlessness are directly downstream of a decentralized validator set.
In Ethereum today, mev-boost
accounts for mev-boost
, proposers (the validator randomly selected as the leader) sell their block-building rights to the highest paying bidder through an auction. The figure below demonstrates this flow (we exclude the relays because they functionally serve as an extension of the builders).
.
Proposers are incentivized to outsource their block building because builders (the canonical name for MEV-extracting agents specializing in sequencing transactions) pay them more than they would have earned had they built the block themselves. Circling back to our goal of "preserving the homogeneity of validator rewards in the presence of MEV," we see that mev-boost
allows access to the builder market for all validators, effectively preserving near-equivalent MEV rewards among solo stakers and professional staking service providers – great! But…
Of course, there is a but… mev-boost
has issues that continue to rankle some of the Ethereum community. Without being exhaustive, a few of the negative side-effects of taking the mev-boost
medicine are:
mev-boost
market requires validators to run additional software. The standard suite for solo staking now involves running four binaries: (i) the consensus beacon node, (ii) the consensus validator client, (iii) the execution client, and (iv) mev-boost. Beyond the significant overhead for solo stakers, reliance on this software also provides another potential point of failure during hard forks. See the Shapella incident and the Dencun upgrade for an example of the complexity induced by having more out-of-protocol software.mev-boost
. Three builders account for mev-boost
blocks (mev-boost
implements an open-outcry, first-price, winner-takes-all auction, leading to high levels of builder concentration and strategic, bidding. Without inclusion lists or another censorship-resistance gadget, builders have extreme influence over transaction inclusion and exclusion – see censorship.pics.mev-boost
pushes staking service providers to compete on thin margins. Additionally, relays (who conduct mev-boost
auctions on the proposer's behalf) serve as sophisticated middlemen facilitating timing games. Thus, we have seen marketing endorsing playing timing games to boost the yield from staking with a specific provider."OK, OK … blah blah … we have heard this story before … tell me something I don't know." (
Obligatory 'stage-setting' out of the way, let's look a little more carefully at the ~essence~ of a block-space distribution mechanism.
^ "Is that what I think it is?"
Consider the game of acquiring block space; MEV incentivizes agents to participate, while the combination of in-protocol and out-of-protocol software defines the rules. When designing this game, what elements should be considered? To answer this question, we use a familiar rhetorical pattern of "who, what, when, where, & how" (hopefully Section 1 sufficiently answered "why"), which we refer to as the W^4H questions
. (
These questions might seem overly simplistic, but when considered in isolation, each can be viewed as an axis in the design space to measure mechanisms. To demonstrate this, we highlight a few different species from the block-space distribution mechanism genus that have been explored in the past. While they may feel disjointed and unrelated, their relationship is clarified by understanding how they answer the W^4H questions
.
^ fantastic book.
We present a compendium of many different proposed mechanisms. Note that this is only a subset of the rather substantial literature around these designs – cf. infinite buffet. For each of the following, we summarize only the key ideas (see related work for more).
mev-boost
is an out-of-protocol instantiation of block-auction PBS; enshrined PBS (ePBS), as originally presented, is the in-protocol equivalent.ETH
holders).We know, we know – it's a lot to keep track of; it's nearly a full-time job just to stay abreast of all these acronyms. But by comparing these proposals along the axes laid out by the W^4H questions
, we can see how they all fit together as different parts of the same design space.
For each of the five W^4H questions
, we describe different trade-offs made by the aforementioned proposals. For brevity, we don't analyze each question for each proposal; we instead focus on highlighting key differences arising from each line of questioning.
Before continuing, let's review our original motivation for block-space distribution mechanisms:
Block-space distribution mechanisms aim to preserve the homogeneity of validator rewards in the presence of MEV.
This is a great grounding, but if that is our only goal, why not just continue using mev-boost
? Well, remember that mev-boost
has some negative side effects that we probably want the endgame protocol to be resilient against. We highlight four other potential design goals of a block-space distribution mechanism:
Note that while (1, 2, & 3) appear relatively uncontroversial (*knock on wood*), (4) is more opinionated (and requires (3) as a pre-condition). The protocol may hope to eliminate MEV rewards from validator rewards as a means to ensure that the consensus layer rewards (what the protocol controls) more accurately reflect the full incentives of the system. This also ties into questions around staking macro-economics and the idea of protocol, issuance – a much more politically-charged discussion. On the other hand, MEV rewards are a byproduct of network usage; MEV could instead be seen as a value capture mechanism for the native token. We aren't trying to address these questions here but rather explore how different answers to them would shape the design of the mechanism.
What can we do at the protocol-design level to align with these desiderata? As laid out above, there are many trade-offs to consider, but in the following section, we examine "How is the block builder chosen?" to improve on some of these dimensions.
Editorial note: As mentioned earlier, this section is longer and more technical than the others – feel free to skip to Section 4 if you are time (or interest) constrained!
Section goal: To demonstrate the quantitative trade-off between MEV-oracle quality and the "fairness" of the two most familiar approaches to allocating block proposer rights, which we call Proportional-all-pay
and Winner-take-all
.
We aim to accomplish this with the following subsections:
Proportional-all-pay
and Winner-take-all
mechanisms using the established framework.Let's dig in.
Before diving into the space of allocation mechanisms made possible with execution tickets, we must first set up the model. Consider a protocol that sells execution tickets with the following rules:
1 WEI
, andNote: this version of execution tickets is effectively equivalent to creating two disjoint staking mechanisms – one each for attesting and proposing. Small changes in the design, e.g., not allowing tickets to be resold to the protocol, may have massive implications for how the market plays out, but that isn't the focus of this article. Instead, we narrowly explore the question of block-space allocation, given an existing ticket holder set.
Notably, the set of block producers is disjoint (from the protocol's perspective) from the set of attesters – individuals must select which part of the protocol they participate in by deciding whether to stake or buy tickets. The secondary ticket market may evolve as a venue for selling the building rights just in time to the builder market (as is done in mev-boost
today).
Separately, builders may choose to interact directly with the protocol by buying execution tickets themselves, but their capital may be better utilized as active liquidity, capturing arbitrage across trading venues. Thus, they may prefer buying block space on the secondary market during the just-in-time auction instead.
Why restrict ourselves to this posted-price-unlimited-supply mechanism? Two reasons:
"One may imagine the inclusion of ET market-related transactions to possibly induce MEV, whether these transactions are included in the beacon block or the execution payload." – Barnabé in "More pictures about proposers and builders."
Therefore, we focus on the "unlimited, 1 WEI
posted-price" version of execution tickets, where the protocol internalizes minimal complexity. With this framing, we can ask the question that is probably burning you up inside, "given a set of execution ticket holders, how should the winner be selected?" … sounds easy enough, right? Turns out there is a good deal we can say, even with such a seemingly simple question; let's explore a few different options.
Consider the repeated game of buying execution tickets to earn MEV rewards for your investment.
ETH
with probability ETH
with probability Consider two (quite different) possible mechanisms.
Proportional-all-pay
(a slight modification to the original execution tickets proposal)
Winner-take-all
(the current implementation of PBS)
To demonstrate the different outcomes from these two mechanisms, consider the two-player game where Player 1
has a valuation of Player 2
has a valuation of
Proportional-all-pay
outcome:
This all should feel intuitively correct; with Player 1
has 2x
the value for the block), Player 1
bids, receives and pays twice as much as Player 2
.
Winner-take-all
outcome:
This is pretty different. Player 1
bids and pays just over Player 2
's value (we use Player 2
receives nothing and pays nothing.[3]
Now consider the "revenue" (or the sum of the bids collected by the mechanism) generated from each case:
Proportional-all-pay
revenue: Winner-take-all
revenue: Winner-take-all
has better revenue, corresponding to a more accurate MEV oracle (and thus more MEV burned or smoothed by the protocol) than Proportional-all-pay
. Intuitively, by allocating block-production rights to players with lower values (as Proportional-all-pay
does), we forgo revenue we would have received had we simply allocated the entire rights to the player with the highest value. We point the interested reader to Aside 1 for a more complete treatment.
Another factor to consider is the "fairness" or "distribution" of the allocation mechanism. For example, suppose we agree on the metric:
Proportional-all-pay
fairness: Winner-take-all
fairness: Here, the "performance" of the two mechanisms flips – the Winner-take-all
is less fair because Player 2
has no chance of winning the game with a lower value. In the Proportional-all-pay
, Player 2
can hope to win some blocks despite bidding a lower value. As another example, consider the case where Winner-take-all
mechanism allocates all the rights to Player 1
, while the Proportional-all-pay
splits the rights approximately in half.
Brief note: why might the protocol care about fairness? In a decentralized protocol, a single actor having too much power undermines the credible neutrality of the system. As such, the protocol may be willing to "pay" (in the form of reduced revenue) to ensure that a resource is more evenly distributed among players. Alternatively, we could consider this a measure of "entropy" or even simply randomness being injected into the outcome of the game to try to reduce the influence the most dominant player can have.
This leads to the punchline from this small example: a fundamental trade-off exists between MEV-oracle quality and fairness. The Proportional-all-pay
mechanism (and hence the original execution tickets proposal) is fairer because both players win the game with some probability, incentivizing them each (but more importantly, the higher value player) to shade their bid accordingly, lowering the revenue, and thus the MEV-oracle accuracy, of the mechanism. The first price mechanism elicits higher bids since bidders only pay if they win the entire block production rights, increasing the revenue, but this Winner-take-all
dynamic makes the allocation less fair.
Open question: is Proportional-all-pay
an "optimal" Sybil-proof mechanism? In the permissionless setting, we only consider Sybil-proof mechanisms, where a player doesn't benefit from splitting their bid into multiple identities. We posit that the Proportional-all-pay
mechanism sits in the Goldilock's Zone of a Sybil-proof mechanism that gets both good revenue/MEV-oracle accuracy and fairness. We leave as an interesting open problem to determine the extent to which the Proportional-all-pay
mechanism's "optimality" (e.g., we were unable to find another Sybil-proof mechanism that dominates it in both revenue and fairness).
Convenience link to skip to the conclusion for the less-keen reader ;)
In the numerical example above, we provide the equilibrium bids for the Winner-take-all
and Proportional-all-pay
mechanisms without proof. How can these be determined generally (e.g., continuing to assume that bidders' values are common knowledge)?[4]
The Winner-take-all
is the familiar First Price Auction setting. In such auctions, the complete information Pure-Nash equilibrium has the two highest-value bidders, each bidding the second-highest bidder's value, with every other agent bidding below this. In effect, we expect that the highest-value bidder always wins while paying the second highest bidder's value (we represent this simply as
In the Proportional-all-pay
setting, each player has the utility,
To determine the existence of a Pure Nash Equilibrium, we consider each player's first- and second-order conditions. Let
In our simple two-player example in the Proportional-all-pay
setting, we have the following.
This system can be solved to find the equilibrium bids,
For our toy example, we have
The second-order conditions can also be verified – this is left as an exercise for the reader ;)
Last chance to skip to the conclusion. (If you continue, by definition, you are the "interested reader" – congrats.)
The model described above is established in the algorithmic game theory literature as a Tullock Contest – named for Gordon Tullock, who explored the idea in his seminal work, "Efficient Rent Seeking." He motivates this study by considering situations where investment is made before the outcome is known and where the investments might not transfer easily between participants, e.g., political spending.
"Suppose, for example, that we organize a lobby in Washington for the purpose of raising the price of milk and are unsuccessful. We cannot simply transfer our collection of contacts, influences, past bribes, and so forth to the steel manufacturers' lobby. In general, our investments are too specialized, and, in many cases, they are matters of very particular and detailed goodwill to a specific organization. It is true that we could sell the steel lobby our lobbyists with their connections and perhaps our mailing list. But presumably, all these things have been bought by us at their proper cost. Our investment has not paid, but there is nothing left to transfer." – Gordon Tullock (1980)
This allocation mechanism has been applied in the previous crypto literature as well. Back in 2018 (ancient history in crypto-terms), Arnosti and Weinberg wrote "Bitcoin: A natural oligopoly," which demonstrates that even small operating cost advantages among miners in a Proof-of-Work system lead to surprisingly concentrated equilibria. Similarly, Bahrani, Garimidi, and Roughgarden (these names sound familiar :D) explored the centralization effects of heterogeneity in block building skill in "Centralization in Block Building and Proposer-Builder Separation." There appears to be a deep relationship between permissionless crypto-economic systems, where anti-Sybil mechanisms typically require financial investment for participation, and Tullock Contests – more on this Soon™
(maybe).
Phew, thanks for hanging in there; let's take stock of what we learned. Section 3 demonstrates the fundamental trade-off between MEV-oracle accuracy and fairness of an instantiation of an execution ticket mechanism. A protocol may be willing to *pay* (in the form of reduced revenue) for more distribution and entropy with the goal of improving and maintaining the protocol's credible neutrality. Further, using the model to derive equilibrium bids helps inform how we may expect agents to respond to various allocation and payment rules. Neat – our framework led to some interesting and hopefully helpful insights! Maybe we can extend it to other problems in the space as well?
Further questions that this specific model may help answer (returning to three of our W^4 questions
):
Proportional-all-pay
in both revenue and fairness?Zooming back out, other versions of the W^4H questions
may require different models to reason about.
As per usual, open questions abound, but we hope (a) W^4H questions
help expand the understanding of block-space distribution mechanisms and (b) the deep dive into allocation mechanisms helps inform the potential design space of execution tickets.
^ The world once we figure out MEV.
Excited to be here with y'all.
— made with ♥ by mike, pranav, & dr. tim roughgarden.
The "all-pay" feature is made possible by burning the price paid for each ticket. ↩︎
The "winner-pay" version could be done by refunding all non-winning ticket holders their payment at the end of each round. ↩︎
As mentioned earlier, simply refunding the non-winning tickets instantiates the "winner-pays" property. ↩︎
This is primarily for tractability in calculating equilibria analytically. Although a strong assumption, it's not unreasonable in the context of lookahead auctions where bidders might have established prior distributions on their competitor's valuations. We also view the insights from studying the complete-information equilibria as valuable heuristics for how we may expect these mechanisms to behave in practice. ↩︎