Present a roadmap towards enshrined PBS (ePBS) through a series of modifications
to the existing mev-boost relay. By progressively removing the relay responsibilities and pruning the
critical path of the block-building pipeline,
we aim to converge to a system that looks quite similar to existing proposals for ePBS.
- Agility — We aim to approach this protocol upgrade as suggested by Justin in the Censorship Panel at SBC. To front-load the
R&D effort, we can iterate quickly by experimenting with a portion of existing
relays, builders, and validators to reduce uncertainty and risk around full ePBS.
There are tradeoffs between ePBS and
mev-boostas highlighted by Barnabé at Devconnect and in Notes on PBS. This roadmap explores the design space between the two ends of the spectrum. - Inevitability — At Devconnect, Vitalik noted that with Danksharding, some builder separation becomes mandatory because bandwidth requirements for large (32 MB) blocks exceed what is within reach of a home-staker. This roadmap allows us to progress the research discussion by examining how different mechanisms work in practice.
- Accessibility — By presenting relay data and designing the optimistic architecture in the open, we increase visibility into the existing block-building market. This helps answer research questions (e.g., ROP-0 from Barnabé and Caspar) and allows independent relays stay competitive with vertically integrated Builder-Relays. Additionally, optimistic relaying reduces the hardware and networking resources required for a relay to be competitive, lowering the barrier of entry. From the builder perspective, optimistic building requires collateral be posted, but it removes the need for them to be in the high-prio queue of each relay they connect to.
We define the "critical path" as the set of operations and messages that compose the block production pipeline beginning when the builder submits a bid. We present a progression of 3 relay modifications that each reduce the latency associated with the critical path.
Latency is a centralizing force in the competitive block-building market. Since MEV is constantly being produced and extracted, rational builders are incentivized to colocate with relays, form trusted connections to relays, or even run their own relay infrastructure in order to minimize (down to
$\mu s$ or$ns$ ) the time between when they build a block and when that header is part of the auction. We believe that by simplifying the pipeline, we can maintain a competitive and open builder ecosystem, while working to phase out relays all together.
The figure below schematizes the critical path under the existing mev-boost
architecture.
|
The critical path runs through the relay, which is tasked with
- receiving the full block over the network from the builder (this can be several MB of data and will increase with 4844),
- validating the block against an execution node internally before communicating the winning header to the proposer, and
- receiving the signed header from the proposer and publishing* the block.
In practice, this entire process can take hundreds of milliseconds, even when running on high-performance hardware with good network connectivity.
* Note that the winning block is returned to the proposer, so even if the relay doesn't publish the block, the proposer should and is incentivized to do so.
The figure below denotes the critical path under Optimistic Relaying v1. This idea is proposed and implemented; it was also discussed in the MEV community call #0.
|
This flow differs only slightly from the previous; the relay does not immediately validate the block sent from the builder. This results in a reduction of the latency between when a builder submits a bid to the relay and when that bid becomes eligible to win the auction. This benefits both the builders and the proposers because it allows bids to arrive later in the slot, thus capturing more MEV for both parties. Under this design, builders can dishonestly submit high bids for invalid blocks that end up winning the auction, which results in a missed slot (because the proposer signed an invalid header). Alternatively, EVM valid blocks could be proposed and included but not pay the proposer the value of the bid. We account for this by requiring builders to post collateral to the relay which will be used to refund proposers if a slot or payment is missed. See the proposal, implementation, and community call for further details. This proposal should lower the hardware and networking requirements of running a relay because now there is no need for large amounts of burst compute and bandwidth right at the end of the slot.
The end of the slot is highly congested because all the highest bids are arriving in the final milliseconds before the proposer calls
getHeader. This exaggerates the issue if simulation latency and further benefits builders who are vertically integrated with relays.
Beyond the practical benefits mentioned above, we modified the critical path. Now, the relay is responsible for
- receiving the full block over the network from the builder (this can be several MB of data and will increase with 4844),
- communicating the winning header to the proposer, and
- receiving the signed header from the proposer and publishing the block.
The relay still validates each block it receives, but this validation happens asynchronously, thus is no longer part of the critical path. This demonstrates the main objective of this roadmap — "to reduce the duties of the relay and the latency of the critical path".
The figure below demonstrates the critical path under Optimistic Relaying v2.
|
The critical path still runs through the relay, which is tasked with
- parsing the incoming message from the builder for just the bid details (this is a few hundred bytes),
- communicating the winning header to the proposer, and
- receiving the signed header from the proposer and publishing the block.
Here we remove the additional latency of waiting for the whole block execution body to download to the relay (which will become even more relevant with full Danksharding). This can result in an invalid or missing block from the builder, in which case the proposer refund is handled in the same manner as v1.
This design has an additional practical benefit. The relay is no longer able to censor because the bid is eligible when the header is parsed. The relay doesn't yet have information about the transactions in the execution body, so it can't censor based on those transactions.
The figure below demonstrates the critical path under Optimistic Relaying v3.
|
Note that now the relay is no longer in the critical path! The builders and proposers communicate directly through the p2p layer. We assume that the builders will be well-connected nodes in the p2p network because they are incentivized to have extremely short paths to the proposers, thus the messages will still be fast.
The critical path is now just
- the proposer listening over the p2p network for header-only bids (this is a few hundred bytes), and
- the builder listening over the p2p network for a signed header corresponding to their bid.
The relay is still present in this architecture, but only serves as an oracle in the case of a missed slot. The relay observes the mempool and determines if (a) a signed header was produced on time, but (b) the corresponding signed block was not produced on time. In this situation, the builder is at fault, and their collateral is again used to refund the proposer as in v1 & v2.
Note that the proposer payments could be implemented in an unconditional way. Such a mechanism was presented by Alex O. and Stephane. This would eliminate the need for the relay to directly control the builder collateral, and reduce the relay to a data-availability oracle for the signed block appearing on time. The tradeoff here is the engineering complexity and inherent risk of using smart contracts to implement this logic. This may well be worth investing time into in the future, but we estimate that in the short-term, the relay operators (or guarantors) should handle the refunds manually.
The figure below demonstrates the critical path under ePBS.
|
The final evolution of this roadmap is to replace the v3 relay with a committee of validators and enshrine PBS into the protocol. The specifics of the mechanism can vary; Vitalik has proposed single-slot and two-slot. Under the two-slot implementation (which seems to be the most popular currently), the proposer chooses a header to include in their beacon block and publishes it in their slot. One committee attests to this block and once a builder is confident that the block will not be reorged, they publish an intermediate block in the subsequent slot that contains the full execution payload. The remaining committees attest to this intermediate block. The enforcement of honest behavior is implemented into the fork-choice rule, so that if a builder produces a block that differs from the winning header, the committee members simply do not attest to it.
The first committee attests to the timely publication of a signed header and the remaining committees attest to the timely publication of a signed block, which is exact set of actions that the relay listens for in v3.