chore(deps): bump libssz crates to 0.3.0

[MegaRedHand]

Bumps libssz, libssz-derive, libssz-merkle and libssz-types from 0.2.2 to 0.3.0 (release notes).

Why

0.3.0 tracks consensus-specs v1.7.0-alpha.13 and ships a merkleize rewrite that elides all-zero subtrees and reuses buffers instead of allocating per layer, which touches every hash_tree_root we compute.

Impact on this codebase: none

0.3.0 is a breaking release, but every breaking change is confined to progressive containers and lists:

Breaking change	Used here?
Progressive merkleization roots changed (EIP-7916): ProgressiveList, ProgressiveBitlist, #[ssz(progressive_container)]	No
Progressive containers capped at 256 fields	No
Unknown #[ssz(...)] keys are now compile errors instead of being silently ignored	No

No source changes were needed.

Lockfile scope

The Cargo.lock diff is deliberately limited to the four libssz entries (version + checksum). A full cargo update -p libssz ... re-resolve additionally repointed leanVM's mt-field/mt-poly at num-bigint 0.4 and shifted several other duplicate-version picks (itertools, syn, getrandom). That churn is unrelated to this bump, and silently moving a crypto dependency's bignum library does not belong in a dependency bump, so it was left out. cargo check --locked confirms the hand-scoped lockfile resolves cleanly.

Verification

Run against the minimal lockfile, on the latest leanSpec production fixtures:

• cargo check --workspace --all-targets --locked — clean
• cargo clippy --workspace --all-targets --locked -- -D warnings — clean
• cargo test --workspace --locked — all green, including the SSZ-sensitive suites (stf_spectests, forkchoice_spectests, signature_spectests)

The spec-test suites are the meaningful check here: they compare hash_tree_root output and SSZ encode/decode against the leanSpec fixtures, so they would catch any merkleization or serialization change reaching our types.

[github-actions]

🤖 Kimi Code Review

Overall Assessment: This PR bumps critical SSZ dependencies (libssz ecosystem) from 0.2.2 to 0.3.0. This is a high-risk change for a consensus client given that SSZ encoding/decoding and Merkleization are consensus-critical paths.

Critical Issues

1. Missing Code Adaptations for Breaking Changes

File: Cargo.toml (lines 88-91)

SemVer 0.2.x to 0.3.0 indicates breaking API changes. The PR only updates Cargo.toml/Cargo.lock without corresponding source code changes. This suggests either:

• The PR is incomplete and compilation will fail, or
• Runtime behavior may change silently if types/traits changed (consensus split risk)

Action Required: Verify if libssz 0.3.0 introduced breaking changes to:

• Encode/Decode trait signatures
• Merkleization trait behavior
• SSZ union type handling
• Fixed/variable vector encoding boundaries

2. Consensus Critical Testing Gap

Risk: SSZ serialization changes can cause state root mismatches, invalid block processing, or fork choice errors.

Required verification (not visible in diff):

1. Round-trip SSZ tests for all consensus types (BeaconState, BeaconBlock, Attestation, etc.)
2. Merkle root compatibility with spec vectors
3. Cross-client SSZ fuzzing against lighthouse/prysm

3. Exact Version Pinning

File: Cargo.toml (lines 88-91)

# Current (risky for consensus client)
libssz = "0.3.0"

# Recommended (reproducible builds)
libssz = "=0.3.0"

Consensus clients should use exact version pinning (=0.3.0) to prevent accidental minor version bumps that could introduce consensus splits.

Security Considerations

1. Supply Chain: Verify the new checksums in Cargo.lock match official libssz releases (lines 4526-4558). The checksums shown appear valid for crates.io, but confirm no git dependencies were substituted.

2. XMSS/Leansig Interaction: If libssz changed how byte vectors are encoded, verify XMSS signature aggregation in leansig (git dependency) remains compatible. Signature deserialization depends on SSZ.

Recommendations

1. Do not merge until:

   • All libssz 0.3.0 changelog entries are reviewed for consensus-relevant changes
   • CI passes with full spec tests (especially ssz_static and merkle test suites)
   • Code compiles (confirm no trait implementation changes needed)

2. Add regression test: Ensure this PR includes or triggers tests that verify:

   // Example: State root must remain stable across version bump
   let state: BeaconState = load_test_state();
   assert_eq!(state.tree_hash_root(), expected_hash);

3. Pin versions in Cargo.toml:

   libssz = "=0.3.0"
   libssz-derive = "=0.3.0"
   libssz-merkle = "=0.3.0"
   libssz-types = "=0.3.0"

