Post-Quantum (PQ) Interop #40, May 20, 2026

Protocol Calls & happenings
1

Agenda

Meeting Time: Wednesday, May 20, 2026 at 14:00 UTC (60 minutes)

GitHub Issue

2

Meeting Summary:

The meeting focused on discussing updates and challenges related to DevNet 5 implementation, specification stabilization, and scaling of validators across different clients. Thomas led the discussion, highlighting recent merges of DevNet 5 PRs and the need for stabilization before moving to larger validator numbers. Gajinder and Parthasarathy reported issues with performance and aggregation times when scaling beyond two subnets, identifying potential bottlenecks in aggregation and block building processes. The group discussed hardware requirements for aggregators, with suggestions to increase core counts and consider the impact of current XMSS parameters on performance. Teams shared updates on their client implementations, including fixes for block building, aggregation optimization, and integration with execution layers. The group agreed to focus on debugging current issues with metrics and hardware configurations before making further specification changes, and emphasized the importance of defining clear acceptance criteria for each DevNet phase.

Click to expand detailed summary

The team discussed updates on DevNet 5 implementation and client optimizations. Gajinder reported that DevNet 5 spec has been merged and Zim will start implementing it on DevNet 4, along with optimizations for aggregation and new metrics for subnet performance. The team also addressed validator scaling challenges, which resulted in expected choking issues that need to be addressed by various clients.

The team provided updates on various implementation progress. Shariq reported implementing a PR for block building that allows using older justified blocks. Ruslan discussed fixing Hive tests, including investigating issues with mock peer connections and implementing test drivers. Pablo shared that they made a PR to Linux spec fixing an edge case in block building, addressed network instability issues with useless attestation inclusion, and implemented full block aggregation with working execution layer integration.

Shaaibu reported updates on their site including merged pull requests for DevNet 4 on Linkspark and fixes for failing hive tests related to networking issues. Mercy discussed an OM report received from General DevNet, noting that the issue occurs on the general dev net but not in their internal run, and they are investigating using a profiler to determine if it’s a configuration issue on the server side. Thomas provided an update on research work, mentioning merged PRs in Plonky3 for optimization, a full benchmarking suite for Weir, and a new Arithmetization for Monolith.

Thomas and Emil provided updates on their current work. Emil is improving the spec and paper associated with LeanVM, including developing a Python verifier implementation. Thomas is focusing on stabilizing the Lean spec and plans to showcase it to a broader audience, including Beacon client teams and EF members working on the Beacon specification. They recently merged the DevNet 5 PR, achieving a single proof per block on-chain, and Thomas proposed stabilizing the spec by reaching stability with 1K validators across different clients before introducing new features.

The team discussed issues with devnet performance when scaling beyond two subnets with 64 validators. Parthasarathy reported that while up to two subnets achieved finality and justification, scaling further resulted in new bugs and performance issues, with P95 aggregation taking 4 seconds on average. Gajinder suggested a reverse engineering approach to determine hardware requirements for aggregators, focusing first on client stability and aggregation coverage metrics before increasing complexity. The team identified that current aggregator servers with 8 cores might be insufficient, with recommendations for at least 16 cores based on performance benchmarks showing 2.7 seconds for aggregating four proofs on 32-core systems.

Thomas explained that while the DevNet 4 branch is slower than mainnet, it provides time to debug before making major changes to the specification. The team discussed hardware requirements, with Thomas and Emil agreeing that 16 cores would be a good minimum configuration, though memory performance is also important. Thomas proposed a pragmatic approach of first trying to optimize the current slower branch before considering switching to the main branch with potentially better performance.

The team discussed performance issues with multi-subnet configurations in DevNet, with Anshal identifying that the problem likely stems from validators rather than aggregators, as the system works fine with single or dual subnets but fails with 3-4 subnets. Gajinder agreed to implement additional metrics for aggregator performance and proposer aggregation to better diagnose the issue. The team decided to stabilize the current configuration, increase hardware requirements if needed, and conduct further debugging with metrics and multiple clients before making any specification changes. Mega presented a demo showing successful integration between EthLambda and execution clients using the Engine API, with the implementation available in a PR that can be simplified.

Next Steps:

  • Gajinder: Submit two PRs to LeanSpec by tomorrow — one for aggregate coverage metrics and one for proposer aggregation metrics — to help identify and debug DevNet performance issues.
  • Parthasarathy: Run future DevNet experiments with homogeneous client configurations (same client as aggregator across subnets) before mixing clients, to isolate aggregation issues.
  • Parthasarathy: Increase aggregator hardware configuration from 8-core to at least 16-core for future DevNet runs, based on benchmarking discussion.
  • T. (Emil): Provide precise minimum hardware requirements for aggregators (core count and memory) for the next call, based on benchmarking data.
  • T. (Emil): Continue improving the LeanVM spec and paper, and work toward a lean verifier implementation below 1,000 lines of code.
  • Thomas: Travel to Zurich to present post-quantum consensus for Ethereum at the researcher conference, then return to focus on LeanSpec stabilization and cleanup.
  • Thomas: Work on simplifying and cleaning up the LeanSpec over the coming days/weeks to prepare it for broader feedback from consensus client teams and EF members.
  • Mega: Make a PR to LeanSpec sharing Lambda’s improved block building algorithm so other teams can benefit from it.
  • Mega: Write up a proposal for the EL integration (Engine API / execution payload support) to be added to a future DevNet.
  • Mega: Continue work on multi-machine DevNets for Lean execution clients and add execution requests to the EL integration.
  • Pablo: Share the link to Lambda’s EL integration PR in the chat after the call for async review.

Recording Access:

3

YouTube recording available: https://youtu.be/IogrdpVyLzQ