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 emabark on a journey through intricacies of the Proposer-Builder Separation (PBS), a grounbreaking approach altering roles within Ethereum's network. We delve into the complex world of Maximal Extractable Value and its pivotal role in the economic strategies of builders and propsers 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 brpader blockchain community. Concluding with an overview and a forward-looking perspective, this article provies 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 of 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 are engaging with, and so forth.
Once this transaction is assembled, it is sent to the network. This broadcast means that the transaction does not only become known to the validator but also becomes visible to a majority of network participants.
Upon receiving the transactions, the validators must validate them since other validators will not accept an invalid transaction. However, their main concern is to choose a profitable transaction since the validator 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 validators (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.
Front-running is trading a 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.
How Validators Work ?
In blockchain domain, validators 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 is 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 validator's authority of sequence transactions within a block opens opportunities for such profitable maneuvers.
Thus we are left with validators 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 validators some slack, as they are not only the ones who can see transactions in the mempool. In fact, any users can run same software and access the entire list of mempool transactions. This means that validators are not special in that regard.
It is important to note that validators don't manually select transactions. Instead, they rely on specific rules of in the software to pick best ones. The rule is is simple: transactions in the mempool are sorted by the associated fee in descending order, and validators pick as many as they can fit in a block.
Knowing this allows any user, not only the validators, to exploit opportunities using the front-running technique.
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, creating and engaging the complex applications created opportunities to extract value from the system by front-running. As more and more of these applications appeared on Ethereum, more and more complex actors evolved alongisde them. These complex actors that search for opportunities within the mempool are commonly called Searchers.
We started seeing different type of applications that facilitate crowdfunding, automatic actions, and gambling services. Since interaction and each of them generated a different type of financial gain, each type is important and to understand.
A Taxonomy of Front Running Attacks
I find it more important to understand the different outcomes that can be obtained using this Front-running technique.
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, lets 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 Alice's transaction is executed after his own, even if Alice's transaction becomes (due to the unavailability of the specific NFT mint she wanted).
Insertion Attack
An insertion attach occurs when Bob modifies the state of a contract running his own function and then needs Alice's 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.
Supression Attack
In a suppresion 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.
From Front Running to MEV
The upgrade from Front-running to MEV happened in the paper by Phil Daian, et al. called Flasboys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges. This paper introduced a larger public to the possibilities of extracting value from monitoring and inserting or reordering transactions on the blockchain. They showed that this was not just possible but was happening on a large enough scalre when the paper was published.
This paper marked the emergence of MEV, but the practicial 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 connect validators, 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 a bit 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.
Blochain MEV: Ethical Dilemmas
Blockchain front-running differs from traditional finance as it often invovles 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 intesifies when we consider "negative MEV" - practices that can lead 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 publich 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 have privileged access to transactions execution.
The Promise of Proposer Builder Separation
Ethereum, just ike many other blockchains, previously used a Proof of Work consensus mechanism similar to that of BitCoin. 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 inteded to shift to Proof of Stake, a more energy-efficient consensus algorithm. In Proof of Stake, we don't have any miners anymore; instead, we have Validators.
Validators have to stake 32 ether to be part of the Validator pool. This time, there is not 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 sub-roles: block building and block proposing. The Builder is responsible for creating the blocks by selecting which transactions are included and determinig their order. The Propser takes the best block created by the Builder and adds it to the blockchain.
This system works by introducing a new layer called Relay. The Relay stands between the Builders and the Proposers and coordinates them. 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 Relaay 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.
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 incetive 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. 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 asked with adding new blocks to the blockchain, and they earn profits from the payments received from builders. These payments are 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 is 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 great 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 feeds, 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.
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.