After Ethereum transitioned from Proof-of-work (PoW) to Proof-of-stake (PoS), validators replaced miners as the key role in the network. The idea of Proposer / Builder Separation (PBS) is to split validators into two roles, Builder and Proposer, to mitigate MEV’s negative impact. Currently, PBS is mainly implemented by MEV-Boost, and in the future, PBS will be built into the Ethereum protocol. This report will introduce PBS’s mechanism and discuss its current situation and future.
Table of Contents
1. Background
After the merge of Ethereum, the threshold for validator nodes has been lowered, allowing more users to participate. This has greatly increased the number of validators, improving Ethereum’s decentralization and security. However, the problem of disproportionate beneficiaries of Maximal Extractable Value (MEV) is still a concern. Currently, the market size of MEV is very large. The following figure shows the cumulative MEV value before the merge, which is close to 700 million US dollars, and this value is still growing (Figure 1).
Figure 1 Cumulative Extract MEV (Before merge); Source: https://explore.flashbots.net/
As MEV grows, validators driven by profit will lead to centralization. In PoS, validators who are selected in advance can see users’ transactions and add their own transactions to them, directly controlling the order of transactions to profit themselves. Validators need complex strategies to maximize MEV. These strategies lead to high fixed costs. Therefore, compared with ordinary validators, validators with more resources will have more opportunities to realize MEV. They will obtain more profits, and then obtain more validator seats, thereby gaining more opportunities to control transactions. For ordinary users, this will not only leadto higher gas fees and network congestion, but also make on-chain transactions unfair.
2.What is PBS
In order to address the above problems, PBS is proposed. In Ethereum, validators are pseudo-randomly selected and propose to the network while building blocks. Therefore, they have great power and control order flow. In PBS, validators are divided into two roles: Builder and Proposer, which respectively undertake block-building and block-proposing functions. Builder is a highly specialized participant who sorts the transaction list and submits headers of the bundles to Proposer. Proposer’s job is to accept the bundle with the highest bid. Importantly, before the auction ends, no one can see the content of the execution block. This is to prevent participants from controlling the flow of transaction in the block.
It’s worth noting that PBS enhances competition between builders. It requires all builders to focus on optimizing block building profitability using complex strategies. For Proposers, they can sit back and enjoy the benefits because they will receive rewards whether or not their proposals are accepted. Another point to note in PBS is that the role of Builder requires higher performance requirements for nodes, while the threshold for Proposer is much lower. Therefore, even without powerful nodes, Proposers can participate in MEV. Overall, PBS not only reduces participants’ control over the order flow but also makes builders share MEV with Proposers, achieving decentralized MEV distribution.
3. The Present and future of PB
There are already some third-party PBS solutions available, such as the MEV-boots developed by Flashbots, which is a short-term implementation solution for Ethereum (PoS). In the future, PBS will be included in Ethereum’s protocol and will become a mandatory enforcement feature.
3.1 MEV-Boost
MEV-Boost is a PBS implementation developed by Flashbots for Ethereum (PoS). MEV-Boost is used as a sidecar for consensus clients, and validators can run it to build a trust bridge with builders. After running MEV-Boost, the market process changes as shown in Figure 2. First, the Builder receives bundles from the Searcher and selects some bundles to form a block based on its own strategy. The Builder then sends the block to relays. MEV-Boost selects the most profitable block from the relay and returns it to the Proposer (validator). In this process, Relay serves as a two-way communication channel between Builder and Proposer. It can connect to one or more builders and verify the validity and bidding of the blocks submitted by Builder. For the Proposer, one or more relays can be run to select the most profitable block and make a proposal.
Figure 2 The role of MEV-Boost; Source: https://docs.flashbots.net/flashbots-MEV-Boost/introduction
After the merge of Ethereum, the MEV-Boost market has developed rapidly. As shown in figure 3, at present, 90% of the blocks come from relays. Flashbots relay was dominant after the merge, but after February 2023, other relays gradually expanded. Builder shares also have a similar trend. Compared with the early stage of Ethereum merge, the current competition is more open. Therefore, the risk of centralization dominated by Flashbots that everyone worried about at the beginning of the merge is gradually easing. Since the MEV-Boost relies on relays, how to guarantee the existence of malicious relays is an issue to be discussed, e.g. by introducing Relay Monitor to ensure that relays are trusted
Figure 3 Total slot share of Relays and builders; Source: https://mevboost.pics/;
3.2 In-protocol PBS
In MEV-Boost, the relay acts as an intermediary between the Proposer and Builder and is responsible for storing the block content. If the relay is malicious, both the Proposer and Builder will be harmed. Therefore, in MEV-Boost, both Builder and Proposer need to trust the relay. However, in-protocol PBS directly adds the Relay role to the Ethereum protocol, and Proposer and Builder no longer need to trust third parties. If either Proposer or Builder violates the rules, they will be directly punished by the protocol itself. For example, if Builder does not disclose block content, Builder still has to pay the bidding fee to Proposer. This will be enforced by the Ethereum protocol and is something that MEV-Boost cannot achieve.
Figure 4 crList in In-protocol PBS; Source: https://notes.ethereum.org/@hww/workshop_feb_2022
In the future, Dank-Sharding will also rely on PBS solutions because Dank-Sharding has strong computing power and bandwidth requirements for participant nodes (32-64 core CPUs, 2.5Gbit/s bandwidth). Under the PBS solution, these burdens will naturally be borne by builders with powerful computing power. The proposer’s burden will not increase, nor will it be centralized. Therefore, in-protocol PBS also conforms to Ethereum’s future development direction Censorship Resistance List (crList) is a term that needs to be mentioned in In-protocol PBS (Figure 4). Proposer has the right to specify a transaction list, and Builder can only choose to package and sort crList; after winning the auction, Builder needs to prove that all transactions in crList have been included, otherwise the block will be considered invalid. This means that packagers cannot insert their own private transactions to obtain MEV, nor can they intentionally reject a transaction.
4. Noteworthy Issues
-
Decentralization of Builder
Private Order Flow can lead builders to become centralized. Private Order Flow refers to the situation where users directly submit transactions to specific builders instead of the public network. In order to gain more benefits, some builders will directly purchase from wallet merchants or basic service institutions that control order flow, causing other resource-lacking builders to lose competitiveness. Therefore, in this context, decentralized builders are necessary because they will make the entire ecosystem more stable, provide stronger security guarantees, and reduce trust requirements. However, it is also worth considering whether decentralized builders have the ability to compete with centralized builders. On the other hand, designing builders for decentralization will also increase costs
-
Trust between Builder and searcher
PBS makes it possible for Proposer and Builder to complete their respective work without trusting each other. However, the interaction between the Searcher and Builder still needs to be based on trust. Therefore, there are also some decentralized solutions for builders, such as introducing the Aggregator role using TEE (Trusted Execution Environment) technology to replace builders. In this case, Aggregator can be regarded as a trusted robot, and the searcher directly submits the bundle to Aggregator. However, even in this case, the Proposer may privately reach an agreement with the Aggregator operator to obtain block content. Therefore, simply using the Aggregator is not enough, and more review measures are needed in this case
-
Trust between Builder and searcher Currently, there are also discussions about the implementation of in-protocol PBS, and the most discussed ones are Single Slot PBS (Figure 5) and Two Slot PBS (Figure 6). Single Slot PBS is similar to replacing the Relay role in MEV-Boost with a decentralized Committee: the Committee keeps the block content, and after winning the bid, the Committee broadcasts the complete block content together with the Builder. Two Slot PBS adds an Intermediate Block to store block content separately. Two Slot PBS is more decentralized, but less efficient because two slots mean the effective block time is extended to 24 seconds (one slot = 12 seconds). Single Slot PBS has a simple structure similar to MEV-Boost, but it is challenging to use cryptographic technology within the protocol because Ethereum’s protocol has not yet used encryption technology internally.
Figure 5 Single slot PBS; Source: https://ethresear.ch/t/single-slot-pbs-using-attesters-as-distributed-availability-oracle/11877
Figure 6 Two Slot PBS; Source: https://ethresear.ch/t/two-slot-proposer-Builder-separation/10980
5.Conclusion
PBS can reduce the risk of centralization of validators caused by MEV incentives, allowing more proposers to participate in the market. After the merge, MEV-Boost has developed rapidly, but relay as the core function of MEV-Boost has also brought certain risks, such as malicious relays and easy external attacks. IN-protocol-PBS will build PBS into the protocol, but specific implementation plans and issues such as Builder centralization are still under discussion. In summary, PBS is critical for MEV and the Ethereum ecosystem, but, as an emerging concept, how to avoid other negative effects while achieving PBS’s own goals still requires more discussion and practice.
]]>