In the beginning, there was nothing. Then a protocol appeared.

The protocol had aims, wanted to achieve lots. But first, it had to recruit disciples who would execute its vision.

The protocol created rights and assigned them to earthly entities, such that these “validators” could propose blocks and attest to them.

In this piece, we are not concerned with attesting (for now), and we’ll narrow our attention to proposing rights.

The proposing rights allow a validator, once selected, to create and propose a block. The block contains both consensus data (e.g., attestations), as well as an execution payload (a list of user transactions). When the validator receives the proposing right, it receives implicitly the right to decide the contents of both attributes, consensus data and execution payload.

MEV-Boost enters

Validators soon figured out that the ability to decide on the contents of the execution payload had value. They could remain the proposers, but create building rights to be allocated to builders, who would offer them a well-sequenced payload against payment.

The allocation of building rights is performed today with MEV-Boost, an out-of-protocol side-car allowing validators to passively listen to offers from builders for their building rights, and strike a deal with builders. The deal is mediated by relays, entities trusted by both sides of the deal.

Block-auction ePBS

What the protocol cannot see, it cannot control, so the community soon got to work on getting some of that infrastructure back into the fold of their protocol. This direction is known as “enshrined Proposer-Builder Separation”, and would allow proposers (validators) to strike deals with builders without the assistance of the relay as a trusted entity. In particular, the aims of ePBS are three-fold:

1. Possibility of unconditional payment: If the proposer commits to a builder bid in time (the commitment is attested to by the attesters, becomes canonical and does not get re-orged), then the proposer receives payment from the builder whether the builder delivers their part or not.

2. Possibility of trust-minimised proposer/builder interaction: The protocol offers a path, secured by its set of attesters and the fork choice rules of the protocol, for proposers and builders to strike deals without the aid of a relay.

3. Consensus/execution separation: Decoupling the consensus data from the execution payload in two distinct objects recognised by the protocol allows consensus data to be written on-chain even in the event of a delivery failure of the execution payload.

I present above “Block-auction ePBS”, the ePBS version which most directly maps to MEV-Boost. The “block-auction” refers to the requirement for the beacon proposer (the validator, who proposes the partial block containing consensus data) to commit to the contents of the execution payload when they commit to a builder. In other words, the proposer receives builder protocol-bids, which take the form of PB = { value, builderID, txroot } (note that we omit signatures from these messages, but these and more which will be introduced below are all assumed to be signed by the right parties).

When the beacon block is produced and contains PB, the fork choice will only accept an execution payload whose contents hash to PB.txroot. In this sense, the beacon proposer remains the true execution proposer (“beacon-exec proposer”), who earns the rewards received from the builder and who ultimately signs off on the the contents which are to be appended to the chain. The protocol-bids are objects legible to the Ethereum protocol, and commit a builder to deliver the block which the beacon-exec proposer has commissioned. You can read more about design constraints and implementation concerns in the rich literature from the Prysm boyz Potuz and Terence (ePBS specification notes, ePBS Forkchoice annotated spec, Block-auction ePBS versus Execution Tickets).

This version of ePBS satisfies points 1. to 3. Yet, importantly, point 2. must not be understood as making relays obsolete somehow. It remains entirely possible for beacon-exec proposers to participate in the trusted MEV-Boost market in the following way:

• Listen to MEV-Boost-bids from builders through the MEV-Boost channel.

• Choose a bid MB = { value, builderID, txroot }.

• Commit to the protocol bid PB = { 0, MB.builderID, MB.txroot }

• Receive MB.value as part of the execution payload, the way it is done today under MEV-Boost, with relays ensuring that the builder does include a valid payment for MB.value in the payload they sequence.

• The builder MB.builderID then delivers the execution payload hashing to MB.txroot. If they fail to do so, the beacon proposer does not receive payment.

We thus stress here that points 1. and 2. of ePBS only embody possibilities of transacting in a trust-minimised fashion with builders, rather than requirements. The natural question is then to understand when would proposers choose to use the trusted, out-of-protocol MEV-Boost interaction. One reason to keep using MEV-Boost instead of the honest ePBS behaviour: Builders are not required to commit to a payment upfront in MEV-Boost, compared to ePBS, meaning that builders may pay the beacon proposer from the gains they realise within the payload they sequence. See also Terence’s “ePBS: Bypassing Relayer” post for more thoughts on the topic.

A final point on block-auction ePBS: Timing games. Timing games occur when a proposer delays as much as possible the proposing of their block in order to obtain more value for it. In block-auction ePBS, as the execution payloads are determined at the release of the beacon block, the timing games will be played by validators who will attempt to delay the release of the beacon block as much as possible to commit to bids of higher value. This clues us in to the fact that we’ve not decoupled the consensus and the execution as much as we could, so let’s investigate a different design.

