Why You Should Care About ePBS?
Proposer š¤ Builder
Background
ePBS, or Enshrined Proposer-Builder Separation, has evolved into a loaded term over years of debate and research. The meaning of ePBS varies significantly between individualsāAlice's understanding of ePBS might not align with Bob's or Charlie's. To set the stage for this blog, it's crucial to clarify my perspective on ePBS.
What is ePBS? At its core, ePBS refers to enshrining proposer and builder separation into the protocol aimed at minimizing the trust dependency between proposers and builders. The term "enshrined" is profound: what does it mean to enshrine something into the protocol? One way to view this is to signify the transition towards a trustless exchange. As simple as it sounds, one can assume the protocol operates trustlessly, when people run vetted open-source client code, which is transparent and auditable. Today, the proposer's role is part of the protocol, ePBS is to enshrine the builder's role, thereby facilitating trustless interaction between proposers and builders. Today, trust between the proposer and the builder is established through a relayer. However, the objective of ePBS is not to eliminate the relayer but to remove the necessity for trust between the builder and the proposer. This represents a subtle yet profound distinction, which will be explored later.
Relayer Choking Points
The relayer acts as a trusted intermediary between the proposer and the builder. I will not explore the functions and workings of the relayer, as there is already substantial material available on the topic. Instead, I will concisely outline the first and second-order negative effects of the relayer on the protocol and discuss its potential unsustainability in the long term.
Relayers are expensive to operate and intended to be an open-source good but suffers from a lack of a sustainable funding model and is often underappreciated by the community. This has led to relayers exiting the market due to weak aligned incentives. Various funding models for relayers have been proposed, but none have been concretely implemented. It is unlikely that a solution, agreed upon by all stakeholders, including client teams, validators, builders, and others, will emerge anytime soon.
Relayers are frequently seen as actors outside the protocol, not involved in the client development cycle. For every network upgrade, researchers and core developers collaborate to 1) scope the feature set, 2) carry out the implementation, 3) conduct testing, 4) gather feedback, 5) proceed with further implementation and testing, 6) launch devnets, 7) upgrade testnets, and finally, 8) upgrade to the mainnet. Out-of-protocol actors typically don't get involved until later stages. This often results in lagging in providing feedback, adhering to the schedule, and increasing the risk of bugs.
Relayers add to another layer of censorship. A relayer may choose not to serve a particular builder or not to relay a specific block due to certain requirements, but the validators requesting the block are neutral or rationally driven. Today, when a validator selects a relayer, it often opts for the most popular ones.
Relayers play a crucial role in the infrastructure, with 90% of block production outsourced through them, featuring an inverse O(1) security model. When a validator connects to N relayers through mev-boost, it takes only 1/N of the relayers defecting to result in a missed block.
Relayers are a centralizing force. Over two-thirds of the mev-boost blocks are produced using just three relayers.
Proposer and relayer relationship
Let's divide today's mev-boost-based PBS into two domains: the interaction between proposers and relayers, and the interaction between relayers and builders. We will first address the proposer and relayer domain by examining the differences before and after the implementation of ePBS.
Today, proposers rely on relayers for:
Making sure the proposer is served with a valid header
Making sure the proposer gets paid when an honest action was carried out
Making sure the proposer's block gets propagated and also returned to the original proposer
The first point involves a trade-off between builder safety and consensus safety, with different types of relayers having varying risk tolerances. An optimistic relayer, for example, does not verify the payload upfront but requires a deposit from the builder to cover any losses if the payload turns out to be invalid. The third point involves a trade-off between builder safety and consensus liveness. Currently, relayers introduce delays in propagating the block they receive from the proposer to reduce the risk of the proposer's same-slot unbundling attacks against the builder. When a relayer receives the signed block close to the 4-second deadline, it faces a dilemma: whether to reveal the payload or risk missing the proposer block. Typically, the proposer block is missed, and if this happens, the consensus data is also lost, and the proposer is not compensated. There is no reliable method to differentiate between a proposer who is honest but slow and one who is malicious and aiming to attack the builders.
ePBS enhances all three points. For the first point, while a builder might still reveal an invalid payload or not reveal one at all, the consensus data for the block remains available. Only execution is missed, the beacon chain maintains consensus liveness. In the second point, the proposer receives payment from the builder unconditionally, provided the block stays canonical. This exchange is trustless and integrated into the protocol. For the third point, the urgency of block propagation and decision-making between the 3-4 second mark is alleviated, as ePBS introduces a more efficient pipeline structure. The process begins with the proposal broadcast, followed by attester voting, then builder's reveal, ensuring a clear separation of duties. However, the builder still faces a dilemma if the proposer releases the block at the cutoff, potentially causing a split view. Next, we will discuss the domain involving relayers and builders.
Relayer and builder relationship
Today, builders rely on relayers for:
Making sure builder's payload is protected until it's safe to release
Making sure all the builders are treated equitably
The first point concerns builder safety again. If a builder's payload leaks, other proposers and builders could potentially steal the content, whether in the same slot or the next. The second point addresses builder fairness. As the integration between relayers and builders becomes more prevalent, it may become challenging for new builders entering the market to receive support. Validators often select the most popular relayers based on third-party curated lists, making it difficult for smaller, competitive builders to promote themselves to validators without intermediary relayers.
ePBS enhances all two points. Without the relayer, the builder itself protects the payload and determines when it can be released. The second point becomes particularly appealing to independent, small, and competitive builders. If you are such a builder, it's worth considering the level of trust you place in a relayer, especially with the possibility of vertical integration between relayers and builders. Builders become trustless relays without investing or purchasing credit for this "trust." ePBS promotes healthy competition among builders, aligning with the Ethereum protocol's goals.
Builder's identity is on the chain
Have you experienced this? You receive a notification about a missed block, collect the logs, head to the client's Discord, ask questions, share your logs, and the client devs suggest the issue lies with the relayer. So, you join the relayer's Discord, inquire further, and the relayer points the finger at the builder. Then, you move to the builder's channel. Given that mev-boost connects to multiple relayers and each relayer connects to multiple builders, pinpointing the source of failure often becomes a cumbersome process.
One benefit of ePBS is builder's identity is coded on chain. Builders are now registered on the beacon chain, making it easier to identify them if issues arise, including access to their public key, previous patterns, and deposit address. This also enables a more defensive design, if a builder's submission is missing or invalid, their address can be blacklisted for a specified duration. This strategy helps prevent consecutive missing blocks from the same builder, a common issue today.
Misconceptions
In this section, we'll clarify some misconceptions:
Q: The relayer isn't being phased out. Proposers can still bypass it and retrieve bids through an RPC port instead of the P2P network.
A: The objective isn't to eliminate the relayer but to remove the need for trust between the proposer and builder. It's perfectly acceptable for the builder to take on the role of the relayer, providing a faster RPC port for proposers to use. In doing so, the builder can become a trusted relayer without investing in gaining this trust.
Q: Due to concerns about latency, builders will avoid broadcasting bids over P2P, considering it is slow. Instead, both builders and proposers will utilize RPC connections. This action is bypassable.
A: This situation is acceptable. It's okay for all parties to use RPC. P2P serves to ensure liveness. Should all builders relying on RPC encounter failures, proposers would still be able to receive headers via P2P. Having at least one honest builder distributing bids over P2P is essential. This liveness assurance is valuable as it reduces reliance on builders, potentially leading to lower builder staking requirements.
Q: Because proposers can obtain RPCs headers, mev-boost could still be operational. A: Mev-boost can indeed continue to function. The existing design retains compatibility with the same Builder-API as previously used. Proposers will curate their builder lists, which primarily affects UX and is not a significant issue.
Q: What about improvements to mev-boost and relayer to address shortcomings, such as unconditional payment via an escrow contract and adding additional attester duties for header and payload validity, improving the status quo.
A: Achieving the goals of ePBS might be possible with mev-boost alone through incremental updates. The solutions provided by mev-boost and validator may suffice, making it necessary to compare both roadmaps and decide on one, considering the limited resources available. We must also evaluate whether improving mev-boost incrementally is worthwhile and if such enhancements can address all critical issues we aim to solve. This involves a trade-off that requires further exploration.
Open questions
Proposer splitting the builder
When a proposer broadcasts its block with the builder's header close to the attestation cut-off interval, the builder is put into a difficult position. Specifically, if the builder notices that the weight of its header is just half of the total weight, it faces a tough decision regarding whether to reveal the payload. Revealing the payload for blocks that are not canonical leaks information to the next slot. Not revealing the payload when the block remains canonical results in unconditional payment for the builder. This dilemma does not exist with relayers, as the decision to reveal ultimately rests with the relayer.
Fitting everything under 12s
Extending the beacon slot duration beyond 12s represents a major modification with repercussions for a wide range of downstream applications. Such a decision demands meticulous evaluation. Nevertheless, realizing ePBS within the existing 12s framework might be achievable, particularly by separating consensus and execution validation. This separation leads to a more efficient allocation of processing within each slot. For example, attestation could occur at the 4s mark, followed by aggregation and builder reveal at the 7s mark, and then PTC actions at the 9s mark.
Staked builder? CL or EL payment?
The necessity and amount of staking for builders still need to be decided. Given the limited influence of the builder on fork choice and the bids over P2P gossip as a backup for network liveness, the argument for mandating builders to stake could be weaker. One reason is payment through consensus is simpler than execution. If optimizing for consensus-based payments is the primary goal, then allowing builders to hold the balance for payment within the beacon state might be an option.
UX: Multiple builder RPCs support
It is reasonable that stock client software may not incorporate MEV-Boost-like functionalities to enable validators to interface with multiple builders through RPC. Instead, this capability is anticipated to be facilitated by larger entities, including Lido, Coinbase, and other major exchanges. These organizations possess the necessary resources and infrastructure to support these integrations, thereby enabling them to offer validators the opportunity to connect with an array of builders effectively.
Conclusion
Withdrawal has been delivered, and proto-danksharding is soon to be delivered. Over the next year or two, consensus safety will be the highest priority. The current MEV-boost scheme is not sustainable in the long term for the reasons mentioned above. The detailed design of ePBS requires further refinement. If you're interested in contributing, consider joining the ePBS breakout calls and the ePBS Discord channels for ETH R&D!