chore(l1): update tooling Cargo.lock

[iovoid]

Motivation

The tooling Cargo.lock was outdated, causing the "Check Cargo.lock" CI job to fail.

Description

Updates the tooling lockfile.

[greptile-apps]

No reviewable files after applying ignore patterns.

[github-actions]

⚠️ Known Issues — intentionally skipped tests

Source: docs/known_issues.md

Known Issues

Tests intentionally excluded from CI. Source of truth for the Known
Issues section the L1 workflow appends to each ef-tests job summary
and posts as a sticky PR comment.

EF Tests — Stateless coverage narrowed to EIP-8025 optional-proofs

make -C tooling/ef_tests/blockchain test calls test-stateless-zkevm
instead of test-stateless. The zkevm@v0.3.3 fixtures are filled against
bal@v5.6.1, out of sync with current bal spec; the broad target trips ~549
fixtures. Re-broaden once the zkevm bundle is regenerated.

Why and resolution path

PR #6527 broadened
test-stateless to extract the entire for_amsterdam/ tree from the
zkevm bundle and run all of it under --features stateless; combined with
this branch's bal-devnet-7 semantics that scope produces ~549
GasUsedMismatch / ReceiptsRootMismatch /
BlockAccessListHashMismatch failures.

test-stateless-zkevm filters cargo to the eip8025_optional_proofs
suite, which still validates the stateless harness without the bal-version
mismatch.

Re-broaden by switching test: back to test-stateless in
tooling/ef_tests/blockchain/Makefile once the zkevm bundle is regenerated
against the current bal spec.

[github-actions]

🤖 Claude Code Review

PR #6746 Review: chore(l1): update tooling Cargo.lock

Overview

This is a minimal maintenance PR that updates two version pins in tooling/Cargo.lock:

• ethrex-common bumped from 12.0.0 → 14.0.0
• ethrex-storage bumped from 12.0.0 → 14.0.0

The motivation is straightforward: the lock file was stale, causing the "Check Cargo.lock" CI job to fail.

---

Analysis

Correctness

The change is mechanically correct — both packages advance by the same delta (12 → 14), which is consistent and suggests a coordinated version bump in the workspace rather than an accidental mismatch. The jump of two major versions (skipping 13.0.0) is worth a passing note, but in a monorepo where internal crate versions are bumped in lockstep with workspace changes this is normal and not a concern.

Scope

Only one file is touched (tooling/Cargo.lock), and only two lines change. Risk surface is essentially zero.

Process

Lock file-only PRs are a common and legitimate fix for CI drift. The PR description accurately explains why the change is needed.

---

Suggestions / Considerations

• None substantive. The change is correct, minimal, and well-described.
• Optionally, it would be worth confirming that ethrex-common 13.0.0 was never published and the skip is intentional (e.g., a botched tag was retracted), but this is a trivial housekeeping detail that doesn't block merging.

---

Verdict

Approve. This is a routine lockfile maintenance change with no logic, security, or performance implications. Ready to merge.

---

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

[github-actions]

🤖 Kimi Code Review

Review of PR #6746: Version bump for ethrex-common and ethrex-storage

File: tooling/Cargo.lock

Summary:
This diff updates the lockfile to bump internal workspace dependencies ethrex-common and ethrex-storage from 12.0.0 to 14.0.0.

Critical Findings:

1. Major Version Jump (12 → 14)

   • The version skips 13.0.0 and jumps two major versions. Verify whether:
     • Version 13.0.0 was yanked/deprecated, or
     • This aligns with a workspace-wide version bump (e.g., matching the client version)
   • Action required: Confirm the version bump is intentional and documented in the PR description.

2. Breaking Change Risk in Consensus-Critical Crates

   • ethrex-common typically contains primitive types (addresses, hashes, RLP encoding) and ethrex-storage contains state trie logic. These are consensus-critical components.
   • A major version bump suggests API breaking changes. Without seeing the corresponding Cargo.toml changes or source code adaptations in this diff:
     • Verify that no consensus-breaking changes were introduced between v12 and v14
     • Ensure all call sites in tooling/ are compatible with the new API (e.g., changed function signatures, renamed types, different error handling)

3. Lockfile/Manifest Consistency

   • Lockfile updates should correspond to Cargo.toml changes. If the manifests in crates/common/Cargo.toml and crates/storage/Cargo.toml weren't updated in this PR, this lockfile change will be reverted on next cargo update.
   • Action required: Confirm the Cargo.toml files for these crates specify version = "14.0.0".

Recommendations:

• Testing: Given these crates handle EVM state and primitives, run full consensus tests (e.g., Ethereum Foundation tests) to ensure the version bump doesn't introduce subtle behavioral changes in RLP encoding, trie hashing, or storage layout.
• Changelog: If this skips v13, document what breaking changes occurred between v12→v13 and v13→v14 in the PR description for auditability.
• CI Verification: Ensure CI passes with --locked to verify the lockfile is in sync with manifests.

Verdict:
The change appears mechanical but carries risk due to the consensus-critical nature of the updated crates. Approve only if:

1. The corresponding Cargo.toml changes are included in the full PR (not shown in this diff snippet), and
2. Breaking API changes between v12 and v14 have been verified not to affect consensus rules or require code adaptations in the tooling crate.

---

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

[github-actions]

🤖 Codex Code Review

No findings in the supplied diff.

tooling/Cargo.lock:2941 and tooling/Cargo.lock:2944 now reference ethrex-common 14.0.0 and ethrex-storage 14.0.0, which matches the current workspace dependency wiring in tooling/ef_tests/engine/Cargo.toml and the existing 14.0.0 package entries already present in the lockfile. Since this PR only updates tooling lockfile metadata and does not touch execution, consensus, gas accounting, trie, RLP, or validation code, I do not see a correctness, security, or performance concern here.

Residual risk: I could not fully re-resolve the tooling workspace in this sandbox because Cargo needs the patched git dependency for secp256k1, and network access is restricted.

---

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