The Past, Present, and Future of Ethereum PBS

Author: Chaskin OnChain, Crypto KOL; Translation: LianGuaixiaozou

1. How did we get here?

The original design concept of Ethereum was for one party to handle the entire process of block creation. This involved aggregating transactions from the memory pool, creating block headers, and either finding a golden nonce in proof-of-work or signing the block header in proof-of-stake. In the early years, block creation was simple: mining nodes extracted transactions from their memory pools, sorted them based on gas prices (representing the computational work for each transaction), and kept them within the gas limit of each block. However, with the rise of decentralized finance (DeFi), this method of block creation has undergone significant changes.

(1) Centralized Risks of MEV

• ZKP Project Team Must Read Circuit Audit – Are Redundant Constraints Really Redundant?
• SBF family faces salary dispute with FTX US
• Exploring the Future of DeFi Risk Management Perspectives from Developers, DAOs, and Communities

In DeFi, the order of transaction sorting has a significant impact. Let’s say there’s a pending transaction in the memory pool that aims to exchange 1 ETH for BITCOIN on UniSwap (of course, I’m referring to HarryPotterObamaSonic10Inu). The amount of BITCOIN you receive is based on the current exchange rate between ETH and BITCOIN in the UniSwap pool. If someone else’s transaction (exchanging 2 ETH for BITCOIN) is processed before yours, you will end up with less BITCOIN because the exchange rate between ETH and BITCOIN has changed. Considering the importance of transaction order, and the fact that transaction order is controlled by miners, this has led to the emergence of what we call MEV (Miner/Maximal Extractable Value). MEV represents the potential profits miners can obtain by selecting, excluding, or reordering which transactions to include.

At first glance, MEV may seem harmless. It could even act as a booster for network security, providing more incentives for mining or validation, right? Besides the usual block rewards and transaction fees, there is now MEV to compete for. But the reality is far from harmless. If left unchecked, MEV could become a powerful centralizing force. There’s a story that illustrates this: Imagine you just heard about this MEV game and learned that validators are earning over 10% APR because of it. It’s tempting, right? You go all-in! You send 32 ETH to the staking contract to start your validator node. But wait… you only see a 4% return. When it’s your turn to propose a block, transactions are simply ordered based on their gas prices. You don’t see any MEV magic happening. You don’t have the complex algorithms and strategies to mine MEV gold. Without understanding the intricacies, you’re stuck with the default: sorting transactions by gas price.

This is where centralizing power comes into play. Even if you’re a computer expert, the simple computer you’re using is no match for the supercomputers running the next level of MEV extraction game. Clearly, the outcome of the game is shutting down your validator node and sending your ETH to these super powerful setups that promise to share the MEV cake. You might see a few giants running the network, which is a truly alarming centralizing result. If this is the direction of future development, then Ethereum’s fundamental goals have failed. In that case, a network controlled by a few could also be a centralized database.

(2) The Birth of Flashbots

Phil Daian, a PhD student specializing in smart contract security at Cornell University, was one of the first to discover the MEV problem. In August 2017, he published a blog post titled “Decentralized Cost of 0x and EtherDelta”, which was inspired by a front-running vulnerability he discovered during the 0x ICO.

Front-running refers to discovering a transaction in the mempool that intends to swap token A for token B. Then, a front-runner programmatically initiates a similar transaction with a higher gas price. This strategy ensures that the front-runner’s transaction gets processed before the initial transaction. Once the initial transaction is processed, the front-runner can immediately swap token B back to token A, ultimately obtaining more token A than initially started with. This strategy is sometimes referred to as a sandwich attack because the user’s transaction is sandwiched between two transactions initiated by the front-runner. As a result, when the front-runner profits, the person who initiated the initial transaction receives fewer token B. While sandwich attacks are common, people can use various strategies to effectively extract MEV.

