Agenda
Resources
- Previous call: https://forkcast.org/calls/pqi/036/
- Facilitator email: thomas.coratger@ethereum.org
- Facilitator Telegram: @tcoratger
- Telegram: PQ Interop — threads:
#general,#devnet-1,#devnet-2,#devnet-3,#devnet-4,#devnet-5,#testing,#tooling,#leanVM,#onboarding
High-Level Documents
- Devnet-0 : lean consensus client interop
- Devnet-1 : PQ signature signing & verification
- Devnet-2 : single-layer PQ signature aggregation
- Devnet-3 : aggregator role separation + subnet aggregation
- Devnet-4 : recursive aggregation
- Devnet-5 proposal (HackMD) : multi-message / block-level proof aggregation
Overview
A. Devnet-4: Implementation & Specification Status
B. Devnet-5: Early Specification Discussion
C. Testing infrastructure: cross-client visualization tooling
D. leanSpec engineering: multi-fork architecture & validator sync-lag gate
E. Metrics & Observability
A. Devnet-4 — implementation & specification status
Latest devnet status (Apr 28)
- Devnet-4 relaunched with 2 subnets.
- Finality lost after slot 110. Heads of all clients continue to progress.
- Both
reaminstances crashed. qleanandlanterntime out when responding to reqresp fromzeam(acting as aggregator).- Operator coordination: teams should flag any pending client image release before the next restart so it can be held until the new image is ready.
Spec & test work
- New test vectors added.
- Interop debugging — bring root-cause progress on the items above.
B. Devnet-5 — early specification discussion
Reference: Devnet-5 proposal (HackMD).
Background
Lean consensus uses post-quantum (hash-based) signatures. They are large, and blocks are dominated by proofs. Recursive aggregation is the lever: fold two proofs into one short proof asserting that both signed, repeat until the block fits.
Devnet-4 applies this per attestation_data: each block carries one aggregated proof per distinct vote target, capped at MAX_ATTESTATION_DATA = 8. Worst case is 8 aggregated proofs plus 1 block signature. Better than per-validator, but proofs still dominate.
What Devnet-5 wants to add
Fold the 8 per-attestation_data aggregates and the block signature into a single block proof. Verifying a block becomes verifying one SNARK. This is the largest size reduction available without changing the signature scheme.
The catch — aggregation is one-way
Folding A and B into AB destroys A and B as separately verifiable objects. This breaks block production, not block validation:
- The next proposer extends the previous block’s per-
attestation_dataaggregate with new votes (theknown_aggregated_payloadscache amortises aggregation work across slots). Without the intermediate aggregates, there is nothing to extend. - Two concrete failure modes follow:
- Hidden payloads. A node receives Block N’s block proof but missed the standalone aggregates on gossip. Fork choice still works (it only needs justification claims from headers), but on Block N+1 the node has no leaves to fold.
- Justification drift. The local store learns of a new justified checkpoint from a block proof, while the head block’s state still references the old one (
store.justified > head.justified). The node knows the truth but cannot prove it on-chain. The safe rule is to treat itself as not synced and abstain from proposing — a liveness cost paid for safety.
Mitigation — binary aggregation tree
Build a tree instead of folding to a single root:
- Leaves — individual proofs.
- Intermediates — pairwise aggregates (per
attestation_data). - Root — block proof.
Publication granularity then becomes a knob, not a forced choice:
| Published | Block size | Reusability |
|---|---|---|
| Root only | smallest | none |
Root + per-attestation_data intermediates |
small | proposers can extend |
| Whole tree | large | maximum |
The middle row is the working assumption. A common message format keeps every node in the tree a valid aggregated payload, so peers can fetch the granularity they need.
Open questions for the call
-
Propagation of intermediates. Side gossip channel? Req/resp from aggregators when a node is the next proposer and only received the root? Recommended scope for Devnet-5: lock the binary-tree publication choice and defer the propagation mechanism to the next devnet unless it becomes a blocker.
-
Recursive proving cost. Recursive SNARK proving is slow. We need wall-clock numbers before locking the slot budget. One promising mitigation is to push folds off the proposer’s critical path and onto aggregator validators during the existing aggregation interval, in parallel waves: with 8 leaves, 4 → 2 → 1 reduces the proposer’s critical path from 7 merges to 1. Wall-clock saving is modest at this leaf count (≈2×); the real win is removing 6 merges from the proposer path. A pattern in production at Polygon zkEVM, Plonky2, and Mina; reuses role separation already present in the 3SF-mini slot pipeline.
-
Fork-choice independence. The proposal assumes fork choice works without payloads. True today. Breaks if any future rule (slashing, surround votes) needs per-validator vote info now locked inside a recursive proof. Want explicit sign-off on this invariant before locking the design.
-
Multi-message scope. Multi-message means a single aggregated proof attests to more than one distinct message at once. Devnet-4’s per-
attestation_dataaggregates each cover only one message; a Devnet-5 block proof has to cover up to 9 messages (the 8 distinctattestation_datavotes + the block signature). Every additional(message, slot)pair the proof has to recognise costs prover time and proof size, so the proposed scope caps the proof at messages spanning at most 3 distinct slots:- up to 2 slots worth of
attestation_data— the 8 votes are required to come from no more than 2 distinct slots; - 1 slot reserved for the block signature, which is bound to the block’s own slot.
To be confirmed.
- up to 2 slots worth of
-
Message-level primitives. Today’s aggregation only handles a single
(message, slot)pair per proof. Devnet-5 needs an interface that bundles several. Proposed two-tier model:- Type-1 — a proof aggregating any number of signatures over the same
(message, slot). This is what we already have (per-attestation_dataaggregate). Merging two type-1 proofs is commutative and idempotent, and signers can be removed without breaking soundness. - Type-2 — a proof bundling
ntype-1 proofs that each cover a different(message, slot). This is the new object Devnet-5 needs in order to combine the 8 per-attestation_dataaggregates with the block signature into one block proof. - Split — decompose a type-2 back into its
nunderlying type-1 proofs. This is the property that keeps the binary aggregation tree useful: a future proposer extracts the per-attestation_dataaggregate from the previous block’s bundle and extends it with new votes, instead of starting from scratch.
Two questions for the call:
- Is this interface realisable cryptographically — specifically, can type-2 be constructed in a way that supports splitting?
- Does it cover every aggregation we need across Devnet-5 and the next devnet, or are there shapes that don’t fit either type?
- Type-1 — a proof aggregating any number of signatures over the same
-
Tree arity. The tree does not need to be binary. Single-message/single-slot already permits aggregating an arbitrary number of previously aggregated multi-signatures in one step. n-ary trees mean fewer merges overall but each merge is bigger — needs a quantified comparison before we commit.
-
Ephemeral intermediates. Treat intermediates as ephemeral, fetchable for a short window while signatures arrive. Under sustained non-finality the aggregator cache must enforce the justifiability schedule filter (which bounds aggregate diversity at
O(√(T - F))). If the filter is enforced only at consensus-time, the gossip cache grows linearly regardless.
Spec & test-infrastructure work to start now
We do not need every detail locked to begin opening small spec issues. Concretely:
- Define the type-1 / type-2 message containers and their (de)aggregation operations.
- Specify the publication policy (root + per-
attestation_dataintermediates). - Fix the proposer/aggregator wave assignment if we adopt parallel folding.
- Test runtime. The spec test-vector CI currently runs ~50 min for production configurations and ~20 min for test configurations. Devnet-5 will compound this. We need a mocking or scheme-substitution strategy to bring it back to a tractable budget before merging Devnet-5 changes — otherwise each iteration costs an hour.
The HackMD does not yet reflect this discussion. The doc should be updated so the spec issues open against an aligned reference.
C. Testing infrastructure — cross-client visualization tooling
The Ream team has stood up a cross-client visualization at https://hive.leanroadmap.org/, hosted on a shared VPS, with the underlying simulators contributed upstream into ethereum/hive (neutral ground). They are actively driving the effort and have offered to keep the lead.
Status
Already covered (full list: https://pastebin.com/N89vmn8a):
- Checkpoint sync with leanSpec nodes.
- Finalization matrix against other clients.
- Block validation.
- Gossip and req/resp.
leanSpec test-vector integration is in progress. A formal announcement and walkthrough will land in a subsequent PQ Interop call once it ships.
Action for client teams
The integration requires each client to expose a test-vector consumer — an entry point that loads a fixture and runs it against the client’s internal functions. Ream already has this; the earlier other clients land theirs, the earlier they show up as rows in the matrix.
Make sure your client consumes test vectors against its internal functions in any reasonable form. That is the prerequisite for being included.
On this call
- Demo. Ream will walk through what running the tool against a client looks like, so other teams can see the consumer shape they need to provide.
- Feedback. Look at https://hive.leanroadmap.org/ before the call and flag anything missing or wrong — additions and criticisms are welcome.
- Open question. Execution-side simulators already live in
ethereum/hive. Should the dashboard also be pushed intoethpandaops/hive-ui(so it sits alongside the other Hive dashboards), or is the standalone instance the right home?
Contacts for anything related to this effort: the Ream team and Kolby, or the #testing thread on the PQ Interop Telegram.
D. leanSpec engineering — multi-fork architecture & validator sync-lag gate
Two pieces of leanSpec engineering work that are ready to be discussed and picked up.
D.1 Multi-fork architecture
References: PR #638, tracking issue #686, design notes.
What PR #638 lands (skeleton).
ForkProtocol(ABC)+ForkRegistryfor multi-fork dispatch.StateandStoremove fromsubspecs/intoforks/lstar/(fork-specific).subspecs/becomes fork-agnostic shared libraries.- Construction routes through the fork (
fork.generate_genesis(),fork.create_store()).
D.2 Validator sync-lag duty gate (#689)
Problem. subspecs/validator/service.py has no sync-lag check. A node 800 slots behind continues to attest and propose against its stale head. Stale-head attestations deposit LMD-GHOST weight on the wrong subtree and slow convergence. A node can be SyncState.SYNCED per the state machine and still be many slots behind wall clock during a brief network hiccup, validator restart, or partition — so the binary sync-state flag is the wrong signal. This bites lean harder than beacon because faster finality leaves less time for fork choice to absorb the noise.
Proposed gate. Skip both attestation and proposal when local head trails wall clock by more than SYNC_LAG_THRESHOLD = 4 slots. Decision uses store.head (not justified or finalized) — the gate is about whether the validator’s view of current head is fresh. wall_clock_slot < head_slot (clock skew) does not gate; trust the chain in that direction.
Companion to #688 (BlocksByRange), which addresses catch-up speed itself. The two are independent and can land in either order; together they unblock devnet stalls.
E. Metrics & Observability
Standing item. Updates from teams running Devnet-3 / Devnet-4 telemetry.
Meeting Time: Wednesday, April 29, 2026 at 14:00 UTC (60 minutes)