It’s been a while since I wrote about PBS last, and given the activity on that front over the recent months, this feels like a good time to jump back in. Some of it here is more unstructured thoughts, grasping for connections that aren’t quite clear yet but feel already decent enough to discuss.

ePBS is back

Recent proposals towards enshrining Proposer-Builder Separation (PBS) (Potuz, Terence) seek protocol support for the market relationship currently known as MEV-Boost, re-opening the box of “PBS, wat do?”

To frame the following discussion, I’ll use a distinction I made in the past, between two components of PBS:

1. The market structure: The parties engaged in the market, and their conditions for engaging. Today, it is the idea that we’d unbundle the role of a validator between proposer and builder, and operate a fair exchange between the two unbundled parties, which Potuz’s design constraints seek to satisfy.

2. The allocation mechanism: The space of contracts which the parties may enter into. Today, with MEV-Boost, proposers give up entire rights to their execution payloads after listening to open bids in a “just-in-time” permissionless auction.

My line of arguments with PEPC was that enshrining a specific allocation mechanism such as ePBS could be dangerous, and that we could instead enshrine the ability for the validator to perform programmable fair exchanges instead, allowing maximum latitude for the validator to enter into commitments in their role as proposer. In this note, I go further and question the market structure of validator-as-proposer given recent proposals such as Execution Tickets. ePBS, as proposed recently, enshrines both a specific market structure and an allocation mechanism mostly inherited from MEV-Boost. The market structure determines the space of possible allocation mechanisms, and I argue that some of MEV-Boost’s limitations in inducing a “healthy” builder market may be inherent to the market structure involving validators-as-proposers.

*In the following, I use the term “payload” rather than “block” to limit the discussion to the execution payload only, and not talk about the delivery of the beacon block, which remains the duty of validators.

The pains of being proposer as validator

At its core, the idea of MEV-Boost is: A validator is given proposing rights allowing them to propose an execution payload once their turn is up, and receive proceeds from the use of these rights. Yet the validator wishes to contract out building rights to let someone else (a builder, or builders) decide the contents of the block on their behalf. MEV-Boost allows for this sale to happen, while making it happen wholesale, and spot. Proposers sell off their whole payloads, and builders commit to payload contents at the time of the bid. This is a specific allocation mechanism, and other designs exist, such as slot or hybrid auctions where the commitment is made to use a payload from a specific builder, but without committing in advance to the specific content of the payload.

At this point, more than anything, it feels like a protocol limitation that the validator has to remain the payload proposer, that they have to sign off on a process with which they have nothing to do in terms of its construction. In this sense, the signature of the proposer feels almost purely cosmetic, a technical necessity almost. Meanwhile, this technical necessity still requires the complex mechanics of the fair exchange at the heart of MEV-Boost. The exchange in question is that of a builder’s promised output (a block), against the signature of the validator, who assigns building rights while retaining proposing rights for themselves.

The complexity of operating this exchange cannot be removed, only displaced, allowing certain trust assumptions to change depending on whether the complexity exists out-of-protocol or in-protocol. The protocol taking on this complexity may be worth it, if we felt it was indeed the right idea for the protocol to organise and secure the allocation of building rights. By enshrining this exchange, the protocols continues to make the validator a proposer of the execution payload by default, and the protocol offers the ability to perform the exchange with a specific allocation mechanism, such as “spot, wholesale PBS”, or, as in a recent proposal by Potuz, “0-slot early, wholesale PBS”, a.k.a, slot auctions.

So now comes the question of deciding whether to enshrine a protocol mechanism for validators-as-proposers and builders to enter into mutually binding agreements with one another, i.e., for validators-as-proposers to have trustless option allowing them the sale of their building rights. An argument made during the recent (e)PBS breakout call was that the presence of this mechanism would sanitise the supply side of this market, i.e., relays and builders. For relays, the argument goes that since a protocol-approved mechanism exists, we can now take off our plate the responsibility of figuring out sustainable relay economics. For builders, the idea is that we now level the playing field to enter into service, since there exists a trustless, in-protocol way of doing so.

My issue is that neither assumption really questions whether it is the allocation mechanism or the market structure themselves which have created a market we consider too centralised. Relays today exist specifically to perform the fair exchange between validators-as-proposers and builders, and there is no indication that they would exist under the same shape or with the same economics given a different structure, or indeed exist at all. Builders may also very well be subject to centralising forces due to the wholesale and spot nature of the allocation mechanism. As a result, enshrinement of ePBS could enshrine the very things which cause the problems we seek to solve. So while ePBS does improve upon the status quo of MEV-Boost by increasing the action set of all market participants, could it also cement the existence of a market which is fundamentally unadapted? Are the improvements worth the cost of development, and are they the right boundary to set for the protocol?

Are validators good proposers?

We first question the market structure: Why should the right to propose an execution payload be given by default to the validator in the first place?

https://twitter.com/cwgoes/status/1727025552757059631

re: this tweet. Note that the original design of PoS on Ethereum was doing FFG as an overlay on top of good ole PoW chain. Would we be talking about timing games in that world? Checkmate.