During the ICO frenzy, Phil and a team deployed a bot that generated approximately $1 million in annual revenue. After sharing their method in the aforementioned blog post, several similar bots emerged, creating a competitive landscape where bots would bid for gas to gain transaction priority. This prompted Phil to deploy global nodes to capture real-time transaction data. This research culminated in his famous article “Flash Boys 2.0”.

This is an interesting related story shared by Phil when he was a guest on the Chopping Block. After UniSwap’s founder Hayden Adams shared his design on ethresear.ch (UniSwap being the most popular decentralized exchange at present), Phil immediately expressed his concerns to Vitalik Buterin and Hayden. Phil believed that UniSwap’s design would lead to a significant amount of MEV, making it a prime target for exploitation and exposing users to the risks of transaction reordering and sandwich attacks. Vitalik responded by saying that these could be seen as additional cost mechanisms using blockchain. Phil was very angry at this response, as he believed that powerful financial entities like Goldman Sachs would squeeze individual retail investors just like the current financial system. However, over time, Phil gradually understood Vitalik’s perspective.

Recognizing the importance and challenges of the MEV field, Phil and his partners co-founded Flashbots, focusing on research and solutions in the MEV field. Flashbots realized that MEV would continue to exist, and their mission is to ensure that the existence of MEV does not create a system where being a bad actor or creating negative externalities is more advantageous to individuals than being a good actor. Such examples exist in TradFi, where the most profitable strategies often exploit system advantages. At the same time, Flashbots believes there may be a way for users to harness the power of MEV and subsidize those who protect network security, while also subsidizing transactions on the network, allowing people to obtain better prices and provide them with the execution they desire in these systems. If designed properly, MEV could become a driving force for cryptocurrencies to surpass traditional systems.

(3) Utilizing MEV: Auction and Proposer-Builder Separation

Flashbots recognizes that miners’ monopoly over transaction ordering is a valuable resource. The first step in their democratization of MEV was the creation of an auction system for transaction ordering rights. This led to the birth of MEV GETH, which introduced the concept of proposer-builder separation (PBS) for the first time. Barnabé Monnot of the Ethereum Foundation describes PBS as “a design concept where protocol participants may use third-party services in the process of achieving consensus.” Prior to this, miners had complete control: they decided the order of transactions, performed hash calculations, and then added blocks. But MEV GETH changed everything. It introduced external participants called searchers, who paid to have their transaction bundles included in miner blocks.

With MEV GETH, miners had a new endpoint. They could receive MEV-optimized transaction bundles from searchers. Each bundle also included a transaction that paid the miner, incentivizing them to choose that bundle. Naturally, miners chose the bundle that offered them the highest fee. As searchers competed for MEV opportunities in the public memory pool, their bids naturally increased due to this competition. This competition ensured that miners obtained the largest share of MEV profits.

Let’s explain this issue in detail with an example: Suppose Alice is a searcher and discovers an arbitrage opportunity between two decentralized exchanges. She can profit 0.07 ETH by buying token X on UniSwap and immediately selling it at a higher price on SushiSwap. Therefore, she creates a transaction bundle optimized for the 0.07 ETH MEV opportunity and is willing to pay the miner 0.05 ETH to prioritize her transaction in the next block. Another searcher, Bob, also discovers the same opportunity. He creates a similar transaction bundle but pays the miner 0.06 ETH to obtain the same privilege. Alice and Bob both send their MEV-optimized transaction bundles to the miner. On the other end, the miner receives these bundles and then decides which one to include in the next block. The miner naturally chooses Bob’s bundle because it has a higher fee, allowing the miner to obtain the maximum benefit. This is a win-win situation. The miner captures most of the MEV opportunity, earning 0.06 ETH from the 0.07 ETH opportunity. At the same time, the searchers gain a net profit of 0.01 ETH, which they wouldn’t have been able to obtain otherwise. The essence of the MEV GETH mechanism is bidding. Alice and Bob compete with each other, providing incentives to the miner, ensuring that the miner obtains a significant share of MEV profits.

