The Consensus Layer Meeting 152 focused on key Ethereum updates, including Holesky Testnet finality issues and validator participation. Discussions covered the Pectra Shadow Fork as a parallel testing solution and Pectra Sepolia Fork debugging efforts. Developers assessed Pectra Mainnet Readiness, reviewing dependencies and finality conditions for a stable launch. The meeting concluded with a fee mechanism analysis, exploring griefing risks, withdrawal processing concerns, and potential solutions to enhance network resilience.
- Holesky Testnet Updates
- Pectra Shadow Fork
- Pectra Sepolia Fork Updates
- Pectra Mainnet Readiness
- Fee Mechanism Analysis
Holesky Testnet Updates
The discussion on Holesky revolved around its current performance, challenges faced by clients, and possible mitigations to ensure stability.
Holesky has been struggling with non-finality issues, where transactions fail to reach a confirmed state. However, a recent increase in participation provided a glimmer of hope. Some client teams, particularly Lighthouse, reported temporary mitigations that made their nodes more manageable, though they did not fully resolve the underlying structural inefficiencies.
One of the major concerns highlighted was the inefficient storage and management of tree states. Currently, these states are being stored in multiple locations—within the freezer database (cold DB), in-memory structure, and hot database. However, the hot database, which is supposed to store only unfinalized states, is getting overwhelmed, leading to excessive disk usage.
This inefficiency has made Holesky’s non-finality period particularly resource-intensive, forcing clients to implement ad hoc solutions.
The extended period of non-finality has significantly impacted resource consumption across the network. Many Consensus Layer (CL) clients are consuming high amounts of memory and disk space, leading to operational inefficiencies.
With tree states being duplicated across different storage systems, disk space is rapidly filling up, causing additional strain on client nodes. The prolonged lack of finality has worsened this situation, with validators struggling to keep their nodes running.
Based on current conditions, it was estimated that Holesky could finalize by March 28, approximately 22 days from the meeting date. This prediction assumed that no further setbacks would arise and that validator participation levels remained stable.
However, concerns remained that any additional delays would continue straining client resources, further impacting testing efforts for upcoming Ethereum upgrades.
With Holesky’s finality still weeks away, the discussion turned toward potential recovery strategies and the possibility of launching an alternative testnet. The central question was whether Holesky should remain the primary testnet once finality is restored or if it should be replaced.
Four primary options were considered:
- continuing to use Holesky post-finality
- creating a new testnet to replace it
- launching a temporary Shadow Fork as a contingency plan
- or adopting a hybrid approach that preserves Holesky while also deploying an alternative testnet.
Various stakeholders, including client teams, staking providers, and developers, weighed in on whether Holesky should be maintained or replaced. Lido, a major staking provider, emphasized that Holesky was critical for their operations, particularly for testing protocol updates, integrations with DeFi protocols like Aave and EigenLayer, and monitoring tools.
In the end, the decision was made to take a hybrid approach—continuing efforts to finalize and stabilize Holesky while simultaneously launching a Shadow Fork to serve as a backup. The situation remains fluid, and the long-term viability of Holesky will be reassessed once finality is achieved.
Pectra Shadow Fork
Given the ongoing challenges with Holesky, the discussion shifted towards the creation of a Shadow Fork to act as a temporary test environment. The primary objective of this Shadow Fork would be to replicate Holesky’s conditions while eliminating some of the issues that have made the network unusable.
The Shadow Fork would provide a controlled environment for testing and allow developers to diagnose issues without the unpredictability caused by Holesky’s non-finality. The key benefit of a Shadow Fork is that it would mirror Holesky’s validator set, state, and network conditions, making it an effective sandbox for testing.
A major point of discussion was how quickly a Shadow Fork could be implemented. Unlike launching a brand-new testnet, setting up a Shadow Fork was seen as a faster solution, potentially taking only a week.
Beyond Holesky and the Shadow Fork, other Ethereum testnets were considered for temporary testing. Devnet 7 and Ephemery were two testnets that had been spun up previously, and some developers suggested that they could be used to offload testing workloads. However, these networks had their own limitations.
Additionally, there was a decision to shut down some older testnets, including the Mekong testnet. Mekong had been running an older version of the Ethereum protocol for some time, but most developers had already moved their testing efforts to newer environments.
Pectra Sepolia Fork Updates
Aside from the ongoing Holesky situation, developers also discussed recent developments on the Sepolia testnet, which had undergone a Pectra fork. But it encountered unexpected issues related to how different EL clients processed transactions.
The main issue stemmed from custom deposit contracts, which some EL clients handled differently. This inconsistency caused temporary disruptions in Sepolia’s functionality, requiring rapid debugging and fixes from client teams.
Fortunately, developers were able to quickly diagnose and resolve the issue, restoring the network to a healthy state. One major takeaway from this incident was the importance of standardizing how deposit contracts are processed.
Developers noted that certain EL clients parsed contract logs differently, leading to discrepancies that could result in network failures if not addressed. To prevent this from happening on mainnet, a proposal was introduced to ensure that all EL clients adhere to the same encoding standards when handling deposit contract logs.
Another key observation from the Sepolia fork was that, despite the initial issues, the network had stabilized faster than expected. Some developers even noted that Sepolia was in the best condition they had ever seen it, making it a viable environment for further testing.
Pectra Mainnet Readiness
As Ethereum moves towards its next major upgrade, timing considerations for mainnet deployment were discussed. The consensus was that Holesky’s recovery and the Shadow Fork’s success would play a crucial role in determining when Ethereum’s new features would be rolled out on mainnet.
A key point of concern was that several unresolved EL client issues still needed to be addressed before setting a concrete mainnet release date. These included the ABI encoding issue, some network stability concerns, and attestation-related bugs that were still being diagnosed.
Developers emphasized that rushing into a mainnet upgrade without thorough testing could introduce new vulnerabilities, particularly given the complexity of the changes in the upcoming upgrade. Another challenge was that some staking pools and node operators were still waiting for clarity on network conditions before upgrading their setups.
Many were hesitant to make major changes until it was clear whether Holesky would remain a viable testnet or if the community would transition to the Shadow Fork or a new testnet entirely. Given these uncertainties, the general agreement was that no firm mainnet release date should be set until Holesky finalizes and the Shadow Fork is thoroughly tested.
Fee Mechanism Analysis
The discussion shifted to Ethereum’s fee mechanism, focusing on concerns about griefing attacks & exploit vectors in staking withdrawals. A key issue was whether attackers could manipulate withdrawal fees to block other users.
One proposed attack involved inflating the fee market, making withdrawals too costly for validators. While sustaining such an attack long-term would be expensive, even brief disruptions could destabilize Ethereum’s staking ecosystem.
An analysis found denial-of-service (DoS) attacks on withdrawals were unlikely to be profitable, but griefing attacks—causing delays at minimal cost—remained a concern. One proposed fix was adjusting fees per request instead of per block to prevent sustained high fees.
However, developers were cautious about changes that could complicate Ethereum’s Consensus Layer (CL). Another idea was increasing the withdrawal target rate for faster processing, but this risked overloading CL resources.
Related Articles
- Highlights of Ethereum's All Core Devs Meeting (ACDE) #206
- Highlights of Ethereum's All Core Devs Meeting (ACDE) #205
- Highlights of Ethereum's All Core Devs Meeting (ACDC) #150
- Highlights of Ethereum's All Core Devs Meeting (ACDE) #204
- Highlights of Ethereum's All Core Devs Meeting (ACDC) #149
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!