Highlights of Ethereum's All Core Devs Meeting (ACDC) #153

The Consensus Layer Call 153 focused on key updates for the Hoodi Testnet and discussions around Pectra mainnet readiness. The meeting also addressed the challenges of history expiry, particularly its dependencies on EIP-6110. Additionally, there were discussions on validator custody dynamics, PeerDAS Devnet updates, and Fusaka’s potential EIP-7688 inclusion.

• Hoodi Testnet Updates
• Pectra Mainnet Readiness
• Pectra Devnet 6
• History Expiry
• PeerDAS Devnet 5 & Devnet 6
• EIP-7688

Hoodi Testnet Updates

The Hoodi testnet has officially launched with a major milestone in this process, i.e., Pectra upgrade, scheduled for Wednesday, March 26. So far, the testnet is running smoothly, and developers are actively monitoring its performance to ensure a stable transition.

Client teams are working toward full compatibility with Hoodi, with Lodestar already confirmed to be fully supported. However, some clients, like Reth, do not yet have a formal release but expect their main branch to function properly.

Meanwhile, Lighthouse & Geth are actively developing updates to achieve full compatibility, with releases anticipated soon. Core Devs encouraged community involvement, particularly for infrastructure testing, and reminded participants to keep their clients updated.

Pectra Mainnet Readiness

The discussion on Pectra’s readiness for mainnet deployment focused on several critical factors that must be met before proceeding. A key prerequisite is the stability of the Hoodi testnet, with the March 26 upgrade serving as a crucial milestone.

Additionally, an active bug bounty competition running until March 24 could impact the timeline if critical vulnerabilities are discovered. Client team feedback also played a role, with some expressing caution about moving forward too quickly.

The consensus was to hold off on setting an immediate mainnet launch date while prioritizing stability. The team will continue working on bug resolution, monitoring Hoodi’s performance, & reviewing bug bounty findings.

Source: Expected Dates by abcoathup.eth

Pectra Devnet 6

Pectra Devnet 6 is testing the effects of increasing the gas limit to 60 million. This was done to assess how well clients handle higher transaction loads and whether increasing gas limits causes performance issues in execution and consensus clients.

Following the gas limit increase, several execution-layer clients experienced performance issues, particularly with memory consumption. Geth & Lighthouse struggled the most, showing high RAM usage and even out-of-memory crashes under certain conditions.

Other client pairs, such as Besu & Teku, also faced some difficulties, though they proved to be more stable in handling the increased load. The testing process revealed that some clients required significant optimizations to keep up with the demands of the new gas limits.

The resource requirements for running nodes also increased substantially. Initially, many nodes were running with 8 GB of RAM, but this proved to be insufficient, leading to performance degradation.

After adjusting configurations, 16 GB of RAM became the new baseline for stable operation. Geth & Lighthouse continued to struggle more than other clients, showing that further optimizations are needed. Moving forward, developers will continue stress testing

History Expiry

History expiry is a mechanism designed to remove older blockchain history, optimizing storage & improving network efficiency. As part of Ethereum’s long-term upgrade plan, there has been a commitment to expire pre-merge history, with an initial target set for May 1st, 2025.

This change aims to reduce the storage burden for node operators by eliminating unnecessary data. However, history expiry is dependent on EIP-6110, which introduces a new way to manage Ethereum’s deposit logs.

Until EIP-6110 is fully activated, all deposit logs must remain intact, making it essential to align history expiry with the upgrade’s rollout. Since EIP-6110 is only live in Pectra, this creates a dependency between Pectra’s deployment & history expiry.

A key challenge discussed was the uncertainty around Pectra’s mainnet launch, which could impact the May 1st history expiry deadline. The team debated whether to delay history expiry until after Pectra is fully deployed or explore alternative solutions.

One proposed approach was to expire history only before the deployment of the deposit contract, rather than removing all pre-merge history. This compromise would preserve critical deposit logs while still reducing storage requirements.

To ensure a smooth implementation, history expiry has already been activated on Sepolia, but it has not been widely tested. The team emphasized the need for formal testing, including assessing how many nodes drop history, evaluating network-wide synchronization, & ensuring system stability.

PeerDAS Devnet 5 & Devnet 6

Devnet 5 has remained relatively stable, with most client implementations functioning as expected. However, Lighthouse encountered syncing issues that were identified & resolved.

A major challenge arose with the Prysm client, where its database design led to over 10 million data columns & files, causing performance issues. The team is now working on redesigning the database to prevent excessive file creation, aiming to resolve this before the launch of Devnet 6.

Validator custody, originally planned for Devnet 6, is now being fast-tracked to Devnet 5 for earlier testing & feedback. This change allows developers to make necessary adjustments before a wider rollout.

Additionally, validator custody will be evaluated on a separate Kurtosis-based test network to ensure secure storage & retrieval of data under varying network conditions. Parallel to these efforts, P2P key fuzzing experiments are underway, with a 16-node network simulating real-world validator interactions.

Further testing efforts include experiments with higher blob counts, revealing peering issues at scale. Devnet 6 will focus on validator custody as a primary test case, along with network scaling tests & performance tuning for high blob counts.

EIP-7688

EIP-7688 is a proposal that introduces stable container structures within Ethereum’s state storage. Ethereum’s generalized index structure (G-indices) is not stable across upgrades. If an SSZ structure is modified, all indices shift, requiring updates across smart contracts and governance mechanisms.

This creates complex upgrade dependencies for applications like Lido, RocketPool, & EigenLayer. Stable containers prevent breaking changes in index references.

Additionally, they reduce governance overhead by eliminating frequent manual updates and enable future state optimizations, making it easier to reduce beacon state size.

Major staking pools strongly support EIP-7688. They currently face upgrade headaches due to shifting indices. Lodestar and Nimbus have already started implementing EIP-7688, with other clients expected to follow soon.

Related Articles

1. Highlights of Ethereum's All Core Devs Meeting (ACDE) #207
2. Highlights of Ethereum's All Core Devs Meeting (ACDC) #152
3. Highlights of Ethereum's All Core Devs Meeting (ACDE) #206
4. Highlights of Ethereum's All Core Devs Meeting (ACDE) #205
5. Highlights of Ethereum's All Core Devs Meeting (ACDC) #150