All Core Devs - Consensus (ACDC) #178, May 14, 2026

Protocol Calls & happenings
,
1

Agenda

  • glam
  • hegotá

Meeting Time: Thursday, May 14, 2026 at 14:00 UTC (90 minutes)

GitHub Issue

2 Likes
2

Video, transcript & chatlog

News coverage

Resources

1 Like
3

Meeting Summary:

The meeting focused on scoping and planning for DevNet 4, with extensive discussions about EIPs and technical implementations. The team reviewed EAT-70, EAT-71, and EAT-72 specifications, with Barnabas explaining that EAT-72 would be better suited for Blob DevNets rather than Glamsterdam DevNet 4 due to current limitations with Lighthouse handling blob transactions. The group discussed adding target gas limits to payload attributes, with Nico presenting changes that would allow per-validator gas limit configuration and support for GLOAs. They also reviewed dual deadlines for payload and blob data availability, with Potuz advocating for implementation to enable reorging of late payloads. Sukun presented a committee attestation broadcast specification aimed at increasing subnet sizes and reducing epoch times by 4X, proposing batched attestation data transmission and reduced mesh sizes. Francesco and Ignacio then introduced EIP-8025 for optional execution proofs, explaining how it would make payload validation sublinear and stateless through cryptographic proofs, with both consensus layer and execution layer specifications already defined and implemented in multiple clients.

Click to expand detailed summary

The team discussed the inclusion of EIPs in the Glamsterdam DevNet 4 scoping. They agreed to include EAT-70 and EAT-71, while deferring EAT-72 to Blob DevNet due to implementation challenges and lack of support from some clients like Lighthouse. Bosul mentioned ongoing work on finalizing the specification for EAT-72, and Kamil shared an updated EIP for the sparse blob pool. The group aligned on including EAT-70 and EAT-71 in both Glamsterdam DevNet 4 and Block DevNet 7 to avoid feature drift.

The team discussed changes to the engine API to include target gas limits in payload attributes, moving away from static flags on the EL side. Nico explained that this change would allow per-validator configuration and be necessary for GLOAs using vanilla ELs as builders. The group agreed that EL developers should review and approve the related PRs (5223 and 5236) before Monday, with the changes planned for inclusion in the next DevNet. There was consensus that this modification should be mandatory and part of the required fields, with no significant concerns raised by CL developers present.

The team discussed merging dual deadlines for payload and data availability to enable benchmarking without requiring code changes on clients. Potuz proposed using different deadlines to prevent payloads from executing into the next slot, which received support from Toni and others. Justin agreed to merge the necessary PRs, pending review from other clients. The group also touched on pre-validating pending deposit signatures and the scope of upcoming DevNets, with Barnabas suggesting that remaining EIPs could be included in GLAM DevNet 5 if BAL7 launches successfully. Potuz emphasized the need to complete current implementations and focus on testing fork choice accuracy rather than adding new features.

The team discussed implementing changes to handle deposit transactions, with Terrence presenting benchmarking results showing that 8,192 deposits can be batch verified in 800 milliseconds on current hardware. The group agreed to continue testing with existing clients like Prism and Teku for a few days while waiting for additional client branches, including from Lighthouse. They decided to cap the gas limit at 190 million for Amsterdam to prevent accidental triggering of the overflow issue, with plans to increase it to 200 million once the 7688 solution is implemented in future versions.

The team discussed two approaches for implementing SSZ (Simple Serializable JSON) in the Engine API. Barnabas proposed a straightforward approach that translates the existing API structure into REST with minimal changes, while Marius suggested a more comprehensive refactoring of the entire API structure. Łukasz reported that their team achieved a 5-10x performance improvement over JSON using Barnabas’s approach. The group agreed to collect more opinions and discuss both options at the upcoming ACDT meeting before making a decision on which approach to implement.