However, if they could open an endpoint for anyone to send transaction bundles to the miner, malicious actors could exploit this openness to overload their system, potentially launching a DOS attack. To address this vulnerability, Flashbots introduced the Flashbots Relay. This relay plays a crucial filtering role: it evaluates incoming transaction bundles based on the miner’s potential profitability, the validity of the transactions, and the fees provided. Only the optimal bundles are forwarded to the miner. This approach does introduce a certain degree of centralization, as the process relies on the Flashbots Relay to filter out unwanted or potentially harmful traffic. Interestingly, there already exists a certain degree of PBS between mining pool operators and miners. Typically, operators construct the block body, which includes the transaction bundles sent by the relay, perform a hash calculation on the block header, and then distribute it to miners to continue hashing and find the golden nonce.

2. Current Situation

As Ethereum transitions from Proof of Work (PoW) to Proof of Stake (PoS), there have been significant changes in the pattern of transaction verification and block proposal. PoW relies on miners and computational power (hashrate) to verify and add new blocks to the blockchain, while PoS shifts this responsibility to validators who stake their own ETH to become block proposers.

Almost all mining pools are using MEV GETH, but as Ethereum transitions to PoS, the system needs to be adjusted. PoS is designed to cater to the needs of independent stakers: individual validators operating on low-resource devices like Raspberry Pi. The design goal of PoS is to ensure a balanced situation where no participant in the verification process, whether an independent staker or part of a large staking pool, has an inherent advantage. Prior to the transition to PoS, a few mining pools dominated the hashrate. This allowed for the establishment of trust relationships between these pools and Flashbots Relay. Any dishonest behavior, such as the pool stealing MEV from searchers, could jeopardize this relationship. Suppose a miner receives a sandwich attack transaction package from a searcher. If the miner further includes the searcher’s transaction among their own transactions, it would bring short-term gains but also sever their connection with Flashbots, causing them to lose future MEV profits as they would no longer have access to Flashbots Relay.

(1) MEV Boost

Unlike large mining pools, independent stakers may not have long-term incentives to maintain trust. In some cases, they may find it more profitable to exploit the builder’s MEV and then disappear from the network. This behavior would result in their complete forfeiture, losing all 32 ETH, but in certain cases, the potential profit from stealing MEV may exceed this loss. This has indeed happened in April, when a malicious validator stole $20 million from the Sandwich robot before shutting down their validation node.

To address this new attack, Flashbots has introduced MEV Boost, a system designed specifically for the independent staker environment.

Mechanism of MEV Boost:

• Relay: In the previous system, only Flashbots acted as a relay, but MEV Boost has been democratized. Now, anyone can become a relay node, expanding participation and security. Flashbots has also open-sourced their relayer code.

• Builders: A new role has emerged – builders. These entities collect transaction packages from searchers and combine them into complete blocks.

• Auction System: Builders bid to include their complete blocks and submit them to the relay. The relay performs a critical validation step to ensure the validity of the block.

• Validator Interaction: The relay forwards the highest bid received from competing builders along with the corresponding block header to validators, who propose a block to the Ethereum network.

• Block Commitment: The designated validators sign the block header, which is a commitment. Once signed, they are bound to that block. If they attempt to sign another block, it will be considered malicious behavior and they will be penalized.

• Final Proposal: With the commitment, the relay sends the complete block details to the validators, who then submit a formal proposal to the network.

This setup introduces trust issues:

• Builder-Relayer trust: Builders need to trust that relayers will not steal their MEV. Imagine a scenario where a relayer receives a block from a builder and replaces the builder’s address with their own address in the sandwich trades. Then they pass the manipulated block header to the proposer.

• Proposer-Relayer trust: On the other hand, proposers must trust that the block headers they sign are valid. Proposing an invalid block would result in loss of block rewards as the network would reject invalid blocks.

The PBS design addresses a recurring challenge: while the interaction between proposers and transaction ordering participants is given, there clearly needs to be a mechanism where:

