Highlights of Ethereum's All Core Devs Meeting (ACDE) #208

The All Core Devs Execution (ACDE) Call 208 centered around the successful activation of the Pectra fork on the Hoodi testnet and the proposed April 30th mainnet deployment. The call also introduced a formal upgrade process framework and assessed the readiness of clients & applications.

• Pectra Hard Fork on Hoodi
• Ethereum Protocol Upgrade Process
• Pectra Mainnet Fork Date
• Cell Proofs Computation
• EOF (EVM Object Format) Debate & Decision
• Fusaka Fork Scope Finalization
• History Expiry & Portal Network
• Protocol Research Call
• Sepolia Testnet Renaming

Pectra Hard Fork on Hoodi

The Pectra hard fork on the Hoodi testnet was successfully activated, with a stable participation rate observed soon after. Finalization occurred without any major hiccups, signaling that the network responded well to the changes.

Pari shared that while overall the upgrade went smoothly, two minor and non-critical issues were noticed. One issue was potentially linked to the Caplin Erigon validators, and another involved higher-than-expected resource usage on the Lighthouse client during the transition.

Fortunately, the Lighthouse team quickly addressed the issue and pushed a fix through a Beta 5 release. Although the fork itself went well, validator state testing is still ongoing.

Due to the open validator set and a large queue, final results—particularly concerning consolidations and manually triggered withdrawals—are expected to take a few more days. That said, there is optimism around how things are progressing so far.

On the application and infrastructure side, the Lido team confirmed a successful upgrade across all 14 of their node operators and four staking modules. All related oracles and reporting systems functioned as intended.

While Lido has not yet tested new functionality specific to Pectra—such as triggerable exits, consolidations, or changes related to max effective balance—they expressed confidence in the upgrade and praised the work of the client teams. Ether.fi is also preparing to begin testing but was previously held back by dependencies on Eigenlayer, which in turn was waiting on Gnosis Safe contracts to go live on Hoodi.

That particular bottleneck has now been resolved, as Gnosis Safe is confirmed to be active on the testnet. Overall, testing at the application layer appears to be progressing well.

Ethereum Protocol Upgrade Process

Fredrik from the Ethereum Foundation’s security team introduced a document that aims to formalize the entire upgrade process during hard forks. While most of the steps outlined in the document are already being followed in practice, the goal is to make them official and repeatable, ensuring no critical element is overlooked in future forks.

A key addition in this proposed process is the inclusion of an incident response plan, which assigns specific responsibilities to designated individuals ahead of the fork. These roles would include verifying that the fork has activated successfully, ensuring proper communication, and quickly addressing any incidents that may arise during or after the fork.

One major shift in thinking is the need for a more thorough verification stage. Rather than simply considering finality on a testnet as a sign of success, the process should also include checks to confirm that specific EIPs function correctly both on testnets and the mainnet.

The document also outlines suggested timelines between various phases of testing. For instance, it proposes a minimum of 14 days between testnets and a 30-day window between client releases and the first testnet upgrade. This buffer would allow time for bug bounties, internal security audits, and external reviews.

While some teams agreed with this cautious approach, there was an acknowledgment that these timelines might slow things down, and feedback on this aspect is still open for discussion. The conversation also touched on how this formal process should be maintained.

Pectra Mainnet Fork Date

With testing progressing steadily on Hoodi, the conversation turned toward selecting a tentative date for the mainnet Pectra fork. April 30th was proposed as the earliest possible date, which aligns with the required 30-day buffer following the Hoodi testnet activation.

This buffer ensures enough time for thorough testing by client teams, infrastructure providers, and application developers. The general consensus in the meeting leaned toward setting this as a tentative fork date, pending confirmation from a few remaining stakeholders.

More accessibility. More education. More power to Ethereum! ⚡️

🚨 Pectra mainnet upgrade may land on April 30 (slot 11599872)!

🗒️Expect client mainnet release specs blogpost between April 10–14.

A final decision will be made in the next ACD(C) call.

📢 For the first time,… https://t.co/TSNhhNmQmJ

— Pooja Ranjan | ranjan.eth (@poojaranjan19) March 27, 2025

While most client teams signaled that releasing their mainnet-ready versions by mid-April (between April 10–14) would be feasible, some dependencies at the application layer raised concerns. The plan includes finalizing client releases, publishing a blog post at least two weeks in advance, and assigning point-of-contact individuals from each client team to monitor the upgrade as it happens.

Cell Proofs Computation

Then, the discussion shifted to computation of cell proofs — a key operation involved in handling blob data in Ethereum. The central question was whether this computation should be handled by the execution layer (EL) or the consensus layer (CL) clients.

Historically, the CL has been responsible for this, but as the functionality evolves and becomes more performance-intensive, some developers have suggested shifting the burden to the EL to take advantage of better optimization opportunities. One key motivation for this shift is performance.

Execution clients typically have more efficient access to the relevant state and data structures needed to compute proofs, which could result in faster block processing and lower overhead. Additionally, by consolidating blob-related responsibilities in one layer, client development and debugging could become more streamlined.

However, this proposal isn’t without trade-offs. Moving this logic to the EL introduces more complexity to that layer and requires clear coordination between EL and CL implementations.

Teams have already begun experimenting with the migration in private forks and devnets. Proto Lambda shared that he has implemented the computation logic in the EL and is seeing promising performance improvements.

EOF (EVM Object Format) Debate & Decision

