Highlights from the All Core Developers Execution (ACDE) Call #229

Ethereum core developers used ACDE #229 to transition Glamsterdam from a scoping exercise into a testing & validation phase, with attention shifting toward Devnet readiness, client optimizations & execution repricing. With major Glamsterdam scope decisions largely finalized, discussion centered on Devnet-2 readiness, execution layer optimizations & a new wave of proposals targeting mempools, transaction formats & post-quantum preparedness.

Rather than introducing large new protocol changes, the focus narrowed toward ensuring Ethereum can safely scale without embedding inefficiencies into the system.

• Housekeeping Updates
• Glamsterdam Updates
• New EIPs Introduced
• Hegota Updates

Housekeeping Updates

Three new breakout calls were introduced, each targeting a long-term pressure point for Ethereum.

1. One breakout call will focus on post-quantum transaction signatures, following growing concern that Ethereum’s reliance on ECDSA cannot be left unaddressed indefinitely.
2. Another will center on L1-zkEVM, reflecting continued interest in aligning Ethereum’s base layer with zero-knowledge execution models.
3. A third call will focus exclusively on Glamsterdam repricings, underscoring that execution pricing is now treated as a core design concern rather than a parameter tweak.

Ethereum has entered a phase where work is becoming more parallel, more technical & more execution-driven.

Glamsterdam Updates

Much of the discussion centered on Devnet-2, which is now scheduled to launch in early February. Client teams reported steady progress, with clarifications added to the Devnet documentation to reflect changes made during implementation.

Rather than focusing solely on EIP inclusion, Devnet-2 is being positioned as a measurement environment. Clients are being asked not only to support required features but also to expose feature flags that allow benchmarking with specific optimizations enabled or disabled.

This approach reflects a broader shift in Ethereum development. Instead of relying on theoretical performance assumptions, developers want empirical data before committing to higher gas limits or repricing execution costs.

Block-Level Access Lists (BALs) emerged as one of the most important technical pillars in the current Glamsterdam cycle. While BALs are already part of the agreed scope, the discussion made it clear that basic spec compliance is no longer considered sufficient.

Developers repeatedly emphasized that the real value of BALs lies in the optimizations they enable. Four optimizations were discussed in detail:

1. Parallel execution
2. Batch reads
3. Parallel state root calculation
4. Sync-related optimizations

Among these, batch reads stood out as the most critical unknown. While parallel execution offers predictable performance gains, batch reads directly affect how efficiently clients can handle state access, which is expected to become the dominant bottleneck as throughput increases.

Several client teams reported having already implemented three of the four optimizations, with benchmarking expected to begin shortly. Sync optimizations were treated as more client-specific, but the broader message was consistent: clients that do not implement the core optimizations will struggle to keep up once execution limits increase.

Although no formal rule was adopted, developers broadly agreed that parallel execution, batch reads & parallel state root calculation should be treated as implicit fork readiness requirements.

The discussion on Glamsterdam repricings highlighted why execution pricing cannot be adjusted in isolation. Repricing compute, reads & writes requires a clear understanding of how execution behaves once optimizations are in place.

Without that baseline, repricing risks over-penalizing state access or underestimating achievable throughput. Developers stressed that repricing based on unoptimized clients would lock Ethereum into conservative assumptions that no longer reflect technical reality.

As a result, the repricing effort is explicitly tied to having a stable set of client optimizations available for benchmarking. Timeline pressure was also acknowledged. To allow sufficient testing ahead of interoperability events later in the year, core optimizations need to be in place by the end of February.

Wallet UX was briefly discussed as well. While users will continue to see a single gas field, state-heavy transactions may become more expensive under new pricing models.

Communicating these changes without confusing users remains an open challenge. As attention turns toward future Devnets, developers raised the question of how to prioritize additional work.

The emerging consensus favors deepening execution readiness before adding more EIPs. BAL optimizations were repeatedly cited as higher priority than introducing new protocol changes in the next Devnet iteration.

Some proposals, such as increasing the maximum contract size, were discussed not as feature upgrades but as stress tests to evaluate worst-case execution scenarios. Similarly, the possibility of temporarily raising gas limits in Devnet-2 was framed as an experiment rather than a commitment.

Several EIPs that do not directly change protocol rules sparked detailed discussion about scope & governance.

1. EIP-7610, which proposes reverting contract creation if storage is non-empty, proved particularly contentious. While some clients already enforce similar behavior, others raised concerns about performance overhead & long-term compatibility with future state models. Given the lack of unanimous client agreement, developers opted to keep the proposal under consideration rather than enshrining it as canonical behavior.
2. Two other proposals, EIP-7872 (max blob flag for local builders) & EIP-7949 (genesis file format), were broadly supported in principle but explicitly scoped out of fork-level commitments. Developers agreed that command-line flags & configuration formats should not be dictated by protocol governance, even if standardization remains desirable.

New EIPs Introduced

As execution throughput increases, networking inefficiencies are becoming harder to ignore. Two mempool-related proposals were presented to address emerging bottlenecks.

Source: ACDE-Mempool_Propagation.pdf

1. EIP-8077 proposes enriching transaction announcements with metadata such as sender address & nonce. Today’s hash-only announcements make selective fetching difficult & exacerbate nonce-gap issues under bandwidth constraints. While some developers questioned whether partial metadata is sufficient, the proposal reflects growing recognition that mempools must evolve alongside execution scaling.
2. EIP-8094 targets inefficiencies in blob transaction replacement. Currently, replacing a blob transaction forces the full blob data to be retransmitted, even when only pricing parameters change. Avoiding redundant sidecar transfers could significantly reduce network load as blob usage grows.

Both proposals are exploratory, but they underscore a shared concern, i.e., networking assumptions that worked at lower throughput will not scale indefinitely.

Hegota Updates

The final segment of the discussion focused on headliner proposals for the Hegota upgrade, offering a glimpse into Ethereum’s longer-term direction.

1. One proposal, Universal Enshrined Encrypted Mempool, aims to bring encrypted transactions directly into the protocol. Rather than relying on trusted relays or private RPCs, the design introduces permissionless key providers & defers transaction decryption until after block inclusion. The goal is to reduce front-running while preserving liveness for regular transactions.
2. Another headliner, Frame Transactions, proposes a fundamental restructuring of Ethereum’s transaction model. By separating authentication, execution & fee payment into structured frames, the proposal enables native account abstraction, fee sponsorship & support for post-quantum signature schemes. While adoption concerns remain, proponents argue that Ethereum cannot move away from ECDSA without first changing how transactions are authenticated.
3. The final presentation, SSZ Execution Blocks, addresses growing inefficiencies in Ethereum’s execution data formats. Linear RLP encoding & repeated format conversions are increasingly costly at higher throughput. Moving toward SSZ-native execution payloads could improve performance, enable partial data availability & align execution with newer transaction designs.

Overall, the discussions around ACDE #229 reflected a clear shift in Ethereum’s execution roadmap from expansion to consolidation. With Glamsterdam’s scope largely settled, developer focus has moved toward validating assumptions through Devnet testing, client alignment & execution repricing.

Networking constraints, transaction design & post-quantum readiness are now being examined as scaling necessities rather than future research topics. Together, these efforts signal a cautious but deliberate push to scale Ethereum without hard-coding today’s inefficiencies into tomorrow’s protocol.

If you find any issues in this blog or notice any missing information, please feel free to reach out at yash@etherworld.co for clarifications or updates.

To promote your Web3 articles, events, and projects, you may reach out anytime via EtherWorld PR for submissions and collaboration.

Related Articles

1. Highlights of Ethereum's All Core Devs Meeting (ACDC) #153
2. Highlights of Ethereum's All Core Devs Meeting (ACDE) #207
3. Highlights of Ethereum's All Core Devs Meeting (ACDC) #152
4. Highlights of Ethereum's All Core Devs Meeting (ACDE) #206
5. Highlights of Ethereum's All Core Devs Meeting (ACDE) #205