chore: bump leanVM to a44bca4

[MegaRedHand]

Motivation

Track upstream leanVM at a44bca4 (previously f66d4a9).

Description

No source changes were required: the XMSS aggregation API used by ethlambda-crypto (xmss_aggregate, AggregatedXMSS::compress/decompress) is unchanged at this rev. Only crates/common/crypto/Cargo.toml and Cargo.lock change.

Notes:

• Plonky3 p3-* crates are kept pinned at 82cfad73. leanVM references Plonky3's default branch with no rev, so cargo update floats them forward; newer Plonky3 commits use the unstable maybe_uninit_slice feature, which doesn't build on Rust 1.92.0.

Testing

• cargo build --workspace succeeds.
• cargo test -p ethlambda-crypto --release -- --ignored (the slow XMSS aggregation/verification tests) all pass against the new rev.

Note: previously targeted 8eec56c; updated to a44bca4.

[github-actions]

🤖 Claude Code Review

PR #421 — chore: bump leanVM to 8eec56c

Overview

A dependency-only bump of leanVM from f66d4a9 → 8eec56c. Two files change: crates/common/crypto/Cargo.toml (rev strings) and Cargo.lock (cascading updates). No ethlambda source code changes.

---

What changed inside leanVM (lock file evidence)

The most notable internal change visible in the lock file is the wholesale replacement of rayon with a new first-party parallel crate across all the mt-* math/proving crates, backend, lean-multisig, sub_protocols, zk-alloc, and system-info:

• rayon drops out of: mt-fiat-shamir, mt-field, mt-koala-bear, mt-poly, mt-sumcheck, mt-symetric, mt-whir, system-info
• A new parallel crate (git+...leanVM.git?rev=8eec56c, depends only on system-info) is added and wired throughout
• zk-alloc picks up both parallel and system-info as new deps
• windows-sys consolidates from three versions (0.52.0, 0.60.2, 0.52.0 in various places) to a single 0.61.2 — minor cleanup

---

Assessment

Correctness / API stability — Strong evidence provided. The XMSS aggregation API (xmss_aggregate, AggregatedXMSS::compress/decompress) is the only surface ethlambda touches, and the author ran the slow ignored crypto tests (cargo test -p ethlambda-crypto --release -- --ignored) against the new rev. That's the right test to run here.

The rayon → parallel substitution — This is an upstream concern, not ethlambda's, but worth noting for awareness: parallel has only system-info as a dependency. If it is a thinner/custom thread pool compared to rayon, proof generation performance could shift. Since this is an internal leanVM refactor and tests pass, it is not a blocker, but worth watching if aggregation latency changes in devnet.

Plonky3 pin — The note about p3-* crates being pinned at 82cfad73 to stay buildable on Rust 1.92.0 (avoiding the maybe_uninit_slice unstable feature) is well-documented and the right call. The pinned entries are not in the diff because they didn't move, which is the expected outcome.

One thing to verify — The PR description says cargo build --workspace and the crypto tests pass, but doesn't mention make lint (clippy). Since there are no source changes this is almost certainly a non-issue, but it would round out the CI evidence.

---

Summary

This is a clean, low-risk dependency bump. The changed surface in ethlambda is two rev-string lines in Cargo.toml; everything else is the generated lock file. The author has provided the correct build and test evidence. No issues found.

---

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

[github-actions]

🤖 Kimi Code Review

Security & Consensus-Critical Concerns

1. Custom Parallelism Library Replacing Rayon (High Risk)

   • Location: Cargo.lock diff (e.g., lines 666, 676, 4858, 4909)
   • Issue: The leanVM dependencies have switched from rayon (battle-tested, audited) to a custom parallel crate (defined at line 5624). In a consensus client, thread-scheduling bugs in signature aggregation can lead to non-deterministic state transitions or side-channel leaks.
   • Action: Audit leanVM@8eec56c's parallel crate for:
     • Data races in XMSS signature aggregation paths.
     • Constant-time violations in cryptographic operations (branching on secrets in thread pools).
     • Proper Send/Sync bounds on internal structures.

2. Custom Allocator (zk-alloc) Introduction

   • Location: Cargo.lock lines 668, 4870, 4918, 9053
   • Issue: The new zk-alloc dependency (used by mt-poly, mt-sumcheck, mt-symetric, backend) implements custom memory allocation. Custom allocators require unsafe Rust and are prone to use-after-free or double-free bugs that could corrupt the beacon state or leak private keys.
   • Action: Verify zk-alloc has:
     • #![forbid(unsafe_code)] OR extensive Miri/Valgrind testing in CI.
     • Fuzzing coverage for allocation edge cases (OOM handling, zero-size types).

3. XMSS Signature Verification Regression Risk

   • Location: crates/common/crypto/Cargo.toml lines 17, 20
   • Issue: Updating lean-multisig and leansig_wrapper changes post-quantum signature verification logic. A subtle bug here could cause a consensus split (nodes rejecting valid blocks or accepting invalid ones).
   • Action: Before merging, run the full XMSS test suite including:
     • Negative test cases (tampered signatures, wrong pubkeys).
     • Aggregation edge cases (empty sets, single signatures, maximum aggregation size).

Performance Implications

• Location: Cargo.lock (rayon → parallel migration)
• Issue: The custom parallel crate may not match rayon's work-stealing performance characteristics. Signature verification is in the hot path for attestation processing.
• Recommendation: Benchmark process_attestation throughput on a testnet before/after this update. Verify no regression under high load (thousands of attestations per slot).

