PROPOSER BUILDER SEPARATION AT PROTOCOL LEVEL (2024)

WRITTEN BY — FARDEEN KHAN — Fardeen Khan | LinkedIn

JOIN OUR RESEARCH BASED OPEN SOURCE COMMUNITY FROM HERE — http://linktr.ee/weufoundationsocial

WE ARE GOING TO DISCUSS AROUND THESE MAJOR TOPICS IN THIS BLOG….

A blockchain is a data structure that stores a sequence of transactions in a secure and decentralized way. Each transaction is grouped into a block, which contains a unique identifier (hash), a reference to the previous block (previous hash), and other metadata. The blocks are linked together by their hashes, forming a chain of blocks. This chain is verified and maintained by a network of nodes that follow a consensus protocol. The blockchain data structure ensures that the transactions are immutable, transparent, and verifiable.

HEAD AND BODY OF A BLOCK… SAME LIKE OUR BODY SYNAPSE SOME INFORMATION AND THE WHOLE BODY EXECUTE IT.

• Block header: This is the metadata of the block, which includes the block number, the timestamp, the hash of the previous block, the hash of the current block, and the consensus data. The consensus data is the information that is used by the consensus algorithm to validate the block and reach an agreement among the nodes. For example, in proof-of-work, the consensus data is the nonce and the difficulty, which are used to solve the cryptographic puzzle. In proof-of-stake, the consensus data is the stake and the signature, which are used to prove the ownership and validity of the block.
• Block body: This is the payload of the block, which contains the executable transactions. Transactions are the records of data transfer or state change that occur on the blockchain network. Transactions are usually signed by the sender and verified by the receiver. Transactions can also contain smart contracts, which are self-executing programs that define the rules and logic of the transactions.

In proof-of-stake, validators and block builders are separated. Validators are the ones who stake their Ether and run nodes to secure the network. They are randomly selected to propose blocks and attest to their validity. Block builders are the ones who collect and order transactions from the mempool and submit them to the validators. They are rewarded by the fees paid by the users for their transactions. This system is more scalable, secure, and fair, as it reduces the barriers to entry, the environmental impact, and the influence of block builders over transaction ordering.

The consensus client implements the new consensus algorithm, which enables the network to achieve agreement based on validated data from the execution client. The execution client continues to run the EVM and process transactions as before, but now receives block proposals from the consensus client instead of miners. This modular design makes the network more scalable, secure, and efficient, as it reduces the complexity and dependency of each component.

A block proposer in Ethereum is a validator who is randomly selected to propose a new block for the network. The block proposer has to take care of the execution payload, which is the set of transactions that will be executed by the EVM and change the state of the network. The execution payload has to be valid, meaning that it follows the rules of the network and does not contain any invalid or conflicting transactions.

The block proposer also has to consider the constraint of the base fee, which is the minimum gas price that a transaction must pay to be included in a block. The base fee is determined by the network and adjusts dynamically according to the demand for block space. The base fee is burned, meaning that it is removed from the total supply of Ether and does not go to the block proposer or any other validator.

The block proposer has to balance the trade-off between maximizing their profit and ensuring the security and efficiency of the network. On one hand, the block proposer wants to include as many transactions as possible in their block, especially those that pay a high priority fee (also known as the miner tip), which is the additional fee that goes directly to the block proposer. On the other hand, the block proposer does not want to create a block that is too large or too small, as this could affect the base fee and the network congestion in the future. A block that is too large could increase the base fee and discourage users from sending transactions, while a block that is too small could decrease the base fee and encourage spamming or manipulation of the network.

Therefore, the block proposer has to estimate the optimal size and composition of their block, taking into account the current and expected base fee, the priority fees of the transactions in the mempool, and the gas limit of the network. The block proposer can use various strategies and heuristics to do this, such as sorting the transactions by their effective gas price (the sum of the base fee and the priority fee), filtering out the transactions that are below a certain threshold, or using a dynamic algorithm that adjusts the block size and the priority fee according to the market conditions.

From MINER EXTRACTABLE VALUE (POW) to MAXIMAL EXTRACTABLE VALUE ….BLOCK PROPOSER IS THE BEST PLACE TO CAPTURE THE MAXIMUM VALUE .

Ordering matters for block proposers because it affects the amount of maximal extractable value (MEV) they can obtain from the transactions in a block. MEV is the extra profit that block proposers can earn by manipulating the inclusion, exclusion, or reordering of transactions in a block, in addition to the regular block reward and gas fees.