• Proposers can submit builders’ blocks without knowing the block contents, yet still ensure the validity of the blocks.

• Builders can securely send their blocks to proposers, confident that their MEV will not be stolen.

Before delving into MEV Boost, it is necessary to understand the default way Ethereum creates blocks without using MEV Boost. This setup relies on the collaboration between the Validator Execution Client and Consensus Client. The Execution Client receives transactions, checks their format, and adds them to the memory pool without processing them. Meanwhile, the Consensus Client processes PoS consensus, selects a validator to create the next block. Then, the selected validator’s Execution Client arranges the transactions into a new block based on gas prices, forwards it to the Consensus Client, and submits it to the network. Other validators attest to the accuracy of the block, and once validation is complete, it immediately becomes the latest link in the blockchain.

If validators choose to use MEV Boost, this process changes. When they propose a block, they no longer rely on their own Execution Client but connect to a relay network. Validators can choose which relayer to connect to.

MEV Boost is optional, but 95% of validators are using it. Essentially, almost every validator delegates block creation to a third party, except for the nodes run by Vitalik Buterin. This delegation indicates that the core function of the Ethereum protocol, block creation, is now primarily taking place outside the Ethereum system itself. A key role in this setup is the relayer, and the role of the relayer contrasts with the fundamental principles of Ethereum. Currently, there are approximately 9 active relayers, but only 6 relayers have a block relay share of over 9%.

Trust becomes an issue because the relationships between relayers and builders, as well as relayers and validators, are not trustless. There are also concerns about censorship resistance. In the relay auction process, relayers have the power to decide the validity of blocks. This discretion allows them to exclude blocks containing transactions related to sanctioned addresses. A recent data shows that due to this censorship imposed by relayers, 38% of blocks in the past week have followed OFAC guidelines after the sanction on Tornado Cash.

3. Looking to the Future

Ethereum is formulating a strategy to re-integrate processes currently operating outside its core protocol. The goal is to force proposers to obtain blocks from builders, essentially having the protocol handle the current responsibilities of relayers. The current relayer system has weaknesses. For example, relayers may fail to properly validate blocks, incorrectly validate builder bid-related payments by proposers, or even delay or fail to deliver blocks. Most importantly, running relayers is not cheap. So far, there is no sustainable financing model. The highest-utilized Ultrasound Relay estimates its operating costs to be between 70,000 and 80,000 euros per year, not including other expenses such as software maintenance. Relayers currently operate as public utilities.

It is also worth noting that MEV Boost, being external software developed by a company (Flashbots), has not undergone rigorous testing like protocol-embedded software. This is evident from the Prism client after the Shapella upgrade: integration errors of MEV Boost caused proposer signature issues, resulting in slot losses and forfeitures. The purpose of integrating this process into the Ethereum protocol is to address these challenges and ensure that proposers can still be compensated even if the protocol between proposers and builders breaks down. Therefore, if a builder provides a faulty block, the proposer can still receive the full bid while making the builder bear the consequences. Although the specifics of this integration (referred to as ePBS) are still under research and may take several years to implement, there have been many similar implementation ideas.

(1) Enshrining Proposer-Builder Separation

To understand the potential implementation of ePBS, one must first understand some basic components of the Ethereum PoS algorithm. In Ethereum, time is divided into intervals of 12 seconds called slots. 32 of these slots together form an epoch. In each slot, a random validator is selected to propose a block. At the same time, a committee is designated to prove that they believe the block, which they consider to comply with Ethereum’s PoS fork selection rules, is valid, ideally validating the latest proposed block as the head of the blockchain. If a block is not proposed in a given slot, after 4 seconds, the validating validators will validate the previous block.