Let’s try and think about reasons why validators ought to be the default payload proposers. Censorship-resistance may be a reason to keep validators active in the construction of execution payloads. We want the decentralisation of our validator set, a key tool to realise the maximum breadth of preferences possible, to be exercised during payload construction. Yet validators forego this ability entirely today when they use MEV-Boost, or could forego it entirely tomorrow when they would use ePBS. Proposals such as inclusion lists or derivatives (e.g., Multiplicity) exist to remedy this situation, allowing validators to impose binding but non-efficiency-decreasing [1] constraints on payload construction. These proposals are however somewhat orthogonal to the question of allocating proposing rights, in that they bind whomever happens to own this right, whether that is another validator or some other party.

The answer to why we care for validators to be attributed proposing rights by default may also be: We care for validators who are self-building to impose their favourite ordering or make the payload contents as they please, i.e., we want them to retain building rights along with proposing rights. Indeed, it may be seen as a feature that a decentralised set of participants (the validators) gets their turn one at a time to make a payload as suits them. Alice might like her payloads to be ordered fairly, where the definition of fairness is Alice’s prerogative and may be wildly distinct from Bob’s. In this case, removing the property right of building execution payloads from validators would be an issue: We would no longer guarantee that validators get the option to build execution payloads as they please. I do not personally see that as a major issue. First, the market has revealed the preference of most validators to not exercise this building right themselves, delegating the construction to other parties. Second, while validator agency over payload contents via self-building may be good, the validator has not in my opinion more reason than anyone else to make a “well-ordered payload” (separating out the question of censorship-resistance which was addressed in the previous section). Note that earlier designs such as MEV-Burn preserve the default allocation of proposing rights to the validators, while forcing them to give up their building rights.

Validator-proposer separation (a.k.a., attester-proposer separation, a.k.a., execution tickets)

So what if the protocol decided to no longer attribute by default the property right of proposing and building the execution payload to validators, but instead allocated it by some mechanism to parties possibly distinct from validators? If validators are simple “pass-through” intermediaries to a group of third-party entities constructing payloads, wouldn’t it make sense for the protocol to be concerned only with the allocation of proposing rights?

This is the gist of execution tickets (ETs), where a permissionless market allows buyers to purchase the right to propose execution payloads. These rights confer the ticket holder with a random allocation, where the holder learns a few moments ahead of time (how long exactly is a parameter to determine) when their ticket will allow them the opportunity to propose an execution payload.

The protocol may then no longer be concerned with the fair exchange of building rights between a protocol-legible validator-as-proposer and a protocol-illegible builder. The ticket-holder-as-proposer is still legible to the protocol, though the ticket holder may not be staked. In particular, the protocol may no longer be responsible for the fair exchange, if any, between the ticket-holder-as-proposer and builders: The protocol has performed its allocation function when selling the ticket.

Many questions remain over the viability of execution tickets as allocation mechanisms for the market structure which separates validators from proposers. My personal opinion is that convincing us of the correctness of the market structure would convince us that some mechanism exists to perform the allocation properly, ETs or otherwise, if ETs were indeed not the right mechanism.

The most potent line of argument I’ve seen questioning the market structure of validator-proposer-separation comes from Quintus Kilbourn and Conor McMenamin in their excellent post “When To Sell Your Blocks”. Here, they distinguish between passive monopolists and active monopolists. In the validator-as-proposer model, one may consider the validator to be a passive monopolist, who simply listens to bids made by builders for the right to build the payload. In the validator-proposer-separation model, as performed by ETs for instance, the ticket holder would become an active monopolist, who according to Quintus and Conor “cannot be circumvented and is thus able to do things like establish minimum tips that transactions have to pay to be included in their block(s) (monopoly pricing) and frontrun time-sensitive flow with little concern for recourse.”

Quintus and Conor further note:

[T]he distinction between active and passive monopolists doesn’t hold in a rational model. This distinction is derived moreso from observed behaviour from validators. It may be that in the long run, validators approach the rational behaviour of being active monopolists anyway. On the other hand, exogenous reputation concerns may prevent this.

In other words, if validators tend towards rationality in the long run, the difference between validators-as-proposers and ticket-holders-as-proposers may not remain very large. The accelerationist argument for this trend towards rationality has been established in practice, but might there be fundamental attributes which validators possess that would prevent them from ever fully becoming active monopolists? This remains an open question in my sense, one that my recent attempts at further unbundling the roles of a validator under the rainbow staking framework gets at. If there is no complementarity between the different roles that a validator may embody (as attester, as censorship-resistance producer, as payload producer), then there is a stronger argument for why nothing in the essence of validators prevents them from trending toward active monopoly, and why unbundling these roles may be a good idea.

Conclusion

There is almost a fractal construction at play when, in a validator–proposer separation world, the proposer recruited by the protocol could once again delegate the role of construction to another entity, the builder (or builders if the proposer used a different allocation mechanism for the builder rights such as partial block auctions). So overall, when we talk about market structure or allocation mechanism, we need to precise which market we’re interested in: the market allocating proposing rights, or the market allocating building rights?

I believe the implementation of ePBS should be considered holistically, in comparison with other choices such as execution tickets and validator–proposer separation more broadly. ePBS does improve upon certain aspects of the current MEV-Boost market, such as providing access to a trustless path and giving us the ability to enshrine different mechanisms like slot auctions. Yet, ePBS is concerned with the allocation of building rights, primarily, and perhaps this is not a problem the protocol should concern itself with. It may be enough indeed to allocate proposing rights, and relinquish control and observability past that point.