PBS Fork

A builder intentionally withholds valid transactions from a block, often to comply with OFAC sanctions or for other strategic reasons. If a proposer accepts this censored block, but the network's consensus rules deem it invalid due to missing transactions that should be included, a fork can occur as honest validators reject it.

• Example: A builder excludes a valid transaction from a sanctioned address.
• Result: The block may be valid technically but rejected by social consensus or client software configured for censorship resistance.

Disputes arise over the distribution of Maximal Extractable Value (MEV). A proposer might attempt to 'steal' MEV by front-running or sandwiching the builder's transactions after receiving the block header, violating the PBS agreement.

• Mechanism: The proposer receives the header, previews the profitable transactions, and tries to create a more profitable block body.
• Consequence: The builder's original block and the proposer's altered block conflict, causing a temporary chain split until consensus resolves it.

The relay, a trusted intermediary between builders and proposers, acts maliciously or suffers a critical failure. This can include:

• Data withholding: Providing an incomplete block body to the proposer after commitment.
• Double-signing: Facilitating the same block header to multiple proposers.
• Censorship: Selectively not forwarding blocks from certain builders.

These actions break the trust assumptions of PBS, leading to inconsistent views of the chain and potential forks.

A proposer fails to adhere to the PBS protocol's strict commit-reveal scheme. The canonical flow is: receive header → sign commitment → receive full block. Violations include:

• Unblinding Attack: The proposer attempts to decrypt or discern block contents before commitment.
• Rejection after Commitment: Refusing to publish the corresponding block body after signing the header.

Such non-compliance invalidates the cryptographic and economic guarantees of PBS, forcing the network to fork around the bad actor.

Network latency or processing delays can cause a proposer to miss the deadline for publishing a builder's block. Even if the builder and relay act honestly, the block may not be propagated in time for the next slot.

• Result: The proposer may propose an empty or locally built block, while the builder's valid block is also propagated by the relay network.
• This creates a competing fork that must be resolved by the fork choice rule (LMD-GHOST).

A builder submits a block that is structurally or semantically invalid (e.g., invalid state transition, incorrect execution payload). If a relay fails to validate it properly and forwards the header to a proposer, the proposer may sign it.

• Upon revelation, the network's execution clients will reject the invalid block body.
• The proposer is now stuck with a signed commitment to a junk block, slashing risk may apply, and the chain must fork to a valid block.

This highlights the critical role of relay validation in PBS.

The primary actors whose economic incentives are directly threatened. A fork would create two competing chains, forcing them to choose sides and potentially slashing their stake on the non-canonical chain. This introduces significant financial risk and operational complexity, as they must run separate software clients and manage assets on divergent networks.

The entities whose existence is predicated on PBS. A fork that rejects PBS would eliminate the specialized builder role, collapsing the MEV supply chain back into validators. This would:

• Revert MEV extraction to a more opaque, validator-centric model.
• Invalidate significant infrastructure investment in builder software and relay services.
• Force MEV searchers to adapt their strategies for a new, less efficient market structure.

End-users and decentralized applications face immediate disruption and uncertainty. Key impacts include:

• Network instability and potential replay attacks during the fork period.
• Token duplication and confusion over asset value on forked chains.
• Smart contract state divergence, which can break application logic and require emergency upgrades.
• Increased transaction costs and latency due to network contention.

Centralized exchanges, bridges, oracles, and node providers must execute complex emergency procedures. They must:

• Halt deposits and withdrawals to prevent loss from replay attacks.
• Decide which chain to recognize as the canonical "ETH".
• Update all internal systems, APIs, and listing policies to support the new forked asset(s).
• This process is costly and risks significant user funds if mishandled.

The core developers and governance bodies (like Ethereum's ACD) face a crisis of legitimacy. A fork represents a failure of the social consensus process. Client teams must decide whether to implement the fork code, potentially splitting the developer community. The event would be a major test of credible neutrality and the chain's ability to upgrade without fracturing.

A contentious fork poses a systemic risk to the network's security model. It can:

• Reduce the total staked ETH across both chains, lowering the cost to attack either.
• Create chain fragility by establishing a precedent for political forks over technical upgrades.
• Erode long-term investor and developer confidence in the protocol's stability and neutrality, potentially impacting adoption and valuation.

A specific ePBS design where the block production process is split across two consecutive slots to ensure builder commitment finality before proposers reveal their bids.

• Slot 1 (Builder): Builders commit to a block header and a bid.
• Slot 2 (Proposer): The winning proposer reveals the full block body.
• Benefit: Prevents last-second bid manipulation and time-bandit attacks.

A critical mechanism within PBS designs to prevent builders from censoring transactions. A cr-list (censorship resistance list) is a set of transactions that a proposer requires to be included.

• Process: The proposer provides a cr-list to the builder. The builder must include all feasible transactions from this list in the block.
• Purpose: Ensures transaction inclusion cannot be blocked by centralized builders, preserving network neutrality.

An alternative PBS approach where builders operate on a separate, parallel network (e.g., a rollup) with its own execution and data availability layer.

• Concept: The builder network produces block "fragments" which are then committed to the main chain.
• Advantage: Decouples builder resource requirements (high) from validator requirements (low), potentially reducing hardware centralization pressures.

A centralizing component in current PBS that acts as an intermediary to prevent proposer cheating. Relays receive blocks from builders and forward only the header to proposers, releasing the full block after a valid signature.

• Function: Prevents block theft (proposer taking the block without paying) and validates builder work.
• Risk: Concentrates power; a malicious relay could censor blocks. This is a key motivation for moving to enshrined PBS.

The long-term, protocol-native implementation of Proposer-Builder Separation. Unlike MEV-Boost, it is baked directly into Ethereum's consensus rules, eliminating trust assumptions in relays. Core mechanisms include:

• Builder Commitments: Builders cryptographically commit to a block header before revealing the full block body.
• In-protocol Payments: A crList (censorship resistance list) allows proposers to force inclusion of transactions, mitigating censorship.

A specialized node operator that constructs execution payloads (blocks) by aggregating transactions and MEV opportunities. Builders compete in an auction by submitting bids (the value they will pay to the proposer) for their block. Their role is to:

• Maximize block value through arbitrage, liquidations, and DEX trades.
• Create payloads that are valid and profitable for the winning proposer.

A trusted intermediary in the MEV-Boost ecosystem that facilitates the block auction. Relays receive block bids from builders and forward the highest-value, valid header to the proposer. Their critical functions are:

• Bid Aggregation: Hosting the auction marketplace.
• Data Availability: Ensuring the full block body is available after the header is proposed.
• Censorship Resistance: Some relays implement policies to mitigate transaction censorship.

The total value that can be extracted from block production beyond standard block rewards and gas fees. PBS is designed to democratize access to MEV and mitigate its negative externalities. Common forms include:

• Arbitrage: Profiting from price differences across DEXs.
• Liquidations: Executing undercollateralized loans.
• Sandwich Attacks: Frontrunning and backrunning user transactions.

Ethereum's post-Merge architecture, which PBS explicitly bridges. Understanding this split is key:

• Consensus Layer (CL): Manages the beacon chain and validators. Proposers operate here, responsible for block proposal and attestation.
• Execution Layer (EL): Manages transaction execution and state via the EVM. Builders operate here, constructing the contents of a block. PBS cleanly separates these responsibilities.