chore(deps): bump leanMultisig (5eba3b1) and leansig (c08a3ba)

[MegaRedHand]

Summary

• Bumps leanMultisig (lean-multisig, leansig_wrapper) from 2eb4b9d to 5eba3b1 (latest devnet4).
• Bumps leansig to c08a3ba by following its default branch. leanMultisig depends on leansig without a branch/rev spec, so matching that source avoids two leansig copies in Cargo.lock.
• Adapts to the upstream rename SchemeAbortingTargetSumLifetime32Dim46Base8 → SIGAbortingTargetSumLifetime32Dim46Base8 in crates/common/types/src/signature.rs.

Test plan

• make lint
• make test
• Smoke-test on a local devnet (make run-devnet)

[github-actions]

🤖 Kimi Code Review

Overall Assessment: The PR updates dependencies and adapts to a breaking API change in the leansig XMSS library. While the changes appear mechanical, there are consensus-safety and reproducibility concerns given this is a consensus client.

---

1. Critical: Dependency Pinning and Reproducibility

File: Cargo.toml (line 59)

The removal of the branch = "devnet4" constraint without pinning to a specific rev reduces build reproducibility:

-leansig = { git = "https://github.com/leanEthereum/leanSig", branch = "devnet4" }
+leansig = { git = "https://github.com/leanEthereum/leanSig" }

Issue: While Cargo.lock currently pins this to commit c08a3bae, future cargo update runs will float to the latest default branch commit. For a consensus client, this is dangerous—upstream changes to post-quantum signature verification could silently introduce consensus splits.

Recommendation: Pin to a specific revision:

leansig = { git = "https://github.com/leanEthereum/leanSig", rev = "c08a3bae74b0d85379cab72dcbefa4091546ecbb" }

---

2. High: XMSS Type Rename Verification

File: crates/common/types/src/signature.rs (line 15)

The type alias changes from SchemeAborting... to SIGAborting...:

-pub type LeanSignatureScheme = leansig::signature::generalized_xmss::instantiations_aborting::lifetime_2_to_the_32::SchemeAbortingTargetSumLifetime32Dim46Base8;
+pub type LeanSignatureScheme = leansig::signature::generalized_xmss::instantiations_aborting::lifetime_2_to_the_32::SIGAbortingTargetSumLifetime32Dim46Base8;

Consensus Risk: Ensure this is purely a naming change and not a semantic change to the signature scheme parameters (lifetime 2^32, dimension 46, base 8, Poseidon1 hashing). If the upstream library changed the underlying XMSS tree construction or hash function, this would fork the chain.

Action Required: Verify the upstream commit history between 5cc7e37 and c08a3ba to confirm the cryptographic parameters remain identical.

---

3. Medium: Cryptographic Dependency Updates

File: Cargo.lock (multiple locations)

Large-scale updates to cryptographic libraries require careful validation:

• alloy-primitives 1.5.7 → 1.6.0 (SSZ encoding changes?)
• bls12_381 cleanup (removal of 0.7.1, keeping forked 0.8.0)
• secp256k1 0.30.0 → 0.31.1 (new version introduced)
• sha3 0.10.8 → 0.10.9 and 0.11.0
• rand family updates (0.8.5 → 0.8.6, etc.)

Concern: SSZ encoding/decoding changes in alloy-primitives or ethereum_ssz could affect block hashing and signature verification. The bls12_381 crate (used for BLS signatures in consensus) must remain compatible with the spec.

Recommendation: Run consensus spec tests and verify block/attestation SSZ serialization round-trips match the reference implementation.

---

4. Low: Removal of Unused Dependencies

File: Cargo.lock

The lockfile cleanup removes several unused crates (halo2_proofs, pasta_curves, zkhash, blake2b_simd, jubjub). This is positive for compile times and attack surface reduction.

---

Summary of Action Items

1. Pin leansig to a specific rev in Cargo.toml to prevent accidental upstream drift.
2. Audit the leansig commit diff (5cc7e37..c08a3ba) to confirm the type rename doesn't change XMSS semantics.
3. Run consensus spec tests to verify BLS and XMSS signature verification still pass after the bls12_381 and alloy-primitives updates.
4. Verify SSZ compatibility—ensure the ethereum_ssz 0.10.4 update doesn't change serialization formats used in block roots or signing data.

