Builders and Relays in ePBS
How the current PBS market structure may change under ePBS
Introduction
EIP-7732 i.e. enshrined Proposer-Builder Separation (also known as execution Payload–Block Separation) is a proposed EIP that promises to scale Ethereum by pipelining block validation, decoupling the execution layer validation from the consensus layer validation.
A key change includes the introduction of a new consensus role, the builder. While in the current out-of-protocol PBS proposers need to trust the builder (relay in MEV Boost) to reveal the payload, with ePBS the trust assumption is removed, with builders committing to an unconditional payment to the proposer and deciding whether to reveal the payload or not later in the slot. Builders become staked entities with a balance on the Consensus Layer (CL), and can be debited the proposer payment regardless of whether the execution payload actually makes it on chain.
In this post we focus on how ePBS may affect the builder market and the existing PBS market structure.
Builder → Proposer Submission
In ePBS, builders will be able to permissionlessly send bids via P2P in addition to the existing Builder API calls. Because of their nature, P2P bids will not be cancellable, and will likely be limited to a very small number per slot to avoid spam and excessive load on the network. P2P bids may still be useful when the builder is not connected to the proposer directly and doesn’t want to submit via a relay. Nevertheless, we expect P2P bids to be used sparingly because of the increased latency and lack of cancellations - a key feature that relays provide in the current market structure.
While the Builder API spec is still being worked on, we expect a few changes to happen, namely:
the
get_headercall will likely become authenticated with a signature from the proposer to streamline direct connectionsrelays won’t need to re-sign every header, assuming the builder submitting the block is staked (more on this below)
enshrined support for multiple builders in the API, i.e. no need for a sidecar to multiplex Builder API calls
Overall, it’s likely that the get_header call will remain the main way through which proposers will source bids from the builder market.
Auction dynamics
The relay auction in MEV Boost is usually modelled as a second-price open auction: builders have access to competitors’ bids and keep outbidding each other until the builder with the highest value block wins, paying the second highest bid. Note that the “relay as auctioneer” role comes from the untrusted nature of the builder in out-of-protocol PBS, and the need for a trusted counterparty to hold the auction on behalf of the proposer. In other words, it’s currently challenging for a builder to be able to bypass the relay, thus giving value to the relay as a venue for price discovery.
Under ePBS proposers will be able to source headers from builders trustlessly, therefore we expect some builders to connect directly to proposers, bypassing the relay. Proposers will have an incentive to source headers from as many builders as possible (including the relay), but in practice due to operational overhead, additional requirements on the content of the block (e.g. censoring) and other needs such as decentralized staking pools checking for MEV stealing, it’s likely that some proposers will only connect to a subset of builders.
With some builders having access to a direct connection to the proposer, the value of the open auction breaks down: a “direct builder” has an incentive to bid lower in the open auction and higher in the private, direct get_header call. Bidding truthfully in the open auction would therefore put builders at a disadvantage, providing an informational asymmetry to competitors.
As a result, it seems likely that relays will have to stop providing real time access to bids or risk seeing builders stop submitting altogether.
The change from second-price open auction, to first-price blind auction is a key change that will affect builders bidding strategies, as well as impacting the equilibrium winning bid for proposers.
Staked Builders
Under ePBS, builders will be required to stake ETH in the CL in order to provide unconditional payments to proposers. This will have a few implications:
Builders will have to source capital to stake in advance, in order to cover bids for a given period of time. How much to stake may vary from builder to builder, also depending on the expected number of blocks won and the length of the deposit queue. For reference, at the time of writing Titan Builder won around 45% of all blocks and tipped around 750 ETH to proposers over the past 7 days, and 4,000 ETH in the past 30 days (source).
Builders will need to stake enough to account for the highest bid they might send. Currently, non-optimistic submissions from builders have no stake requirements since the relay will simulate the block before accepting it, while optimistic submissions require builders to stake collateral. Non-optimistic submissions are generally very unlikely to win due to the increased simulation latency, except for a few important cases: “tail builders”, integrated searcher-builders who only build blocks for high value MEV transactions in tail events, e.g. large liquidations; and optimistic builders submitting high value blocks (say 50 ETH or more), exceeding the optimistic collateral.
Based on this we expect block building to become a more capital intensive enterprise, as builders will need to carefully manage staked collateral to avoid being locked out of bidding, while also managing the opportunity cost of the staked capital. We also expect to see fewer high value blocks (already relatively rare), as the new capital requirements would make many of them economically unviable. For smaller builders, relays could potentially offer a service to provide upfront capital (by re-signing bids), in exchange for a fee.
Conclusion
To summarise, we expect significant changes in the PBS market structure under ePBS.
The net effect on the block auction is unclear: on the one hand, open auctions have advantages over first-price blind auctions, including increased transparency and truthful bidding; on the other hand, the current relay auctions are not exactly second-price open auctions, and builders already engage in strategic bidding, waiting until late in the slot before placing bids.
The direct connection to builders and the new staking requirements will most likely negatively affect competition and increase concentration by raising barriers to entry, introducing inventory-management constraints, and making some building strategies unviable. It is possible that these negative effects may be outweighed by the positive effects on the Ethereum network at large, such as better pipelining and scaling, the analysis of which is outside the scope of this post.
Acknowledgements
Thanks to Alex, Caspar, Jason, and Potuz for feedback and discussions. Feedback is not necessarily an endorsement.