Maintainability & Supply Chain

• Location: crates/common/crypto/Cargo.toml lines 17, 20
• Issue: Git dependencies on external repositories without version tags increase supply chain risk. If leanVM force-pushes or deletes the 8eec56c revision, builds become non-reproducible.
• Recommendation: Request leanVM maintainers to create signed tags (e.g., v0.2.0) and pin to tags instead of commit hashes when possible.

Minor Observations

• The comment explaining the lean-multisig name history is helpful and accurate. Keep it.
• windows-sys minor version bumps (0.60.2 → 0.61.2) appear to be transitive updates and are likely safe, but verify Windows CI passes.

Summary
Do not merge without:

1. Reviewing the parallel and zk-alloc source in leanVM for unsafe code and thread-safety proofs.
2. Running full XMSS cryptographic test vectors.
3. Performance regression testing on signature aggregation.

---

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

[github-actions]

🤖 Codex Code Review

Findings

1. High: This PR swaps the consensus-critical XMSS backend to a different git SHA with no in-repo regression signal that the aggregation and verification semantics are unchanged. The only code that pins the backend is crates/common/crypto/Cargo.toml, while the wrapper still hard-depends on xmss_aggregate(..., 2) and xmss_verify_aggregation(...) at crates/common/crypto/src/lib.rs and crates/common/crypto/src/lib.rs. All meaningful XMSS tests are still ignored as “too slow” at crates/common/crypto/src/lib.rs, lib.rs:333, lib.rs:369, and lib.rs:390. For a consensus client, that means a silent behavior change in the upstream git revision can land without CI catching a fork-inducing incompatibility.

2. Medium: The lockfile materially expands the trusted code surface in the signature path by replacing rayon with a new internal parallel crate and introducing zk-alloc through backend/lean-multisig, but the PR provides no audit trail or rationale for those additions. See Cargo.lock, Cargo.lock:3664, Cargo.lock:5627, and Cargo.lock:9050. Since this dependency is used for attestation/proposer XMSS proof handling, allocator or scheduler bugs are not just performance bugs; they can become verification failures or DoS vectors. I would not merge this without either vendoring/reviewing the upstream diff or documenting the exact upstream changes being trusted.

Notes

I did not find any repo-local changes to fork choice, attestation processing, justification/finalization, state transition, or SSZ logic in this PR; the risk is entirely in the XMSS dependency bump.

I also could not do a clean build in this sandbox because the new git revision is not locally cached and network access is restricted, so I could not independently validate the upstream code path.

---

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

[greptile-apps]

Greptile Summary

This PR bumps the leanVM dependency from commit f66d4a9 to 8eec56c, updating crates/common/crypto/Cargo.toml and the corresponding Cargo.lock. No source code in this repository needed to change because the XMSS aggregation API (xmss_aggregate, AggregatedXMSS::compress/decompress) is stable across both revisions.

• The primary change in Cargo.lock is the rev bump for all leanVM-sourced crates (backend, lean-multisig, leansig_wrapper, lean_vm, rec_aggregation, and the mt-* math crates).
• Within leanVM, the upstream team replaced the rayon parallelism crate with their own internal parallel crate (backed by system-info) across all relevant math/proving crates; rayon remains in the lock file for other consumers.
• windows-sys is bumped from 0.52.0/0.60.2 to 0.61.2 for several registry crates as a transitive update. Plonky3 p3-* crates remain locked at 82cfad73, consistent with the noted stability concern around maybe_uninit_slice on stable Rust.

Confidence Score: 5/5

Safe to merge — only dependency pins and the generated lock file change; no source code in this repo is modified.

The XMSS aggregation API consumed by ethlambda-crypto is unchanged at the new rev, the author confirmed a successful workspace build and passing XMSS integration tests, and the Plonky3 crates remain at the expected commit. The internal leanVM switch from rayon to a custom parallel crate is upstream-only and validated by the test suite.

No files require special attention. Both changed files (Cargo.lock and crates/common/crypto/Cargo.toml) are mechanical dependency updates.

Important Files Changed

Filename	Overview
crates/common/crypto/Cargo.toml	Bumps the lean-multisig and leansig_wrapper rev pins from f66d4a9 to 8eec56c; no other changes to declared dependencies.
Cargo.lock	Lock file updated to reflect the new leanVM rev for all 14+ upstream crates, rayon replaced by the new internal parallel crate within leanVM crates, windows-sys bumped to 0.61.2 across several crates, and Plonky3 p3-* crates remain at the previously pinned 82cfad73.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["ethlambda-crypto"] --> B["lean-multisig @ 8eec56c"]
    A --> C["leansig_wrapper @ 8eec56c"]
    B --> D["backend"]
    B --> E["lean_vm"]
    B --> G["parallel (replaces rayon)"]
    D --> H["mt-air"]
    D --> I["mt-fiat-shamir"]
    D --> J["mt-field"]
    D --> K["mt-poly"]
    D --> L["mt-sumcheck"]
    D --> M["mt-symetric"]
    D --> N["mt-whir"]
    D --> G
    G --> O["system-info"]
    K --> P["zk-alloc"]
    P --> G
    style G fill:#f9f,stroke:#333
    style P fill:#bbf,stroke:#333

Loading

_{Reviews (1): Last reviewed commit: "chore: bump leanVM to 8eec56c" | Re-trigger Greptile}

[MegaRedHand]

We see lower aggregation performance on this commit. We're pausing merging this while investigating