Now let’s look at the design of ePBS. This most popular model spans two slots. First is the bidding phase, where builders send their bids to validators. Then, Slot 1 begins, and proposers select a bid and submit it by publishing a block that includes the builder’s bid. Then, a group of validators vote to support the block, ensuring its position in the chain. In Slot 2, builders see the bid and its proof submitted in the proposer’s submission block. Considering that the proposer’s submission is irreversible, the selected builder publishes their block and ensures that their MEV is not stolen. Finally, validators verify this new block.

The newly released model is similar to the method of two slots, but introduces a LianGuaiyload-timeliness committee. First, the builder’s bid is selected and submitted by the proposer, and then the validator committee provides proof. Then, the builder discloses the payload of the block (its transactions), and the payload timeliness committee confirms that the payload is provided on time and the validity of the payload. Another difference between these two methods is the operation specification of Ethereum’s proof of stake, but this part is not within the scope of this article.

Another design revolves around the concept of slot auctions. In this design, the builder promises a slot in the epoch during the bidding period, without specifying the block. They basically promise to create a block within the allocated slot and pay a certain price for it. This provides adaptability, especially for cross-domain MEV that requires real-time operations.

So far, all ePBS designs grant builders complete control over block transactions. One potential solution is to use an inclusion list. This list (sent by the proposer to the builder, ideally containing all transactions that are currently in the memory pool or don’t need to be in the memory pool) contains the transactions that must be part of the builder’s block, if there is space. If the builder’s block is full, it must be indicated and confirmed that they have acknowledged the list. This approach enhances the network’s censorship resistance. If the builder wants to censor transactions, doing so will become very difficult and expensive over time. Due to EIP 1559, continuously filling blocks will result in exponential growth in base fees. Therefore, if builders continue to censor transactions by filling virtual transactions in blocks, the rising costs will make this practice no longer feasible.

In some cases, the proposer may want to have some influence on block creation. Another ePBS feature allows the proposer to create part of the block (the start or end) and delegate the remaining part to the builder. All these designs and features are not mutually exclusive, and the focus is on how to balance their advantages and disadvantages.

(2) Optimistic Relaying method

Another approach of ePBS is to leverage our existing trusted relays. The idea is to gradually reduce the responsibilities of the relays until they are primarily used as optimizers rather than critical components. In the first phase, we relinquish the relay’s responsibility of validating the block’s validity. This greatly reduces the operating cost of the relays, as there is no longer a need to simulate the blocks to ensure their validity. Additionally, it simplifies the role of the relays, reducing the delay in communication with the proposers and builders by approximately 100 to 200 milliseconds. So how do we ensure that the proposers are compensated if a block is proven to be invalid? During bidding, builders will be required to provide collateral equal to their bid. If the block is invalid, the collateral will be used to compensate the proposers for what they should have received. This concept is called Optimistic Relaying V1.

Pushing optimistic relaying further to V2, we can eliminate the need for relays to download blocks, reducing latency by 50 to 100 milliseconds.

Ultimately, the endgame for optimistic relaying is starting to look like the latency-optimized committee model I mentioned earlier. The sequence goes as follows: Builders submit their bids on the peer-to-peer layer. Proposers accept bids and attach signed headers. Builders then launch blocks. At this stage, the relay’s only job is to monitor the peer-to-peer layer’s mempool, essentially recording activities that occur. The role of the relay becomes very lightweight, only needing to watch the mempool. This makes the relay more like a latency-optimized committee. All these steps are in preparation for the relay to be replaced by the latency-optimized committee in the future, simplifying the entire protocol.

(3) Utilizing builders for additional protocol enhancements

The emergence of PBS is Flashbots’ response to the centralizing effects of MEV, aiming to make positive use of MEV. With the introduction of this new role in Ethereum specifically dedicated to block construction, these entities have the opportunity to operate like supercomputers, in stark contrast to lightweight validators. Protocol designs are emerging that utilize these powerful builders. The idea is to keep validators simple and direct, while builders (without such restrictions) can operate at a higher level of computation. These enhanced builders are primarily applied to scaling.

