Why We Should Hold Off on EIP-7732 for Now: No Urgency, Better Alternatives Exist

Source: The case against EIP-7732 for Glamsterdam - blog.sigmaprime.io

EIP-7732 proposes enshrining proposer-builder separation (PBS), aiming to improve scaling by giving stakers more time to handle execution payloads. However, there’s no pressing need to adopt this EIP immediately. Existing solutions like MEV-Boost are effective, and the main scaling benefits can be realized without the complexities of trustless payment systems that EIP-7732 introduces.

Criteria for adopting an EIP

Before including an Ethereum Improvement Proposal (EIP) in a network upgrade, the following must be true:

• It is time-sensitive and urgent to implement in the upcoming fork.
• There are no better or simpler alternatives available.
• It provides clear, necessary improvements.

EIP-7732 arguably doesn't meet these conditions right now.

Why there is no rush to enshrine PBS

MEV-Boost is stable

MEV-Boost, which enables proposer-builder separation, performs reliably with very few issues that have not materially affected the network. These rare incidents have not been resolved specifically by ePBS (encrypted PBS), so they don’t justify immediate changes.

Main scaling benefits achievable without trustless payments

EIP-7732’s key scaling features - slot restructuring and payload decoupling - could be implemented without locking in a specific trustless payment system or introducing complex new roles, like dedicated builders.

Even if a new mechanism is needed, these changes might not be required right away, given Ethereum's current capacity.

Understanding the scaling goals

EIP-7732 aims to:

• Give stakers more time to verify execution payloads
• Allow more time to propagate execution payloads through the network

Currently, block processing within a 4-second slot has tight constraints - especially for validators with slower network or hardware capabilities. Maximizing proposer revenue means committing payloads late, cutting into attestation time. Validators that can’t keep pace lose rewards.

Goal: Ensure most stakers (meeting minimum specs) can process blocks on time, even as blocks grow larger and more resource-intensive.

However, resources required vary substantially. Scaling depends on the worst-case block processing time, so minimizing this variance is key before pushing new slot structures.

Delayed Execution: More time to validate payloads

Instead of executing and validating a block during its slot, EIP-7732 contemplates attesting to a block’s payload availability at slot _N_ and its validity at slot _N + 1_. This “delayed execution” extends validation time, potentially allowing:

• 3 seconds to propagate a full block
• 8 to 12 extra seconds to validate payloads

This can triple the max block size and multiply gas limits several times.

Note: Different implementations of delayed execution exist (like EIP-7732 and EIP-7886).

Payload Decoupling: Separating consensus from execution

Payload decoupling removes the need for attesters to get the full payload before attestiation. Instead:

• Attesters focus on consensus block availability and validity.
• A separate group (“payload timeliness committee”) manages execution payload verification.

This could extend payload receipt times from 3 seconds to much longer, helping with scale.

However, it's unclear if this adds net benefit since the ratio of propagation to validation time matters. Research in data availability sampling (PeerDAS) and how blob data is handled influences this.

Why ePBS is still experimental

Research on encrypted proposer-builder separation (ePBS) has progressed over 3 years, covering:

• Slot auctions
• Payment systems at the execution layer
• MEV Burn integration

All remain under active exploration. Committing prematurely risks locking in suboptimal designs and reducing future flexibility.

Capital barrier: Staked-builder requirement

EIP-7732 requires builders to stake capital, enhancing accountability but also raising entry barriers. This could further centralize an already concentrated market.

Alternatives exist that avoid this staked builder requirement, offering more openness.

Final thoughts

• EIP-7732 is a strong and mature proposal for enshrined proposer-builder separation.
• If the community faces urgent scaling needs, EIP-7732 could be prioritized for Glamsterdam.
• However, there’s currently no urgent need to enshrine PBS when the network is stable, and similar scaling improvements could be achieved without premature commitment to trustless payments.
• Ongoing work on slot auctions, payments, and MEV Burn integration encourages patience to maintain design freedom.