To understand Proposer-Builder Separation, we must first explore how we arrived at this concept. As with most complex topics, understanding the complete history and thinking process requires delving into the early days of Ethereum itself.
In this article, we embark on a journey through the intricacies of the Proposer-Builder Separation (PBS), a groundbreaking approach altering roles within Ethereum's network. We delve into the complex world of Maximal Extractable Value (MEV) and its pivotal role in the economic strategies of builders and proposers, particularly focusing on how profits are generated and distributed under this model. This exploration further extends to the dynamics of profit distribution, shedding light on both the efficiency gains and the challenges it poses to equitable distribution. Beyond the immediate financial implications, we also scrutinize what these transformative changes mean for Ethereum's commitment to decentralization and its impact on the broader blockchain community. Concluding with an overview and a forward-looking perspective, this article provides a comprehensive understanding of how the Proposer-Builder Separation is charting a new course in the world of blockchain economics.
The Evolution of Front-running To grasp the mechanics of transactions on Ethereum, let's first examine the process of initiating an action on the blockchain. When you decide to act, you generate a transaction. This transaction details the intended action, the originating account, any amount of ether being transferred, the contracts you're engaging with, and so forth.
Once this transaction is assembled, it's sent to the network. This broadcast means that the transaction doesn't only become known to the Miner but also becomes visible to a majority of network participants.
Upon receiving the transactions, the Miners must validate them since other Miners will not accept an invalid transaction. However, their main concern is to choose the most profitable transaction since the Miner gets to keep the associated fee. The transaction fee is determined by the person creating the transaction, and they have the option to choose the fee amount. Suppose the user wishes to prioritize their transaction and ensure it is included in the next block. In that case, they need to pay a competitive fee, which should be on par with the fee associated with other competing transactions yet to be mined.
This inherent blockchain mechanic allows Miners (and almost any other participant in the network) to gain a comprehensive preview of the ongoing activities on the blockchain.
Because of this transparent and decentralized nature of blockchains in general, we have an emerging behavior such as front-running.
Like in the early days of my blockchain experience, I went to Investopedia to get some information. They define front-running as:
Front-running is trading stock or any other financial asset by a broker who has inside knowledge of a future transaction that is about to affect its price substantially. A broker may also front-run based on insider knowledge that their firm is about to issue a buy or sell recommendation to clients that will almost certainly affect the price of an asset. Thus, Front-running is not new in the financial world, but it is a new development in blockchains. Granted, everything was new at the beginning of the blockchain era.
How Miners Work In the blockchain domain, Miners hold significant power, as they have the discretion to decide not only which transactions get included in the next block but also the order of these transactions. The implications here go beyond just leapfrogging in a queue—it's about strategically positioning transactions for financial gain.
For example, if you notice a transaction poised to purchase a large amount of ether, placing your own buy order right before theirs could drive up the price. Then, by placing a sell order right after their purchase executes, you capitalize on the resulting price movement. The Miner's authority to sequence transactions within a block opens opportunities for such profitable maneuvers.
Thus, we’re left with Miners that receive all transactions that the network contains but not yet mined, they being the final judge that decides what is included in the next block and in what order. In blockchain terminology, these transactions are part of the mempool , ones that are in the network but not yet included in a block.
But let’s cut Miners some slack, as they are not the only ones who can see transactions in the mempool. In fact, any user can run the same software and access the entire list of mempool transactions. This means that Miners are not special in this regard.
It's important to note that Miners don't manually select transactions. Instead, they rely on specific rules in the software to pick the best ones. The rule is simple: transactions in the mempool are sorted by the associated fee in descending order, and Miners pick as many as they can fit in a block.
Knowing this allows any user, not only the Miners, to exploit opportunities using the front-running technique.
I have to admit I know a few things about Front-running because I built an exploitation framework that uses symbolic execution and front-running to exploit hackers on the Ethereum mainnet. Both tools are currently deprecated, but it’s fun to know they are inspired by Die Hard characters (Karl and Theo ). Below, you can watch the Defcon 27 presentation alongside Bernhard Mueller, the inventor of Mythril (symbolic execution engine).
VIDEO
The Evolution of Front-running During the early days of Ethereum, the community recognized that since the blockchain was capable of more than just facilitating value transfers (as was the case with Bitcoin), creating and engaging with complex applications created opportunities to extract value from the system by front-running. As more and more of those applications appeared on Ethereum, more and more complex actors evolved alongside them. These complex actors that search for opportunities within the mempool are commonly called Searchers .
We started seeing different types of applications that facilitate crowdfunding, automatic actions (cron-like actions), and gambling services. Since interaction with each of them generated a different type of financial gain, each type is important (and fun) to understand.
A Taxonomy of Front-running Attacks I find it important to understand the different outcomes that can be obtained using this Front-running technique.
💡 This taxonomy is taken from “SoK: Transparent Dishonesty: Front-running Attacks on Blockchain.” by Shayan Eskandari, Seyedehmahsa Moosavi, Jeremy Clark I will explain why each of these is important since they all play a different role in the front-running game.
In the following examples:
Alice represents the unsuspecting user sending a transaction to the blockchain
Bob represents the attacker
Displacement attack In this attack, Alice sends a transaction to secure a unique or last place in a system. For instance, let's say Alice wants to mint a specific NFT. Bob, on the other hand, wants to ensure that his transaction is executed ahead of Alice's. To achieve this, Bob takes Alice's place in the block, ensuring that Alice's transaction is executed after his own, even if Alice's transaction becomes invalid (due to the unavailability of the specific NFT mint she wanted).
Insertion attack An insertion attack occurs when Bob modifies the state of a contract by running his own function and then needs Alice's original function to operate on this altered state. For instance, if Alice places a purchase order for a blockchain asset at a higher price than the best offer, Bob will execute two transactions: he will buy the asset at the best offer price and then sell the same asset at Alice's slightly higher purchase price. If Alice's transaction is executed afterward, Bob will profit from the price difference without actually having to hold the asset.
Suppression attack In a suppression attack, Bob attempts to stall or delay Alice's transaction. This action is similar to censorship, as it ensures that Alice's transaction is not included in a block for a specific amount of time. While this type of attack is less common and may be more costly, it is still noteworthy.
Since this is more uncommon, I will give you an example of a suppression attack. Maybe the most popular suppression attack was executed against the Fomo3D gambling dapp. The way to win this game was to be the last person who bought a “ticket” over a period of time. But each ticket buy also increased the pot; thus, there was always an incentive for a new player to buy a new ticket. So how do you win? You buy a ticket and suppress ALL other transactions until the time expires.
There are two ways to win this game. The first way is by colluding with all the miners and persuading them to censor all transactions except for yours. The second way is by filling the blocks with very expensive transactions to ensure no other player can get their transactions in until the time runs out. This is exactly how the first round of the game ended. The attacker purchased a ticket and sent very expensive transactions to the network. Since the miners chose the most profitable transactions to include in the blocks, no other transactions where users could buy tickets were accepted, ultimately running out the clock.
Someone had to stop Balrog From Front-running to MEV The upgrade from Front-running to MEV happened in the paper by Phil Daian, et al. called Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges
Miner-extractable value (MEV): We introduce the notion ofMEV, value that is extractable by miners directly from smartcontracts as cryptocurrency profits. One particular source ofMEV is ordering optimization (OO) fees, which result from aminer’s control of the ordering of transactions in a particular epoch. PGAs and pure revenue opportunities provide one source of OO fees. We show that MEV creates systemic consensus-layer vulnerabilities.This paper marked the emergence of MEV, but the practical implementation of Flashbots was the moment when people could reliably position their transactions in relation to other transactions in the mempool. Flashbots created a side channel that connected miners, allowing Searchers to specify a set of transactions they wanted to be included and their order. The bundle of transactions was either included completely or not at all, giving Searchers the ability to specify which transaction they wanted at the center. Previously, they had to bid a relative fee to the transaction they wanted, but this did not guarantee 100% certainty that the bundle would either be completely included or not at all.
We will use “Front-running” and “MEV” interchangeably since the two techniques are largely similar.
Blockchain Front-running: Ethical Dilemmas Blockchain front-running differs from traditional finance as it often involves open, strategic placement of transactions. The ethical dilemma emerges with 'negative MEV', where users may get a worse price due to others exploiting public information. While not illegal, this raises concerns about fairness. It's easier to ignore MEV, when it adds just-in-time liquidity to my concentrated market maker swap, providing a better trade. But ignoring it becomes difficult when MEV leads to a worse trade for you.
The ethical debate intensifies when we consider 'negative MEV' – practices that can lead to a user receiving a worse price due to others exploiting their knowledge of the blockchain's pending transactions. Here, the lines between savvy trading strategies and exploitative practices start to blur, raising legitimate questions about the fairness and morality of such actions.
While Ethereum transactions are public by design, services like Flashbots introduce a nuanced layer of privacy, enabling select transactions to bypass the public pool. This can prevent bidding wars and protect profits for traders executing lucrative trades or arbitrage. However, it raises concerns over whether the playing field remains level when certain players have privileged access to transaction execution.
💡 Are you a nice person if you’re front-running other people? Does the outcome matter? The Promise of Proposer-Builder Separation Ethereum, just like many other blockchains, previously used a Proof of Work consensus mechanism similar to that of Blockchain. In Proof of Work, miners solve complex mathematical problems to gain the right to create the next block. Once they come up with a solution, they are permitted by the network to publish the block. The block contains a list of transactions, and the miners keep the associated fee from each transaction. The process requires a lot of computational power, making it energy-intensive.
Ethereum has always intended to shift to Proof of Stake, a more energy-efficient consensus algorithm. In Proof of Stake, we don't have miners anymore; instead, we have Validators .
Validators have to stake 32 ether to be part of the Validator pool. This time, there’s no complex mathematical puzzle; anyone who is willing to lock the 32 ether promises to behave correctly, otherwise, part of their stake gets slashed.
Even though we upgraded from Proof of Work to Proof of Stake, the Validators have the same amount of power. They can choose what transactions get in each block and in what order. The biggest change we have regarding this game is that we know who the next block producer is.
The concept of Proposer-Builder Separation (PBS) was designed for Ethereum Proof of Stake and has gained some popularity ever since.
Enter the Relay The Validator's role was split into two new sub-roles: block building and block proposing. The Builder is responsible for creating the blocks by selecting which transactions are included and determining their order. The Proposer takes the best block created by the Builder and adds it to the blockchain.
Proposer-Builder Separation has two main goals:
preventing censorship; decentralizing power by reducing the advantage large entities have in block-building. This system works by introducing a new player called the Relay. The Relay stands between the Builders and the Proposers and coordinates them. Builders send blocks to the Relay, and when the time comes to propose a new block, the Relay sends the most profitable block to be signed by the Proposer. This way, the power to add new blocks is separated from the ones choosing which transactions should be included in the next block.
Can't separate without a separator Monetization structure Builders monetize their roles through priority fees and direct transfers, with priority fees introduced by EIP-1559. These fees are offered by users to prioritize their transactions within a block, acting as an incentive for Builders. Additionally, Builders can maximize their profits by strategically manipulating the transaction order within a block to exploit different types of arbitrage opportunities, a process commonly done by Searchers (not discussed in this article). The net profit for a builder is the total amount of priority fees and direct transfers received minus the payments made to proposers for block inclusion.
Proposers, on the other hand, are tasked with adding new blocks to the blockchain, and they earn profits from the payments received from builders. These payments are a form of revenue sharing where builders compensate proposers for incorporating their blocks into the blockchain. The arrangement typically results in higher earnings for proposers under the Proposer-Builder Separation (PBS) system, especially when MEV opportunities are plentiful.
There's a marked difference in revenue potential among builders and proposers based on their efficiency in transaction selection and block construction. Those adept at harnessing the PBS model often enjoy greater profits by extracting more value from each block. This leads to a variance in earnings across participants, as those who are more skilled at identifying and seizing MEV opportunities tend to earn more.
However, it is important to note that the monetization model for Relays in this framework is currently undefined. Relays, which are responsible for propagating blocks, making sure Builders pay the Relayers, mediating the auction process, have not been integrated into the revenue structure established by priority fees, direct transfers, and MEV strategies that benefit builders and proposers. This lack of a defined revenue model leaves a gap in the overall economic landscape of blockchain transactions and block propagation.
Relay cost structure and incentives We’ve got 800k+ Validators. These Validators can become a proposer if they choose to use a Relay instead of building blocks themselves.
Graph from https://mainnet.beaconcha.in/
The MEV-Boost software allows validators to maximize their staking rewards by selling block space to builders through an open market. Presently, MEV-Boost is used to build approximately 90% of all blocks. It is important to note that MEV-Boost is a PBS implementation, which implies that the vast majority of blocks at some point in the hands of the Relays.
Graph taken from https://www.rated.network/relays?network=mainnet
The current design and market position of Relays pose a problem as they don't seem to earn any revenue. While Builders are paid for their work of selecting the best transactions and building the block, and Proposers are paid for submitting the built blocks, Relays remain in between everything and gain nothing.
We trust the Relays, but their incentive to behave correctly is unclear. This may hinder our understanding of their actions.
You pass blocks It is essential to have at least one developer and servers to run a Relay system effectively. This ensures that the Relays can operate smoothly and stay unbiased while mediating between Builders and Proposers. The system should be able to respond promptly, handle block auctions, publish blocks, and punish improper behavior while providing the best experience for the Builder and the Proposer. However, these processes come at a cost that can amount to tens of thousands per month. The issue is that there is no incentive structure in place for Relays , which can cause problems. If they remain without clear incentives, the honest ones may have to shut down, while the dishonest ones may find ways to exploit their users. We don’t want to remain with the dishonest Relays as the most trusted actor in PBS.
🔜 It is crucial that we establish clear and understandable incentives for the Relays to maintain and sustain their important role. Without such incentives, the Relays will be forced to seek alternative means of compensation, which may undermine the initial purpose of their existence. To ensure that the community trusts and supports the Relays, it is essential that the benefits of running a Relay are transparent and well-defined.
Incentive ideas for the Relays As a community, we need to find ways to create an honest and functional future. I propose starting with simple incentive structures for Relays.
Sharing fees with Relays Creating a structure where the fees are shared with Relays will tie compensation to the volume of activity the Relay facilitates. This provides a constant incentive structure for Relays to stay online, behave trustworthy, provide low latency and perform efficiently.
However, it's unclear whether we need to modify Ethereum protocol rules or if the Builder should pay Relays. Alternatively, Builders and/or Proposers may be required to stake some Ether, allowing them to take a cut themselves if they are not paid.
Subscription Model A flat subscription fee can be implemented for all users connected to the Relay. This will provide a steady and predictable source of income for the Relay, enabling them to manage their expenses and revenue more effectively. Various subscription models could be offered, allowing for lower latency or more secure communication channels for different types of users.
However, this approach may result in the creation of different user tiers, which may not be desirable. We aim to level the playing field, reducing the advantage of users with greater financial resources.
Data and Analytics Services Leveraging the wealth of data that flows through Relays, a new avenue for monetization opens up through offering analytics services. Relays can package and sell insights derived from transaction patterns, network usage, and performance metrics, creating a value-added service for market analysts and participants who need real-time and historical data.
While potentially lucrative, this model raises questions of user privacy and data security. The infrastructure required to aggregate, analyze, and distribute data must be established without compromising the core functions of the Relay or the trust of the network participants.
Inclusion Services The Relays can create partnerships with DeFi protocols, DAOs or other blockchain services to ensure the transactions for their users are included, offering seamless transaction capabilities. This can take different forms, such as transactions handling Account Abstraction, or even more generally having User Intents instead of a specific execution path.
Conclusion The introduction of Proposer-Builder Separation (PBS) in Ethereum's Proof of Stake consensus marks a significant shift in the landscape of blockchain transaction processing. By addressing the issues of front-running and miner extractable value (MEV), PBS aims to enhance the fairness and decentralization of the network. It does so by dividing the responsibilities of block creation and proposal between Builders and Proposers, with the Relay system serving as an intermediary to balance interests and optimize outcomes.
Yet, despite its innovative approach, the PBS framework faces challenges, particularly in the incentivization of Relays. These entities, crucial for coordinating between Builders and Proposers, currently lack a direct reward mechanism for their services. As the network evolves, it becomes imperative to establish clear incentives for Relays to ensure their commitment to an unbiased and efficient process.
The future of Ethereum's transaction processing is not just a technical issue; it's a question of vision. Do we envision a blockchain that merely functions, or one that sets the standard for equity and efficiency? The answer lies in our collective hands as we strive to build an Ethereum that remains true to its foundational principles of decentralization, security, and openness.
Regards I want to thank everyone on the team for their hard work and support. A special shoutout to Nelson and Sergey for their help along the way. Your knowledge and input have really made a difference.
Resources and links
.png)