Block proposers act upon MEV by trying to find the optimal order of transactions that maximizes their revenue, while also considering the trade-offs and risks involved. For example, some transactions may have higher priority fees (also known as miner tips) that go directly to the block proposer, while others may have lower priority fees but create arbitrage or liquidation opportunities for the block proposer or other searchers (independent actors who look for MEV opportunities and submit them to the network). Block proposers may also try to front-run, back-run, or sandwich other transactions to exploit price differences or market inefficiencies.

See Also

Builder+ – BTCS Inc. – Advanced Blockchain Operations

In proof-of-work based systems, the searcher and proposer relation works as follows:

• A searcher is an independent actor who looks for profitable MEV opportunities, such as arbitrage, liquidation, or front-running, by analyzing the transactions in the mempool or the blockchain.
• A proposer is a miner who competes to create new blocks filled with processed transactions, by solving a cryptographic puzzle that requires a lot of computational power.
• A searcher can submit a transaction that executes an MEV opportunity to a proposer, along with a high priority fee (also known as the miner tip) that goes directly to the proposer. The priority fee is the additional fee that a user pays on top of the base fee, which is the minimum gas price that a transaction must pay to be included in a block.
• A proposer can choose to include the searcher’s transaction in their block, and order it in a way that maximizes the MEV profit. The proposer can also share a portion of the MEV profit with the searcher, as an incentive for them to reveal the MEV opportunity.
• Alternatively, a proposer can act as a searcher themselves, and find and execute MEV opportunities on their own, without paying any priority fee or sharing any profit with anyone else.

SIMPLY , IT’S ALL ABOUT TRUST HERE AS WELL -

Mining pools are groups of miners who pool their resources and share the rewards of mining blocks in a proof-of-work (PoW) system. Mining pools allow miners to increase their chances of finding a valid block and reduce the variance of their income. Mining pools also act as intermediaries between searchers and proposers, who are the actors that look for and execute MEV opportunities in a PoW system. Searchers can trust mining pools to include their transactions in a block and share the MEV profit with them, as long as the mining pool has a good reputation and a large market share

The relation between searchers and proposers in proof-of-work systems relies on trust, and that there is a possibility of manipulation. For example, a proposer could cheat a searcher by accepting their transaction but not including it in their block, or by reordering the transactions in their block to benefit themselves. A searcher could also cheat a proposer by submitting a transaction that does not execute the MEV opportunity as promised, or by withholding a transaction that could prevent a loss for the proposer.

However, there are also some factors that discourage manipulation and encourage cooperation between searchers and proposers. For instance, a proposer who cheats a searcher may lose their reputation and future business opportunities, as the searcher could blacklist them or report them to other searchers. A searcher who cheats a proposer may lose their chance to earn MEV profit, as the proposer could reject their transaction or prioritize other transactions. Moreover, both searchers and proposers have to compete with other actors in the network, who may offer better deals or faster execution. Therefore, it may be more rational and profitable for searchers and proposers to cooperate and share the MEV profit, rather than manipulate and risk losing it.

The problem of solo validators in a PoS system is that they have a lower chance of being selected as proposers and earning rewards, compared to validators who join a pool or a service. This is because the probability of being selected as a proposer is proportional to the amount of stake, and solo validators usually have less stake than pooled validators. Solo validators also have to bear the costs and risks of running their own nodes, such as hardware, software, security, and availability. Moreover, solo validators have less bargaining power and influence over MEV extraction, compared to pooled validators. This is because solo validators have less control over the order and inclusion of transactions in a block, and they have to compete with other searchers and proposers who may offer better deals or faster execution .

The role of builders in the proof of stake based chains is to collect and order transactions from the mempool and submit them to the proposers, who are the validators that are randomly selected to create new blocks. Builders are rewarded by the fees paid by the users for their transactions. Builders interact with the proposers by sending them bundles, which are sets of transactions that execute MEV opportunities, along with a bid for their inclusion in a block. Proposers can choose to accept or reject the bundles, and order them in a way that maximizes their revenue, while also considering the trade-offs and risks involved. Proposers can also share a portion of the MEV profit with the builders, as an incentive for them to reveal the MEV opportunities.

However , proposers cannot steal the content of the blocks that the builder has given to them, because they only see the bundle headers, not the bundle bodies, until they have already selected the header that wins the auction. A bundle is a set of transactions that execute MEV opportunities, along with a bid for its inclusion in a block. A bundle header contains the hash of the bundle body, the bid, and the signature of the builder. A bundle body contains the ordered list of transactions and the proof of validity. If the proposer tries to change the content of the block, they will invalidate the hash and the signature, and the block will be rejected by the network.

