chore(deps): bump libssz family to 0.2.2

[pablodeymo]

🗒️ Description / Motivation

• Bumps the libssz family of dependencies from 0.2.1 to 0.2.2.
• A new 0.2.2 release is available; this keeps us on the latest patch.
• Pins the intended version explicitly in the workspace manifest instead of leaving it implicit in the lockfile.

What Changed

• Cargo.toml — libssz, libssz-derive, libssz-merkle, libssz-types requirement changed from "0.2" to "0.2.2".
• Cargo.lock — corresponding libssz* entries updated 0.2.1 → 0.2.2.

Correctness / Behavior Guarantees

• No source changes; purely a dependency patch bump.
• Caret requirement "0.2.2" raises the floor while still allowing compatible patch updates (>=0.2.2, <0.3.0).

Tests Added / Run

• make fmt — clean
• make lint — clean
• make test — 62 passed, 8 pre-existing AttestationTooFarInFuture failures in forkchoice_spectests (verified identical on main, unrelated to this change).

Related Issues / PRs

• N/A

✅ Verification Checklist

• Ran make fmt — clean
• Ran make lint (clippy with -D warnings) — clean
• Ran cargo test --workspace --release — 8 pre-existing forkchoice spectest failures unrelated to this change (same on main)

[github-actions]

🤖 Kimi Code Review

Review for PR #394: SSZ library version bump

Critical Concerns

1. Syn version downgrade in proc-macro crate (Cargo.lock)

File: Cargo.lock (libssz-derive dependency section)
The update downgrades syn from 2.0.117 to 1.0.109 in libssz-derive 0.2.2. This is concerning because:

• Duplicate dependency risk: If other crates in the dependency tree use syn 2.x, the project will now compile both versions, increasing binary size and compile times significantly
• Maintenance: syn 1.x is in maintenance mode; new proc-macro features require 2.x
• Potential breakage: Verify that libssz-derive 0.2.2 correctly handles all SSZ derive macros with the older syn version

Recommendation: Check if the syn downgrade was intentional (e.g., for compatibility) or accidental. If intentional, document the rationale in the PR description.

2. Consensus-critical SSZ changes

File: Cargo.toml (lines 59-65)
Patching SSZ libraries (libssz, libssz-derive, libssz-merkle, libssz-types) from 0.2.1 to 0.2.2 requires verification:

• Test vector compliance: Ensure 0.2.2 passes all Ethereum consensus spec SSZ tests. Any serialization change is a consensus fork risk.
• Changelog audit: Review the diff between 0.2.1 and 0.2.2 for:
  • Merkleization logic changes (libssz-merkle)
  • Encoding/decoding edge cases (libssz)
  • Container/vector boundary handling (libssz-types)

Security & Best Practices

3. Version pinning strategy

File: Cargo.toml (lines 62-65)
Pinning to exact patch versions (0.2.2 instead of 0.2) is correct for consensus clients to ensure deterministic builds. However:

• Security patches: Ensure a process exists to manually bump these when security fixes are released in 0.2.3+
• Supply chain: Verify the checksums in Cargo.lock against the crates.io published versions (already present in the diff, good)

4. Build reproducibility

The Cargo.lock update appears complete (all four SSZ crates updated in lockstep). Verify that:

• cargo build --locked succeeds
• No transitive dependencies introduce duplicate versions (check with cargo tree -d)

Minor Observations

• Documentation: The PR should include a summary of what bugs were fixed in libssz 0.2.2 that necessitate this update
• CI: Ensure SSZ roundtrip tests and spec tests run against the new version before merge

Summary

The change appears mechanically correct, but requires verification of the syn downgrade rationale and SSZ 0.2.2 changelog review before merging due to consensus-critical nature of these libraries.

---

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

[github-actions]

🤖 Codex Code Review

1. Medium: Cargo.toml keeps the libssz* dependencies on a caret range ("0.2.2"), not an exact pin. For a consensus-critical SSZ/Merkleization stack, that means a fresh dependency resolution can silently move to 0.2.3+ and change encoding or HashTreeRoot behavior without another code review. If the goal is to audit exactly this serializer release, these should be =0.2.2.

2. Medium: Cargo.toml and Cargo.lock upgrade the library that defines SSZ encoding/decoding and Merkleization for blocks, attestations, state, storage keys, and p2p payloads, but the PR contains no accompanying conformance evidence. In this codebase, that is effectively a consensus change. I would want green runs of crates/common/types/tests/ssz_spectests.rs and crates/blockchain/state_transition/tests/stf_spectests.rs before merging.

I did not find any direct code-level bug in the patch itself; the risk is entirely in the unaudited dependency upgrade. I also could not independently run cargo check or the fixture suites in this sandbox because cargo/rustup cannot write to the home cache and network access is unavailable.

---

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

[github-actions]

🤖 Claude Code Review

Here is my review of PR #394:

---

PR #394 — chore(deps): bump libssz family to 0.2.2

Overview

