chore: bump leanVM to e2592df on devnet5

[MegaRedHand]

Motivation

Track upstream leanVM at e2592df (the repo's devnet5 branch), previously 8fcbd779 (#408).

Description

The aggregation crate renamed its public API since 8fcbd779. ethlambda-crypto adapts to the new names; shapes, fields, and call signatures are unchanged, so the port is mechanical:

Old (8fcbd779)	New (e2592df)
TypeOneMultiSignature	SingleMessageAggregateSignature
TypeTwoMultiSignature	MultiMessageAggregateSignature
aggregate_type_1	aggregate_single_message_signatures
merge_many_type_1	merge_single_message_aggregates
split_type_2	split_multi_message_aggregate
verify_type_1 / verify_type_2	verify_single_message_aggregate / verify_multi_message_aggregate

Plonky3 pin: p3-* crates are pinned back to 3f67d136 (the rev devnet5 already used). Newer revs pulled in transitively by leanVM use the unstable maybe_uninit_slice feature, which doesn't build on Rust 1.92.0.

Validation

• ✅ cargo build --workspace
• ✅ cargo clippy -p ethlambda-crypto clean
• ✅ cargo fmt --check clean

Notes

• The heavy round-trip tests (aggregate/verify/merge/split) remain #[ignore] (12+ GiB/proof), so semantic correctness here is verified by compile + prover setup, not a live proof.
• test_setup_is_idempotent stack-overflows in debug builds: the new bytecode compiler needs >2 MiB of stack. Release is unaffected and make test uses --release, so CI passes; flagging for awareness.

[greptile-apps]

Greptile Summary

This PR bumps the leanVM dependency pin from 8fcbd779 to e2592df (the repo's devnet5 branch head) and adapts ethlambda-crypto to the upstream rec_aggregation API rename.

• API rename in lib.rs: Six symbols are mechanically renamed (TypeOneMultiSignature → SingleMessageAggregateSignature, TypeTwoMultiSignature → MultiMessageAggregateSignature, and matching function names); all call sites, field accesses, and return types are structurally identical to the previous revision.
• Lock file: rayon is replaced by a new intra-monorepo parallel crate across all mt-* and related leanVM crates; zk-alloc gains parallel and libc dependencies are added where needed.
• Plonky3 pin: p3-* crates are held at 3f67d136 to avoid a maybe_uninit_slice nightly-only feature pulled in by newer transitive revisions.

Confidence Score: 5/5

Safe to merge — the change is a pure upstream API rename with no alterations to call signatures, field accesses, or logic.

Every change in lib.rs is a symbol substitution whose before/after shapes are identical. The lock file update is generated and consistent with the Cargo.toml rev bump. The PR was validated with a full workspace build, clippy, and fmt. No functional logic was touched.

No files require special attention.

Important Files Changed

Filename	Overview
crates/common/crypto/src/lib.rs	Mechanical rename of all lean-multisig API symbols to match upstream; call signatures, field accesses, and control flow are unchanged
crates/common/crypto/Cargo.toml	Dependency rev bumped from 8fcbd779 to e2592df for both lean-multisig and leansig_wrapper; no other changes
Cargo.lock	All leanVM crates updated to e2592df; rayon replaced with a custom parallel crate from leanVM; new zk-alloc dependency on parallel; libc added to lean-multisig

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[ethlambda-crypto] -->|imports| B[lean-multisig @ e2592df]
    A -->|imports| C[leansig_wrapper @ e2592df]

    subgraph "Type-1 (single-message) path"
        D[aggregate_single_message_signatures]
        E[merge_single_message_aggregates]
        F[verify_single_message_aggregate]
    end

    subgraph "Type-2 (multi-message) path"
        G[split_multi_message_aggregate]
        H[verify_multi_message_aggregate]
    end

    B --> D
    B --> E
    B --> F
    B --> G
    B --> H

    I[aggregate_signatures] --> D
    J[aggregate_mixed] --> D
    K[aggregate_proofs] --> D
    L[verify_aggregated_signature] --> F
    M[merge_type_1s_into_type_2] --> E
    N[verify_type_2_signature] --> H
    O[split_type_2_by_message] --> G

Loading

_{Reviews (2): Last reviewed commit: "Merge branch 'devnet5' into chore/devnet..." | Re-trigger Greptile}

[github-actions]

🤖 Kimi Code Review

The diff updates the lean-multisig dependency (post-quantum XMSS signature aggregation) to a newer revision with renamed APIs. The changes are mechanically correct and consistently applied.

Security & Correctness

• Dependency verification recommended: The PR switches from rev 8fcbd779 to e2592df across the leanVM ecosystem. While the diff only shows API renaming (TypeOneMultiSignature → SingleMessageAggregateSignature, etc.), the underlying cryptographic implementation in the ZK prover/verifier could have behavioral changes. Verify the leanVM changelog for any modifications to the proof system, transcript handling, or curve parameters before merging (Item 1).
• No consensus logic changes: The state transition, fork choice, and attestation processing logic are untouched. This is strictly a crypto library adaptation.

Code Quality

• Consistent renaming: All call sites in crates/common/crypto/src/lib.rs correctly map to the new API:
  • aggregate_type_1 → aggregate_single_message_signatures (lines 176, 220, 253)
  • verify_type_1 → verify_single_message_aggregate (line 292)
  • merge_many_type_1 → merge_single_message_aggregates (line 323)
  • verify_type_2 → verify_multi_message_aggregate (line 379)
  • split_type_2 → split_multi_message_aggregate (line 418)
• Documentation updated: Doc comments at lines 117, 146, 149, 303, 306, and 388 are updated to reflect the new type names, preventing documentation drift.

Dependencies

• Threading model change: The leanVM crates now depend on a custom parallel crate instead of rayon (visible in Cargo.lock changes to mt-fiat-shamir, mt-field, etc.). Ensure this doesn't conflict with ethlambda's own parallelism or thread pool configuration (Item 2).
• New libc and zk-alloc deps: These appear in the leanVM subtree for memory management in ZK contexts. Acceptable as transitive dependencies, but monitor for unsafe usage in upstream if auditing the full dependency tree.

Verdict
Approve with the caveat that Item 1 (upstream behavioral review) is performed. The code changes themselves are correct and idiomatic.

---

Automated review by Kimi (Moonshot AI) · kimi-k2.5 · custom prompt

[github-actions]

🤖 Claude Code Review

Here is the review for PR #423:

---

PR #423: chore: bump leanVM to e2592df on devnet5

Author: Tomás Grüner | Base: devnet5 | +75 / -49 across 3 files

---

Overview

A mechanical dependency bump: leanVM 8fcbd779 → e2592df. The upstream crate renamed its public aggregation API; ethlambda-crypto adapts to the new names. Call signatures and data types are unchanged — this is purely a rename port.

---

Code Quality

The rename in crates/common/crypto/src/lib.rs is complete and consistent. Every use site (aggregate_signatures, aggregate_mixed, aggregate_proofs, verify_aggregated_signature, merge_type_1s_into_type_2, verify_type_2_signature, split_type_2_by_message) is updated. The local LMType1/LMType2 aliases absorb the rename cleanly — internal code that uses those aliases is untouched. Docs in decompress_type1 and merge_type_1s_into_type_2 are updated to match. Overall a well-executed mechanical port.

---

Findings

Minor — comment/function name mismatch in split_type_2_by_message

The updated doc comment at crates/common/crypto/src/lib.rs (around line 397) now reads:

Mirrors leanSpec PR #717 split_multi_message_aggregate_by_message

but the actual Rust function being called is split_multi_message_aggregate (no _by_message suffix). _by_message appears to be the Python-side leanSpec name, not the Rust symbol. A developer tracing the leanSpec reference will hit a search dead-end. Suggest either:

• dropping the function name from the comment and keeping only the PR reference (leanSpec PR #717), or
• quoting the Rust function name: split_multi_message_aggregate.

---

Low — debug-build stack overflow undocumented at the test itself

The PR description honestly flags that test_setup_is_idempotent stack-overflows in debug builds (new bytecode compiler needs >2 MiB stack). make test uses --release so CI is fine, but a developer running cargo test -p ethlambda-crypto without --release will get a mysterious crash rather than an informative skip. Adding a small annotation directly on the test would make the situation self-documenting:

#[test]
#[cfg_attr(debug_assertions, ignore = "needs >2 MiB stack; run with --release")]
fn test_setup_is_idempotent() { ... }

This is not a blocker since CI passes, but it avoids a confusing DX trap for future contributors.

---

Informational — rayon replaced by custom parallel crate

The Cargo.lock diff shows rayon removed from all mt-* crates and replaced by parallel — a new first-party leanVM crate that wraps system-info. This is an upstream change and no action is needed here, but it is worth noting for anyone debugging threading behavior in proof generation: the parallelism implementation is now custom rather than the well-audited rayon. No regression risk inside ethlambda itself.

---

Informational — semantic correctness untestable at review time

All heavy round-trip tests (aggregate/verify/merge/split) remain #[ignore] due to 12+ GiB proof sizes. Correctness validation is compile + prover setup only. This is pre-existing and unavoidable; just flagging it so reviewers understand the confidence boundary.

---

Verdict

Approve. The port is correct and complete. The one actionable item (Item 1 — comment mismatch) is minor; Item 2 (debug ignore annotation) is a quality-of-life improvement worth considering before the test grows more users.

---

Automated review by Claude (Anthropic) · sonnet · custom prompt

[github-actions]

🤖 Codex Code Review

No blocking findings in the in-repo changes. The Rust wrapper edits in crates/common/crypto/src/lib.rs are mechanical API renames only; the important consensus-relevant behavior stays intact: (message, slot) binding checks are still enforced in verify_aggregated_signature and verify_type_2_signature, SSZ proof-size guarding is unchanged in compress_type1_to_byte_list and compress_type2_to_byte_list, and the type-2 split path still rejects ambiguous message matches in split_type_2_by_message.

Residual risks / testing gaps:

• The real risk in this PR is the dependency bump in crates/common/crypto/Cargo.toml:16. Per the PR notes, leanVM e2592df now needs enough stack to overflow the only non-ignored setup smoke test, test_setup_is_idempotent, in debug builds via ensure_prover_ready / ensure_verifier_ready. That is not a consensus correctness bug, but it is a real regression in local validation and debugging ergonomics.
• The end-to-end XMSS aggregation tests that would actually exercise the new upstream prover/verifier remain ignored in lib.rs:471, lib.rs:495, lib.rs:531, lib.rs:552, and lib.rs:576. For a crypto/dependency-rev PR, that leaves semantic confidence mostly delegated to upstream.

I could not run cargo test locally because this environment has no network access and no cached Rust 1.92.0 toolchain.

---

Automated review by OpenAI Codex · gpt-5.4 · custom prompt