HOW THIS RELATION BETWEEN BUILDER & PROPOSER IS DONE USING A SOFTWARE PIECE ….

MEV-Boost is a software that allows Ethereum validators to access a competitive block-building market. MEV-Boost is an implementation of proposer-builder separation (PBS) for proof-of-stake (PoS) Ethereum. With MEV-Boost, validators can source blocks from a marketplace of builders, who optimize the order and inclusion of transactions to extract maximal extractable value (MEV). MEV-Boost is free, open-source, neutral software built by Flashbots for the community.

Relays are intermediaries that receive blocks from builders and forward them to proposers. Builders are the ones who collect and order transactions to extract maximal extractable value (MEV). Proposers are the validators who are randomly selected to create new blocks. Relays are trusted by both builders and proposers for fair routing, validity, accuracy, and data availability. Relays also verify and simulate the blocks sent by the builders, and rate-limit them as necessary. Relays can connect to one or many builders, and aggregate their bids for the proposers.

• Building blocks with MEV-Boost allows validators to access a competitive market of block builders, who optimize the order and inclusion of transactions to extract maximal extractable value (MEV). MEV is the extra profit that validators can earn by manipulating the transactions in a block, such as frontrunning, backrunning, or arbitraging.
• Building blocks with MEV-Boost reduces the complexity and dependency of each component in the system. Validators only need to run a consensus client and an MEV-Boost client, while block builders only need to run an execution client and a builder client. This modular design makes the system more scalable, secure, and efficient.
• Building blocks with MEV-Boost improves the fairness and transparency of the network. Validators can choose the best block from a pool of bids submitted by block builders, and share the MEV profit with them. Block builders can also use the standard Ethereum Builder API, which defines the interface between validators and block builders.

As you can see there is no relays in between the builder and the proposer . SO in the future we can see a direct relation between the builder and the proposer…

Block building is usually more costly than block verification, because it involves finding and executing transactions that maximize the profit of the block builder, such as maximal extractable value (MEV) opportunities. MEV is the extra profit that can be earned by manipulating the transactions in a block, such as frontrunning, backrunning, or arbitraging. Block building also requires solving a cryptographic puzzle or proving the stake in some consensus protocols, such as proof-of-work (PoW) or proof-of-stake (PoS).

Block verification is usually less costly than block building, because it only involves checking the hash, signature, and rules of the block, without executing the transactions or solving the puzzle. Block verification can be done by any node in the network, while block building can only be done by a selected node or a group of nodes, depending on the consensus protocol.

The idea behind making the computation of block building costly and block verification cheap is to create an asymmetry that results in more accessible and more resistant blocks. The asymmetry makes it easier for the network to reach a consensus and verify the transactions, while making it harder for the attackers to alter or invalidate the blocks.

If we implement PBS in the protocol structure itself, some of the changes that may come to the PBS relation are:

• The protocol may define a standard interface and a bidding mechanism for block builders and validators to communicate and cooperate. This may increase the efficiency and fairness of the block building market, and reduce the dependency on intermediaries or third-party services.
• The protocol may enforce some rules or incentives for block builders and validators to share the MEV profit and prevent manipulation or collusion. This may improve the security and decentralization of the network, and reduce the negative externalities of MEV extraction .
• The protocol may introduce some features or innovations that enhance the performance and functionality of the block building process, such as parallelism, sharding, or rollups. This may increase the scalability and throughput of the network, and enable more complex and diverse transactions.

• Slot auctions are a way of allocating block space to external block builders who bid for the right to make a block on behalf of the block proposer.
• Slot auctions can be either block auctions or slot auctions. Block auctions require the block builder to commit to a specific block content before sending a bid to the block proposer. Slot auctions only require the block builder to commit to a bid and reveal the block content later.
• Block auctions have the advantage of being more transparent and verifiable, as the block proposer can check the validity and value of the block before accepting it. Slot auctions have the advantage of being more flexible and efficient, as the block builder can optimize the block content until the last moment and avoid revealing it to potential competitors.
• Block auctions may be more suitable for scenarios where the block proposer wants to impose some constraints or preferences on the block content, such as inclusion lists or partial block auctions. Slot auctions may be more suitable for scenarios where the block proposer wants to maximize their revenue by accepting the highest bid without caring about the block content.

