TL;DR
We should choose EIP-7732 as our Glamsterdam headliner.
- EIP‑7732 enables foundational slot restructuring, offering higher gas limits and more blobs for the same slot time than any competing proposal
- EIP‑7782, cutting slot time from 12 to 6 seconds, delivers UX improvements but only reduces the overhead fraction from ~⅔ to ~½—leaving scalability ceilings intact
- Hardware ZK provers are already achieving ~10.8 s for 32 M‑gas blocks (sub‑12 s), so full slot restructuring now enables proving within the slot.
- 7732 is far ahead on maturity: specs + PoC branches on two clients
- Payload‑Block Separation uses bandwidth more efficiently & cleanly prevents execution layer problems from cascading into consensus layer instability
Setting the Stage
Since the Beacon Chain genesis in 2020, consensus‑layer core‑developers have shepherded six hard-forks (Altair, Merge, Capella, Deneb, Electra, Fusaka). In five of these upgrades, the “headlining” EIP was obvious long before launch. Electra was the lone exception, and its protracted debate foreshadowed the situation we face today with Glamsterdam.
This time four EIPs plausibly deserve the top spot:
EIP | Title | One-liner |
---|---|---|
EIP-7732 | Enshrined Proposer Builder Separation | Slot Restructuring + Payload-Block Separation |
EIP-7886 | Delayed Execution | Slot Restructuring |
EIP-7782 | Reduce Block Latency | Shorten Slots to 6s |
EIP-7805 | Fork-choice Enforced Inclusion Lists | Fortify Ethereum's Censorship Resistance |
To compare them we map to each of Ethereum's three strategic initiatives announced this spring:
Strategic Initiative | Directly Advanced By |
---|---|
Scale L1 (more block space) | 7732 , 7886 |
Scale L2 (more blobs) | 7732 , 7886 |
Improve UX (lower latencies, seamless interoperability, preconfirmations, faster finality) | 7732 , 7886 , 7782 |
EIP-7805 stands slightly apart: it targets credible neutrality / censorship resistance, one of Ethereum’s core values, but does not by itself advance the three 2025‑2027 initiatives. The broad expectation is that FOCIL will ship — the only question is when.
Why Not Pick the "Greedy" Option (EIP-7782)
If we were to be greedy and simply ask "Which of these EIPs would bring users the most tangible benefit right now?", there is a strong argument that we may end up selecting EIP-7782. Shorter slots lead to faster transaction inclusion, faster finality, and potentially higher throughput.
To understand why we recommend against this greedy approach, we need to take a step back and examine how shorter slots interact with our other goals of scaling both L1 and L2. In the simplest terms, we can split the slot time into two components:
- Block & Blob Broadcast & Execution
- Overhead (Attesting, Aggregation, Calculating the head, etc.)
For any given slot design, the overhead is the work which MUST be done on a per slot basis, and cannot be done in parallel with block broadcast & execution.
The more we scale L1 & L2, the more time we need for Block & Blob Broadcast & Execution. Thus to maximally scale L1 & L2, we must minimize the fraction of slot time spent on overhead. Once overhead is minimized, making the slot shorter harms scalability, because the fixed overhead now consumes a larger share of each slot.
We have not minimized the overhead time yet, so today the overhead fraction stands at 2/3 of the slot. EIP-7782 advocates minimizing the overhead by adjusting attestation/aggregation deadlines, while simultaneously lowering the slot time. The latest estimates would cut the overhead down to 3 seconds. With a slot time of 6 seconds, this is an overhead fraction of 1/2.
While EIP-7782 has a better overhead fraction than today, it still severely limits the degree to which we can scale L1 & L2. This is why there is widespread agreement that we also need some kind of slot restructuring to lower the overhead further.
Some argue that we should choose EIP-7782 for Glamsterdam and do slot restructuring in a future fork. I argue against this because:
- Shortening slots first and restructuring second will take longer to deliver both upgrades because:
- Shortening slots requires careful timing measurements of physical limits of the network. All of these measurements would need to be repeated and recalibrated if we restructure the slot after shortening.
- Slot restructuring allows for even shorter slots than are possible without restructuring. Restructuring after would potentially lead us to want to shorten slots a second time, duplicating even more work.
- Real-time proving is around 12 seconds today. This is decreasing by a factor of two roughly every six months. Delivering slot restructuring in Glamsterdam would make real-time proving viable in Glamsterdam. Shortening slots in Glamsterdam will likely delay this.
- EIP-7782 is less mature; no client has fully implemented it, and there are many downstream effects on infrastructure and tooling that will need to be updated. If we declare our intention to shorten slots for Hstar, we provide time for this.
For these reasons, I believe we must prioritize slot restructuring in Glamsterdam and shorter slots in the following fork.
Slot Restructuring High-Level
There are two contending EIPs for slot restructuring:
For the time being, I will keep this post high-level and simply give a summary of the benefits of each proposal. For a deeper technical discussion of these, see my earlier writing.
Pros | EIP-7732 | EIP-7886 |
---|---|---|
Maximal Pipelining: minimal overhead | ✅ | ❌ |
Existing Full Spec | ✅ | ❌ |
Existing Implementations | ✅ | ❌ |
Payload Block Separation (numerous benefits discussed below) | ✅ | ❌ |
Trustless Builder Payments | ✅ | ❌ |
No Execution Layer Changes | ✅ | ❌ |
No "free" DA Concerns | ✅ | ❌ |
Fastest to Implement | ❌ | ✅ |
Benefits of Payload Block Separation:
- Stability: if there's a problem producing blocks on the L1, Ethereum can continue to finalize. This could happen if a major client has a bug causing it to produce invalid blocks or similarly if a major builder has a bug. Today, if there's a problem with a builder/relay continously producing invalid blocks, eventually the circuit breaker will trip and everyone will revert to local building. As we move more towards full danksharding and real-time proving, local building will become less and less viable and this fallback will not be available. Without separating the payload and consensus block, we are forced to throw out the votes along with invalid execution blocks, causing Ethereum to lose finality. This is a major problem if not addressed quickly.
- Increased Propagation Efficiency: the consensus block without the payload is much smaller and faster to verify leading to faster propagation times. This allows the attestation deadline to be pushed very early towards the start of the slot. For more discussion, see the motivation section of EIP-7898.
- ZK-ification of the execution layer and consensus layer become independent problems.
- See more discussion here
The comparison between these EIPs can be roughly summarized in one sentence:
EIP-7732 requires more code changes than EIP-7886, but it achieves more, and leaves the protocol in a much better place after Glamsterdam.
I believe we should take a longer-term perspective on the protocol and that we should not sacrifice the medium and long-term health of Ethereum for short-term gains. Given that EIP-7732 is also significantly more mature than EIP-7886, it's not clear that we could even deliver EIP-7886 significantly faster.
For these reasons, I believe EIP-7732 should be Glamsterdam's headliner.
Addressing Criticisms
In this section I will dive a bit more into technical details and address the criticisms of this viewpoint, chiefly articulated in Toni Wahrstätter’s design‑trade‑off post. Toni makes a few different arguments, some of which are explicit and others which may or may not be implied but which I will address anyway for completeness and clarity.
- EIP-7732 forces proposers to whitelist builders and this is a cost.
This is no different than today. Proposers today maintain a personal list of relays and they can do the same after 7732. 7732 enables two flavors of relays: relays that custody only bids that they collect from builders, and relays that custody full blocks and operate the same as today, going around the protocol.
- If proposers use the in-protocol mechanism, builders must count attestations to ensure safety
Today, builder safety is achieved via relays waiting until just before the attestation deadline and then propagating the block from several points in the network at once. This statement that builders cannot achieve safety without attestation counting seems to be predicated on the idea that builders would not have access to infrastructure to propagate bids simultaneously and thus they could not achieve the same level of safety without attestation counting. I disagree with this line of reasoning for two reasons. First, it's not clear that builders wouldn't have access to this kind of infrastructure. Even if they don't build it themselves, both forms of relays that listed above are capable of having infrastructure to propagate the bid simultaneously. If relays want to offer this as a service they could and they could help propagate the signed bid whether the proposer uses the relay or not. Second, simultaneous propagation is no longer required for blocks, and works better for bids. A builder with a signed bid in their hand well before the attestation deadline is much safer than a builder with a signed block in their hand well before the attestation deadline. Even if they don't have access to the infrastructure to propagate the signed bid from multiple points simultaneously, they can propagate it earlier and without revealing their block whereas the builder with a signed header must wait until the right time before the deadline and propagate from multiple points simultaneously to ensure safety.
- For proposers, the economic rational choice is going out of protocol
There isn't an explicit explanation here, but this criticism seems to stem from the idea that builders can release blocks earlier without sacrificing safety using an out of protocol mechanism and therefore they can create larger blocks or blocks with more blobs. This was addressed above. Builders can achieve the same or better levels of safety with 7732 even before counting attestations.
- EIP-7732 is bad for preconfirmations unless without sacrificing pipelining
This line of reasoning, and much of the concerns around attestation counting raised above, fails to consider Dual-deadline PTC vote design. This is a simple modification where we simply decouple the blob availability deadline from the block availability deadline. This will enable us to force the builder to relinquish their post-state monopoly while allowing maximal pipelining for blobs. This same mechanism could force the builder to rely on simultaneous bid propagation infrastructure for safety rather than couting attestations.
EIP-7732 eliminates the need for EIP-7886. But the reverse is not true. If we did 7732 later, we will have wasted this hard-fork.
EIP-7886 is certainly less code than EIP-7732 but this does not mean the protocol as a whole is less complex. Separating the consensus and execution blocks is in many ways a more natural design that makes future upgrades easier to reason about given the existing separation between consensus and execution clients.