All Core Devs - Execution (ACDE) #219, August 28, 2025

Meeting Summary:

The team prepared for a YouTube presentation stream and discussed the status of non-finality testing on Devnet 3, with plans to finalize it by the end of the day. They reviewed an updated timeline for Fusaka and discussed the upcoming Ethereum fork, including the 30-day agreement with L2s for testnet releases and potential timeline adjustments. The team also covered various technical implementations and EIP proposals, including gas limit changes, block access lists, and code chunking in the MPT, while emphasizing the importance of maintaining discipline in the release process and ensuring proper stakeholder communication.

Click to expand detailed summary

The team held a brief meeting to prepare for streaming a presentation on YouTube. Tim and Akash coordinated to ensure the live stream was set up properly, with Akash confirming readiness to go live. The conversation ended with Tim giving the final okay to start the stream.

The team discussed the status of non-finality testing on Devnet 3, where Barnabas reported 50-55% participation and syncing issues across multiple clients. They agreed to aim for finalizing Devnet 3 by the end of the day, with fixes from client teams expected by mid-next week. The team also reviewed an updated timeline for Fusaka, with Alex presenting a schedule that includes trunk branches by the end of the week, Devnet 5 launch next week, and mainnet releases planned for early October. There was some discussion about maintaining a 30-day period between client releases and testnet forks, as previously agreed in the protocol upgrade process.

The team discussed the timeline for the upcoming Ethereum fork, focusing on the 30-day agreement with L2s for testnet releases and the importance of adhering to this commitment. They debated whether the 30-day timeline was necessary, with some arguing for a more compressed rollout to meet the end-of-year target, while others emphasized the need for a predictable and secure upgrade process for L2s. The group also touched on the potential impact of delays on the broader Ethereum ecosystem and the need for better communication and planning in the future.

The team discussed the timeline for the testnet release and the process of integrating changes into trunk branches. Tim proposed two paths forward: basing the ready schedule on the current process or adjusting it to accommodate community preferences for an earlier release. The group debated the urgency of the January 1st versus January 15th release dates, with some stakeholders expressing a preference for more time to integrate changes. Stokes agreed to reach out to rollups and other affected parties to gather feedback on the proposed timeline changes. Lightclient emphasized the importance of maintaining discipline in the release process and avoiding frequent changes to agreed-upon deadlines.

The team discussed timeline preferences for software releases, with a current agreement of 30 days in the documentation that will be maintained unless stakeholders indicate otherwise. They agreed to check with affected stakeholders about their timeline preferences while preparing the schedule according to the existing document. The team also confirmed plans to deprecate Polesky after the fork, with an announcement expected in the coming weeks, and Luis reported progress on gas limit work for Besu, which now has a working implementation for MoD and Dev that will be tested soon.

The team discussed the process for implementing a 60 million gas limit change, agreeing to wait until all major clients have releases that can handle it, rather than forcing an immediate update. Tim suggested making the 60 million gas limit the default in testnet releases before Fushaka’s mainnet launch, while Ansgar emphasized the importance of quick upgrade capability for any potential issues. The team also addressed concerns about Zen’s compatibility and discussed the possibility of CLs querying ELs for gas limit information, though Felix noted this could be implemented through existing RPC APIs without requiring an engine API change.

The team discussed updates on block access lists and gas price repricing EIPs. Toni reported that client teams are busy implementing EIP-7732, with progress being made toward a first step. Ansgar and Maria proposed creating a meta EIP to track gas price repricing EIPs, which would serve as a version-controlled document for early devnets. The team agreed to give this approach a try, with Ansgar and Maria taking the lead on research in this area. Roman inquired about the status of gas limit testing efforts, which Tim and the team discussed briefly.

The team discussed managing a large number of proposed EIPs for an upcoming fork, with concerns about reviewing 20-30 EIPs in a timely manner. They agreed to have teams pre-review the list and flag the most important ones for discussion, with a focus on async communication through Magicians threads and potentially using a tier ranking feature in Forkcast. Tim proposed following up with teams to gather more EIP preferences before the next ACDE meeting, where some presentations would be scheduled.

Guillaume presented EIP-2129/26, which introduces code chunking in the MPT to enable larger contracts without waiting for binary trees implementation. He explained that the change requires a simple transition and adds two extra fields to contract accounts: code size and code root, while maintaining compatibility with existing EOA accounts. Tim and others discussed potential benefits and downsides, including performance improvements for zk proofs and increased gas costs. Marc then presented two additional EIPs: EIP-7843, which introduces a new feature for the “EIP” (EIP) system, and EIP-7843, which adds a slot number opcode to facilitate future slot length changes.

The meeting focused on discussions about conditional transactions and their implementation complexity, with Marius expressing concerns about the amount of work they would add to the mempool. Tim and Marc agreed to further discuss these issues with Marius. Potuz presented two EIPs aimed at separating execution from consensus, proposing to reuse the existing consolidations contract to pass arbitrary data to the consensus layer. Felix supported the idea of making the mechanism more generic, but noted that the current system contracts are not extensible and would need to be replaced if more data storage is required. The group agreed to continue discussions on these proposals.

Next Steps:

  • PenOps team: Help Devnet 3 reach finalization by end of tomorrow.
  • Client teams: Review and approve the blob schedule PRs by end of day tomorrow.
  • Barnabas: Merge the blob schedule PRs after 24 hours if no complaints are received.
  • All client teams: Continue working on fixes for syncing issues on Devnet 3 by mid-next week.
  • Lighthouse team: Provide fix for non-finality issue by mid next week.
  • PenOps team: Trigger another non-finality test next week after fixes are implemented.
  • All teams: Test syncing fixes once available next week.
  • PenOps team: Schedule Devnet 5 launch for end of next week if Devnet 3 issues are resolved.
  • All teams: Prepare for Devnet 5 launch after client fixes are deployed and tested.
  • Barnabas: Continue monitoring Devnet 3 recovery and participation rates.
  • All teams: Discuss slow sync theories in Monday’s testing call.
  • Alex: Update the Fusaka timeline based on the current state of devnets.
  • Alex: Create an updated Fusaka timeline following the process document requirements.
  • Alex: Reach out to rollups and other stakeholders to confirm their preferences regarding the timeline between releases and testnet forks.
  • Client teams: Prepare for shadow forks on Holesky, Sepolia, Goerli, and Mainnet.
  • Tim: Prepare an announcement in the next week about Polesky deprecation after Fusaka goes live.
  • Besu team: Test their improved implementation for Mod and Division opcodes in the next few days.
  • Client teams: Continue working on performance improvements to support 60 million gas limit before Fusaka.
  • Client teams: Consider including 60 million gas limit as default in testnet releases when ready.

Recording Access: