Ethereum client teams gathered during ACDC #180 to review the latest progress on the Glamsterdam upgrade while also discussing early proposals that could eventually become part of the Hegota fork. The meeting highlighted both the technical challenges facing current devnets and the longer-term scalability improvements being explored for Ethereum's consensus layer.

As Ethereum continues progressing toward the next generation of protocol upgrades, developers are simultaneously addressing implementation issues, refining networking infrastructure, improving validator APIs, and evaluating future consensus-layer optimizations. The discussions revealed how Ethereum's development process balances immediate stability concerns with long-term protocol evolution.

• Glamsterdam Updates
• Hegota Updates

Ethereum's current roadmap builds upon the foundations established during recent upgrade cycles. Readers looking for broader context can explore EtherWorld's coverage of the Glamsterdam Devnet 5 launch, as well as previous analyses of Ethereum's evolving upgrade roadmap.

Glamsterdam Updates

The primary focus of the call was the status of Glamsterdam Devnet-5, which remains unstable due to a combination of client implementation bugs and network behavior issues discovered during testing.

One major challenge involves a Prysm peering bug whose fix is currently rolling out across testing environments. At the same time, developers continue investigating a Grandine fork-choice issue that remains unresolved. Interestingly, many of these problems surfaced after testing conducted with a malicious Lodestar client that intentionally built chains on empty blocks, exposing edge cases that normal network conditions might never reveal.

Another significant topic involved PTC attestations. Developers discovered that Prysm was broadcasting invalid PTC attestations across shuffling boundaries during extended fork scenarios. A temporary mitigation has already been deployed, causing clients to skip PTC duties whenever they are not part of the committee responsible for the observed block's shuffling configuration.

However, the broader concern extends beyond this individual bug. Developers noted that all clients currently perform PTC duties based solely on the canonical chain head. Potuz highlighted a potential liveness risk in situations where multiple competing branches exist and no cross-branch PTC attestations are available. Such scenarios could introduce challenges for network recovery and finality under prolonged fork conditions.

Beyond devnet stability, significant progress was made on API improvements. The Gloas Proposer Preference API reached an important milestone through Beacon APIs PR #608. The proposal introduces new POST and GET endpoints alongside Server-Sent Events (SSE) functionality while simultaneously deprecating legacy endpoints such as prepare-beacon-proposer and register-validator.

The proposal received no objections from client teams and has effectively been cleared for merging. This represents another step toward modernizing Ethereum's validator infrastructure while simplifying proposer interactions.

Networking improvements were another major focus area. Client teams discussed the ongoing transition toward QUIC as Ethereum's primary transport protocol. While there is broad agreement that QUIC offers significant advantages over existing networking solutions, developers emphasized the need for a gradual migration strategy.

Rather than immediately removing MPLEX, consensus was reached to maintain it as a fallback transport layer. Lighthouse intends to disable MPLEX approximately two months after Gloas, while Teku and Nimbus require additional time before fully transitioning. Nimbus already has a working implementation but has not yet enabled it by default.

The decision reflects Ethereum's commitment to avoiding network fragmentation during infrastructure upgrades. Cross-client coordination remains a critical priority whenever changes impact peer-to-peer networking.

The meeting also covered several Beacon API improvements. Validator state terminology has become increasingly outdated following the introduction of EIP-6110 and EIP-7251. Developers discussed proposals to rename validator pending states to better reflect actual validator lifecycle behavior after Electra and future upgrades.

Additional Beacon API enhancements include optional peer scoring and disconnect reason reporting through updates to the /eth/v1/node/peers endpoint. Since these changes remain backward compatible, client teams expressed support for moving forward without major concerns.

The ePBS ecosystem also received attention. One proposal attracting significant discussion was EIP-8282, which introduces a dedicated builder deposit contract.

The proposal aims to reduce denial-of-service risks associated with sharing a deposit contract between validators and builders. Built upon architectural concepts already established by EIP-7002 and EIP-7251, the proposal is widely viewed as the correct long-term direction. However, developers remain cautious about introducing changes that could delay the Glamsterdam timeline. As a result, the proposal was deferred for additional analysis and discussion in upcoming meetings.

Builder infrastructure discussions also included Builder-specs PR #138, commonly referred to as the Staked Builder API. The proposal received approval and is expected to merge soon, with future enhancements planned through follow-up pull requests. Meanwhile, Builder-specs PR #162 remains under discussion due to concerns around stateful mappings and the need for beacon nodes to track builder-specific bid origins.

For additional background on Ethereum's proposer-builder separation roadmap, readers may also enjoy EtherWorld's coverage of Ethereum's evolving builder ecosystem and PBS-related research developments.

Hegota Updates

While Glamsterdam remains the immediate priority, developers also examined early proposals that could potentially become part of Hegota.

The centerpiece of the discussion was EIP-8243, a proposal focused on pre-aggregating attestations at their source.

Under the proposal, operators managing co-scheduled validators would be able to submit a single pre-aggregated attestation through a batcher and batch-seal mechanism. The goal is straightforward: significantly reduce consensus-layer network traffic while maintaining security guarantees.

Early estimates suggest the approach could reduce wire traffic by approximately two times. Given Ethereum's growing validator set and increasing network complexity, such bandwidth savings could become increasingly valuable over time.

However, as with most protocol changes, the proposal introduces trade-offs. Developers spent considerable time discussing whether the complexity introduced by batching infrastructure is justified when compared with simpler alternatives such as increasing the number of aggregators.

Security considerations were also examined. Researchers noted that spam risks remain bounded at roughly twice the committee size, helping contain potential abuse. Nevertheless, further analysis will be required before determining whether the proposal offers sufficient benefits to warrant inclusion in a future fork.

If time had permitted, the call would also have revisited two additional proposals already familiar to many client teams.

The first is EIP-8061, which seeks to increase exit and consolidation churn limits. The proposal has already been implemented and tested since Devnet-1, with developers reporting that weak-subjectivity parameters remain tunable and manageable.

The second is EIP-8080, which proposes routing exits through the consolidation queue. The proposal has previously been discussed in interoperability meetings and remains a candidate for future consideration.

Together, these discussions demonstrate that Ethereum's development process extends far beyond the next scheduled fork. While Glamsterdam focuses on stabilizing networking, APIs, validator infrastructure, and builder workflows, Hegota represents an opportunity to explore more ambitious consensus-layer efficiency improvements.

As client teams continue preparing for Devnet-6 and refining Glamsterdam's feature set, the broader Ethereum research community is already laying the groundwork for what comes next. Whether through attestation batching, validator lifecycle improvements, networking upgrades, or builder ecosystem refinements, the protocol continues its iterative journey toward greater scalability, resilience, and decentralization.

If you find any issues in this blog or notice any missing information, please feel free to reach out at yash@etherworld.co for clarifications or updates.

To promote your Web3 articles, events, and projects, you may reach out anytime via EtherWorld PR for submissions and collaboration.

Related Articles

1. Highlights from the All Core Developers Consensus (ACDC) Call #179
2. Highlights from the All Core Developers Consensus (ACDC) Call #178
3. Highlights from the All Core Developers Consensus (ACDC) Call #177
4. Highlights from the All Core Developers Consensus (ACDC) Call #176
5. Highlights from the All Core Developers Consensus (ACDC) Call #175

To follow blockchain news, track Ethereum protocol progress, and read our latest stories, subscribe to our weekly today.