Dankrad Feist’s Danksharding design, an Ethereum researcher, indicates that these high-resource-intensive builders can construct a large block containing all the data. The data is then split and submitted by multiple KZG commitments. Creating this block requires a significant amount of resources, but validating them is relatively inexpensive. Lightweight validators can then use Data Availability Sampling to check a small portion of the block and virtually determine the accessibility of the entire dataset, increasing the data throughput of Proto-Danksharding by about 16 times. Danksharding is complex and will not be discussed here, but the key is that these advanced builders can be entrusted with more roles to further enhance network capabilities.

Another idea for utilizing builders is the potential implementation of based rollup. A few years ago, Vitalik Buterin discussed rollup sorting models and coined a term called Total Anarchy for one of the models, where anyone can publish a rollup block and the sequence that arrives first on the chain is the official block. This approach has many drawbacks, such as on-chain spam and ambiguity in the winning sequence. However, Justin Drake recently emphasized a more efficient strategy that utilizes builders in based rollup. In this model, builders on the first layer act as rollup sorters, selecting the optimal sequence to include in the chain. This ensures that only the optimal sequences are included.

In addition to rollup, the introduction of powerful builders can stimulate other innovative structures, such as stateless clients. They allow nodes to operate as usual without the need to retain outdated states. This makes the nodes more lightweight and relies on the builders’ ability to generate specific cryptographic proofs.

(4) Protocol Enforced Proposer Commitments (PEPC)

Protocol Enforced Proposer Commitments (PEPC) is a concept proposed by Barnabé Monnot, a researcher at the Ethereum Foundation, in October 2022. The core goal of PEPC is to give proposers greater power in the creation of the blockchain. They sell the entire task to specialized builders and lose their rights. In PEPC, in addition to the usual Ethereum requirements, proposers can add additional conditions to a block to consider it valid. If a block fails to meet any of these additional conditions, it is considered invalid and validators reject it. This is different from EigenLayer commitments, where validators with additional commitments either lose some staked ETH due to disqualification or receive rewards for fulfilling commitments. However, in PEPC, the validity of a block is unrelated to commitments.

Let’s assume Alice is a proposer in the Ethereum network. With PEPC, Alice can make specific commitments for upcoming blocks. She can commit that her block will include at least three transactions related to a specific smart contract and she is willing to allocate 70% of the block’s gas to these transactions. She broadcasts this commitment, which becomes part of the validity conditions for her block. Now, builder Bob sees Alice’s commitment. He packages transactions that meet Alice’s criteria and sends them to her. If Alice’s block, after construction, meets her commitments (i.e., contains the specified transactions consuming the specified gas), the block will be considered valid and can be added to the blockchain. Otherwise, Alice’s block will not be accepted, ensuring that she fulfills her announced commitments.

A key difference between ePBS and PEPC lies in the nature of commitments. In ePBS, proposers and builders follow a fixed, uniform procedure. It is a one-size-fits-all approach. The proposer submits a specific block hash, and then the builder generates a matching payload. However, PEPC introduces diversity. Each proposer can set unique conditions, providing greater flexibility. It should be noted that the existence of PEPC depends on ePBS; they complement each other. The specific workings of PEPC are still under discussion and research.

(5) Conclusion

PBS is not a specific implementation; it is a design philosophy. It indicates the existence of an incentive mechanism with division of labor, where protocol participants delegate some responsibilities to more specialized external entities. The goal of the protocol is to provide a reliable and as trustless as possible interface to ensure smooth, fair, and inclusive delegation. Without this trustless interface, some participants may have advantages, leading to the centralized MEV issues observed prior to the PBS era. The core of PBS emphasizes fairness and decentralization. While the exact elements to be integrated into the protocol will be seen in future Ethereum updates, the overall goal of Ethereum remains clear: accessible, open, and trusted state computation overseen by a set of decentralized lightweight validators.

We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!

Follow us on Twitter, Facebook, YouTube, and TikTok.