A major topic of discussion in the call centered around the long-debated EVM Object Format (EOF)—a structural change to how smart contracts are encoded and executed in the Ethereum Virtual Machine. The conversation focused on determining whether and how to include EOF in the upcoming Fusaka fork.

Over time, several versions of EOF had been proposed, each varying in complexity and scope. In this meeting, the debate narrowed down to three concrete options, with a strong lean toward a simplified and modular version known as Option A + Pay Opcode.

The main appeal of Option A was its minimalism. It includes the core benefits of EOF—structured code, better validation, and future extensibility—without overwhelming client teams with complexity.

This version also proposes a new PAY opcode, which enables more gas-efficient transfers and aligns with future design goals around contract modularity and account abstraction. The team felt this balance struck the right compromise between ambition and practicality, especially given the workload already lined up for Fusaka.

There was some pushback, mostly around the idea that even a minimal EOF adds a lot of developer overhead. Clients must ensure compatibility, tooling needs updates, and smart contract authors need to be educated.

The PAY opcode was also debated, but most agreed that including it upfront, rather than backporting it later, made more sense given its low risk and potential gas savings. In the end, while no formal vote occurred, there was clear momentum behind proceeding with Option A + PAY opcode for Fusaka.

Fusaka Fork Scope Finalization

With momentum building around the Fusaka fork, the discussion moved to finalizing its scope. While the inclusion of EOF (Option A + PAY) was nearing consensus, teams also reviewed several other EIPs that had been proposed before the submission deadline.

One notable addition was EIP-7883, which focuses on ModExp (modular exponentiation) repricing. This EIP aims to make gas costs more predictable and reflective of actual computational effort, especially important for applications that rely heavily on cryptographic operations.

The ModExp repricing proposal was accepted into the Fusaka (CFI) list without major objection. Its implementation is relatively straightforward, and the performance benefits are well understood.

There was also a broader reflection on how Ethereum upgrade planning is evolving. Rather than trying to fit every good idea into a single fork, the emerging strategy is to space out changes more deliberately.

ACDE #208
⏱️ 90-minute call.
👨‍💻 140 devs in the room.
🚀 One mission: ship the next Ethereum upgrade.

Missed the live stream? Check out the audio podcast shared by @oceansofmilk form @EthCatHerders.

🎧https://t.co/JAcGP3Qxy1#ethereum #ACD #ethdevs #podcast #Pectra https://t.co/YGmcOp5STI pic.twitter.com/RmLJNzS40v

— Pooja Ranjan | ranjan.eth (@poojaranjan19) March 27, 2025

History Expiry & Portal Network

The meeting then moved on to the topic of history expiry, a feature aimed at reducing the storage burden on Ethereum nodes by pruning old chain history. This feature is now being actively tested on the Sepolia testnet.

Developers discussed the timeline and how to manage the transition, particularly the need for clients to coordinate both consensus and execution layer behavior to avoid unexpected behavior when historical data is removed. There was a strong emphasis on ensuring that client teams are ready, both in terms of technical implementation and proper documentation.

Some final fixes were still being rolled out, but the general feeling was that the ecosystem was on track. Plans are in place to gradually reduce the historical data range stored by nodes, with clearly defined boundaries and fallbacks.

This transition is expected to start soon after the Pectra fork, allowing time for testing and stability. The conversation also highlighted the role of the Portal Network, a lightweight peer-to-peer network designed to serve historical data in a more decentralized and bandwidth-efficient way.

As history expiry becomes a reality, tools like Portal will be increasingly important for serving older data that full nodes no longer store by default. This allows light clients and researchers to still access archival data without imposing a heavy load on the core network.

Protocol Research Call

Toward the end of the meeting, an announcement was made about the launch of a new Protocol Research Call series. The goal of this initiative is to create a dedicated space for deeper, more exploratory discussions that often get squeezed out of the regular core developer calls due to time constraints.

These calls will be open to researchers, client developers, and protocol designers, with the aim of surfacing longer-term ideas and experimental proposals earlier in the pipeline. The hope is that this format will provide a more relaxed, collaborative environment where topics like cryptographic primitives, sharding, new EVM features, or consensus innovations can be explored without the immediate pressure of inclusion in a near-term fork.

The call cadence is still being determined, but the expectation is that it will run on a bi-weekly or monthly basis depending on community interest. Overall, there was a positive reception to the idea, especially as Ethereum continues to mature and demands more structured coordination between research and engineering.

Sepolia Testnet Renaming

As the call neared its end, the team briefly touched on the topic of finding a replacement for the Sepolia testnet. With upcoming changes like history expiry and evolving infrastructure needs, the idea is to gradually transition to a new long-term testnet.

The discussion wasn't technical but focused more on the naming process. Contributors were encouraged to participate in an ongoing Ethereum Magicians thread, where community suggestions for the new testnet name are being collected.

The process is meant to be fun and collaborative, giving developers and users a sense of ownership over the network they’ll be relying on for years to come.

In the final wrap-up, the coordinators outlined a few key next steps. One was to finalize and merge the meta-EIP PRs that document the decisions made during the call, especially regarding Fusaka scope and the tentative Pectra mainnet timeline.

Another was to begin coordinating point-of-contact assignments for the upcoming Pectra fork so that each client has a designated lead ready for upgrade monitoring. There was also a reminder to review and comment on the new upgrade process documentation shared by Fredrik, as it will soon become the template for future forks.

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