Sukun presented a proposal to increase subnet and committee sizes by 4x to reduce epoch time from 32 to 8 slots. The key changes include batching attestation messages, reducing gossip overhead, and decreasing the mesh size (D value) from 8 to 4. Simulation results showed significant improvements in bandwidth usage and propagation time, with the new system performing similarly for 2,000 validators as the current system does for 500 validators. Sukun indicated the changes could be deployed without requiring a fork, building on top of the partial messages proposal for blocks.

The team discussed updates to specifications and potential changes to the fast finality roadmap, including shortening slots per epoch and adjusting attester caps. Potuz raised concerns about the impact on fast confirmation rules and suggested analyzing vote effectiveness. Sukun agreed to consider these points and conduct further analysis on the proposed changes. The group also debated the utility of the “I have” and “I want” gossip systems, with Sukun indicating a preference to measure their effectiveness on mainnet before making decisions. Barnabas suggested implementing feature flags for the ETH B2B rollout to enable testing of different P2P configurations without increasing bandwidth requirements.

The meeting focused on discussing EIP-8025, which introduces optional execution proofs into the protocol. Francesco and Ignacio from the ZK EVM team presented the proposal, explaining how it enables sublinear payload validation through cryptographic proofs. The EIP includes two opt-in modes: proof generating mode for validators and proof verifying mode for other nodes. The team has implemented both consensus layer and execution layer specifications, with client implementations in Lighthouse and Prism. The proposal aims to gather data and build confidence in the system before potentially enshrining it in a future hardfork. The conversation ended with questions about protocol changes and validation processes, with the presenters clarifying that proof verification does not gate attestation and that the notify new payload call is fire and forget.

Next Steps:

  • Barnabas: Coordinate with client teams about inclusion of EAT-72 in Blob DevNet 0/1, ensuring Lighthouse blob transaction support is available before proceeding.
  • Bosul: Finalize and iron out remaining local spec changes for EAT-72, then share the frozen spec so client teams can begin implementation.
  • EL developers: Review and approve Nico’s engine API PR (11444) for adding target gas limit to payload attributes before Monday’s ACDE call.
  • Nico: Ensure consensus specs PRs 5223 and 5236 are ready for review and inclusion in Glamsterdam DevNet 4.
  • Justin: Merge dual deadlines PRs (use different deadlines for payload and blob data availability) today or as soon as possible.
  • Justin: Review and merge PR for pre-validating pending deposit signatures (share PR link with team for review first).
  • Terence: Open clean PRs for review of the deposit benchmarking/batch verification work (currently on branch “Glamserdan.net3deposit”), targeting a few days timeline.
  • Parithosh: Run benchmarking tests for builder deposit processing on reference hardware using Prism’s branch and Teku’s existing implementation.
  • Lighthouse team: Provide a branch with deposit processing time logging/benchmarking support so processing times can be measured alongside Prism and Teku.
  • All CL client teams: Review and provide feedback on the dual deadlines PRs and begin implementation so that block reorging can be enabled once DevNet 4 is stable.
  • Barnabas: Cap gas limit to 190 million for Glamsterdam DevNet 4 to avoid triggering overflow issues before EIP-7688 is included.
  • Parithosh/Barnabas: Add SSE Engine API topic (Barnabas’s PR vs. Marius’s PR) to the ACDE agenda for broader discussion and consensus before merging.
  • Nethermind (Łukasz) and any available CL team: Prototype and test both SSE Engine API approaches (Barnabas’s REST translation vs. Marius’s named fork approach) and report findings.
  • Sukun: Move committee attestation broadcast specification (EIP for Hagotah) from EIP-B2B into the consensus spec repo and address feedback (dropping I-have/I-want, removing redundant checkpoint data from attestation data).
  • Sukun: Analyze how reducing slots per epoch affects the fast confirmation rule and share numbers with the team.
  • Francesco/Ignacio (EF ZK EVM team): Share EIP-8025 specs and implementation links with client teams for review; continue iterating on the EIP based on feedback received.
  • Parithosh: Schedule discussion of “return deposits for distinct credentials” and “custom suite thresholds for validators” EIPs for the next ACDC call.

Recording Access:

4

YouTube Stream Links: