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

The All Core Devs Execution (ACDE) Call 213 focused on finalizing the Fusaka upgrade scope, advancing Devnet 2 planning, and initiating early discussions for headliner proposals in the Glamsterdam fork.

With Fusaka Devnet 1 nearing launch and active testing on gas limit performance underway, the call centered around EIPs like 7951, 7934, and 7907, along with trade-offs in validator inclusion, execution scalability, and home-node decentralization. It was also confirmed that next week’s calls would be cancelled due to in-person meetings, with Ansgar stepping in as host the following week.

• Gas Limit Increase Discussion
• Fusaka Devnet Scope Decisions
• Glamsterdam Headliner Proposals
• EIP Versioning Proposal

Gas Limit Increase Discussion

Ethereum currently operates under a conservative gas ceiling, which constrains the amount of calldata that rollups can publish to L1. As more applications and rollups settle data on Ethereum, this limitation risks becoming a bottleneck. The proposed 60 million gas ceiling aims to alleviate this, offering more blockspace and improving transaction capacity without needing a hard fork.

Testing has already begun on this front using the Hoodi Testnet to gather more robust benchmarks. The idea is to make a data-driven decision after additional performance insights are obtained.

There is no unified consensus on how to go about this change. Some developers propose a direct jump to 60 million, while others suggest a gradual increase to avoid introducing sudden stress on node operators. The latter, while safer, is criticized for creating repeated coordination overhead.

There are two main strategies under consideration for raising the gas limit.

• The first is a direct jump to 60 million, which offers the advantage of simpler coordination and quicker access to scalability benefits. However, this approach carries the risk of introducing unforeseen instability or stress on the network, especially if not all edge cases are well understood in advance.
• The second strategy involves gradual increases, such as moving from 45 million to 50 million and then to 60 million. This method allows for a safer progression and creates more opportunities to monitor and test performance at each stage. Yet, it also introduces significant coordination overhead, requiring more time, planning, and synchronization across client teams and the broader ecosystem.

One of the most important moments in the call came from Micah Zoltu, who emphasized that the discussion has been overly focused on the needs of validators and block builders, neglecting RPC providers and individuals running full nodes at home.

His question was stark and ideological:

"Does Ethereum still want to be runnable from a home computer?"

He argued that increasing the gas limit without compensatory design changes (like state pruning) would rapidly accelerate state growth, effectively locking out individuals who don’t have datacenter-grade hardware. Historically, Ethereum was envisioned as a decentralized network where anyone could spin up a full node. That vision, Micah pointed out, is at risk of erosion.

As gas limits rise, the effects cascade across different categories of Ethereum participants.

• Block Builders: Operate high-performance infrastructure tailored for MEV extraction and competitive bidding. They are well-equipped to handle higher gas limits without significant strain.
• Validators (Homestakers): Individuals running validator nodes from home using mid-tier machines. They will likely need hardware upgrades—particularly in terms of SSD storage and bandwidth—to stay in sync with the network.
• RPC Providers (e.g., Infura): Organizations offering scalable node access to dApps and developers. They have the technical capacity and operational scale to manage increased demands effectively.
• Local Node Runners: Hobbyists or developers running full nodes on personal laptops or desktops. This group is most vulnerable to exclusion, as rising data requirements could push them out of participation entirely.

Currently, with optimizations like the flat database used in Basu, a full node can operate within approximately 80 GB of disk space. However, if the gas limit is doubled, the rate of state growth will also accelerate. Developers estimate this will increase from roughly 3 GB/month to 6 GB/month. Over a few years, this means that storage needs could grow beyond 1 TB, creating barriers for everyday users.

During the call, developers referred to EIP-7870, which attempts to formalize constraints around resource usage for nodes. However, this EIP was criticized for not adequately considering the unique needs of home RPC users. This omission revealed an underlying assumption that Ethereum no longer aims to serve low-resource, consumer-grade operators.

The developers didn’t make a final decision during this call and will continue their discussion on #gas-limit-testing Discord channel.

Fusaka Devnet Scope Decisions

Ethereum core devs used this ACDE call to finalize the scope of Devnet 2, the final pre-release testing environment for the upcoming Fusaka upgrade. This stage is critical because any feature not scheduled for Devnet 2 is effectively excluded from the Fusaka mainnet fork.

As the Ethereum protocol prepares for the Fusaka upgrade, several Ethereum Improvement Proposals (EIPs) were scrutinized for inclusion in the upcoming Devnets.

(I) EIP-7883 – ModExp Gas Cost Increase