If this is a routine dependency update with no API changes, acknowledge that the version bump appears to be a compatible maintenance release despite the minor version increment, but still requires full consensus test suite validation before deployment.

---

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

[github-actions]

🤖 Claude Code Review

This PR is a minimal, well-scoped dependency bump limited to Cargo.toml/Cargo.lock, with no source changes. Here's the review.

Review

Overall: looks good. This is a clean, low-risk dependency bump with an unusually thorough PR description that already does the hard work of scoping the blast radius.

Correctness / Verification

• The lockfile diff is correctly scoped to just the four libssz* entries (version bump + checksum), matching what a cargo update -p libssz -p libssz-derive -p libssz-merkle -p libssz-types would produce without dragging in unrelated transitive re-resolution (e.g., the num-bigint bump for leanVM's mt-field/mt-poly mentioned in the description). Deliberately avoiding an unscoped cargo update here is the right call — this codebase's CLAUDE.md and general hygiene favor minimal, explainable diffs, and silently repointing a crypto-adjacent bignum dependency inside a routine SSZ bump would be a bad surprise for reviewers.
• All four checksums are standard 64-hex-char SHA-256 digests — no truncation or corruption in the lockfile entries.
• The PR claims cargo check/clippy/test --locked all pass, and that the SSZ-sensitive spec suites (stf_spectests, forkchoice_spectests, signature_spectests) were run against the latest leanSpec fixtures — these are exactly the right tests to catch a hash_tree_root/merkleize regression, since this codebase's own hash_tree_root() usage sits directly on top of libssz-merkle.

Risk assessment of the upstream change

• The stated breaking changes in 0.3.0 (progressive containers/lists under EIP-7916, the 256-field cap, unknown #[ssz(...)] keys becoming compile errors) are all accurately identified as unused in this codebase — a grep for progressive_container/ProgressiveList/ProgressiveBitlist would confirm zero usage, consistent with the PR's table.
• The merkleize rewrite (eliding all-zero subtrees, buffer reuse) is a pure internal optimization that should not change hash_tree_root() output for well-formed inputs — correctness here rests entirely on the spec-test suites, which is appropriate.

Nothing else to flag

No source files changed, no new API surface, no consensus-logic touched. Given the accurate, self-verifying description and the narrow diff, this is safe to merge as-is.

---

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

[github-actions]

🤖 Codex Code Review

No findings in the checked-in diff.

The PR only bumps the libssz* crates in Cargo.toml and refreshes the corresponding lock entries in Cargo.lock. I don’t see a repository-owned code change here that would directly alter fork choice, attestation handling, justification/finalization, state transition, XMSS verification, or SSZ call sites.

Residual risk is upstream-only: this is a consensus-critical serialization/merkleization dependency, so any behavior change in libssz 0.3.0 could affect hash_tree_root, SSZ decode strictness, or container offset handling across blocks, attestations, and state. I could not verify that in this environment because cargo is blocked from writing to ~/.rustup / ~/.cargo, so build and test execution failed before compilation. Before merge, I’d want the existing SSZ and consensus vectors rerun, especially crates/common/types/tests/ssz_spectests.rs, crates/blockchain/state_transition/tests/stf_spectests.rs, and crates/blockchain/tests/forkchoice_spectests.rs.

---

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

[greptile-apps]

Greptile Summary

The PR upgrades the four workspace libssz crates from 0.2.2 to 0.3.0 without requiring source changes.

• Updates the workspace dependency constraints for libssz, libssz-derive, libssz-merkle, and libssz-types.
• Updates only the corresponding versions and checksums in Cargo.lock.
• Existing consumers use standard SSZ containers and derive attributes rather than the progressive constructs affected by the documented breaking changes.

Confidence Score: 5/5

The PR appears safe to merge because the dependency constraints and lockfile entries are consistent and no reachable compatibility or serialization failure was identified.

Existing code avoids the documented progressive-container breaking changes, and the reported locked workspace checks plus SSZ-sensitive fixture suites exercise compilation, serialization, and hash-tree-root behavior.

Important Files Changed

Filename	Overview
Cargo.toml	Updates all four workspace libssz dependency constraints consistently to 0.3.0; no actionable compatibility issue was identified in existing consumers.
Cargo.lock	Updates the matching four resolved package versions and checksums without changing unrelated dependency selections.

_{Reviews (1): Last reviewed commit: "chore(deps): bump libssz crates to 0.3.0" | Re-trigger Greptile}