The All Core Devs Execution (ACDE) Call 211 marked the first major post-Pectra coordination session, shifting focus toward the upcoming Fusaka network upgrade. Discussions centered around the success of the Pectra mainnet deployment, early planning for Fusaka Devnets, and strategic EIP prioritization.

Key topics included proposals for raising the gas limit, mitigating state growth risks, repricing computational bottlenecks like ModExp, and improving long-term coordination through tooling and governance reforms.

Pectra Updates

Following the opening of the call, attention quickly shifted to the recently completed Pectra fork, which had gone live on Ethereum mainnet just a day prior. This section served as a collective debrief, celebrating the fork’s successful deployment with no consensus failures, bugs, or downtime.

Pectra was acknowledged as the largest EIP-packed fork in Ethereum’s history, introducing the highest number of simultaneous protocol upgrades. The development teams took a moment to appreciate the milestone and recognized the collaborative effort across clients, testers, and community contributors.

Traditionally, EIPs are tested extensively in testnets and simulations. However, for Pectra, the team introduced the practice of running a selected subset of spec tests on mainnet directly.

The goal was to validate EIPs in real-world production conditions, catching edge cases that might slip through synthetic environments. This approach acted as a sanity check, further reinforcing the confidence that Petra’s changes would hold up under live traffic.

Introduction to Fusaka Fork

With Pectra successfully deployed, Ethereum core developers immediately turned their focus to the next major upgrade—Fusaka. It was agreed that discussions around future forks would now be centered within the execution-layer (EL) and consensus-layer (CL) calls, with a stronger emphasis on ACDT (All Core Devs Technical) sessions, especially for high-priority features like PeerDAS.

Additionally, the PeerDAS breakout sessions were rescheduled from Tuesdays to Mondays to align better with this updated workflow. There was also a bit of housekeeping—developers noted inconsistencies between the updated meeting structure and the existing shared calendars, particularly around PeerDAS scheduling.

The team agreed to correct the calendar entries to reflect these changes accurately. Overall, the tone was organized and proactive, ensuring that all developers are in sync as Fusaka planning begins.

Strategic Direction & Governance of Gas Limit Scaling

EIP-7935 aims to increase Ethereum’s transaction capacity without changing consensus rules. While it introduces no technical alterations, it serves as a strategic signal—a call to prioritize performance optimizations that enable future gas limit increases.

Its purpose is to align client teams, developers, and researchers around scalability as a core objective. Discussions around gas scaling have largely emphasized validator and block builder capabilities.

However, RPC providers and home node operators, constrained primarily by disk space, remain overlooked. Ethereum's current state grows by ~5 GB per month at a 30M gas limit, doubling with higher gas ceilings.

This growth can strain solo node runners and centralized service providers alike. Developers are split. One camp argues that Ethereum must commit now to prevent stagnation and force infrastructure improvements.

Others caution that it’s reckless to scale without solving core architectural issues like state expiry, storage repricing, and ZK client readiness, which are still in progress. EIP-7935 also revived a governance-level debate—should EIPs reflect only hard protocol changes, or can they serve broader strategic purposes?

Some devs accept informational EIPs as legitimate coordination tools, while others call for clearer boundaries to preserve the EIP system’s integrity. Regardless, consensus emerged that testing, benchmarking, and implementation readiness must guide actual gas limit changes.

Alternative Approaches to Gas Limit Scaling

Ethereum’s state contains essential on-chain data—balances, contracts, storage. As state size grows unchecked, node performance deteriorates, especially for operators with limited storage (≤2TB SSDs).

This puts decentralization at risk. Solutions like state expiry, stateless clients, and block size caps were discussed as crucial safeguards.

Rather than raising the gas ceiling outright, developers proposed repricing specific operations. Increasing gas costs for storage-heavy or performance-sensitive tasks could allow Ethereum to scale horizontally—by freeing up room for low-cost operations while constraining risk areas.

This approach buys time for deeper protocol upgrades to mature. Authored by Dankrad Feist, EIP-7938 introduces a predictable, exponential gas limit schedule using client-side defaults. Starting June 2025, clients would vote to increase the gas limit by 10x every two years—up to 500M by 2029—unless manually overridden.

The proposal is opt-in, non-consensus, and backward-compatible, offering a low-friction way to align stakeholders and allow long-term planning. To complement gas limit discussions, EIP-7934 proposes a hard 10MB cap on block size to prevent propagation failures across Ethereum’s P2P network.