The PR is acceptable if the above verification steps pass, but Item 1 (pinning) should be addressed before merge.

---

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

[github-actions]

🤖 Codex Code Review

1. Blocker: Cargo.toml:59 removes the leansig branch pin and replaces it with a floating default-branch git dependency. For a consensus client, that is not safe: the lockfile currently resolves to commit c08a3bae... (Cargo.lock:3707-3709), but any future cargo update / lockfile regeneration can silently pull a different XMSS implementation without a corresponding code review. That creates real consensus and security risk here because signature verification, serialization, and aggregation behavior can drift independently of the pinned lean-multisig / leansig_wrapper revs (crates/common/crypto/Cargo.toml:15-19). I would require pinning leansig to an explicit reviewed rev before merging.

I did not find a separate source-level correctness bug in the touched Rust code; the signature.rs type rename looks mechanical. I wasn’t able to run the targeted tests in this environment because Cargo needed to write/fetch git dependencies and the runner has read-only ~/.cargo/~/.rustup plus no network, so this review is source-based rather than execution-backed.

---

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

[github-actions]

🤖 Claude Code Review

Here are the full review findings:

---

PR #387 Review — chore(deps): bump leanMultisig (5eba3b1) and leansig (c08a3ba)

Overview

This is a dependency bump across four files:

• Cargo.toml — switches leansig from branch = "devnet4" to default branch
• crates/common/crypto/Cargo.toml — bumps lean-multisig/leansig_wrapper rev 2eb4b9d → 5eba3b1
• crates/common/types/src/signature.rs — adapts to upstream rename of the XMSS instantiation type
• Cargo.lock — large cascade of transitive updates (-553 / +415 lines)

The lock file correctly records the resolved commits for all git dependencies, so builds are reproducible as-is.

---

Code Change — signature.rs

The single line change at crates/common/types/src/signature.rs:15 renames:

// before
pub type LeanSignatureScheme = ...::SchemeAbortingTargetSumLifetime32Dim46Base8;

// after
pub type LeanSignatureScheme = ...::SIGAbortingTargetSumLifetime32Dim46Base8;

This is purely an upstream identifier rename. The cryptographic scheme parameters (aborting, 32-bit lifetime, dim 46, base 8) remain unchanged in the new name, and the local alias LeanSignatureScheme insulates the rest of the codebase from it. No behavioral concern here.

---

Dependency Management Concerns

leansig pinning regression — the most notable issue in the PR.

Cargo.toml changes from:

leansig = { git = "...", branch = "devnet4" }

to:

leansig = { git = "..." }

The PR body explains the rationale: leanMultisig itself depends on leansig without a branch/rev, so if ethlambda pins to branch = "devnet4" but leanMultisig resolves a different commit, Cargo includes two copies of leansig in the build. Switching to the default branch avoids the duplication.

The problem is that the Cargo.toml now has no explicit pin for leansig. Any future cargo update will silently advance leansig to whatever the default branch tip is at that moment. For a core cryptographic library (XMSS signatures are the consensus-layer security boundary), this is a meaningful regression in supply-chain control.

The preferred fix is to pin leansig to an explicit rev in Cargo.toml that matches what leanMultisig 5eba3b1 itself resolves:

leansig = { git = "https://github.com/leanEthereum/leanSig", rev = "c08a3ba" }

This is safe, keeps the deduplication (Cargo matches on source URL + rev), and avoids the implicit tracking of a mutable branch pointer.

---

Cargo.lock Observations

Positive: Several heavy ZK-proof dependencies are dropped entirely — halo2, halo2_proofs, pasta_curves (both 0.4.1 and 0.5.1), jubjub, zkhash, bls12_381 0.7.1, ff 0.12.1, group 0.12.1, blake2b_simd. This reduces binary size and attack surface meaningfully.

Neutral: secp256k1 now appears in two versions (0.30.0 and 0.31.1) because alloy-primitives 1.6.0 added the newer version as a direct dependency while existing crates still resolve 0.30.0. This is a minor duplication but not a correctness concern.

