A two-tier auction market: the right resembles the less sophisticated publicly observable P2P market, and the left resembles the more sophisticated private RPC market.
Thanks to Potuz, Barnabé Monnot, Terence Tsao, and Thomas Thiery for comments and discussion.
The current ePBS proposal, EIP-7732, suggests operating a two-tier market where builders can bid to obtain the execution payload construction rights. Large block builders are expected to use the pull-based direct connection market. This market allows for lower latency and more flexibility for the builder, as the builder only needs to commit to its bid once the proposer asks for it. This market, however, requires the proposer to connect to the builder’s RPC and actively pull bid(s) from it. Smaller builders who lack this connectivity with the validator set can use the push-based P2P market. This market has stricter rules for what bidders can do but does not need the proposer to pull bid(s) from it since bids are pushed to the proposer.
This note explores the role of the P2P market in ePBS. Although there has been some initial exploration on the topic, this note presents a clear counterfactual of a world where the P2P market were not included in EIP-7732. This note also emphasizes multiplexing—the ability of proposers to discover builders—as the most important aspect of the P2P market.
The three arguments in favor of the P2P market that the author has seen in previous work are: 1) it allows anyone to set a floor price for the auction, 2) it can be used for MEV-Burn in future protocol upgrades, and 3) it lowers entry barriers for new entrants or long-tail builders.
The first argument is that allowing anyone to bid via the publicly observable P2P market gives all validators the ability to set a floor price for the auction. Validators can bid based on the block that they could locally build. Builders must then bid at least above the bid of these validators to obtain the execution payload construction rights. It has been argued that this is valuable if a cartel of builders intends to keep bids low. The floor price, however, would not break up a cartel. Although proposers would make slightly more revenue in this case, it is unclear what the value of such a floor price is to the protocol.
The beacon proposer selling the rights may be the ideal party to set a reserve price. As I argue in this post, a proposer may want to put a higher reserve price than its valuation for the execution payload construction rights to attract higher bids from builders. The P2P market allows the proposer to signal its reserve price to the market. In this sense, the P2P market allows the validator and other participants to express their preferences.
The second argument states that the P2P market may facilitate MEV-Burn in future protocol upgrades. MEV-Burn aims to decouple the rewards from selling execution payload construction rights from being a validator. This has numerous benefits; for example, it decreases the value of using a staking service provider (SSP) since MEV-Burn decreases the variance of validator payoffs. MEV-Burn requires that builder bids be legible to the protocol. Most designs achieve this by having a committee that observes the best available bids. If ePBS would only have the direct connection market, the MEV-Burn designs need to be revisited since a proposer selling the execution rights is incentivized to understate the amount that will be burnt. Still, the P2P market is expected to only reflect a small portion of the value of the execution payload construction rights, hence even ePBS with the P2P market may not be satisfactory for an effective MEV-Burn solution.
The last reason for the P2P market is that it would allow builders from which proposers are unlikely to pull bids to still compete in the market. Proposers may be unlikely to pull bids from builders that infrequently participate in the auction because they are very specialized or from new builders unknown to the proposer. This could be because proposers have an outdated whitelist of builders from which to pull bids. Allowing these proposers to participate in the push-based P2P market will result in more builder diversity in block construction, which may benefit the protocol.
This last reason is what we will explore in this post. Specifically, what does the Ethereum ecosystem gain by enshrining the push-based P2P market aside from an out-of-protocol solution that facilitates small builders’ participation in the market?
Shea Ketsdever recently released a post on TEE-Boost, an adaptation of MEV-Boost that uses Trusted Execution Environments. In this post, she highlights the different roles a relay plays. One of the roles is multiplexing, allowing proposers to discover builders who may want to participate in the auction.
The ePBS P2P market aims to achieve multiplexing. In the context of ePBS, multiplexing has at least two facets: trustlessness and value reflection. Trustlessness is important because ePBS removes the trust that proposers and builders must place in a relay to facilitate the fair exchange. Value reflection is essential because a multiplexing tool that poorly reflects the value bidders assign to the auctioned item will not efficiently match an auctioneer with the correct bidder.
The ePBS P2P market scores very well on the trustlessness front. Neither a proposer nor a builder must trust anyone since bids are broadcast via the P2P network, and the winning bid is committed to on-chain. The P2P market, however, scores poorly on the value reflection front. Since the P2P network must be DOS resistant, it cannot handle too many bids, so bidders will likely not be allowed to bid as often as they could in MEV-Boost, meaning they have to be strategic about when they bid. Moreover, early bids will not be able to be canceled, which could lead to strategic builders only winning via the P2P market if the valuation of other builders that operate via the direct connection market has decreased (adverse selection). Finally, the value reflection of the P2P market relative to the RPC market will worsen as the RPC market becomes more sophisticated while the P2P market becomes stale.
How would an out-of-protocol actor facilitate multiplexing if ePBS were deployed? In MEV-Boost, relays facilitate multiplexing because submitting blocks to relays is (largely) permissionless, and relays are well-connected to validators. In ePBS, a relay - from no one referred to as a bid curation relay - would look different. A bid curation relay could open an RPC endpoint that proposers connect to and host an auction where builders submit bids, like in MEV-Boost. Bids, however, do not need to contain transaction data since the bid curation relay would not be responsible for the fair exchange problem that is solved via ePBS. Bids in ePBS are a bid value and the hash of the execution payload. A proposer then pulls the highest bid from the bid curation relay and, if it so desires, commits to the highest bid via the in-protocol ePBS system. A winning builder then sees this in-protocol commitment and publishes the block via ePBS.
It becomes clear that the trust assumptions that proposers and builders must place in a bid curation relay are vastly lower than in MEV-Boost. Essentially, the proposer and builders must trust the bid curation relay to forward the highest-paying bid when the proposer asks for it. The bid curation relay is not trusted with the block contents (builder privacy is preserved) and is not responsible for unconditional payment (data availability and validation are enforced via the protocol).
The ePBS relay scores worse on the trustlessness front than the P2P market since the proposer and builders must trust the relay not to censor its bids. On the other hand, the value reflection of such a bid curation relay could be far better. The relay could offer bid cancellations and high-frequency bidding to builders. Moreover, relays could invest in latency reductions and charge for this, as some do in MEV-boost. If a relay successfully reduces latency, more prominent builders may connect to it. This means the value reflection of relays relative to directly connected builders may remain stable or improve over time.
Shea also highlights another option that has been discussed widely before: next to the P2P market; there could be an on-chain registry of builders. There could be a smart contract that any builder could write its RPC endpoint to. Any validator could then see the available RPC endpoints and pull bids from it during its slot. This alternative scores well on the trustlessness front since no trust is required, and it scores well on the value reflection point since it allows all builders to compete on a similar level. The proposer could pull from this registry every time it is supposed to propose a block.
Why do we care about multiplexing? Multiplexing contributes to the credible neutrality of the network. In the context of ePBS, credible neutrality may mean something like this: the builder with the highest valuation for the execution payload construction rights is allocated these rights. If proposers were to rely solely on directly connected builders, some long-tail builders who happened to have an exceptionally high value for a specific block might be excluded. If proposers rely on bid curation relays, they may not forward the highest-paying bid because they prefer to forward another bid for whatever reason. If proposers rely on an on-chain registry of builders, it may not connect to the newer or smaller builders.
Allowing multiplexing to contribute to credible neutrality is a trade-off between trustlessness and value reflection. If a completely trustless market is so poor at value reflection that it never surfaces a winning bid, it does not contribute much to credible neutrality. If a perfectly value-reflecting market puts a lot of trust in one party, the benefit of credible neutrality is also nonexistent.
To conclude, the P2P market is easy to implement, and its maintenance does not require a hard fork so clients can iterate freely. Although the P2P market only contributes a little to the core functionality of ePBS, there are virtually no downsides to implementing it, and it is a nice feature that may benefit some users and could be beneficial for proposers as it increases their revenues and may be helpful for MEV-Burn in the future. Further work could specify the P2P market rules and how an on-chain registry of builder RPC endpoints could work.