The principal-agent problem in PBS (proposer-builder separation) is the conflict of interests between the proposers and the builders, who are the actors that create and order transactions in a block.

One way to solve the principal-agent problem in PBS is to use partial block making by the proposer, which means that the proposer can reserve some space in the block for their own transactions, and only auction off the remaining space to the builder. This way, the proposer can ensure that some transactions that they care about are included in the block, and also reduce the power and profit of the builder.

Another way to solve the principal-agent problem in PBS is to use inclusion list by the builder, which means that the builder can provide a list of transactions that they guarantee to include in the block, along with their bid. The proposer can then choose the best bid based on the inclusion list and the price. This way, the proposer can have some control over the block content, and also increase the transparency and fairness of the block building market.

Data availability is the property that ensures that the data of a block is accessible and verifiable by anyone in the network. Data availability is essential for the security and scalability of blockchain systems, especially for layer 2 solutions such as rollups, which rely on the data of the layer 1 chain to execute and validate transactions.

Builders for data availability can be outsourced by using services or protocols that provide data availability solutions for blockchains. For example, some services offer data availability as a service (DAAS), which means that they store and serve the data of the blocks for a fee. Some protocols use erasure coding or Reed-Solomon codes, which means that they encode the data of the blocks into smaller pieces and distribute them across the network, so that the data can be reconstructed from a subset of the pieces. Some protocols use fraud proofs or data availability proofs, which means that they allow anyone to challenge the availability or validity of the data of the blocks, and penalize the malicious actors.

One way to solve the data availability problem with danksharding is to use the KZG scheme, which is a technique that reduces the data of a block to a small cryptographic commitment. The commitment can be verified by anyone in the network, without requiring the full data of the block. The KZG scheme also allows for efficient data availability proofs, which means that anyone can prove that they have the data of the block, or that the data of the block is unavailable or invalid. The KZG scheme is compatible with zero-knowledge techniques, which are used by some rollups and other parts of the Ethereum protocol.

WHICH WE WILL DISCUSS IN ANOTHER VOLUME OF PROPOSER BUILDER SEPARATION

Incentive compatibility is a property of mechanisms that aligns the individual interests of the participants with the collective interests of the system. Incentive compatibility ensures that each participant can achieve the best outcome for themselves by following the rules of the mechanism, regardless of what the others do.

Incentive compatibility of PBS is desirable because it promotes the security, efficiency, and fairness of the network. However, it is also challenging because of the potential conflicts and trade-offs between the proposers and the builders, who may have different preferences and objectives. For example, proposers may want to include some transactions that they care about, while builders may want to exclude or reorder them to maximize MEV. Proposers may also want to have some control or transparency over the block content, while builders may want to keep it secret or flexible.

There are several approaches and solutions to achieve incentive compatibility of PBS, such as:

• Using partial block making by the proposer, which means that the proposer can reserve some space in the block for their own transactions, and only auction off the remaining space to the builder. This way, the proposer can ensure that some transactions that they care about are included in the block, and also reduce the power and profit of the builder.
• Using inclusion list by the builder, which means that the builder can provide a list of transactions that they guarantee to include in the block, along with their bid. The proposer can then choose the best bid based on the inclusion list and the price. This way, the proposer can have some control over the block content, and also increase the transparency and fairness of the block building market.
• Using dominant-strategy incentive-compatible (DSIC) or Bayesian-Nash incentive-compatible (BNIC) mechanisms, which means that the mechanism design ensures that truth-telling or bidding is the best strategy for both the proposer and the builder, regardless of what the others do (DSIC) or given what the others do (BNIC). This way, the mechanism can achieve the optimal social choice function or outcome for the network.

WHICH WE WILL DISCUSS IN ANOTHER VOLUME OF PROPOSER BUILDER SEPARATION

PBS may introduce some challenges and trade-offs between the proposers and the builders, who may have different preferences and objectives. For example, proposers may want to include some transactions that they care about, while builders may want to exclude or reorder them to maximize MEV. Proposers may also want to have some control or transparency over the block content, while builders may want to keep it secret or flexible.

PBS may expose the users to various attack vectors, such as censorship, front-running, and bribing, that may compromise the security and fairness of the network. Users may also face higher fees or lower priority for their transactions, depending on the market conditions and the bids of the block builders.

PBS may require some changes or adaptations in the user interface and the user experience, as it introduces a new layer of abstraction and complexity in the block building process

WHICH WE WILL DISCUSS IN ANOTHER VOLUME OF PROPOSER BUILDER SEPARATION