PBS Auction

PBS splits the traditional validator role into two distinct entities:

• Proposer: A validator selected to propose a new block. They are responsible for selecting the most profitable block from a market of builders.
• Builder: A specialized actor that constructs execution payloads (blocks) by aggregating transactions from the mempool and MEV opportunities. This separation prevents validators from being forced to run complex, resource-intensive MEV extraction software.

The core of PBS is a commit-reveal auction for block space. Builders compete by submitting sealed bids to the proposer.

• Commit Phase: Builders send a cryptographic commitment (e.g., a hash) of their block and a bid.
• Reveal Phase: The winning builder reveals the full block content. The proposer selects the block with the highest bid, which is paid directly to them, maximizing their rewards from MEV.

A primary goal of PBS is to mitigate transaction censorship. By creating a competitive market of builders, it reduces a single validator's ability to exclude transactions.

• Credible Commitment: The builder's bid acts as a bond, credibly committing them to include the promised transactions.
• Builder Diversity: Multiple independent builders reduce reliance on any single entity, making widespread censorship economically irrational and difficult to coordinate.

PBS formalizes and transparently redistributes Maximal Extractable Value (MEV).

• Efficiency: Specialized builders can more efficiently capture MEV (e.g., through arbitrage, liquidations) than general validators.
• Proposer Reward: Captured MEV is converted into a direct payment (the bid) to the proposer, making MEV rewards more predictable and fair across the validator set. This reduces the incentive for validators to run predatory MEV strategies themselves.

PBS can be implemented in two ways:

• In-Protocol PBS (ePBS): The auction logic is enforced by the consensus layer protocol itself (e.g., via a new message type). This is the long-term goal for maximal security and liveness guarantees.
• Out-of-Protocol PBS: The current interim solution, where the auction is facilitated by a trusted relay. The relay receives blocks from builders and bids from proposers, managing the commit-reveal process off-chain before delivering the winning block to the proposer.

A relay is a trusted intermediary in the PBS auction that receives full blocks from builders and delivers only block headers (with associated bids) to proposers.

• Critical Functions:
  • Privacy: Prevents proposers from stealing block contents.
  • Attestation: Ensures the builder's block is valid before the header is signed.
  • Censorship Resistance: A decentralized relay network is vital for preventing transaction censorship.
• Examples: Flashbots Relay, BloXroute, Ultra Sound Relay.

Enshrined PBS refers to the potential future integration of proposer-builder separation directly into the Ethereum protocol's consensus layer, as opposed to the current outsourced middleware model.

• Goals:
  • Eliminate trust assumptions in relays.
  • Further decentralize block building.
  • Provide stronger anti-censorship guarantees.
• Designs: Research includes two-slot PBS and list-based PBS, which are part of Ethereum's long-term roadmap post-Cancun/Deneb upgrades.

PBS fundamentally changes validator revenue streams by creating a transparent auction for block space.

• Revenue Source: Validators earn priority fees (tips) and MEV rewards via the builder's winning bid, which are paid directly to the proposer.
• Efficiency: Allows validators to capture MEV without needing sophisticated infrastructure.
• Stability: Creates a more predictable and competitive market for block production, smoothing reward variance.

PBS interacts with and enables several other critical crypto-economic primitives.

• MEV (Maximal Extractable Value): The economic value PBS auctions are designed to manage.
• CR Lists (Censorship Resistance): A mechanism where proposers can force inclusion of transactions to prevent censorship.
• Block Building APIs (Builder API): The standard interface (e.g., Ethereum Builder API) that builders use to submit blocks to relays.
• SUAVE (Single Unifying Auction for Value Expression): A Flashbots initiative for a decentralized block building network.

The economic efficiency of PBS can lead to a small number of dominant block builders, creating a new centralization point. This concentration risks:

• Collusion: Builders could coordinate to exclude transactions or manipulate MEV extraction.
• Single Point of Failure: The failure or malicious action of a major builder could significantly disrupt block production.
• Gatekeeping: A builder cartel could impose high fees or arbitrary rules on transaction inclusion.

Validators must trust the relay to faithfully deliver the builder's block header and body. Key risks include:

• Header-Withholding Attacks: A malicious relay could send a valid header but withhold the corresponding block body, causing the validator to propose an empty block.
• Censorship: Relays could filter transactions based on origin or content, violating neutrality.
• Data Availability: Ensuring the relay actually has and will transmit the full block data is critical; this is partially mitigated by data availability sampling in danksharding designs.

The widespread use of MEV-Boost, an in-practice PBS implementation, introduces systemic risks:

• Relay Reliability: Validators depend on a small set of public relays. If all trusted relays go offline, validators may miss proposals.
• Builder Manipulation: Sophisticated builders can use time-bandit attacks to reorg chains if they discover more profitable MEV, undermining chain finality.
• Soft Consensus: The network relies on social consensus and client software to blacklist malicious relays or builders, an out-of-protocol failure mode.

PBS creates new economic incentives that can compromise validator behavior:

• MEV Theft: A dishonest validator could accept a builder's payment, then sign a different, more profitable block (a sabotage attack), though this is penalized.
• Bid Visibility: In open auctions, builders see each other's bids, which can lead to bid sniping or collusion.
• Payment Assurance: Validators must trust the builder's payment (e.g., via a trusted payment channel or conditional transaction) will be included and executed.

Future enshrined PBS, where the separation is baked into the consensus protocol, aims to mitigate trust but has its own design challenges:

• Complexity: Adding auction logic to the core protocol increases attack surface and implementation bugs.
• Builder Collusion at L1: Malicious builders could theoretically execute balancing attacks to split the chain if they control a large portion of block space.
• Censorship Resistance: The protocol must include mechanisms (like crLists) to force inclusion of censored transactions, which adds complexity.

The ecosystem is developing standards and tools to counter PBS risks:

• Relay Diversity: Validators should connect to multiple relays to avoid single points of failure.
• Monitoring: Use tools to track relay uptime, builder dominance, and censorship metrics.
• Reputation Systems: Decentralized reputation for builders and relays can discourage malicious behavior.
• Protocol Solutions: EIP-7547 (Inclusion Lists) and PBS with CR (Censorship Resistance) are proposed to enforce transaction inclusion rights.