• One of the first proposals touched upon was EIP-7883, which deals with improving gas cost accuracy in MODExp (modular exponentiation) operations. The issue arose from edge cases where inputs to these operations are smaller than 52 bytes.
• In such situations, the Ethereum Virtual Machine (EVM) ends up undercharging for gas, creating potential attack surfaces.

• To resolve this, the proposal suggests that gas should be calculated as if inputs are always ≥52 bytes, even if they aren’t. This change doesn’t affect normal mainnet behavior but ensures security and consistency in worst-case scenarios.

(II) EIP-7951 – Upgrading from RIP-7212 for Signatures

• The team also addressed the replacement of RIP-7212 with EIP-7951, a cryptographic enhancement that’s technically simple but strategically powerful.
• EIP-7951 supports the P-256 curve, already standard across TLS, SSH, OAuth, and device-level authentication platforms like Face ID, Android Keystore, Apple Secure Enclave, and YubiKeys.
• This update is essentially a drop-in fix for RIP-7212, which had a rare edge case bug.
• From the Ethereum side, it enables a seamless UX shift: signing Ethereum transactions with biometrics or device keys — making on-chain activity as smooth as unlocking your phone.
• Notably, the new proposal is backed by 780+ test vectors and uses a single interface, avoiding the complexity that plagued earlier BLS implementations. It’s widely agreed this should ship with Fusaka.

ACDE #213 is Live!

Agenda highlights:
– Fusaka & gas limit updates
– RIP-7212, EIP-7883, devnet-2
– Glamsterdam: EIP-7928, EVM64, #FOCIL, Attestations
– June call cancellations & next #ACDE host

📺 Watch live:
X: https://t.co/QNwdzBesem
YT: https://t.co/bdkYvInR0p#Ethereum…

— Pooja Ranjan | ranjan.eth (@poojaranjan19) June 5, 2025

(III) EIP-7907 – Meter Contract Code Size And Increase Limit

• Next up was EIP-7907, a more ambitious yet long-demanded update: increasing the maximum smart contract size. The current limit stands at 24 KB, which has become restrictive for more complex dApps.
• While developers have been requesting this for years, the change isn't trivial but it affects how execution-layer (EL) clients handle contract storage.
• Some client teams mentioned it requires only ~200 lines of code, but concerns persist around database indexing, read/write performance, and how this could disrupt syncing and archival processes.
• While there's no consensus yet, the room leaned toward including 7907 in Devnet 2 if testing shows it won’t slow down core implementation. If complexity arises, it may be pushed to Glamsterdam instead.

(IV) EIP-7934 – RLP Execution Block Size Limit

• EIP-7934 is a lightweight safety net: it caps the maximum size of execution blocks to prevent performance bottlenecks. With higher gas limits, there’s a risk that certain blocks could take too long to process, hurting consensus performance and validator UX.
• This cap ensures validators can process and propagate blocks efficiently, maintaining the network’s responsiveness. It has wide support from Geth, Besu, and other clients, and was considered a non-controversial inclusion in Devnet 2.

(V) EIP-5920: PAY opcode

• Finally, EIP-5920 was also reviewed. It proposed a restructuring of gas pricing behavior, but was ultimately dropped. The community found it confusing, with unclear benefits, and it lacked strong advocacy. For now, it has been moved out of scope entirely.

Devnet 2 acts as the final implementation gate before the Fusaka mainnet launch. During the discussion, the Ethereum core developers collectively agreed to prioritize low-risk, high-impact EIPs, avoid introducing late-stage complexity, ensure clear decisions on what to include or exclude, and most importantly, lock the upgrade scope to maintain overall network stability.

After extensive feedback and review from multiple client teams, a final shortlist of EIPs was confirmed for inclusion in Devnet 2 under the Fusaka upgrade.

(I) CFI'd EIPs for Fusaka Devnet 2:

• EIP-7951: Replaces the earlier RIP-7212, which contained a critical bug. This proposal offers a cleaner and safer cryptographic signature scheme aligned with modern hardware.
• EIP-7934: Introduces a cap on execution payload size, improving block processing predictability and speeding up execution for clients.
• EIP-7907: Allows larger contract sizes—a long-standing developer request. However, it may require database structure changes in EL clients and is being treated as a stretch goal.

(II) DFI'd EIPs for Fusaka Devnet 2:

• EIP-5920 (PAY opcode): Excluded due to divided client support, non-trivial downstream implications, and a lack of urgency or consensus from smart contract developers.

