Notes On PBS

Quintus · November 10, 2022, 3:32pm

I am starting this thread to aggregate internal discussion on @barnabemonnot’s new post Notes On Proposer-Builder Separation (PBS) and to open up discussion externally

Quintus · November 12, 2022, 12:11am

To kick things off, I’d like to offer a slightly different angle on things, which is implicit in the article, but I think warrants being stated explicitly. These aren’t super clear thoughts, apologies for the semi-ramble.

The value derived from the execution of user transactions: It is worth $10 to me that I am able to send a payment over Ethereum, and though I may pay a fraction of that, this value is realised once the payment goes through.

Although I agree with the idea that execution is and should be one of the main ways in which Ethereum creates value, I don’t think that execution should be viewed as a binary concept. In other words, I don’t think inclusion is really the only thing that matters to users. Already, we see users care about the price at which swaps or other more complicated financial operations are executed on top of whether they were executed at all . Ideally, the future of Ethereum holds a world of many complicated, weird and wonderful applications. Some of these applications (arguably most), may need to outsource computation or require aggregation of conflicting preferences. Incentivisation for this computation and expression of preferences is likely to lead to more MEV. If well designed, greater extraction of this MEV should imply higher user payoff. Let’s call this aligned MEV.

Taking the existence of aligned MEV as a given, it seems that there are (at least) two properties we would want block construction to satisfy:

Avoid “bad” MEV: Ultimately, “bad” is a subjective term, but there may be some things that we generally agree on as being good to avoid. Importantly, we want to impose constraints across the board, so that some validators don’t gain a wild advantage over others. Some candidates for MEV we want to avoid:
- Censorship: the value of pure censorship is implicit, since it satisfies the builders own preferences and no payment is transferred. There could also be value in risking an empty slot in pursuit of some super high return strategy.
- Extortion: a validator knows that inclusion within the next block is worth x to the originator of the transaction, they can refuse to include that transaction unless x-\epsilon is paid
- Mafia EV (h/t sxysun): by this I mean the block builder seeing a user transaction and executing it under conditions such that the builder profits at the expense of the user in a zero or negative-sum way. (e.g. sandwiching).
- Value that is not redistributed: currently realised MEV that flows to users validators is redistributed to users in the sense that it contributed to the Ethereum security budget. Some value is needed to incentivise the ecosystem of agents seeking to solve the optimisation problem (e.g. searchers, solvers and builders), but MEV captured above this should be considered non-redistributive and undesirable.
Give freedom to search for high social welfare state updates: not only should our attitude be that we want to give equal access to maximum MEV rewards to all validators because it’s good for decentralisation (the original “naivete” goal), we should also want to maximise extraction of aligned MEV because it represents higher social welfare for users. Some examples of AMEV:
- Avoid reverted transactions
- CoWswap-like batch solving
- reordering AMM trades for highest utility (sort of happens already)
- finding stable matchings for matching markets or any kind of search for preference matching

So we want to limit some kinds of MEV and maximally enable the extraction of other kinds. These goals seem somewhat in tension as it can be hard to move bathwater without the baby. Many proposals to avoid “bad MEV” (maybe we should call this unaligned MEV?) end up restricting the search too. E.g.

Completely threshold encrypted mempools don’t allow for any intelligent block construction and introduce latency among other issues.
Many proposals for consensus-based FIFO ordering don’t allow for any expression of preferences outside of impatience
PBS introduces latency which increases time between transaction submission and knowing the outcome, and decreases utility for time-sensitive users (like cross-domain arbitrageurs). Having bids be floated through a gossip network will probably be much worse

So from a protocol perspective is how much bad can be eliminated without throwing out too much of the good? If aligned MEV favours the users, we can maybe expect users to vote with their feet by sending order flow to non-predatory block builders/building systems perhaps. The task obviously can’t be left up fully to market forces either.

For example, because of multi-block MEV, the current incentives might demand a market in which slots are auctioned way in advance, but auctioning slots way in advance makes slots homogeneous as there is little information to condition bids on. Now, instead of competing on a bunch of different strategies (some of which only pay off on occasion), builders basically compete only on their expected returns per slot, which may centralise the market and reduce competition, meaning that value is no longer redistributed via the security budget.

