How to Architect a Proposer-Builder Separation (PBS) System

In a traditional proof-of-stake blockchain, a validator is responsible for both constructing a block of transactions and proposing it to the network. Proposer-Builder Separation (PBS) splits this role into two distinct entities: the block builder and the block proposer. The builder specializes in creating the most profitable or desirable block content via a competitive auction, while the proposer (a validator) simply selects the highest-bidding builder's payload. This separation is fundamental to mitigating centralization risks and maximal extractable value (MEV) concerns.

The core mechanism enabling PBS is a trust-minimized auction. Builders create ExecutionPayload objects—complete blocks with transactions and associated fees—and submit bids to a public mempool or a relay. Proposers then receive these blinded bids and commit to the header of the highest-value block without seeing its contents, a process known as commit-reveal. This prevents proposers from stealing profitable transaction orderings. The winning builder's full block is only revealed after the proposer's commitment is finalized on-chain, enforced by cryptographic commitments and slashing conditions.

Implementing PBS requires specific protocol changes. On the consensus layer, Ethereum's beacon chain introduces a new message, BuilderBid, and a transaction type, SignedBuilderBid. The execution client must be able to validate and execute the received ExecutionPayload. A critical off-chain component is the relay, which acts as a mediator to receive builder bids, validate them (e.g., ensuring fee recipient is correct, block is valid), and forward them to proposers. Relays must be run by reputable entities to ensure liveness and censorship resistance, though their role is being minimized in future designs like enshrined PBS.

