please comment with things I’ve missed
One of the big lessons of MEV over the last few years is that the interface between validators and market participants is crucial. PGA’s, failed transactions, latency games, auction revenue, and consensus instability are all partly side-effects of different interfaces.
While Proposer-Builder Separation (PBS) on Ethereum is the canonical example of such an interface, this interface is both imperfect and designed with the specific setting of Ethereum in mind. In light of these imperfections (highlighted below) and the growing popularity of alternative chain designs and L2’s, there are many open questions which remain unanswered. It is of the utmost of importance for the blockchain research community to come to a deep understanding of the issues at hand.
Much of the current research and discussion is framed in the context of MEV-Boost and PBS on Ethereum. This framing should not limit the scope of posed questions to Ethereum. We encourage readers of the analyses and open questions below to apply these questions to other settings which come to mind. As a starting point, it might be useful to list some of the original design goals for Ethereum’s PBS to understand how other settings might differ:
Simplicity of proposers: resource requirements for proposers should be low and there should not be significant additional gains to implementing complex strategies.
Limited economies of scale: being a larger or more-well capitalised staker should not bring in additional yield as this is a centralisation vector. Hence, proposers should not be trusted entities (otherwise home stakers will likely not be trusted).
Protocol Value Capture: Of the value that is captured, as much as possible should be directed to the protocol/validator. This is a separate issue from protecting “unsophisticated” users from negative externalities of MEV. E.g. latency infrastructure providers should not capture most of the value of the auction.
Efficiency and Mitigation of Negative Externalities: It is difficult to comprehensively describe this goal, but some specific examples are
- Blocks should not be filled with failed transactions
- Validators should not be spammed
- Mike Neuder’s Talk at PBS.day
- What is Proposer/Builder Separation (PBS) on Ethereum?
- Notes on Proposer-Builder Separation (PBS)
- Block production in Ethereum after the Merge - HackMD
- Why enshrine Proposer-Builder Separation? A viable path to ePBS - Proof-of-Stake - Ethereum Research
- Equivocation attacks in mev-boost and ePBS - HackMD
- [DRAFT] Payload-timeliness committee (PTC) – an ePBS design - HackMD
- Relays in a post-ePBS world - Proof-of-Stake - Ethereum Research
- Issues · flashbots/mev-boost · GitHub
- Optimistic Relaying
- Paper on Latency Games
- MEV-Boost using EigenLayer - HackMD
- All talks at PBS.day
- A similar list maintained by Mike Neuder (includes code)
- Unbundling PBS: Towards protocol-enforced proposer commitments (PEPC) - Economics - Ethereum Research
- Cosmos Protocol-Owned-Building
- Empirical analysis of Builders' Behavioral Profiles (BBPs) - Economics - Ethereum Research
- Time boost: a new transaction ordering policy proposal - Arbitrum Research
- [2306.02179] Buying Time: Latency Racing vs. Bidding in Fair Transaction Ordering
- Jito on Solana
- Themis: Fast, Strong Order-Fairness in Byzantine Consensus
- [2301.13321] Censorship Resistance in On-Chain Auctions
- Random Encrypted Ordering
- [2307.10878] Threshold Encrypted Mempools: Limitations and Considerations