Original post by Robust Incentives Group @ethereum--Barnabé Monnot
Original compilation: DAOctor@DAOrayaki.org
Original title: Notes on Proposer-Builder Separation (PBS)
Proposer-Builder Separation (PBS) is a hotly debated topic, a broad design concept that emphasizes the relationship between protocol and non-protocol actors to maintain and operate a blockchain. While discussions have been going on for over a year, Merge first and Devcon second brought more resources and attention to PBS. In this article, we will focus on the status, essential value and challenges of PBS.
What is PBS?
Beyond a single mechanism specification or implementation, PBS is first and foremost a design philosophy that recognizes that protocol participants may invoke services from third parties in the course of their consensus responsibilities. A "protocol participant" is any constrained and active validator in Ethereum proof-of-stake that is expected to perform various duties, including proposing blocks, producing proofs, or participating in the current Sync Committee.
Pre-Merge: bundle searcher and mev-geth
In a way, PBS started before the merger and Ethereum moved to proof-of-stake. We consider the "default behavior" to be that of a block producer, which simply takes a set of transactions from their transaction pool and packs them into a block as efficiently as possible. The first departure from this default behavior was due to some miners opening up direct private lines of communication with transaction originators who would agree off-chain on the conditions under which the transaction would be included.
While such contracts were built privately, mev-geth, developed by Flashbots, quickly opened up a marketplace between block producers and transaction originators. The marketplace relies on a trust relationship between miners (organized as mining pools in PoW) and entities called Seekers. Seekers typically source user transactions from public transaction pools or some private service they operate. User transactions are bundled with the searcher's own transactions to extract value from user transactions, for example, following user transactions through arbitrage, or following oracle updates through a liquidation process.
Bundles are communicated to market participants in an unambiguous manner, with the promise that seekers pay block producers if the bundle is included. However, the market is limited to known block producers, a whitelist of major mining pools to prevent bundle theft. Block producers that replicate the Seekers strategy, replacing Seekers' payments with their own full payments, will be detected and subsequently kicked off the market, potentially losing significant payments in the future. PBS is represented here as block producers receiving bundles from seekers to include on top of their blocks.
Post-Merge: block builder and mev-boost
After the merger, with the introduction of independent validators who did not join the staking pool, maintaining a whitelist for the market proved to be infeasible. Independent validators propose blocks infrequently, with the current number of validators bound in the protocol, it is estimated to be once every two months. This changes the nature of the game from a game of repeated interactions with the threat of penalties for deviations to a game with players that are often more "single shot".
The solution to this constraint is to get a commitment to the content of a particular block from the validator without the validator needing to know what the content is. The market is now called mev-boost, and forwards the headers of the blocks created by block builders, along with the builders' bids, to block proposers, promising to pay the proposers an amount for choosing the blocks they produced. At the center of the market is the relayer, responsible for checking the validity of the block built by the builder, that is, whether the block is EVM valid and has indeed paid the proposed amount to the proposer.
image description
Merged block build, from Devcon demo
Towards an "in-protocol" PBS
Faced with the prospect of relay failures, such as validation or liveness failures, and the opportunity to remove a new single point of failure (essentially a centralizing factor) from the system, Vitalik introduced an "in-protocol" PBS design. In these designs, validators again blindly commit to using the blocks provided to them by builders. However, the protocol itself provides two guarantees, not the relay of the proxy protocol:
For builders, the proposer has made a commitment, and that commitment can only be recovered through consensus failures (e.g., reorgs or safety failures with single-slot finality);
For the proposer, the builder's payment promise is fulfilled no matter what the builder does, such as ultimately failing to release block content or releasing invalid blocks.
A possible design for an intra-protocol PBS with two rounds of the protocol: one to secure the proposer's commitment, and another to secure the builder's disclosure
PBS and the principal-agent problem
In a recent podcast with AltLayer's Yaoqi Jia, I argued that PBS is not so much a thing we need as a constraint that protocols must respond to. Before or after a merger, block producers are willing to procure a portion of their blocks outside of the protocol, meaning that the goals of the protocol may be subverted.
Historically, this is not the first time. An important protocol goal is reward fairness, or that protocol participants are all expected to receive the same amount of rewards relative to their size. While this is true in Proof of Work, where rewards are proportional to the hashrate brought to the network, rewards vary widely enough to incentivize most, if not all, miners to join mining pools and share the profits with their members. However, there is no guarantee that blocks produced by a mining pool will respect the preferences of the pool members, unless the construction of the blocks is distributed among the pool members. If the behavior of the fund pool goes against the wishes of its members, it still has the right to withdraw from the fund pool, which is also an important reason for exit.
Whenever protocol participants outsource some of their control over block construction, a new instance of the principal-agent problem arises. In such a framework, the principal asks the agent to take some actions, but the motives of the principal and the agent may not be completely aligned. Employers want their employees to do as much work as possible, but employees want to minimize their effort, so an appropriate compensation structure can help realign incentives. A block proposer wants transactions to be included, but builders may want to censor those transactions, so mechanisms to enforce proposer preferences help realign incentives.
Market Structure and Allocation Mechanism
In my opinion, it makes sense to think about PBS in a modular way to better appreciate its design space. This approach allows us to consider more clearly the structure of the principal-agent problem, and the extent to which protocols intervene to solve it.
PBS as market structure/legal system. The protocol defines the conditions under which proposers can interact with third parties during block construction. For example, the protocol provides enforceability of the agreement, e.g., enforcing payment commitments made by proposers or third parties. The protocol also provides a tool for third parties to identify commitments made by proposers. This facility comes from the protocol's consensus mechanism, which makes secure commitments that prevent them from being revoked.
PBS as a distribution mechanism/business logic. The protocol defines the space of contracts that proposers and third parties can enter into. For example, the agreement determines that only the full rights to generate blocks can be sold, and organizes an auction to distribute these rights.
Under mev-boost, the protocol does not interfere with the principal-agent problem. It does not recognize the role of the builder as an entity that interacts with the proposer. At best, the consensus layer client provides stakers with the ability to blindly sign block headers, and perhaps other services such as local profit conversion, but these are not part of the protocol (only the word "builder" appears in order to convince myself in the preliminary "sharding" section of the consensus spec repo).
This non-intervention means that there is no trust-minimizing, in-protocol way in which proposers can be compensated when the other side of the market does not honor their agreement. Whether this is the responsibility of the agreement is entirely debatable. My views on this are mixed.
On the one hand, proposers seeking to maximize profits may engage in dangerous behaviors such as delaying the publication of blocks or calling in external entities to help them create blocks. Protocols may disdain to support such activities and, in fact, may wish to prevent moral hazard as much as possible.
On the other hand, the asymmetry between block building and block validation (discussed in Vitalik's Endgame post) really opens up possibilities for designs that couldn't be implemented without calling on external entities. If we intend to fully move closer to the design philosophy of PBS, such as requiring powerful builders to produce Danksharding blocks, then the requirement to interface with such a third party will be imposed by the protocol on the proposer. If some proposers are unable to perform the duties required by the protocol (especially proposers in resource-constrained environments), and on this basis, when these proposers inevitably invoke third parties to perform duties on their behalf, this will be a problem. A rough deal.
If builders are less trusted in fulfilling their commitments, we may end up with a protocol that achieves smaller social benefits than one in which proposers fully participate in fulfilling their duties. I'm not worried about this part. First, even in a competitive market, builders are profitable entities. They care about their blocks to get into the protocol, especially when payments are committed and will happen regardless of their performance. Second, while missing a block due to builder failure is a loss to the protocol, it is always possible if only because of higher real-world latency"make up"Lost time, for example, with a cumulative, time-based EIP-1559.
Regardless, answering these questions will answer what Ethereum is or should be as a protocol. What does it require of an actor? What is its worldview for economic organization around the protocol's mandate? What are the boundaries of its concern?
In Series 2, we'll discuss some of the mechanisms that might be considered in the search for Ethereum's final form.