For developers, interacting with PBS involves understanding new APIs. Builders use the builder API (specified in Ethereum's Builder API repository) to submit bids to relays. Proposers configure their validator clients to connect to one or more trusted relays using the Engine API's engine_getPayload endpoint for the blinded block flow. Code for a simple builder might fetch transactions from a mempool, simulate a block, calculate its value, and submit a signed bid via HTTP POST to a relay's /relay/v1/builder/blocks endpoint.

The long-term vision for PBS is enshrinement, where the auction mechanism is moved directly into the core protocol. This would eliminate reliance on off-chain relays, further decentralizing the process. Current research, such as MEV-Boost (an interim, off-chain implementation), provides a practical sandbox. Understanding PBS architecture is essential for anyone working on validator operations, MEV strategies, or the future development of Ethereum's protocol layer, as it redefines the economic and security model of block production.

Proposer-Builder Separation (PBS) is a design paradigm that decouples the roles of block proposer and block builder in a blockchain's consensus layer. The proposer is responsible for selecting and proposing the next block header, while the builder assembles the block's full contents, including transactions. This separation is critical for mitigating Maximal Extractable Value (MEV) centralization risks and enabling specialized, competitive block-building markets. Ethereum's transition to a PBS model, facilitated by mev-boost middleware, is the canonical example of this architecture in production.

Architecting a PBS system requires understanding three core components. First, the Relay acts as a trusted intermediary that receives blocks from builders and forwards them to proposers, often providing attestations about block validity and payment. Second, the Builder is a specialized node that constructs blocks by optimizing transaction ordering for fee revenue and MEV, submitting sealed bids to relays. Third, the Proposer (often a validator client) receives block headers from the relay via an external builder API, signs the most profitable header, and commits it to the chain.

The communication between these components relies on a specific API schema. Builders submit blocks to relays via builder_submitBlindedBlock, containing a BlindedBeaconBlock—a block where transaction bodies are replaced by commitments. Proposers fetch execution payload headers from relays using builder_getHeader. Upon selecting a header, the proposer signs it and sends it back via builder_proposeBlindedBlock. This flow ensures the proposer never sees the full transaction list, preventing them from stealing MEV strategies. You can review the full specification in the Ethereum Builder API documentation.

Implementing a builder requires sophisticated transaction sourcing and simulation. A competitive builder must connect to a mempool (like the Flashbots protected mempool or a public p2p network), simulate potential bundles of transactions to estimate profitability, and construct a block that maximizes total value for the bid. This involves solving a complex optimization problem under gas and state constraints. Builders often use private transaction pools and advanced algorithms like PGA (Priority Gas Auctions) simulation to outbid competitors.

Security and trust assumptions are paramount in PBS design. The system introduces new trust vectors: proposers must trust the relay not to censor them or provide invalid headers, and builders must trust the relay to deliver their bids faithfully and not steal their MEV strategies. Distributed relay networks and cryptographic attestations (like digital signatures on payloads) are architectural patterns used to mitigate these risks. Furthermore, in-protocol PBS (ePBS) is an active area of research to embed these guarantees directly into the consensus protocol, reducing reliance on off-chain trust.

To start architecting, you will need a deep understanding of your blockchain's consensus client (e.g., Prysm, Lighthouse), execution client (e.g., Geth, Nethermind), and the Builder API. Development typically involves extending a consensus client to support the external builder API and potentially operating or integrating with a relay. Testing should be done on a devnet using tools like the Ethereum Holesky testnet and local relay implementations to validate the entire proposal flow before mainnet deployment.

At its heart, PBS introduces a market for block space. The proposer (typically a validator) is responsible for proposing a new block to the network but outsources the task of constructing it. The builder is a specialized entity that assembles a block's contents—transactions, MEV opportunities, and ordering—into an execution payload. The builder submits this payload, along with a payment to the proposer, in a sealed-bid auction. This separation allows validators to remain simple and neutral while enabling sophisticated, competitive block building.

Architecting a PBS system requires implementing three key communication flows. First, builders must subscribe to a relay to receive transaction flow and submit their block bids. The relay acts as a trusted intermediary, receiving sealed bids from builders and forwarding the most profitable one to the proposer. Second, the proposer's client software must be modified to connect to a relay, receive a list of header bids, and select the one with the highest attached payment. Finally, the chosen builder's full block body is revealed and published to the network upon the proposer's commitment.

The primary implementation pattern today is MEV-Boost, an out-of-protocol PBS middleware for Ethereum consensus clients. A validator runs MEV-Boost alongside its beacon node and validator client. MEV-Boost connects to multiple external relays (like Flashbots, BloXroute, and Agnostic), auctions the block-building right, and delivers the winning header to the validator for signing. This keeps the core protocol simple while enabling an active builder market. The architectural diagram involves your validator client, your beacon node, the MEV-Boost service, and several relay endpoints.

Critical design considerations include trust assumptions and censorship resistance. Proposers must trust that the relay will correctly reveal the full block body corresponding to the winning header—a failure here results in a missed block proposal. To mitigate this, proposers should connect to multiple reputable relays. Furthermore, the system should be designed to respect cr lists (censorship resistance lists), where validators can specify transactions that must be included if possible, ensuring basic network liveness and resisting transaction censorship by builders.

For builders, the architecture centers on a high-performance block-building engine. This involves receiving a mempool stream, running local simulation to extract MEV via arbitrage or liquidations, and optimizing the transaction order for maximum fee revenue. Builders often use specialized software like Flashbots SUAVE or custom solvers. The built block is then signed and submitted as a sealed bid to relays. Builder profitability depends on low-latency infrastructure, sophisticated transaction simulation, and access to exclusive order flow.

Looking forward, the endgame for PBS is in-protocol PBS (ePBS), where the auction mechanism is baked directly into the Ethereum protocol. Proposals like ePBS with a builder circuit aim to reduce trust in relays by using cryptographic commitments and slashing conditions. When architecting systems today, it's prudent to design with this evolution in mind, ensuring client APIs and interfaces are adaptable for a smoother transition from an out-of-protocol to an in-protocol PBS future.

Proposer-Builder Separation (PBS) is a design paradigm that decouples the roles of block proposers (validators) and block builders (specialized entities) in proof-of-stake blockchains like Ethereum. Its primary goals are to mitigate Maximal Extractable Value (MEV) centralization risks and to democratize access to block production. In a PBS flow, builders compete in a marketplace to construct the most valuable block by including transactions and MEV bundles. The winning builder's block is then proposed by a validator. This architecture requires designing several key components: a builder client that constructs blocks, a relay that hosts a trusted marketplace, and a validator client modified to outsource block building.

The builder is the core engine of the system. Its primary function is to receive transactions from the public mempool and private order flows, then use a local execution client (like Geth or Erigon) to simulate and construct a block that maximizes fee revenue. Builders often implement sophisticated strategies for MEV extraction, such as arbitrage and liquidation bundling. A critical technical challenge is ensuring the builder's proposed block is valid. This requires the builder to run a full execution client to simulate the block's state transitions and generate a valid execution payload. The builder signs this payload and submits it, along with a fee bid, to a relay.

The relay acts as a trusted, neutral intermediary between builders and proposers. It receives sealed block bids from multiple builders, validates them, and hosts an auction. A common implementation is the mev-boost relay software, which uses a simple HTTP API. Builders submit bids to /relay/v1/builder/header and /relay/v1/builder/blinded_blocks. The relay's crucial duties include payload validation—checking the block's correctness and the builder's signature—and censorship resistance—ensuring all valid bids are considered. After selecting the highest-value bid, the relay delivers a blinded block (a block header without the transaction body) to the proposer.

On the proposer (validator) side, integration requires modifying the consensus client (e.g., Prysm, Lighthouse). Instead of building a block locally, the client requests a blinded block header from connected relays via the Builder API. It selects the header with the highest attached bid, signs it, and returns the signature to the relay. The relay then reveals the full block payload to the proposer, who publishes it to the network. This two-step process ensures the proposer cannot steal the builder's transaction order. Validators typically configure their clients with a list of trusted relay URLs, such as https://0xac6e77dfe25ecd6110b8e780608cce0dab71fdd5ebea22a16c0205200f2f8e2e3ad3b71d3499c54ad14d6c21b41a37ae@boost-relay.flashbots.net.

Implementing a basic builder involves setting up an execution client, a builder client like mev-boost or a custom solution, and connecting to a relay network. A minimal builder service in Go might listen for transactions and construct a block template. Key steps include initializing an execution engine API connection (using the Engine API), adding transactions from the mempool, simulating the block's gas usage and state changes, and finally creating and signing the ExecutionPayload. The signed payload is then submitted to the relay. Builders must handle errors gracefully, particularly around payload simulation failures and relay communication timeouts.

Architecting a PBS system introduces significant considerations. Trust assumptions are centralized in the relay, making relay decentralization a active area of research (e.g., PBS with enshrined proposers). Builder reputation systems are emerging to penalize builders who submit invalid blocks. Furthermore, the upcoming EIP-4844 (Proto-Danksharding) will require builders to also handle large blob transactions. Successful PBS architecture balances performance for high-frequency bidding with robustness to ensure consistent, censorship-resistant block production for the network.

Proposer-Builder Separation (PBS) is a design pattern that decouples the roles of block building and block proposing in proof-of-stake blockchains like Ethereum. In this model, specialized actors called builders compete to construct the most valuable block, while validators (proposers) simply select and attest to the best block they see. The relay is the critical, neutral middleware that facilitates this auction. It receives blocks from builders, validates them, and presents them to proposers, all while ensuring the process is fair and verifiable. A trust-minimized relay is essential for the system's security and liveness.

The core architectural challenge is preventing the relay from becoming a centralized point of failure or censorship. A naive implementation where the relay sees the full block content creates a trusted third party. The solution is to use cryptographic commitments. Builders submit a block header and a commitment to the full block body (e.g., a Merkle root of transactions) to the relay. The relay runs a sealed-bid auction, where proposers see only the header and the associated bid. After a proposer selects a winning header, the corresponding full block is revealed. This ensures the relay cannot censor or manipulate the content of a bid after it has been accepted.

Implementing this requires careful state management. The relay must maintain an in-memory or fast database mapping block_hash to the encrypted or committed block data during the auction phase. Upon selection, the builder must provide the decryption key or the full data for the relay to verify it against the commitment. Data availability is critical; the relay must ensure the full block is published to the network after the auction concludes. Failure to do so results in a slashable offense for the builder, enforced by the underlying consensus layer. Code for commitment verification might look like:

solidityCopy
function verifyBlockCommitment(bytes32 blockHash, bytes calldata blockData, bytes32 commitment) public pure returns (bool) {
    return keccak256(blockData) == commitment && keccak256(blockData) == blockHash;
}

To further minimize trust, the relay's operations should be verifiable. This can be achieved by having the relay publish all received bid commitments and the auction outcome to a smart contract or a public data availability layer. This creates a public record that anyone can audit to prove the relay executed the auction correctly and did not exclude valid bids. Projects like the Ethereum Builder API specification and mev-boost provide real-world references for these interfaces. The relay's code should be open-source, and its critical logic could be embedded in a verifiable delay function (VDF) or a trusted execution environment (TEE) to provide cryptographic guarantees of correct execution, though these add complexity.

Finally, the relay must be designed for liveness and robustness. It needs high availability to receive builder submissions and serve proposers. A distributed architecture with multiple redundant nodes, load balancing, and DDoS protection is necessary. The economic design should also incentivize honest participation; relay operators might charge a small fee from the builder's bid, aligning their incentive with maximizing bid flow. By combining cryptographic commitments, verifiable operation logs, and a robust infrastructure, you can architect a relay that enables efficient block building markets while upholding the decentralized values of the underlying blockchain.

Proposer-Builder Separation (PBS) is a critical protocol upgrade designed to decentralize Ethereum block production. It separates the roles of block proposer (a validator) and block builder (a specialized entity), mitigating centralization risks like MEV extraction dominance. In a PBS architecture, the proposer's role is simplified to selecting the most valuable block from a competitive, open market of builders. This guide outlines the key components required to architect a PBS system: the Validator Client, the Builder, and the Relay, which acts as a trusted intermediary to prevent abuse.

The core of the integration lies in the validator client setup. Modern clients like Lighthouse, Teku, and Prysm support PBS through the builder API. To participate, a validator must configure its client to connect to one or more relays. This is typically done by setting the --builder or --suggested-fee-recipient flags to enable external block proposal. The client will then query connected relays for block headers during each slot, comparing the value of the builder's block against a locally constructed one, always choosing the most profitable option for the validator.

Builders are sophisticated systems that construct full blocks by aggregating transactions and MEV opportunities from searchers. They submit block bids—containing the block header, execution payload, and a fee—to relays. Architecting a builder requires a high-performance execution client (like Geth or Erigon), an MEV-boost relay compatibility layer, and strategy software (e.g., mev-geth). Builders must optimize for gas efficiency and maximum extractable value (MEV) to win auctions. They communicate with relays via a standardized JSON-RPC API, submitting sealed bids for specific slots.

Relays are the trust-minimized hubs of the PBS ecosystem. They receive blinded block headers from builders and forward them to proposers, while ensuring the builder's execution payload is valid and available. When architecting a system, you must choose which relays to trust. Major relays include Flashbots, BloXroute, and Eden. Validators configure their clients with relay URLs (e.g., https://0xac6e77dfe25ecd6110b8e780608cce0dab71fdd5ebea22a16c0205200f2f8e2e3ad3b71d3499c54ad14d6c21b41a37ae@boost-relay.flashbots.net). It's recommended to use multiple relays to maximize competition and censorship resistance.

Implementation involves specific code changes. For a validator, enabling PBS in Lighthouse requires the --builder flag and a configured suggested_fee_recipient. Builders interact with relays using the eth_sendBundle or eth_callBundle RPC methods. A critical security consideration is block withholding: a malicious relay could censor transactions. To mitigate this, validators should use relays that commit to credible neutrality and open sourcing their code. The system's architecture must also account for network latency, as bid auctions are time-sensitive, typically concluding within the 12-second slot time.

The future of PBS is enshrined proposer-builder separation (ePBS), where the separation logic moves into the consensus layer protocol itself. Current PBS, implemented via mev-boost, is an off-protocol interim solution. When architecting today, design with this evolution in mind. Use modular components that can adapt to protocol changes. Monitor Ethereum Improvement Proposals like EIP-7547 for updates. A well-architected PBS system increases validator rewards, strengthens network decentralization, and prepares your infrastructure for the next phase of Ethereum's development.

Building a robust PBS system requires careful consideration of its core pillars: the relay, the block builder, and the proposer software. The relay must be highly available and resistant to censorship, often implemented as a trusted neutral service with cryptographic attestations. Builders compete in a sealed-bid auction, assembling the most valuable block from the mempool and MEV opportunities. The proposer's client software must securely integrate with these external components, validating block headers and ensuring the received execution payload is valid before signing.

Several architectural decisions present key trade-offs. A trusted relay model simplifies initial implementation but introduces a central point of failure. Alternatives like peer-to-peer PBS or suave aim to decentralize this role. Builder strategy is another critical area; builders must optimize for maximal extractable value (MEV) through arbitrage and liquidation bundling while managing gas efficiency and compliance with OFAC sanctions lists, which can impact block profitability and network neutrality.

Looking forward, PBS is evolving beyond its current enshrined form in Ethereum. Ethereum's EIP-4844 (Proto-Danksharding) will introduce data blobs, requiring builders to efficiently incorporate large amounts of cheap data. MEV-Boost++ and MEV-Share are proposals to refine the auction mechanism and redistribute MEV benefits more broadly. The long-term vision includes fully enshrined PBS at the protocol level, potentially through a builder API integrated directly into the consensus client, eliminating reliance on external relays.

For developers architecting a PBS system today, practical steps include: 1) Using the Builder API specification to ensure compatibility, 2) Implementing or connecting to a relay like the Flashbots Relay or Ultrasound Money Relay, and 3) Thoroughly testing the integration on testnets like Goerli or Holesky. Monitoring metrics like bid inclusion rate, block value, and latency is crucial for optimization.

The future of PBS is tightly coupled with MEV research. Innovations in encrypted mempools, fair ordering protocols, and reputation systems for builders will shape the next generation of block production. As the ecosystem matures, the focus will shift from simply enabling PBS to ensuring it operates in a credibly neutral, efficient, and decentralized manner, preserving Ethereum's core values while scaling its capacity.