While minor in scope, this change is critical to maintaining inter-client sync and network resilience if gas limits increase. With EIP-7935 providing directional intent, EIP-7938 delivering structured growth, and EIP-7934 ensuring network stability, Ethereum is assembling a layered strategy for responsible scalability.

ModExp (Modular Exponentiation) EIPs

As part of the broader conversation on gas limit increases, developers highlighted a critical technical vulnerability tied to the Modular Exponentiation (ModExp) precompile. This cryptographic operation, commonly used in zk-SNARKs and other advanced applications, is highly computationally intensive.

However, its current gas pricing is outdated and misaligned with its execution cost. To address this, EIP-7883 proposes a repricing mechanism that better reflects worst-case performance scenarios.

Without this adjustment, higher gas limits could enable denial-of-service attacks by filling blocks with low-cost but long-execution ModExp calls. Complementing this, EIP-7823 introduces a safeguard by setting a hard cap on input sizes to the ModExp precompile.

Though current usage rarely exceeds input sizes of 512 bytes, the proposal enforces a 1024-byte upper limit to prevent future abuse. This is a preventive measure that protects the network from potential exploitation as transaction patterns evolve or attacker strategies become more sophisticated.

Both proposals were met with broad support across client teams, particularly given their low implementation complexity and high risk-mitigation value. These repricing and capping measures are likely to be among the first EIPs implemented in Fusaka Devnet 1.

Long-Term Governance Planning

As Ethereum’s upgrade cadence and complexity continue to grow, developers emphasized the need for improved coordination tooling and governance processes. Tim Beiko introduced a proposal outlining ways to enhance how AllCoreDevs manages priorities, tracks EIP progress, and aligns stakeholders across execution and consensus layers.

Another contributor suggested building tools that would allow for transparent EIP lifecycle tracking, team-level prioritization, and better visibility into who is responsible for what. These ideas stem from a shared concern: as Ethereum scales technically, it must also scale its organizational capacity to make decisions and execute upgrades efficiently.

One of the core issues discussed was the current ambiguity in EIP scheduling and prioritization. Developers noted that forks often become overloaded or misaligned because there is no structured process for teams to express their priorities or bandwidth.

A proposed solution is to have each client team submit an ordered list of EIPs they support for inclusion, which could then be merged into a shared roadmap. This would replace informal “include it if it’s ready” approaches with clearer expectations, avoiding wasted engineering effort and improving cross-client alignment.

In addition to tooling, there was discussion around the longevity and accountability of working groups. Many past initiatives have lost momentum due to a lack of structured check-ins and formal review.

Developers proposed instituting a recurring review loop, where working groups periodically report back to AllCoreDevs to assess whether their objectives remain relevant. By formalizing how work is tracked, scoped, and sunsetted when necessary, Ethereum can maintain agility while also increasing reliability in its upgrade pipeline—something increasingly essential as forks like Fusaka, and those beyond it, grow more ambitious

Pectra Pages

During the closing segment of the call, Trent Van Epps issued a final reminder for contributors to submit entries for Pectra Pages—a community-led documentation effort capturing personal reflections, challenges, and achievements from the recent Pectra fork. Unlike technical changelogs, Pectra Pages aims to preserve the human stories behind the upgrade, including insights from core developers, client teams, testers, and infrastructure contributors.

With around 40 submissions received so far, Trent encouraged others—especially the many who participated in Pectra—to share their experiences, even if informally. He noted that the form only takes 10–15 minutes to complete.

This initiative is intended to serve as both a historical archive and a morale-boosting tradition, giving visibility to the behind-the-scenes work that often goes unrecognized. Contributors were asked to check their DMs or reach out directly if they hadn’t yet submitted, as publication was planned for early the following week.

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
_____________________________________________________________________

Disclaimer: The information contained in this website is for general informational purposes only. The content provided on this website, including articles, blog posts, opinions, and analysis related to blockchain technology and cryptocurrencies, is not intended as financial or investment advice. The website and its content should not be relied upon for making financial decisions. Read full disclaimer and privacy Policy.

For Press Releases, project updates and guest posts publishing with us, email to contact@etherworld.co.

Subscribe to EtherWorld YouTube channel for ELI5 content.

Share if you like the content. Donate at avarch.eth or Gitcoin

You've something to share with the blockchain community, join us on Discord!

Follow us at Twitter, Facebook, LinkedIn, and Instagram.