PEPC is interesting in this regard. We don’t know what the optimal PBS-like commitment market looks like. The optimal design might change through over years or blocks or even validator-to-validator and PEPC helps discover/adapt to the moving ecosystem. At the same time, there may be some local optimum where we can get stuck despite being globally far from optimum. What are the right constraints to avoid being stuck (e.g. SSLE), while still allowing freedom for discovery (which might be inevitable anyway).

As a last thought, I’ll mention an example of where I believe market forces could select a system that is well designed for AMEV. Decentralised building could end up being better for users due to more efficient extraction of AMEV by aggregation of many different strategies/local pieces of information while avoiding undesirable MEV because of constraints imposed by the decentralised builder “rules” (similar to consensus enforcing block validity conditions).

I hope the above added some stimulus even by being way off XD

apriori · November 21, 2022, 1:13am

Very good write-up inspiring a few half-baked thoughts.

Builder pre-confirmations could help with this. The idea Vitalik recently put forth:

users receive enforceable commitment from builder to include tx if priority fee >= 5
users receives state root if priority fee >= 8

Advantages

Agency for users ~ more ways to express preferences
Significant UX Improvement ~ High TPS chains have no edge
Enforceable builder commitments (abstractions)
Compatible with distributed builder

Trade-offs

Centralized builders could win the market before a distributed builder is viable
Reliant on out of protocol slashing

Is it worth considering how to leverage Mev-Boost? Proposals like Mev-Boost ++ could help test PEPC or other variants prior to IP-PBS.

Quintus · November 21, 2022, 10:00pm

Yes I can definitely see how pre-commitments address a lot of issues and “credible commitments” in general are an interesting approach. I’ve been wondering if pre-commits don’t just move the uncertainty elsewhere. For example, a validator could commit to including some transaction with a certain state root, but then another transaction paying 1000x what the first is paying arrives, but is only valid if the pre-confirmed txn is invalidated. If the commitment holds, then the val has obviously lost out.

barnabemonnot · January 9, 2023, 2:52pm

I came back to these notes much later than I was expecting to Thank you for writing them up! And I am still thinking about the points you raised.

I really agree here, and it was a lazy way of writing. My value as a user is not for a single execution path, it’s more like a vector of values over all possible states upon which my transaction acts, or equivalently over all outcomes that my transaction could bring about. In the case of a swap, if I have quasi-linear utility with respect to the token I am swapping to, the execution price will affect the value I receive from the transaction. Last year I was working on a post that was aiming to write these ideas properly, and how various gadgets constrain the various outcomes that can be brought about (e.g., if transactions are encrypted, a proposer can’t realise the outcome where they sandwich the transaction), but I never found a good way to write it up, and Xyn eventually had a much more powerful approach.

It’s interesting to revisit these questions in the light of SUAVE. One of your questions is how much can the protocol do? Can it somehow enforce that only aligned MEV is extracted, and eventually redistributed? Can it only do one or the other, or neither?

On the extraction types, the issue as always is general computation. I don’t think there exists an objective way of recognising MafiaEV for instance. Even detecting that a sandwich took place seems hard. So I am not particularly hopeful for in-protocol “MEV segmentation”, that would let one type of extraction happen but not others. Which pushes the problem upstream, ie. perhaps to SUAVE.
On the redistribution, this seems more in the scope of the protocol itself. Research goes on about incentive compatibility of various mechanisms. I have not seen a strong mechanism for out-of-protocol MEV redistribution, but does it mean it doesn’t exist?

I am quite hopeful about this approach, and generally strengthen MEV-boost with local intelligence (e.g., relay monitor) + experiments in deploying credible commitments in various shapes, e.g., Eigenlayer or other methods. The economics of pre-commitments are not so clear to me, and perhaps as a stepping stone to designing system for them, the problem should be written up more clearly. For instance what is valuable to whom and when, something Julian has been investigating a little with block vs slot auctions in PBS.