Slot-auction ePBS

Slot-auction ePBS makes a subtle design change, with big consequences. Beacon proposers may now commit to protocol-bids taking the shape of SPB = { value, exectutionProposerID }, so no longer committing to the contents of the execution payload, but committing to a specific execution proposer instead. The contents of the block released in the second step may be determined just in-time by the execution proposer, who is sovereign in their step. The execution proposer is even able to offer building rights to a distinct entity from themselves, a builder commissioned to deliver a block whose commitment is selected by the execution proposer.

The execution proposer will likely wish to wait until the last possible moment to propose the execution payload, so we assume timing games will be played in the execution step.

It is less clear what will happen during the beacon step. To understand, we introduce SA-MEV-Boost, a slot-auction-friendly version of MEV-Boost which offers to the beacon proposer off-band bids SMB = { value, executionProposerID }. The beacon proposer running SA-MEV-Boost may select some bid SMB, and commit to the protocol bid SPB = { 0, executionProposerID }. The execution proposer executionProposerID is then trusted to produce an execution payload that pays out SMB.value to the beacon proposer, yet, unlike MEV-Boost, there is no relay at this point vouching for the payment existing. The relationship between the beacon proposer and the execution proposer under SA-MEV-Boost may thus be mediated in a similar fashion to optimistic relays in ePBS: Someone, e.g., an escrow-relay, may guarantee the availability of funds to pay the beacon proposer SMB.value is any outcome, but the escrow-relay is not responsible for the delivery of the execution payload once available.

Once the execution proposer executionProposerID is selected, this proposer may use the classic MEV-Boost infrastructure to allocate building rights to an outside builder. The relays on this side function as relays do in the current version of ePBS, i.e., combine the functions of escrow-relay (if optimistic) and delivery of the payload. When both SA-MEV-Boost and MEV-Boost were summoned, the delivered payload should contain a payment from the builder to the execution proposer, as well as a separate payment from the execution proposer to the beacon proposer.

The beacon proposer is faced with the following decision tree:

Listen to bids (protocol or SA-MEV-Boost) and either:

1. Commit to themselves as execution proposer. Listen to (MEV-Boost) builder bids and

   1. Select the highest MEV-Boost-bid they receive, or

   2. Build locally.

2. Commit to someone else as execution proposer. Receive the value either from the unconditional payment protocol facility or from SA-MEV-Boost guarantees.

It appears to me that the expected value for the beacon proposer is maximised by choosing to commit to themselves first, and then running MEV-Boost to obtain the best offer from an outside builder. The auction for execution rights offers a valuable good: The knowledge that one is in control of proposing the execution payload, which may be leveraged by preconfirmation systems. However, between the settlement of the auction allocating execution proposing rights and the expected delivery of the execution payload, more transactions may trickle in and increase the value which a builder may extract from sequencing. By committing to themselves, the beacon proposer may become the “preconfirmation leader”, to whom tips are paid for the service of preconfirming. The preconfirmed transactions may then be sequenced according to the commitments offered by the beacon proposer, using e.g., PEPC-Boost (“relay-enforced proposer commitments”, see also the bonus section at the end) to ensure that the builder delivers an execution payload satisfying the preconfirmations entered into by the beacon proposer.

Still, the discussion above makes it quite clear that we expect quite a lot of involvement from the beacon proposer into the make-up of the execution payload, and if it is indeed a dominant strategy for the beacon proposer to commit to themselves and run MEV-Boost in the last-mile to allocate building rights, we haven’t gained much either in terms of diminishing the system’s reliance on relays. Yet slot-auction ePBS may function as an intermediate step towards total decoupling. We need another intermediate step before getting there, so let’s introduce it next.

Slot-auction+32 ePBS

We suggest now to let the beacon proposer of slot N determine the execution proposer of slot N+32, i.e., run a Slot-auction+32 ePBS. While this may seem like a strange construction, we intend here to decouple further the ties between the beacon proposer and the execution proposer of a given slot. In particular, this construction allows spot inclusion lists, created by the beacon proposer of slot N and binding the execution proposer of slot N (the latter being decided by the beacon proposer of slot N-32).

Despite this, we may very well still be in a scenario where it is a dominant strategy for the beacon proposer of slot N to commit to themselves as execution proposer for slot N+32, so we’re not done with our decoupling. In particular, the beacon proposers still receive all of the value to be obtained from being in control of the allocation of execution proposing rights. The thrust behind Execution Tickets (ETs) is indeed to completely remove this dependency, and while the design we arrive at isn’t exactly ETs, we will argue that it achieves this goal too. Let’s move on to this construction.

Execution Auctions (f.k.a. APS-Burn)

