Ethereum’s All Core Developers Execution (ACDE) Call #219 brought together client teams & ecosystem contributors to coordinate around Fusaka’s readiness, Holesky’s retirement, gas-limit scaling, and Glamsterdam’s proposal pipeline. The discussion highlighted progress on Devnet-3 non-finality recovery, upcoming configuration PRs for blob scheduling, and the importance of aligning fork timelines with the post-Pectra process document.
Core developers also reached consensus on winding down the Holesky testnet after Fusaka, continued work toward raising the block gas target to 60M, and reviewed several PFI EIPs that could shape the next upgrade.
Fusaka Updates
Devnet-3 has been running through extended non-finality periods that were originally expected to last about two days but stretched to nearly a week. Client teams reported mixed results:
- Prysm nodes were generally stable
- Lighthouse and Lodestar/Nimbus encountered significant syncing delays and memory issues, which kept participation at around 50–55%.
In order to regain finality, targeted validator exits were triggered, but these processed slowly, underscoring bottlenecks in current implementations. Looking ahead, the plan is to stabilize Devnet-3 with fixes from client teams like Lighthouse, Teku, and Lodestar.
Once those are available, another non-finality test will be run next week. If recovery is strong, developers will then launch Devnet-5, scoped as a “fix-only” validation step, to confirm stability before scheduling further forks.
Alongside the non-finality testing, developers also reviewed pending pull requests. These configuration PRs are seen as essential to align blob availability ahead of Fusaka.
Four key PRs were highlighted:
Barnabás Busa, who authored the changes, noted that if no objections are raised within 24 hours, the PRs will be merged to enable upcoming shadow forks on Holesky, Sepolia, and Mainnet. These PRs standardize blob handling, reducing inconsistencies and ensuring that testing environments mirror expected mainnet conditions.
The key theme was how to sequence testnets, forks, and releases in a way that balances speed with ecosystem stability. Core developers reaffirmed the importance of the post-Pectra process document.
This document specifies a 30-day window between client releases and the first testnet fork, a compromise made with rollups and infrastructure providers who require time to update their stacks safely. While there is flexibility to pipeline testnets closer together (they need not all be a month apart), the initial 30-day gap before the first testnet remains the baseline.
Some participants emphasized that this agreement should not be repeatedly re-litigated for each fork. To handle uncertainty, the call agreed on a two-track planning approach.
- One track would produce a “default” schedule aligned with the process doc.
- The second track would proactively poll major stakeholders (L2s, infra/app providers, staking operators) about their preferences on activation sequencing, testnet roles (e.g., which testnet should serve as the “app-staging” last fork), change-freeze windows, and gating criteria such as non-finality recovery and client sync health before scheduling each step.
Holesky Testnet (Retirement Plan)
Another important agenda item was the future of the Holesky testnet. Consensus was reached to retire Holesky a few weeks after Fusaka activates on it.
This would reduce operational overhead and streamline the post-Fusaka testnet landscape. A formal blog post is expected in the coming week to announce the timeline, migration details, and any final opportunities for testing.
The tentative target mentioned in earlier discussions is to wind down Holesky by the end of September. By clearly communicating the retirement plan, developers aim to give ecosystem teams sufficient time to migrate workloads and avoid confusion once Fusaka is live.
Gas-Limit Updates
The discussion around the gas limit focused on the ongoing effort to raise Ethereum’s block gas target to 60 million before the Fusaka upgrade. Core developers highlighted that several bottlenecks, particularly related to state growth and sync performance, are still preventing a safe transition.
Teams like Nethermind and PandaOps are leading coordinated measurement work, publishing results and sharing dashboards that make it easier for clients to compare their performance metrics. Progress has already been made with opcode-level optimizations, for example on mod and div operations, which are expected to improve efficiency in high-gas environments.
Still, much of the work revolves around ensuring that all clients can handle the extra load under mainnet-like stress conditions. The timeline for activating a higher gas limit remains tied to these measurable improvements, but the intent is clear: reach 60M gas before Fusaka, so the upgrade can roll out on stronger foundations.
Glamsterdam Updates
Glamsterdam discussions revolved around how to structure and prioritize proposals for inclusion (PFIs) in the next hard fork. Client teams agreed that PFI call time should go first to items explicitly requested by client developers, ensuring that scarce discussion slots are used effectively.
Besu was the first to share a preference list, which will be lined up for review on subsequent calls. A major technical topic was the Block Access List (BAL, EIP-7928), which is one of the selected Glamsterdam headliners.
Developers noted that a dedicated breakout call for BAL now happens every two weeks, and all major client teams have already started implementation work. This reflects the urgency of aligning on BAL, as it will directly shape execution-layer capabilities and block structure in the next upgrade.
Finally, several PFI EIPs were reviewed for context, though no inclusion decisions were made. While these were not evaluated for inclusion, the discussions allowed authors to answer technical questions from client teams and provided early feedback.
EIP-7843 was introduced as a very small but useful proposal: it would add a simple opcode to directly return the current slot number on-chain. Today, developers typically compute the slot indirectly through timestamp math, which works under current assumptions but risks breaking if slot lengths change in the future.
The opcode provides a safer and cheaper way to access this information. This is seen as low-hanging fruit that could save developers pain down the road without adding major complexity.
EIP-7793 was pitched as a way to make encrypted mempools enforceable. Encrypted transactions are ordered in one slot and revealed in the next, but today there is no mechanism to enforce that the revealed transactions actually follow the original ordering.
EIP-7793 proposes a new transaction type called a conditional transaction which includes the required index within the block. The transaction will only execute if it is placed in that position, enabling stronger guarantees against front-running.
An accompanying opcode lets contracts verify the transaction’s actual index on-chain. This ensures encrypted mempools have real enforceability rather than just social expectations.
Several other proposals were also briefly surfaced. EIP-2926, EIP-8012, and EIP-8014 were flagged for awareness and questions but without any inclusion decisions.
A Meta-EIP was proposed to consolidate the many opcode and precompile gas-cost updates into a single umbrella framework. This would help ensure repricings are justified with concrete performance data, test vectors, and a consistent methodology rather than being decided ad hoc.
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
Disclaimer: The information contained in this website is for general informational purposes only. The content provided on this website, including articles, blog posts, opinions, & analysis related to blockchain technology & cryptocurrencies, is not intended as financial or investment advice. The website & its content should not be relied upon for making financial decisions. Read full disclaimer & privacy policy.
For Press Releases, project updates & guest posts publishing with us, email contact@etherworld.co.
Subscribe to EtherWorld YouTube channel for ELI5 content.
Share if you like the content. Donate at avarch.eth.
You've something to share with the blockchain community, join us on Discord!