PQ Interop #18 | Dec 3, 2025

[will-corcoran]

Resources

• Zoom link: https://ethereumfoundation.zoom.us/j/4840114962?pwd=S8FArsXkTutjZDmVohZ7b0VOCaY4An.1
• Facilitator email: will@ethereum.org
• Facilitator Telegram: @corcoranwill

Agenda Overview

A. Client Updates
B. Spec Updates
C. Research Discussion
D. Open Discussion
E. Schedule

Agenda Details

A. Client Updates

Team	Previous Update
Ream	Mostly fixing interop bugs with Zeam on Lean QuickStart. Code up-to-date with recent Lean Spec refactors and validator registry changes. Extended metrics PR merged and in use.
Zeam	Focused on Lean QuickStart interop for Devnet-1. Debugging interop issues with Ream and Lantern. Providing state-transition metrics to dashboard.
Qlean	Spec caught up to ~2 days ago (including latest leansig changes). Local interop attempts with Zeam started but not yet successful. Docker + PR to Lean QuickStart coming soon. Starting to debug interop issues.
Lantern	Using Lean QuickStart; connects to Zeam, exchanges gossip/blocks, but chain does not finalize and state roots diverge. Actively debugging; will open PR to Lean QuickStart for Lantern integration this week.
Lighthouse	Post-DevConnect progress: successfully syncing with itself using current spec. Working on interop with other clients. Plans to post Lighthouse consensus E2E implementation to PQ Telegram group for review soon.
Grandine	Early-stage Lean client (no regular updates yet). Has own SSZ library; flagged potential friction if leanSig repo locks into sigma-prime SSZ implementation.

B. Spec Updates (last week)

• Lean Spec refactors ongoing (file decoupling, readability) – client teams can request freeze until Devnet-1 if preferred
• leansig repo split: old repo stays paper-close; new ethereum org repo (https://github.com/lean-ethereum/leansig) is performance-optimized for Ethereum use
• Two open PRs in new leansig repo (#12 merged, #14 large) add proper SSZ serialization/deserialization (using sigma-prime’s Ethereum SSZ crate) – removes previous bincode → SSZ workaround mess
• After #14 merge, all bincode-to-bytes hacks in Lean Spec will be replaced with direct SSZ
• Test vectors still very slow locally (~1 min per test due to keygen); plan to pre-generate keys and ship in JSON to drastically speed up CI/local runs
• Emile shared early XMSS aggregation crate (for future Devnet-2) with sign/verify/aggregate APIs; client teams asked to review and give timeline feedback when they will need it
• Consensus: Devnet-1 will NOT include aggregation (Devnet-2 feature)

C. Research Discussion (last week)

• SSZ serialization pain point largely solved via new leansig PRs; bytes will be properly exposed for teams with custom SSZ libs (e.g. Grandine)
• Test-vector performance to be addressed post-SSZ merge via pre-generated keys
• Metrics dashboard: Zeam already sending state-transition metrics; Ream metrics merged and working; Qlean/Lantern to be added soon. Discussion on labeling (gossip blocks vs gossip attestations vs future req/resp)
• Devnet-1 success criteria: multi-client interop + finalizing chain + metrics on baseline hardware

D. Open Discussion

• Strong request for an updated Devnet-1 one-pager (like Devnet-0) listing exact spec branches, config, and success criteria – volunteer(s) to open PR in pm repo this week; Will to help maintain afterward
• Client teams report ~15% effort on infra/kickstart vs ~85% on spec implementation (good balance)

E. Schedule

• Devnet-0
• Devnet-1
• Devnet-2 : single-layer PQ signature aggregation
• Devnet-3 : recursive PQ signature aggregation

[unnawut]

1. Last call before merging: feat: add PQ signature metrics leanEthereum/leanMetrics#6
2. Conclude networking measurements for devnet1. Based on discussion in post-quantum chat, I think we could:
   1. Even though signature and attestation gossip is fixed-sized, it's worth benchmarking the snappy compression?
   2. Simulate using shadow - to minimize test infrastructure work
   3. Measure average & max throughput per validator
   4. Ideally because we're doing signature concatenation, our block size will be much bigger than expected, we need a way to distinguish the throughput of block vs attestation gossip and focus on attestation

[KatyaRyazantseva]

Synchronizing Grafana versions for collaborative dashboard usage to avoid dashboard import and update issues as in #7

[varun-doshi]

• Do we want to test machine to machine P2P? And if yes, what is the best method to achieve that?
• What are the goals for Devnet 2?

[KolbyML]

The others contributors to Ream and I have been discussing having other devnets then

Devnet-2 : single-layer PQ signature aggregation
Devnet-3 : recursive PQ signature aggregation

^ currently these devnet's feel blocked on the researchers side of things, so we were thinking maybe we could have other devnets

Some ideas were

• A devnet integrating real EL clients over the engine api. So adding an execution_payload to the lean_block. This could then lead into devnets for the Beacon to Lean transition
• A devnet for blobs, blobs are critical to L1, I am assuming Lean clients would need to support them, for the Lean Chain to even be a consideration
• A devnet for zkSTFing the Lean Chain
• A devnet for syncing clients, instead of running them all at the same time

^ these are just 4 ideas, but the idea is we can work on different devnets in parallel, to accelerate progress towards Lean Mainnet.

An important question is what features of the Beacon Chain do we want to carry over to the Lean Chain etc