The All Core Devs Consensus (ACDC) Call 156 focused on final preparations for the upcoming Pectra mainnet upgrade, with discussions centered around the shadow fork results, client release alignment, and last-minute coordination. The call also reviewed issues from PeerDAS Devnet 6, outlined plans for Devnet 7 under the Fusaka upgrade, and confirmed timelines for upcoming consensus spec releases tied to Pectra.
Pectra Updates
The core focus of this ACDC call was the progress & outstanding issues surrounding the Pectra network upgrade, which is a major upcoming Ethereum consensus layer fork. The conversation opened with a status check on the mainnet shadow fork, a test fork that replicates mainnet conditions to identify client bugs or misconfigurations ahead of real deployment.
The mainnet shadow fork had proceeded mostly without issue. However, there were deposit problems reported by some clients, which stemmed not from bugs in the clients themselves but from the shadow fork configuration.
Specifically, the fork used the same deposit contract address as the mainnet, which had not been the case in previous shadow forks. This design decision inadvertently led to issues with the deposit queue, requiring it to be reprocessed and invalidated by all consensus layer clients.
The discussion revealed that different client teams handled the fallout in different ways. The core takeaway was that this misconfiguration wouldn't be replicable on the real mainnet since the circumstances were unique to the shadow fork setup.
One of the client teams, Lighthouse, had released version 7.0.1 the previous day. This version was reported to improve state cache miss handling, which can affect performance under specific conditions.
While not critical for everyone, it was considered a "nice to have" for those affected users. The team expressed a mild preference that it be the release version referenced in the blog update, but they did not insist on making it mandatory.
As the meeting progressed, the conversation shifted toward the final preparations and coordination for the actual rollout of the Pectra upgrade on Ethereum mainnet. The overall sentiment among participants was optimistic but cautious, with a strong focus on communication, documentation, & version control.
Core Devs acknowledged that Pectra had been a substantial and complex upgrade cycle. Several contributors expressed both relief and excitement that the launch window was now in sight.
A recurring issue throughout the call was ensuring that client versions referenced in the Ethereum Foundation’s blog post were both accurate and future-proof. With some clients releasing new versions right before the fork, the blog could refer to version “X or later” rather than pinning to a specific release.
This approach would allow users who had already upgraded to slightly earlier stable versions to remain compliant without forcing a last-minute upgrade, unless critical. Core Devs widely accepted that all client teams were “fork-ready,” with their final versions either already published or scheduled for release within hours.
Fusaka Updates
It was acknowledged early in the discussion that PeerDAS Devnet 6 encountered several issues, particularly around syncing and subnet configuration. The decision was therefore made to wrap up Devnet 6 and instead focus on launching Devnet 7, incorporating lessons learned and bug fixes from the previous iteration.
Due to the overwhelming focus and resource allocation toward the upcoming Pectra mainnet fork, most client teams had limited bandwidth to prioritize Fusaka-related development. Several contributors proposed delaying the launch of Devnet 7 until after Pectra was finalized, allowing teams time to shift their attention.
Validator custody was a key topic within the Fusaka scope. However, most participants agreed that validator custody was still weeks away from readiness.
The complexity of implementation and lack of cross-client consistency meant that even if a Devnet launched, many clients would not have this feature functioning correctly. Some participants suggested the need to either exclude validator custody from Devnet 7 entirely or allow it to be selectively enabled only in clients that had working, verified implementations.
There was concern about rolling out half-baked versions of validator custody that might cause instability or interoperability issues. Additional feedback emerged around subnet performance inconsistencies during Devnet 6.
Some clients had incorrectly reported having specific subnets or had difficulty serving them, which led to communication breakdowns within the test network. These networking issues, compounded by sync-related bugs, contributed to the Devnet 6 shortcomings and were being analyzed for fixes.
To address syncing in Devnet 7, some client teams like Lighthouse specifically requested that Devnet 7 be deployed sooner, even in parallel to ongoing fixes, to help them debug more effectively. A specific HackMD draft spec was mentioned but flagged as possibly outdated.
Consensus Spec Updates
Core Devs discussed the timing of the next official consensus spec release, which was planned to occur on the same day as the Pectra mainnet upgrade, just a few hours after the fork. This was to ensure that any final changes or adjustments would be bundled together and deployed cohesively.
Attention was also called to another spec-related pull request, referred to as the "consensus specs blog schedule PR". This proposal aimed to document the spec and release planning more transparently and regularly, especially across major forks like Pectra and Fusaka.
The request was made for more client teams to review and approve this PR, so it could be merged in time for inclusion in the next consensus spec release. Discussion turned toward whether the updated specs should be part of Devnet 7. There was a general understanding that if these changes were merged soon enough, they could be used as a baseline for Devnet 7.
ACDC Call #156 came at a key moment, just ahead of the Pectra mainnet upgrade. The conversation was clear and to the point, mainly focused on making sure all client teams were aligned—whether it was around testing outcomes, syncing issues, or version readiness. A few problems did show up during the shadow fork and Devnet 6, but they were discussed and addressed with solutions.
Related Articles
- Highlights of Ethereum's All Core Devs Meeting (ACDC) #153
- Highlights of Ethereum's All Core Devs Meeting (ACDE) #207
- Highlights of Ethereum's All Core Devs Meeting (ACDC) #152
- 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
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!