What stakeholder category do you represent?
L2s, The following feedback reflects the views of the Base team.
What do you view as the top priority theme in this fork & why?
We believe scaling the L1 is the top priority for Glamsterdam because it’s the foundation for onboarding the world to Ethereum. A more scalable L1 lowers costs, increases capacity, and improves reliability for both direct users and L2s. This not only unlocks the full potential of rollups but also ensures Ethereum can serve as the global settlement layer for millions of applications and billions of users.
Which EIP(s) do you favor as a headliner for Glamsterdam?
Edit: We acknowledge that ePBS is the competitive slot restructuring EIP to Delayed Execution in Glamsterdam, and that’s why we list them in different tiers signaling our preference to EIP-7886 Delayed Execution. It can be read as
Option A (our preference): Delayed Execution
Option B: ePBS + BAL
If known, what specific impacts would this have on your community?
-
Delayed execution -
- Scaling L1 and blobs: Delayed execution decouples execution from block building, allowing larger blocks and more blobs. It improves throughput and resource efficiency, enabling Ethereum to scale without overloading validators.
- Directly Applicable to L2s: L2s benefit even more from this decoupling. Removing execution from the critical path allows us to reduce buffer times (e.g. for flashblocks), enabling faster blocks and improved decentralization of infrastructure.
- Fast Preconfirmations: By deferring execution, transaction ordering can be committed quickly—unlocking low-latency UX and composability across both L1 and L2.
-
ePBS - Our community would benefit from the improvements ePBS would make to bandwidth bottlenecks at the CL. This EIP closely aligns with our goal to scale blobs on the L1 and should keep DA costs low for L2 users.
-
Block-level Access Lists - We see the parallelism this proposal enables as high impact on both the L1 and L2 execution performance. For us at the L2 level, this would massively improve the execution performance of non-sequencing nodes and enable pipelined disk access and execution.
Does anything make this an urgent feature for you or your community?
Yes—delayed execution is urgent for realizing the full potential of PeerDAS. By reducing execution time constraints and giving more time to propagate blobs, it allows for higher blob throughput, which is a critical next step for scaling Ethereum’s data availability layer. It also significantly improves user experience with fast preconfirmations and enhances L2 scaling.
The leading headliners among client teams are described in a [series of blog posts listed here]
- Reduce Block Latency to 6s
- While we support faster slot times in the long term for better UX, we are concerned about the risks of shipping this in Glamsterdam. Specifically, the reduced time budget intensifies existing consensus overhead, which could negatively impact scaling in the short term. We agree with the view that slot restructuring should precede slot shortening.