Ethereum devs emphasized tight scope control to avoid destabilizing Fusaka this late in its lifecycle. If any significant blocker arises during Devnet 2, a Devnet 3 may be created — but only for essential additions.

If Devnet 1 and Devnet 2 are successful, core devs might introduce EIP-5920: PAY opcode in Devnet 3. Otherwise, it will wait for the Glamsterdam fork.

Glamsterdam Headliner Proposals

As Ethereum prepares for the upcoming Glamsterdam hard fork, the core developer community is actively evaluating a shortlist of proposed “headliner” EIPs

Headliner proposals are selected based on the following criteria:

1. Impact: Must meaningfully improve Ethereum’s functionality, scalability, or neutrality.
2. Maturity: Well-defined with active prototypes, test coverage, or client adoption.
3. Urgency: Addresses near-term risks such as censorship, inefficiencies, or protocol bottlenecks
4. Synergy: Should complement or enable other parallel proposals in development.

Headliner selection shapes the engineering roadmap, testing schedules, and public communication strategies leading into the fork.

With Fusaka discussion nearing completion, core developers are starting to plan what comes next in the Glamsterdam upgrade. A few major proposals have emerged as strong contenders, each tackling real problems like censorship, performance, and validator security.

(I) EIP-7805: FOCIL (Fork-choice enforced Inclusion Lists)

This EIP introduces validator-driven inclusion lists to address censorship risks in Ethereum block production. Currently, more than 80% of Ethereum blocks are constructed by just two builders, raising concerns about centralization and discriminatory transaction filtering.

• FOCIL enables validators to publish mandatory transaction inclusion lists based on the public mempool. Builders are required to respect these lists or risk block invalidation. This gives control back to a decentralized set of validators and helps enforce Ethereum’s commitment to credible neutrality.
• FOCIL has been implemented across five major Ethereum clients, including Geth, Teku, Prysm, Lodestar and Lighthouse (soon). It has been successfully tested in several Devnet environments, demonstrating a high degree of cross-client interoperability. Furthermore, it is fully compatible with other ongoing proposals such as delayed execution, making it a robust candidate for integration into future protocol upgrades.
• FOCIL significantly enhances Ethereum’s censorship resistance by empowering validators to enforce transaction inclusion, rather than leaving this power solely to centralized builders. It reinforces the protocol’s decentralization by distributing decision-making authority across the validator set. Most importantly, it ensures that all valid public transactions have a guaranteed path to inclusion on-chain, preserving Ethereum’s foundational principle of credible neutrality.

(II) EVM64: 64-bit Optimized EVM Opcodes

• EVM64 proposes a new set of opcodes that operate only on the least significant 64 bits of EVM stack values, in contrast to the traditional 256-bit width. This reflects modern computing realities, where many operations do not require full 256-bit precision.
• EVM64 is expected to offer substantial performance improvements in smart contract execution, especially when paired with just-in-time (JIT) compilers or interpreter optimizations.
• EVM64 explores two implementation strategies. The first is a legacy-prefixed mode, which introduces a prefix to existing opcodes within the standard EVM to signal 64-bit operations. This approach aims to maintain backward compatibility with minimal disruption. The second option is based on EOF (EVM Object Format), where a new type parameter is added within the EOF container to define and isolate 64-bit opcode sections more cleanly and modularly.
• A working prototype of EVM64 has been developed in the Rust implementation of the EVM. While detailed benchmarks are still in progress, early testing suggests meaningful performance improvements, particularly for contracts involving frequent arithmetic operations.
• EVM64 is expected to accelerate compute-heavy contracts by reducing the operational width from 256 bits to 64 bits where appropriate. This can streamline execution paths, lower code complexity, and reduce the number of processing steps. Additionally, it lays the groundwork for future modularization of the EVM by clearly segmenting different opcode sets and enabling better optimization opportunities in compilers and virtual machine design.

(III) EIP-7942: Available Attestations

• This proposal aims to improve Ethereum’s resilience against consensus-layer attacks that cause reorganization or halt finality.

Source: ACD #213

• The core mechanism involves restricting which blocks can serve as valid parents in the fork choice rule, based on the attestation support they have received. Only blocks with adequate attestations from honest validators are permitted to propagate.

• The proposal for Available Attestations is considered technically mature and is currently under review.
  attestations cannot be accepted as valid parents.

• This proposal aims to prevent liveness failures in the beacon chain by ensuring that blocks lacking sufficient validator

(IV) EIP-7928: Block-Level Access List (BAL)