A straightforward patch-version bump of the four libssz* workspace dependencies (libssz, libssz-derive, libssz-merkle, libssz-types) from 0.2.1 → 0.2.2, plus a tightening of the version floor in Cargo.toml from "0.2" to "0.2.2". No source code changes. 2 files changed, 13 additions, 13 deletions.

---

Findings

1. Unmentioned lockfile side-effect: data-encoding-macro-internal switches syn 2 → 1

- "syn 2.0.117",
+ "syn 1.0.109",

This change is for data-encoding-macro-internal v0.1.18 (a transitive dep of data-encoding), not any libssz* crate. It appears the previous lockfile resolution was coincidentally picking up syn 2 for this package; regenerating the lockfile for the libssz bump caused Cargo to resolve it more accurately to syn 1 (which data-encoding-macro-internal 0.1.18 was designed for). Both syn 1.0.109 and syn 2.0.117 are still present in the current lockfile (55 vs 7 users respectively), so there is no deduplication issue. This is benign, but worth calling out since it appears unrelated to the stated change and could confuse future git-blame readers.

2. Upstream changelog not referenced

The PR states "No source changes; purely a dependency patch bump" — but this is an assessment of intent, not of what actually changed in libssz 0.2.2. For an SSZ library, even a "pure bugfix" patch could alter encoding/decoding behavior in ways that affect state root computation or consensus compatibility. The PR would benefit from a link to the libssz changelog or release notes that confirms 0.2.2 is a safe, behavior-preserving patch.

3. Version floor tightening ("0.2" → "0.2.2") is reasonable

Raising the floor to "0.2.2" (semantics: >=0.2.2, <0.3.0) ensures a fresh cargo update can never pull in 0.2.0 or 0.2.1. This is a minor improvement in explicitness. No concern here.

4. All four crates bumped consistently

libssz, libssz-derive, libssz-merkle, and libssz-types are all moved together. Given their inter-dependencies (merkle depends on libssz; types depends on both) this is the correct approach — mixing versions would risk SSZ encode/decode mismatches.

5. Test coverage

The author confirmed 62 tests pass and the 8 AttestationTooFarInFuture failures are pre-existing and identical on main. This is adequate due diligence for a lockfile-only change.

---

Summary

The change is clean and the mechanics are correct. The one substantive gap is the missing reference to the libssz 0.2.2 release notes. For an SSZ library underpinning state root computation, confirming "patch with no behavior changes" via changelog is worth the extra sentence. The syn 2→1 resolution shift for data-encoding-macro-internal is harmless noise from lockfile regeneration.

Verdict: Approve with minor note — confirm upstream changelog shows no encoding-behavior changes, then this is good to merge.

---

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

[greptile-apps]

Greptile Summary

This PR bumps the libssz family of crates (libssz, libssz-derive, libssz-merkle, libssz-types) from 0.2.1 to 0.2.2 and tightens the workspace manifest requirement from the loose "0.2" specifier to the explicit "0.2.2" floor. No application source code changes are included.

• Cargo.toml: Version requirement for all four libssz* crates changed from "0.2" → "0.2.2", raising the resolved-version floor while still allowing compatible patch updates (>=0.2.2, <0.3.0).
• Cargo.lock: All four libssz* entries updated to 0.2.2 with new registry checksums; data-encoding-macro-internal now correctly resolves its syn dependency to 1.0.109 instead of 2.0.117, aligning it with its declared syn ^1 requirement.

Confidence Score: 5/5

Pure dependency patch bump with no source changes; all four libssz crates move from 0.2.1 to 0.2.2 and the lockfile checksums are consistent with the published registry entries.

No application code was modified. The version floor is raised from '0.2' to '0.2.2' which is a more restrictive but semantically equivalent constraint for the currently resolved version. The only incidental lockfile change — data-encoding-macro-internal resolving syn to 1.0.109 instead of 2.0.117 — actually corrects the resolution to match that crate's declared syn ^1 requirement.

No files require special attention.

Important Files Changed

Filename	Overview
Cargo.toml	Pins the libssz family from the loose "0.2" requirement to the explicit "0.2.2" floor, raising the minimum resolved version without restricting future compatible patches.
Cargo.lock	Updates the four libssz* crate entries from 0.2.1 → 0.2.2 with new checksums; also corrects data-encoding-macro-internal's resolved syn dependency from 2.0.117 to 1.0.109 (consistent with its declared syn ^1 requirement).

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Cargo.toml] --> B[libssz 0.2.2]
    A --> C[libssz-derive 0.2.2]
    A --> D[libssz-merkle 0.2.2]
    A --> E[libssz-types 0.2.2]

    C --> F[proc-macro2]
    C --> G[quote]
    C --> H[syn 2.0.117]
    D --> B
    D --> I[sha2]
    E --> B
    E --> D

    subgraph SideEffect [Side Effect in Cargo.lock]
        J[data-encoding-macro-internal 0.1.18] -->|now correctly resolved| K[syn 1.0.109]
    end

Loading

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