Skip to main content

The MPBC Upgrade

Multi-party block construction (MPBC) upgrades PBS by expanding block construction from one builder to multiple builders. Builders still compete in the auction with their most valuable local block but can now also add their transactions to each other's blocks before they are delivered to the proposer. As a result, blocks become larger and more valuable, which starts to address the current structural gaps and benefits Ethereum, users, and the actors in the transaction pipeline.

An overview of the terminology used to describe MPBC is provided in the table below.

Terminology
TermExplanation
Single-Party BlockA block containing transactions contributed by only one builder.
Multi-Party BlockA block containing transactions contributed by more than one party.
Base BlockA highest-bid single-party block available to an operator, used as the starting point for multi-party block construction.
MergingThe process of adding transactions to the base block to make it a multi-party block.
BuilderA sophisticated party responsible for optimizing how transactions find blocks and blocks get constructed.
Base BuilderThe builder that constructed the base block.
Contributing BuildersBuilders that have contributed transactions to a multi-party block.
MPBC OperatorA party that receives blocks and transactions from builders, combines eligible contributions into a multi-party block, and submits the highest-paying block to the proposer.

Upgrading PBS: the MPBC pipeline

MPBC keeps the PBS auction largely the same, but makes it more competitive by adding multi-party blocks to it. MPBC operators identify the most valuable block built by any single builder and append additional fee-paying transactions from other builders which have been tagged as mergeable. The highest bid block wins the auction, irrespective of whether it is a single-party block or a multi-party block. A builder's normal submission does not change. Marking a block or its transactions mergeable is an addition to it. Proposers change nothing, because the winning block arrives over the same connections and through the same auction.

Builders submit their best single-party block, the MPBC layer adds transactions from multiple builders to the best block, and the proposer selects the highest bid.

MPBC proceeds in four stages:

  1. Builders build blocks from the transactions available to them and submit them to operators, indicating which blocks and transactions are eligible for merging.
  2. Operators extend the highest-paying block with transactions from other builders.
  3. Operators check which block pays the most and deliver it to the proposer. This could be a multi-party block or any other block.
  4. The proposer signs the highest-paying block it has received from any operators.

To incentivize all actors, the value added to the block is split between the proposer, the operator, the base builder, and the contributing builder. This provides the proposer with higher bids, incentivizes builders to contribute, and creates a sustainable business model for operators.

MPBC operators

Operators sit between builders and proposers and connect to validators over existing relay connections. Like relays, operators receive complete blocks from all builders connected to them. In contrast to relays, operators are only used when their services increase block value as escrow will be handled in-protocol after ePBS.

Operator services include multi-party block construction, block delivery, and the enforcement of proposer preferences. Operators may communicate to more efficiently perform these services, shown in the table below:

DataPurpose
Execution payloadsJointly propagate payloads to more effectively reach attesters, increasing block value in expectation.
Proposer constraintsVerify transaction inclusion and enforce proposer preferences against builders, giving proposers more control over their blocks.
Builder demotionsOperators identify and restrict the access of malfunctioning builders together, reducing the risk of missed slots and unlocking capital efficiency through shared builder collateral.

Operator requirements

Running an operator is permissionless and there is an open source reference implementation. Like with relays today, an operator's reach grows with the builders and proposers it serves. These connections are based on trust and performance:

  • Builder trust: Builders submit complete blocks to operators and must trust them not to leak or front-run sensitive transactions.
  • Proposer trust: Proposers source bids from operators and must trust them to source the highest bid for them and enforce their preferences.
  • Performant infrastructure: The operator sits in the latency-critical path and has to serve the traffic that comes with it.

Operators do not price transactions or assembly blocks. They just append the transactions builders have already marked mergeable, then apply the value split. The design intentionally kept changes minimal to avoid operator complexity pushing them to become builders themselves.

MPBC impact

By making blocks larger and more valuable, MPBC starts to address the structural gaps in the transaction pipeline:

DimensionSingle-party block constructionUpgraded multi-party block construction
Robustness• A single builder decides on transaction inclusion.
• Limited proposer autonomy.
• Multiple builders can provide transaction inclusion.
• Higher proposer autonomy due to support for proposer services.
Economics• Only transactions known to a single builder are included.
• Relays operate as public goods without compensation.
• Transactions known to multiple builders can be included.
• MPBC layer operators are compensated based on performance.
Performance• Blocks are propagated by a single relay alone.
• Transactions not known to the winning builder spill over into the next slot.
• Blocks are propagated by multiple MPBC layer operators together.
• Fewer spillovers, as multiple builders can include a transaction.
Services• Service support requires opt-in by a single builder.• Service transactions can be included by multiple builders.

This benefits the participants in the block construction pipeline in the following ways:

  • The Ethereum protocol benefits from higher censorship resistance and robustness through multiple inclusion channels, improved economics through higher blockspace utilization, and better support for services.
  • Originators see faster, cheaper, and more predictable inclusion through additional inclusion paths and higher blockspace utilization.
  • Builders gain revenue for every block they contribute transactions to, lowering the barrier to entry for new builders.
  • MPBC layer operators earn revenue proportional to the value they generate by adding transactions from contributing builders to the base block.
  • Proposers receive more valuable blocks and gain more credible support for proposer services, since multiple builders can contribute transactions.

The live metrics quantify the impact MPBC has already had.