Why ePBS Splits Block Building from Proposing
ePBS (EIP-7732) splits block building from proposing primarily to eliminate the centralization risks and security vulnerabilities that arise from relying on third-party relays. It also reduces the computational burden on validators. By embedding the block-building process—previously outsourced to Flashbots' MEV-Boost—directly into the Ethereum consensus layer, ePBS enables trustless interaction between proposers and builders.
1. Understanding the Current Situation: Why Is a Split Necessary?
More than 90% of Ethereum blocks are currently built through Flashbots' MEV-Boost, which relies on an off-chain third party—the relay.
Current state: Builders construct blocks by bundling transactions, and relays verify those blocks and forward them to proposers (validators).
The problem: Relays are centralized single points of failure. If a relay goes down or acts maliciously (e.g., by censoring transactions), the entire Ethereum block-building process is affected. Proposers must also trust that relays will honestly forward blocks and pay the promised fees.
ePBS enshrines this entire process into the protocol (the consensus layer), removing the dependency on relays. That is the fundamental reason for the split—turning the interaction between block building and proposing into protocol rules rather than a third-party service.
2. How Does It Work After the Split?
ePBS achieves secure and efficient block production by splitting responsibilities and introducing new mechanisms.
Step 1: Identify Your Role
What to do: Understand the two roles under the ePBS mechanism.
How to do it:
Case A (if you are a validator/proposer): Your role becomes simpler. Instead of handling complex transaction ordering, you only need to receive commitments (bids) from builders, choose one, and broadcast the beacon block.
Case B (if you are a builder): This is an optional subset of validators. You build the execution payload, generate a cryptographic commitment (SignedExecutionPayloadHeader), and send it to the proposer.
Step 2: Understand the "Propose" and "Build" Workflow
What to do: Grasp how a block goes from "empty" to "complete" under ePBS.
How to do it:
Proposer broadcasts an inclusion list: The selected proposer first creates an "inclusion list" that mandates certain transactions must be included in order to resist censorship.
Builder submits a commitment: The builder packs transactions according to the inclusion list, generates a hash of the execution payload and a payment commitment, and sends these to the proposer.
Proposer selects a commitment: The proposer picks the highest-bid commitment, includes it in the beacon block, and broadcasts it. At this point, the proposer only processes the commitment, not the actual transaction data—making the process extremely fast.
When is it considered done?: You recognize that "proposing" and "building" are now separated in time. The proposer finalizes the block header (which contains the commitment) first, and the builder reveals the specific transaction content afterwards.
Step 3: Learn How PTC Ensures Security
What to do: Understand how the protocol prevents builders from taking the reward but failing to deliver the block (i.e., a broken commitment).
How to do it: ePBS introduces the Payload Timeliness Committee (PTC). This is a randomly selected group of validators tasked with monitoring whether the builder publishes the complete execution payload on time.
When is it considered done?: You understand that if a builder fails to disclose the payload on time or provides fraudulent data, the PTC will vote against them and the builder's staked assets will be slashed. This is a trust mechanism automatically enforced by the protocol.
Prerequisites: ePBS (EIP-7732) is currently in the development and testing phase. As of June 2026, core developers are evaluating it on private forks. The mainnet launch date remains uncertain and may be delayed until late 2026. For now, the focus is on understanding and monitoring the proposal.
3. Three Specific Pain Points This Split Addresses
Removes centralized relays: By bringing the Flashbots external service into the protocol, it eliminates the systemic risk of "relay failure prevents block production."
Reduces the validator burden: Validators currently have only 4 seconds to complete both consensus and execution state transitions, which is extremely demanding. ePBS allows validators to handle only the consensus part and delays execution validation to the next block, significantly improving network propagation speed and lowering node hardware requirements.
Prevents builder fraud: Through a "commitment + slashing" mechanism, builders must disclose the block as promised; otherwise, their stake is penalized—no third-party trust required.
Risk warning: Although ePBS aims for decentralization, if the builder market itself is dominated by a few large players, the concentrated nature of block building could persist even after the roles are split at the protocol level. This is a potential systemic risk rather than an operational mistake.
Common Misconceptions
"ePBS will eliminate MEV"—this is incorrect. ePBS does not eliminate MEV; it restructures the distribution rules. It simply moves the logic of "who gets the MEV profits" from off-chain relays into the on-chain protocol. The goal is to make profit distribution more transparent and decentralized, not to make MEV disappear.
After understanding the above, how can you confirm your understanding is correct?
If you are an Ethereum validator, keep an eye on the release notes of clients like Prysm and Lighthouse. When they release a version that supports EIP-7732, that will be your signal to participate in testing or upgrade. If you are a regular user, follow the testing progress of Ethereum's "Glamsterdam" upgrade—when that upgrade is deployed on public testnets like Goerli or Holesky, it means ePBS is getting close to mainnet.
