Proposals here seek to improve off-chain PBS in the Ethereum ecosystem as it exists today. Two important artifacts here are the builder-specs and the relay-specs that specify the baseline behavior for the interaction between proposer and relay and relay and builder.
Here are some ideas or known issues that serve as good starting points for a proposal:
To use mev-boost, a proposer must first submit a signed registration to each relay they want to work with. Currently, registrations are submitted per validator around once an epoch to each relay. Two high-level concerns with the current process:
Validator registrations are signed by the author but they do not include the list of relays they wish to work with. This message could be extended with a list of relays the validator intends to submit their registration to. This change scopes the registration tightening the off-chain PBS model. By doing so, we get stronger assurances around the validator adoption relays have (which could inform relay sustainability designs) and makes the process of routing registrations to a given relay more flexible (e.g. registrations could be gossiped, iterating towards some kind of enshrined PBS design).
Currently, there is no single global view of which validator has submitted which registration to each relay at each time. This information can be approximated by polling the relay data APIs for all known relays and maintaining an index, but given our domain we can do better by simply forming a single registry on-chain and letting any interested party (including relays) read at will.
Here is a proposal that describes a potential implementation using the blob space unlocked by EIP-4844: https://notes.ethereum.org/@ralexstokes/val-reg-in-4844-blobs.
This is a moderate improvement over the status quo (builders could just price in reorg risk to compensate for this at the cost of less efficient markets) but it would be nice if the relay-specs APIs were “fork aware” so a builder could know if they are building on a fork a given relay supports.
Note: a successful proposal here also includes a proof-of-concept in builder or relay software along with the API changes.
mev-boost currently uses a first-price, open bid auction. A proposal investigating different auction types (e.g. second-price, or closed bid) would be very welcome.
A successful proposal looks like (1) specification of the protocol changes, (2) analysis of the implications (e.g. simulations or back-testing against public mev-boost data) for the design, and (3) optional (but very interesting!) implementation of the design in the relevant part of the mev-boost software.
To make this more concrete, there has been a running thread in the mev-boost R&D community around offering different types of mev-boost bids. One type leverages some streaming transport protocol (like Websockets) to have the relay send bids to the proposer, rather than the current architecture where validators poll each relay. This architectural decision has broad implications for what is possible in terms of bidding strategies for builders and services relays can offer. For example, a Websocket stream could be used to implement credible cancellations via builders. Another type would authenticate the proposer in getHeader calls. Doing so would be required to implement a sealed bid auction for builders.