• This EIP is under active discussion as a critical enabler of both FOCIL and delayed execution. It aims to declare pre- and post-state metadata at the block level, allowing for parallel transaction execution and efficient state verification.
• The average overhead of ~40 KB per block is considered acceptable, but further analysis of bandwidth and worst-case behavior is ongoing.
• Block-Level Access Lists (BAL) provide several practical benefits. By enabling deterministic batch I/O, they make transaction processing more predictable and efficient. BAL also improves the syncing process and accelerates state healing by offering structured metadata about state access patterns.

• Additionally, for proposals like FOCIL that require post-execution validation, BAL simplifies the process by allowing these checks to be performed more efficiently using pre-declared access information.

EIP Versioning Proposal

In the context of Ethereum’s rapid Devnet releases and evolving EIP specifications, a major concern was raised: how do we ensure all stakeholders — client implementers, test authors, and auditors — are working from the same version of an EIP?

With multiple edits happening between review, CFI (Considered for Inclusion), and final implementation, can cause inconsistencies. This led to renewed discussion around introducing explicit EIP versioning.

Ethereum’s testing and client teams have frequently encountered issues like:

• Test failures caused by uncoordinated spec changes.
• Confusion around which EIP version is implemented in each Devnet.
• No easy way to tell if two clients are interpreting the “same EIP version”.

To address the version tracking problem, two primary approaches have emerged:

(I) Option 1: Manual Semantic Versioning (EIP-7577 Style)

• Each EIP includes a version: field (e.g., v1.0.0, v1.1.0).
• Every change must include a summary of what was updated (logic, grammar, etc.).
• Linked to Devnet tags like “Used in Devnet 2”.

(II) Option 2: Git Commit Hashing (Proposed by Tim Beiko)

• Use the Git commit hash of the EIP markdown file as its version ID.
• Tools (like EELS and test generators) can automatically use this hash to anchor test vectors.

While no official system has been finalized yet, Ethereum’s core developers unanimously recognize the need for a formal versioning strategy for EIPs. The previously proposed EIP-7577 is now considered outdated and may require a rewrite, and automation tooling to support Git hash tracking or semantic version bumping is still missing.

A trial versioning implementation is likely to be explored during the Glamsterdam planning phase. Both approaches remain under active discussion, with the final decision to be expected in the coming months based on tooling readiness and coordination needs.

Conclusion

The ACDE #213 call concluded with firm decisions around the Fusaka upgrade, particularly by locking in the scope after Devnet 2. It was agreed that Devnet 1 and Devnet 2 together would define the complete feature set for Fusaka. No new major features will be considered beyond this unless a Devnet 3 becomes necessary. Among the finalized EIPs are EIP-7951 (replacing RIP7212 with a stronger signature scheme), EIP-7934 (which caps execution payload size) and EIP-7907. EIP-5920 was officially dropped from consideration for this cycle.

While Devnet 3 is not currently planned, the door was left open to initiate it if Devnet 1 and 2 go exceptionally smoothly. Should Devnet 3 happen, it will be strictly limited to lightweight, well-supported proposals such as the Pay Opcode. Crucially, such an addition must not disrupt the overall Fusaka timeline or delay the upgrade.

Looking ahead to the Glamsterdam fork, early planning has already begun. The core developers are exploring possible headliner EIPs for that cycle, including FOCIL (to enhance censorship resistance), EVM64 (which introduces 64-bit stack operations), Available Attestations (to improve reorg resilience), and Block-Level Access Lists (for parallel execution support). Developers are encouraged to start reviewing these proposals asynchronously. Continued discussions and refinement will occur in Discord and on the Ethereum Magicians forums.

The governance direction also emphasized several process improvements. The Pay Opcode will likely reappear in Glamsterdam if broader consensus forms around its inclusion. For EIP versioning, better tooling and automation are required, and a trial implementation may occur in the next fork. The broader inclusion philosophy is moving toward more empirical testing and clear categorization of EIPs, such as Scheduled for Inclusion (SFI) versus Declined for Inclusion (DFI). Communication-wise, developers are being advised not to delay low-risk, high-impact features unnecessarily out of procedural caution.

Toward the end of the call, a comment about the maximum blob count per transaction was raised. This was not explored in detail and will likely be revisited in a future ACD call or testing session. Developers were also reminded to use the Gas Limit Testing channel on Discord for performance-related conversations, and to engage with the ongoing EIP-7907 thread to better understand its implications on execution-layer client databases.

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
6. Highlights of Ethereum's All Core Devs Meeting (ACDC) #150