We suggest now a construction similar to MEV-Burn, except applied to the beacon proposer of slot N deciding which bid to commit to, where the bids are made for the execution proposing rights of slot N+32. This construction, Execution Auction, implements the concept of “Attester-Proposer Separation”, introduced by Justin Drake at Columbia Cryptoeconomics 2023. As argued in my previous post Reconsidering the market structure of PBS, APS may be understood as the market structure decoupling the roles of attesting/validating and proposing execution blocks, with ETs embodying a specific allocation mechanism realising this market structure. Execution Auction is an allocation mechanism too, a separate proposal from Execution Tickets which may offer some advantages as discussed below.

Attesters of slot N observe the bids made to purchase the execution proposing rights of slot N+32. The beacon proposer is expected to commit to the highest bid they have seen, while attesters vote for the beacon block only if the committed bid is consistent with the highest bids observed by the attesters.

MEV-Burn as presented in the past, where the beacon proposer of slot N commits to a bid for the allocation of the execution proposing rights of slot N, had in my sense two fairly fatal issues:

1. The value-in-flight issue: Beacon proposers and attesters were aiming to come to consensus over the value of an object whose value was drastically varying while the consensus was attempted. Indeed, transactions to be included in the execution payload of slot N trickle in during the auction, and prices on CEXes also vary at the same time, leading to a high variance of the value which the auction is trying to elicit. The design relying on slot auctions run 32 slots in advance ensures that a very small amount of information is relevant at the time of the auction to estimate the value which the execution payload may eventually return, so it looks more like a bet on the average.

2. The long-lived preconfirmation issue: Forcing the beacon proposer to select the highest bid offered for the execution proposing rights of the same slot also means that it is impossible to offer long-lived preconfirmations, which are committed to before slot N. If same-slot MEV-Burn was offered as a slot auction instead of a block auction, it would remain possible for the winning execution proposer to offer short-lived preconfirmations, committed to between the settlement of the allocation of the execution proposing rights and the ultimate delivery of the execution payload. With Execution Auctions, the winner of the execution proposing rights has 32 slots before their turn comes to propose the execution payload, and may offer long-lived preconfirmations in the meantime.

Execution Auctions offer an alternative allocation mechanism to ETs for the market structure of validator-proposer separation. In my sense, this shape of the allocation mechanism may make more sense than the format offered by ETs, but let’s quickly (re-)introduce ETs first before making that case.

Execution Tickets (ETs)

Suggested by Justin Drake and Mike Neuder, ETs allow execution proposers to go to a market where they purchase “tickets” redeeming execution proposing rights at some indeterminate time into the future.

Another way to put it is the protocol endowing some new, abstract module referred to as “ET market” with the execution proposing rights. These rights are purchased from the ET market by execution proposers. However, questions remain on how exactly should these rights be purchased. In particular, it is not clear to me whether beacon proposers should be responsible for including ET market-related transactions on-chain, or whether execution proposers should have this responsibility. One may imagine the inclusion of ET market-related transactions to possibly induce MEV, whether these transactions are included in the beacon block or in the execution payload. This risk appears to be mitigated by Execution Auctions.

Another possible benefit of Execution Auctions is the deterministic redemption period, e.g., 32 slots. ETs redeem at some random time in the future, which helps with mixing in case a single execution proposer is able to capture a set of tickets sequentially, but creates more variance for the ticket holder, likely to be reflected in the ticket price which the protocol captures. It would be possible to make ETs redeem at some deterministic time into the future though, but then one may want to think about designing for the case where an execution proposer is able to acquire many consecutive tickets. Meanwhile, Execution Auctions enforce a new competition for every slot.

In either case, ET or Execution Auctions, I believe measures should be considered to prevent toxic multi-block MEV from perturbing the liveness of the chain, when a single execution proposer is in control of several consecutive slots. Toxic multi-block MEV appears to mostly come from the proposer “freezing” the state for one slot (including no or very few transactions) and reaping the MEV in the subsequent slot.

Two measures appear to help: Inclusion lists and missed slot penalties. Inclusion lists ensure that the execution proposer must include some minimum amount of transactions supplied by the beacon proposer, so that the execution payload cannot be empty. However, an execution proposer can defeat inclusion lists by going offline for one slot, and miss proposing the execution payload. In this case, missed slot penalties would create economic pressure for the execution proposer to propose something, and something non-trivial by the property of inclusion lists.

A final note: A third mechanism recently proposed by Conor McMenamin, “Appointed Execution Proposers”, also performs the allocation for the Attester-Proposer Separation market structure, with a separate shape than either Execution Auctions or ETs. I hope to discuss some of the ideas in this post in the future, tying it back to rainbow staking among other topics.

Wat do?

I think we need to understand better the conditions required for something like Execution Auctions or ETs to make sense.

• From a consensus perspective, it may well be the case that Single Slot Finality or two-step PBS is a requirement for Slot-auction+32 ePBS and beyond, as the execution proposer delivery guarantees are weaker when the beacon proposer of the current slot N did not select the execution proposer for the same slot N.

