All Core Devs - Consensus (ACDC) #167, October 16, 2025

[nixorokish]

UTC Date & Time

October 16, 2025, 14:00 UTC

Agenda

• Fusaka
  • any callouts on devnet-3?
  • holesky BPO2
  • sepolia fork
  • Fusaka contest: All Core Devs - Consensus (ACDC) #167, October 16, 2025 #1754 (comment)
  • blob APIs
    • proof change with EL
    • getBlob endpoint with CL
    • related: All Core Devs - Consensus (ACDC) #167, October 16, 2025 #1754 (comment)
  • Only require nodes to publish custody columns from reconstruction consensus-specs#4657
  • fusaka mainnet: All Core Devs - Consensus (ACDC) #167, October 16, 2025 #1754 (comment)
  • sepolia BPO1 next week!
• Glamsterdam
  • trustless payments in ePBS
  • EIP-7688 PFI'd for Glamsterdam, although will defer inclusion discussion until Fusaka mainnet date is set
    • All Core Devs - Consensus (ACDC) #167, October 16, 2025 #1754 (comment)

Call Series

All Core Devs - Consensus

🔧 Meeting Configuration

Duration

90 minutes

Occurrence Rate

bi-weekly

Use Custom Meeting Link (Optional)

• I will provide my own meeting link

Facilitator Emails (Optional)

No response

Display Zoom Link in Calendar Invite (Optional)

• Display Zoom link in invite

YouTube Livestream Link (Optional)

• Create YouTube livestream link

[github-actions]

⚡ Protocol Call Resources:

✅ Zoom: Join Meeting
✅ Calendar: Add to Calendar
✅ Discourse: Discussion Topic
✅ YouTube Live: Watch Live

[etan-status]

I have rebased EIP-7688 on top of Gloas. That's the one that introduces stable generalized-indices across forks, reducing the maintenance churn (involving security councils) for builders that consume beacon data in their smart contracts. CL teams have explored this around the Kenya Interop, and quite a bit of feedback was integrated regarding implementation complexity, and design space limitations w.r.t. future forks (thanks @hwwhww).

• Forward compatible consensus data structures (EIP-7688) consensus-specs#4630
• https://eips.ethereum.org/EIPS/eip-7688

As for the design space:

• Lists / Containers grow to whatever size is required, without triggering re-indexing.
• Limits can be moved from per-list capacity to per-resource (e.g., max signature checks per block, could allow more proposer slashings when there are no BLS to execution changes)
• No more breakage when a container reaches a new power of 2 number of fields.
• Fields can be deprecated, leaving a hole in the Merkle tree, the subsequent fields don't move, no breakage.
• Fewer data types that are depending on presets (forked schema).

I am proposing to include EIP-7688 into Gloas.

• Discord discussion: https://discord.com/channels/595666850260713488/598292067260825641/1424863530359853056

[0xFredrik]

Proposing to have a brief mention about Fusaka Contest having ended on the 13th of October and some of the learnings from it

[koenmtb1]

On behalf of Aztec, I'd like to bring up a point around blob retrieval.
(I think there's points listed about this, but just making sure it's the issue we're facing)

Just posted a forum post on this issue.

[fernantho]

I have rebased EIP-7688 on top of Gloas. That's the one that introduces stable generalized-indices across forks, reducing the maintenance churn (involving security councils) for builders that consume beacon data in their smart contracts. CL teams have explored this around the Kenya Interop, and quite a bit of feedback was integrated regarding implementation complexity, and design space limitations w.r.t. future forks (thanks @hwwhww).

• eip7688: use forward compatible SSZ types in Gloas consensus-specs#4630
• https://eips.ethereum.org/EIPS/eip-7688

As for the design space:

• Lists / Containers grow to whatever size is required, without triggering re-indexing.
• Limits can be moved from per-list capacity to per-resource (e.g., max signature checks per block, could allow more proposer slashings when there are no BLS to execution changes)
• No more breakage when a container reaches a new power of 2 number of fields.
• Fields can be deprecated, leaving a hole in the Merkle tree, the subsequent fields don't move, no breakage.
• Fewer data types that are depending on presets (forked schema).

I am proposing to include EIP-7688 into Gloas.

• Discord discussion: https://discord.com/channels/595666850260713488/598292067260825641/1424863530359853056

On behalf of Diva, including EIP-7688 is a must.

• If we aim to build immutable systems, we cannot depend on forks that insert new fields into data structures and shift all generalized indices. Stable generalized indices, and thus stable merkleization across forks, are essential.
• Without this stability, projects that rely on Merkle proofs to remain as trust-minimized as possible face a painful reality: updating and auditing the same smart contracts twice, solely because of a fork. (This already happened to Diva even without being on Mainnet).
• This proposal comes without a security reduction, so we must pay de complexity cost once to gain the forward compatibility

[barnabasbusa]

Would like us to schedule mainnet fusaka.

Proposed dates for
Fusaka 3rd of Dec 2025 - epoch 411392
BPO1 17th Dec 2025 - epoch 414464
BPO2 7th of Jan 2026 - epoch 419072.

https://notes.ethereum.org/@bbusa/fusaka-bpo-timeline

[dgusakov]

I have rebased EIP-7688 on top of Gloas. That's the one that introduces stable generalized-indices across forks, reducing the maintenance churn (involving security councils) for builders that consume beacon data in their smart contracts. CL teams have explored this around the Kenya Interop, and quite a bit of feedback was integrated regarding implementation complexity, and design space limitations w.r.t. future forks (thanks @hwwhww).

• eip7688: use forward compatible SSZ types in Gloas consensus-specs#4630
• https://eips.ethereum.org/EIPS/eip-7688

As for the design space:

• Lists / Containers grow to whatever size is required, without triggering re-indexing.
• Limits can be moved from per-list capacity to per-resource (e.g., max signature checks per block, could allow more proposer slashings when there are no BLS to execution changes)
• No more breakage when a container reaches a new power of 2 number of fields.
• Fields can be deprecated, leaving a hole in the Merkle tree, the subsequent fields don't move, no breakage.
• Fewer data types that are depending on presets (forked schema).

I am proposing to include EIP-7688 into Gloas.

• Discord discussion: https://discord.com/channels/595666850260713488/598292067260825641/1424863530359853056

Dmitry from Lido here.

Several Lido contributors and I, working on different parts of the Lido protocol, believe that EIP-7688 is crucial for the reliable future of the trustless components of the staking protocols and other DeFi applications relying on the CL data in their operations.

While Lido contributors were able to wiggle around the fact that GIndexes might change with hardforks (see - https://github.com/lidofinance/community-staking-module/blob/5993902919c96aa65a03ed9e36a36613bbc580cf/src/CSVerifier.sol#L362-L408), the resulting solution still requires deployment of the new smart contract instances any time GIndexes are changed.

This was a simple example of the usage of EIP-4788 that might be improved with the introduction of EIP-7688. Thanks to the research prepared by MixBytes some time ago, one can see that there are many more use cases of EIP-4788 in DeFi, all of which can benefit from the inclusion of the EIP-7688 into Gloas.

As a Lido contributor and active Ethereum staking participant, I support the inclusion of the EIP-7688 in Gloas.

[akashkshirsagar31]

X Stream: https://x.com/i/broadcasts/1MYxNlBwXRzGw

[nixorokish]

closing in lieu of #1772