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

The All Core Developers Execution (ACDE) Call #214 marked a pivotal coordination point for Ethereum’s upcoming Fusaka upgrade and beyond.

With Devnet 2 nearing launch readiness, the call focused on finalizing which EIPs would be included immediately, which ones would be deferred to Devnet 3, and what long-term scalability concerns must be tackled before Ethereum can safely scale to higher gas limits like 60M or 100M.

Developers also initiated early previews of potential headliner proposals for the Glamsterdam fork, covering deep infrastructural changes such as trustless log indexing and RPC security enhancements.

• Gas Limit Benchmarking
• Fusaka Devnet 2 Vs Fusaka Devnet 3
• Expected Proposals in Glamsterdam Fork

Gas Limit Benchmarking

The core objective of was to evaluate how well Ethereum’s execution clients can handle a proposed increase in block gas limits, specifically aiming for a milestone of 45 million gas per block as part of the Fusaka upgrade. This evaluation was based on extensive testing conducted during the Berlin Interop (Berlinterop) event, where performance metrics were captured under high-compute stress.

The benchmarking was structured around three core pillars:

1. OPCODE/Precompile Benchmarking
2. State Growth Benchmarking
3. Security Risk Profiling

Notably, RPC benchmarks were omitted during this phase but are slated for integration in the coming weeks.

Within the OPCODE scope, functions like ECRecover, Blake2f, Datacopy, MSTORE, and BLS precompiles were tested and found to pose no issues at all. Clients also successfully optimized heavy operations like BN256Add, BN256Pairing, and BN256Mul, removing them as potential blockers.

From the benchmark data:

• Without modEXP, all clients comfortably exceeded 20 million gas, with significantly lower worst-case block times by the end of the week.

• With modEXP, clients still showed healthy performance improvements, though some lag persisted. This is expected to be addressed either by EIP-7883 (modexp repricing) or by continued optimization of modexp implementations in clients.

As of now, there are no blockers for 45 million gas. However, advancing toward 60M or 100M gas per block will require further technical milestones.These include state trie optimizations (especially with SSTORE), reevaluating devp2p limits for receipts (future EIP pending), conducting state sync stress tests, and developing RPC benchmarking tools to measure performance at scale (e.g., under 100M gas loads).

Throughout the session, there was strong support from client teams regarding the 45M gas increase. No clients raised serious objections, and consensus emerged that the network could safely transition to this limit once a few remaining performance patches are deployed.

Importantly, the Ethereum core developers have taken a phased approach: greenlighting 45M first, while preparing for long-term 60M and 100M thresholds with clear deliverables and testing goals.

The decision to implement the gas limit increase will proceed only after all clients complete their targeted improvements and are validated under a shared set of test conditions. Future roadmap priorities include:

1. RPC benchmarking tools, with support from infrastructure providers like Quicknode & Alchemy.
2. Lockstep sync analysis, to determine how long the EL can remain inactive before CL catch-up fails.
3. Engine API overhead reduction, a technical debt item flagged by fjl.
4. And a more robust modeling of execution time ceilings per block based on large state access patterns.

These issues don’t block 45M but are essential stepping stones toward Ethereum’s broader scalability ambitions under Fusaka and beyond.

Fusaka Devnet 2 Vs Fusaka Devnet 3

With Devnet 2 just around the corner, developers made crucial inclusion decisions and drew clear boundaries between what goes into Devnet 2 versus what will be deferred to Devnet 3.

The following EIPs were approved for immediate inclusion in Devnet 2.

1. EIP- 7951: Precompile for secp256r1 Curve Support: Enables precompiled operations for R1 curve. Will be included with existing gas pricing for now, pending benchmarking in Devnet 3.
2. EIP-7907: Meter Contract Code Size And Increase Limit: Introduces dynamic gas costs for contracts larger than 24KB. The original version is included in Devnet 2, but a capped 48KB version is targeted for Devnet 3.
3. EIP-7934: RLP Execution Block Size Limit: Adds a limit to read-protected execution block sizes to reduce DoS risk. No objections, approved directly.
4. EIP-7939: Count leading zeros (CLZ) opcode: A compact opcode for bitwise operations. Although it bypassed formal process, client consensus allowed fast-tracking into Fusaka.

Certain proposals were either not fully ready or required more testing and consensus. These have been deferred to Devnet 3, which is now officially planned.

1. EIP- 7951: Precompile for secp256r1 Curve Support: The precompile’s gas pricing will be re-evaluated and possibly adjusted after more benchmarks.
2. EIP-7907: Meter Contract Code Size And Increase Limit: A more implementation-friendly version of EIP-7907, with a 48KB cap, will replace the original in Devnet 3.
3. EIP-7918: Blob base fee bounded by execution cost: This EIP addresses an issue with the dynamic pricing auction used to set the blob base fee, which can fail when the fee is a small fraction of the total cost. This proposal introduces a reserve price for blobs, ensuring that blob consumers pay a relevant fraction of the market rate for compute resources. It links the blob base fee to execution gas costs, preventing it from dropping too low and ensuring proper fee market function. The proposal also considers future blob scaling and income potential, setting a sustainable reserve price.
4. EIP-7892: Blob Parameter Only Hardforks: The maximum blob count per transaction will be fixed at 6 and moved from the BPO config into a protocol constant.
5. EIP-7975: ETH/70 - Partial Block Receipt Lists: Although not a protocol change, this client-side fix for sync scalability is intended to ship alongside Fusaka client releases.

The goal is to launch Devnet 2 on the Monday following the call.

• At least 3 Execution Layer (EL) and 3 Consensus Layer (CL) clients must be ready.
• If this threshold isn’t met, the launch will be pushed by one day and reassessed daily.
• The Nevermind client will not be ready for day-one but will join soon after.

Devnet 2 will proceed with a minimal, stable feature set, while Devnet 3 will carry forward the refined versions of the proposals, including updated gas pricing, capped code size limits, and blob fee logic.

Expected Proposals in Glamsterdam Fork

The Ethereum All Core Developers Execution Call #214 concluded with two new proposals potentially bound for the Glamsterdam fork.

(I) EIP-7745: Trustless Log Query Index

This proposal introduces a new system for trustlessly querying Ethereum logs, eliminating reliance on centralized RPCs or opaque indexing services.

Currently, Ethereum logs are stored in a linear format, making historical searches over 10+ years slow and resource-intensive. Users must either trust third-party indexers (e.g., Alchemy or Infura) or process massive datasets themselves.

There is also no way to cryptographically prove inclusion or exclusion of logs in a given block.

EIP-7745 introduces a probabilistic, tree-hashed log indexing system designed to replace Ethereum’s legacy Bloom filters. This innovative structure utilizes sparse two-dimensional bitmaps, which are specifically optimized for both memory efficiency and access speed.

The system is capable of generating Merkle proofs that can verify not only the presence of a log event but also its absence, providing cryptographic assurance either way.

One of the standout advantages of this indexing method is its ability to maintain a constant false positive rate, even as network gas limits or log volumes increase. This ensures consistent performance and reliability under growing blockchain loads.

Furthermore, it allows for sub-second log lookups, even across 10 years of historical data, something previously impractical using traditional linear indexing. The design also supports future integration with ZK proof systems, enabling lightweight, remote verifiable queries without compromising trust assumptions.

A partial implementation of this system already exists within the Geth client, under a module named filtermaps. Initial testing has been conducted on a single-node Devnet, which integrates both Geth and Nimbus clients.

However, to enable broader adoption across clients and ensure long-term maintainability, the proposal still requires additional spec simplification, making it easier to understand and implement for other developers in the ecosystem.

While the proposal was praised for its utility and alignment with Ethereum’s stateless vision, concerns were raised about complexity and development prioritization. Still, it is a strong candidate for the Glamsterdam fork, pending further testing and feedback.

(II) EIP-7919: Pure Read RPC Enhancements for Wallets

EIP-7919 aims to improve Ethereum RPC security and wallet UX by enabling verifiable, minimal, and trustless data access across critical transaction layers.

Current wallet workflows face two significant challenges. First, most RPC endpoints such as those provided by Alchemy or Infura are trust required, meaning users must rely on these centralized services to deliver accurate and complete data.

Unfortunately, this trust can be violated due to server-side hacks, misconfigurations, or undetected software bugs, leading to potential data inconsistency or loss.

Second, essential components of transaction transparency such as ETH transfers, beacon chain withdrawals, and gas usage metrics currently cannot be cryptographically verified by the end user. Achieving such verification typically requires downloading entire blocks or using custom external indexers, which undermines decentralization and increases reliance on third party infrastructure.

To resolve these issues, EIP-7919 proposes a set of enhancements. The first is ETH transfer logging, which ensures that internal transfers are captured and verifiable directly from the logs. This provides clear, audit ready data for wallets and exchanges.

The second enhancement is the adoption of SSZ for transactions and receipts. This new serialization format allows for efficient hashing and facilitates reliable inclusion proofs, crucial for trustless verification.

In addition, the proposal introduces receipt completeness proofs, enabling users to confirm whether they have received all logs associated with a block without needing to download its full contents.

Lastly, calldata optimization for L2s is proposed, which reduces the data size and cost of submitting proofs from Layer 2 to Layer 1. This is especially beneficial for rollups, where calldata efficiency directly impacts scalability and user fees.

If implemented, these enhancements would significantly improve wallet security, allowing interactions over privacy preserving networks such as Tor without compromising data trustworthiness. They would also enable anonymous, trustless querying of RPC data, breaking the dependency on centralized APIs.

From a developer and infrastructure perspective, this shift would reduce the need for costly custom indexers, thereby lowering operational overhead. The changes also align closely with the goals of supporting light clients and building toward stateless Ethereum, two critical elements of Ethereum’s long term scalability roadmap.

EIP-7919 was presented in detail during the call, complete with supporting visuals. Although the concept was well received, it remains in the proposal phase, with no client side implementation yet. While not positioned as a headline item for the next fork, it garnered strong support from the community and is viewed as a prime candidate for future inclusion in the Glamsterdam fork.

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.

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