Beyond the Stars: An Introduction to Execution Tickets on Ethereum
You may not know it yet, but the Ethereum research community is currently discussing one of the most exciting ideas to change the protocol since The Merge.
This upgrade, called Execution Tickets, will be a major change in how Ethereum works internally. In this article, we want to clear up the confusion around this topic – answering what they are, how they work, why we need them, and why aliens might play a vital role 👽
To introduce Execution Tickets, we’ll start with a brief account of the developments that led up to them, and then use that knowledge to examine their current design. Get ready to drop the term "Execution Tickets" with confidence at your next crypto gathering ✨
If you spot anything inaccurate, feel free to drop us a line – we’d love to hear your feedback!
History Lesson: How we got here
One of the cardinal problems of blockchains is how to allocate block space most efficiently.
In most cases, block space is a limited resource, since there are more users that want to transact with or store data on the chain than the network nodes can process and store. This is especially important in the Ethereum ecosystem that wants to allow anyone to run their own network node.1 Therefore, there are various mechanisms to allocate it in the most optimal way – usually by adjusting block space pricing to meet the demand.
In the original Ethereum whitepaper by Vitalik, this was essentially designed as a first-price auction (FPA). Users stated how much they would pay for a transaction, and were included if the price was high enough.2
But the soaring popularity of Ethereum revealed several drawbacks to this mechanism. Prices were extremely volatile during periods of high demand such as airdrops, and the average user had to overpay to ensure their transaction was included. In addition, the hard block size limit and the twelve-second slot time caused network congestion and delays.
As a solution, Vitalik, Eric Conner, and a few others came up with EIP-1559. Essentially, the idea is to incrementally adjust the block sizes and transaction fees based on the current network demand.
With EIP-1559, block sizes range from 0 to 30 million gas, with a target of 15 million. If the gas usage of the current block is above or below the target, the transaction fee is adjusted accordingly. This approach makes price changes more predictable and enables wallets to automatically set the gas price for users, which greatly improves the user experience.
Additionally, the transaction fee is divided into a base fee and a priority tip. The base fee is burned to prevent validators from manipulating the system, e.g. by adding random transactions to drive up the price or entering into profitable side-channel agreements with users to bypass the base fee.3 This means that it is proportionally distributed back to all ETH holders, similar to a share buyback. In periods of high demand and high fees, this can make Ethereum deflationary. The priority tip incentivizes validators to include urgent transactions earlier.4
While EIP-1559 solved some problems, unfortunately some new issues surfaced.
MEV enters the stage
In their landmark research paper, the Flashbots team brought the issue of Maximum Extractable Value (MEV) to the front stage of the Ethereum community.5
MEV is commonly defined as “the excess profit that a validator can extract by adjusting execution of user transactions.”6
The original term implied that miners had complete control over the contents of the current block and could manipulate it for their own gain. This included the ability to reorder, block or insert transactions to make money. Additionally, MEV refers to automated programs that seek out low-risk profit opportunities by exploiting the transparency of Ethereum transactions.
There are several types of MEV based on the methods that are used, including frontrunning, backrunning, sandwiching (a combination of frontrunning and backrunning), liquidations, and arbitrage across decentralized (DEX) and centralized exchanges (CEX).
Although this article will not cover all of these in detail, it is helpful to be familiar with the classifications of atomic and non-atomic MEV, as well as toxic and non-toxic MEV.
Atomic MEV refers to MEV solely based on onchain interactions, such as sandwich attacks and liquidations. Non-atomic MEV, on the other hand, involves a combination of on- and off-chain components, such as arbitrage between DEXes and CEXes.
Toxic MEV results in a loss to the user, such as frontrunning, when an actor buys a coin cheaper on the market and resells it to the user at a higher price in the same transaction. Non-toxic MEV includes things that don’t hurt the user but still generate profits. Common examples for this are backrunning and liquidations.
These definitions are not set in stone and often debated. Some parties do not consider non-atomic arbitrage as MEV, while in our definition, we believe it makes sense to include it.
The increasing complexity of the trading process resulted in greater centralization of validators, as only highly sophisticated actors with strong computing power, specialized knowledge and low latency are succeeding. This behavior has raised questions in the Ethereum community about who should receive the rewards, given that MEV revenue is estimated at several hundred million USD per year.7
Proposer-Builder Separation (PBS)
To mitigate MEV, the first step was to separate the proposers (also known as validators, who are responsible for submitting block data to the chain) and block builders (sophisticated entities that perform transaction ordering).
Block builders collect transactions from the mempool to create the blocks and then offer these blocks to the block proposer in each slot. The proposer cannot see what’s inside it, they can only select the most profitable block and receive a fee from the block builder before storing the block on the chain.
This change made it more difficult for proposers to censor transactions at the protocol level, but gave fewer builders more control over the block content. It also simplified block validation for small validators who no longer have to perform the intricate task of block construction, thus creating a more level playing field.
Although this helped validators avoid building complex blocks on their own, a few issues persisted.
MEV is still present and is primarily captured by validators, who auction off their block slots via MEV-boost, and the MEV supply chain, which includes searchers and builders.8 As a result, validators receive greater payoffs than originally intended due to the additional execution layer rewards amplified by MEV.
Specialized validators are better equipped to capture MEV by ensuring higher uptimes, lower latencies, and by playing timing games. This leads to continued centralization pressure for validators and builders, which reduces censorship resistance and increases the risk of various attacks and liveness issues when central entities are down.
Several solutions have been suggested to address this issue, each with its own drawbacks. One widely discussed idea is integrating PBS into the protocol, commonly referred to as enshrined PBS (ePBS). However, it has been criticized as bypassable and thus not incentive-compatible, and no good solution has been found to prevent off-chain agreements among actors.
Idea time: What are Execution Tickets and how do they work?
Execution Tickets, often simply called ET đź‘˝, are a proposed next step in the evolution of the Ethereum protocol to address the above issues. They were originally introduced as Attester-Proposer Separation (APS) by Justin Drake, and later published in an ethresearch article by Mike Neuder.
Over time, it became increasingly clear that validators essentially have to do two jobs. First, they are validating the beacon chain.9 Second, they have to construct the payloads with the actual execution of the EVM, like running the smart contracts or storing transactions onchain.
These two jobs have different requirements. To ensure robustness, the beacon chain requires a high level of decentralization, while the execution part needs efficient compute and low latency.
Execution Tickets essentially divide these two roles.
Validators and Execution Block Proposers
The validator role for the beacon chain will remain mostly unchanged. Validators, also called Beacon Block Proposers, will continue to be selected based on the amount of ETH they have staked. Their responsibilities will include determining the head of the chain and defining the inclusion list, which is a list of transactions that need to be part of the block to ensure censorship resistance. And they will continue to verify the correctness of the blocks, i.e. validate them.
Validators are paid with the consensus rewards from the chain, which lets them clearly predict their revenue and allows home stakers to participate again because of lower compute requirements, thus fostering decentralization.
With Execution Tickets, the role of an Execution Block Proposer is formally introduced to Ethereum for the more technically demanding execution process.10
To participate, anyone wanting to fill an execution block can buy Execution Tickets, which are like tickets for a lottery. For each slot,11 one ticket holder is randomly selected that can then provide the block.
The reward for the execution block proposer is only based on the priority tip of the transactions and the MEV they can capture with the proposed block. With the need for high uptimes, low latency, and high MEV extraction, only sophisticated entities are likely to participate.
This means there will be centralization pressure for execution block proposers, while achieving high decentralization among beacon chain validators.12
It is currently unclear how Execution Tickets will be sold, as this is still an active area of research. There are some ideas around using either a first- or second-price auction, or a pricing mechanism like EIP-1559. The goal is to maximize the price per ticket to capture as much MEV as possible on the protocol level – because when the fee for the Execution Ticket is burned, it increases the value of ETH for all holders.13
Auctioning off lottery tickets has an additional benefit. Directly auctioning off slots can lead to multi-slot MEV (MMEV) which occurs when someone controls more than one slot in a row and can extract more MEV than by having the slots individually. The randomness of the Execution Ticket lottery makes it much harder for players to predictably control multiple slots and thus for playing adversarial games.14
Ensuring economic stability of Ethereum
With all of that said, how do we know if Execution Tickets are actually a good idea?
Generally speaking, there are a few properties you need to consider when designing a mechanism like Execution Tickets.
For example, one goal should be to promote decentralization and MEV capture by the protocol. Additionally, the mechanism must incentivize all stakeholders to actively participate, such as preventing block proposers from leaving blocks empty.
When a mechanism is designed in a way that it incentivizes a block producer to publish blocks that maximize private rewards (think MEV and priority fees), then it’s called block producer incentive compatible (BPIC).
Another property worth considering is so-called OCA-Proofness (OCA stands for Off-Chain Agreement). The mechanism needs to be designed in a way that it minimizes the risk of execution block proposers making back-room deals to earn more.
At first sight, it appears that Execution Tickets score highly in meeting these attributes compared to other proposed mechanisms, which could make them a valuable improvement. However, the research community is actively working on validating this.
But even though many people in the Ethereum community see the benefits of Execution Tickets, there are also critical voices.
At the moment, block production is highly centralized, with only a few entities competing to produce the most profitable block, and the largest builder having a market share of nearly 50%.15 This creates a significant centralization pressure due to the specialized skills required to produce the most profitable block.
With the introduction of Execution Tickets, some people are worrying about even more increased centralization among execution ticket holders, but also more implementation complexity and the risk of missed execution slots without proper penalization.
"We want less censorship and more decentralization, which is why we came up with execution tickets, where execution rights will be sold for a fuckton of money to crypto megacorps and auctioned out to smaller fishes in the foodchain."
Sorry, but are you fucking serious right now?
A strong centralization of execution block proposers could lead to bad second-order effects such as liveness risks (like a block proposer controlling all slots for a day turning off the chain), or even extracting multi-slot MEV, which Execution Tickets try to avoid. As you can see in the example above, there are still diverging opinions on conceptually embracing centralization in certain parts of the value chain with Execution Tickets.
Summary
So what are Execution Tickets, exactly? With Execution Tickets, the validator role as we know it today will be split into two new roles: The Beacon Block Proposer and the Execution Block Proposers. While the former is very similar to the current validators, requiring 32 ETH to stake, the latter is responsible for constructing the execution payload and running the EVM. To become an Execution Block Proposer, you need to purchase a ticket for a new lottery that grants you permission to fill the current slot with a block.
Prospect
Execution Tickets are openly discussed in the community and several researchers are exploring it, although it’s not clear yet if and when Execution Tickets will come to Ethereum. There are still a number of open questions that are actively being researched, like:
-
What is the optimal pricing mechanism for Execution Tickets?
-
Should a secondary marketplace for Execution Tickets exist and what effects will this have?
-
Are inclusion lists sufficient for preserving censorship resistance and avoiding MMEV?
-
Having more than one concurrent proposer is currently discussed as a protocol improvement. How would this be compatible with Execution Tickets?
-
Do we need a staking mechanism or slashing for Execution Ticket holders?
We are actively researching the economic aspects of Execution Tickets at the moment. If you find this topic interesting, feel free to check out the resources below to get a more detailed understanding of the topic. We’ve also included some academic papers on relevant adjacent topics. And if you have any questions, say hi.
Big thank you to Barnabé Monnot, Mike Neuder, Yuki Yuminaga, Sters, and Aaron Hay for their feedback and suggestions.
Resources
-
Introductory talk to Execution Tickets by Justin Drake
-
ETHResearch post on Execution Tickets by Mike Neuder
-
Economic Analysis of Execution Tickets by Jonah Burian & Davide Crapis
-
Overview of the MEV landscape by Monoceros Ventures
-
Non-Atomic Arbitrage in Decentralized Finance by Lioba Heimbach, Vabuk Pahari, and Eric Schertenleib
-
Slot vs. Block Auctions by Justin Ma
-
Reconsidering the market structure of PBS by Barnabé Monnot
-
Introduction to Rainbow Staking by Barnabé Monnot
More in-depth academic readings
-
Economic Analysis of Transaction Fee Mechanisms by Maryam Bahrani, Pranav Garimidi, and Tim Roughgarden
-
Transaction Fee Mechanism Design by Tim Roughgarden
-
Collusion-Resilience in Transaction Fee Mechanism Design by Hao Chung, Tim Roughgarden, and Elaine Shi
-
Dynamical Analysis of the EIP-1559 Ethereum Fee Market by Stefanos Leonardos, et al.
-
Transaction Fees on a Honeymoon: Ethereum’s EIP-1559 One Month Later by Reijsbergen, et al.
-
Optimality Despite Chaos in Fee Markets by Stefanos Leonardos, et al.
-
Analysis of Incentives with Inclusion Lists by Barnabé Monnot
-
MEV on Ethereum: A Policy Analysis by Mikolaj Barczentewicz
Footnotes
Footnotes
-
A counter-example is Solana, which focuses on fewer but more powerful nodes. At time of this writing, Ethereum has a 4x higher transaction volume compared to Solana, but 400x times more validator nodes in the network ↩
-
With the price being the amount of compute used in gas, multiplied by the price per gas ↩
-
In economics research, people refer to this as Myopic Miner Incentive-Compatibility (MMIC). If you fancy a deep dive into EIP-1559 and the extensive academic research surrounding it, have a look at the paper Transaction Fee Mechanism Design for the Ethereum Blockchain: An Economic Analysis of EIP-1559 by Tim Roughgarden. ↩
-
Previously, validators were called miners in Proof of Work (PoW), now in Proof of Stake (PoS) they are usually referred to as block validators or block proposers – you know, the Lido kids ↩
-
Before Proof of Stake, MEV was called Miner Extractable Value. But with miners in Ethereum being a thing of the past (and also to reflect that MEV is not only extracted at the miner/validator level), it was renamed to Maximum Extractable Value to keep the fancy acronym ↩
-
See the papers Towards a Theory of Maximal Extractable Value I: Constant Function Market Makers and Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges ↩
-
It is important to note that in a multi-faceted market, these MEV opportunities always exist and cannot be avoided, no matter how well-designed the market is. ↩
-
See mevboost.pics for a good overview of the current MEV landscape ↩
-
The beacon chain manages the blocks and attestations, runs the fork choice algorithm, and determines rewards and penalties. ↩
-
With Execution Tickets, the
ExecutionPayload
is also moved from the beacon chain to the execution chain. ↩ -
Which is the twelve second timeframe where blocks can be added to the chain ↩
-
Essentially, Execution Tickets solve the allocation of slots and thus create a (primary) market for future block space. This makes them different from PBS because the assigned slots can still be auctioned off to builders. ↩
-
Again, this is like a stock buyback in TradFi ↩
-
By introducing dedicated execution block proposers, it would also be possible to give early promises of including transactions onchain, called preconfirmations. This would allow transactions to be much faster and improve Ethereum’s UX. ↩
-
At the time of this writing, the largest builder is Beaverbuild ↩