Registry bumps are routine patch-level updates (tokio 1.51→1.52, rustls 0.23.37→0.23.40, axum 0.8.8→0.8.9, etc.) and look unproblematic.

---

Test Plan

The test checklist in the PR body is unchecked (- [ ]). This should be completed before merge:

• make lint (clippy -D warnings)
• make test (includes forkchoice spectests)
• Smoke test on a local devnet

The spec tests are the most important gate here — they exercise on_block() with full signature verification, so any behavioral change in the new leansig would surface there.

---

Summary

The change is well-scoped and the rationale is sound. The main actionable point is pinning leansig to an explicit rev = "c08a3ba" in Cargo.toml to avoid tracking the mutable default branch of a cryptographic dependency. Everything else looks correct.

---

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

[greptile-apps]

Greptile Summary

This PR bumps lean-multisig and leansig_wrapper to rev 5eba3b1 (devnet4) and adapts to an upstream rename in the leansig type path (SchemeAborting… → SIGAborting…). It also removes the branch = \"devnet4\" specifier from the workspace leansig dependency, aligning the source spec with how leanMultisig declares it, which collapses what would otherwise be two separate leansig entries in Cargo.lock into one.

• crates/common/types/src/signature.rs: Updates the LeanSignatureScheme type alias to use the renamed SIGAbortingTargetSumLifetime32Dim46Base8 identifier.
• Cargo.toml / crates/common/crypto/Cargo.toml: Bumps pinned revs for lean-multisig/leansig_wrapper to 5eba3b1; drops the branch = \"devnet4\" specifier on leansig so Cargo can unify the single dependency.
• Cargo.lock: Reflects a single, unified leansig entry at c08a3ba plus cascading version bumps for several transitive crates.

Confidence Score: 4/5

Safe to merge; the rename adaptation and rev bumps are mechanical and correct, and the lock file confirms a single unified leansig entry.

The rename in signature.rs is straightforward and the leansig deduplication goal is achieved. The workspace leansig entry now carries no branch, rev, or tag specifier and relies entirely on the lock file for pinning — for a cryptographic dependency that was previously explicitly tracking devnet4, this makes future cargo update runs less auditable.

Cargo.toml — the leansig entry lost its branch specifier and has no rev to replace it.

Important Files Changed

Filename	Overview
Cargo.toml	Removes branch = "devnet4" from the leansig git dependency, leaving no branch, tag, or rev specifier — the dependency now floats on the default branch.
crates/common/crypto/Cargo.toml	Bumps lean-multisig and leansig_wrapper rev from 2eb4b9d to 5eba3b1; no issues.
crates/common/types/src/signature.rs	Adapts LeanSignatureScheme type alias to the upstream rename SchemeAborting… → SIGAborting…; rest of the file is unchanged.
Cargo.lock	Lock file updated to reflect a single leansig entry at c08a3ba and cascading transitive version bumps; looks consistent.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[ethlambda-crypto] -->|rev=5eba3b1| B[lean-multisig]
    A -->|rev=5eba3b1| C[leansig_wrapper]
    A -->|workspace| D[leansig @ c08a3ba]
    B -->|no rev/branch spec| D
    C -->|no rev/branch spec| D
    E[ethlambda-types] -->|workspace| D
    D --> F["SIGAbortingTargetSumLifetime32Dim46Base8
(renamed from SchemeAborting…)"]

Loading

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
Cargo.toml:59
The `leansig` git dependency previously tracked `branch = "devnet4"`, which made the intended tracking target explicit. Now it has no `branch`, `tag`, or `rev` specifier at all, so it floats on whatever the upstream default branch happens to be. The lock file pins it to `c08a3ba` today, but the next `cargo update` will silently advance to whatever HEAD the default branch points to at that moment. For a cryptographic signature library this makes audits and deliberate upgrades harder. Adding `rev = "c08a3ba"` (the commit already recorded in `Cargo.lock`) would keep the deduplication benefit while making the pinned state explicit and reviewable.

```suggestion
leansig = { git = "https://github.com/leanEthereum/leanSig", rev = "c08a3ba" }
```

_{Reviews (1): Last reviewed commit: "fix" | Re-trigger Greptile}