• The pipeline [block-auction ePBS → slot-auction ePBS → slot-auction+32 ePBS → Execution Auctions] offers an iterative approach to offering a true validator-proposer separation, including the ability to capture MEV. However, the question of MEV-Burn applied to the slot-auction+32 mechanism remains: Does this clearly separate MEV rewards from beacon proposers, which is one of the goals of validator-proposer separation? If residual MEV exists due to the imprecision of the MEV-Burn mechanism, timing games in the beacon proposer step may persist. A chaotic idea would consist in endowing execution proposers with the execution proposing rights, such that the MEV-Burn gadget is applied to the execution proposer of slot N instead of to the beacon proposer of slot N, in order to allocate the execution proposing rights of slot N+32.

• The pipeline [block-auction ePBS (→ slot-auction ePBS (→ slot-auction+32 ePBS)) → ETs] is also possible (with SA-ePBS and SA+32-ePBS both optional intermediate steps in-between), yet the jump to an ET world appears more daunting. The main question on my mind is how bad is the MEV created by ETs, i.e., how to design their integrations as new “native assets” offered by the Ethereum protocol.

Bonus: Et tu, PEPC?

Proposer commitments have seen more interest with preconfirmations recently, so it might be worth wondering where PEPC (Protocol-Enforced Proposer Commitments) fits in all this, and how one might think about it given the framework of proposing and building rights.

Essentially, PEPC is a solution for the execution proposer to sell programmable building rights. In PEPC’s design, a proposer could add programmable validity conditions (proposer commitments) on the block they propose, such that the block could not be included in the canonical Ethereum chain if it it did not satisfy the proposer commitments registered by the proposer. In other words, the execution proposer creates the specs, or the template, by which the resulting block must be created, and the builders engaged by the proposer are tasked with delivering the block according to its specifications.

As an example:

1. Proposer Alice could commit to include a transaction with hash 0xabc at index 0 of the block. The commitment is registered on-chain, in Ethereum, either before Alice’s slot or when she proposes her beacon block containing proposer commitments in step 1. pictured above.

2. Proposer Alice offers to sell her building rights, listening to offers from a set of builders.

3. Builder Bob offers Alice 10 ETH for the building rights. Alice accepts by signing Bob’s offer, including it in her commitments.

4. Bob is aware of Alice’s commitment (it is on-chain, hence common knowledge to all participants building on Alice’s branch). Bob makes a block containing 0xabc at index 0. If Bob made any other block, e.g., including transaction 0xdef at index 0, the block would be ruled out as invalid by validators of the chain, but Alice would still get paid 10 ETH since Bob’s commitment was written on-chain as a protocol-bid.

Note that Bob accounts for Alice’s commitment in the bid amount he offers, e.g., Alice’s commitment may have reduced the value which Bob could extract from the block, as otherwise Bob could have made use of the first spot in the block, a very valuable position to be in. But the ability for Alice to make these commitments may have value to herself beyond what Bob could have done with it, e.g., Alice may collect preconfirmation tips from offering the commitment, or, using proposed PEPC features, she could have segmented blockspace such that partial builders each build a specific part of the block, or even sold the building rights of the block in advance (“blockspace future”, though perhaps the latter is less important if the execution proposing rights themselves are sold in advance too).

How does PEPC architecturally fit with the previous designs, where the beacon proposer and execution proposer are decoupled? If Alice is known to be the execution proposer of slot N say, 32 slots in advance, then Alice may register commitments in advance. The question is whether these commitments would be registered as either EVM transactions, in which case they should be included by execution proposers in their transaction payloads; or as special consensus-layer transactions, in which case they should be included by beacon proposers in their beacon blocks.

• If execution proposers register commitments, Alice has up to slot N-1’s execution proposal (inclusive) to register her commitments.

• If beacon proposers register commitments, Alice has up to slot N's beacon proposal (inclusive) to register her commitments.

In either case though, Alice depends upon proposers other than herself for the registration of her commitments. She is also unable to register commitments “just-in-time”, as she is about to sell her building rights to builders. PEPC was originally proposed as an overlay to the “two-slot PBS” design, as presented above with “Block-auction PEPC”.

We could go further to obtain all the properties we care about:

• Decouple the beacon proposer from the execution proposer fully.

• Let the execution proposer make just-in-time commitments, i.e., offer the execution proposer the ability to create the block template right before the delivery of the block by committed builders.

To get there, we need a three-step PBS construction, depicted here:

Opinions my own, reviews are not endorsements: I benefited greatly from conversations with Potuz and Terence, the RIG team + Mike + Fradamt + Ansgar, the ephema crew, Drew, Conor, a discussion with Taiko folks, and many others. It takes a village…