[MegaRedHand]

🗒️ Description / Motivation

First release of ethlambda 🎉

What Changed

• List the files or areas touched
• Brief summary of each change

Correctness / Behavior Guarantees

• What invariants are preserved or updated?
• Are there any behavior changes reviewers should know about?

Tests Added / Run

• What tests were added or updated?
• What commands did you run to verify this change?

Related Issues / PRs

• Closes #
• Related to #

✅ Verification Checklist

• Ran make fmt — clean
• Ran make lint (clippy with -D warnings) — clean
• Ran make test (test-consensus plus test-node, at release-fast) — all passing

[github-actions]

🤖 Kimi Code Review

I'll review this PR diff focusing on the version bump from 0.1.0 to 1.0.0 across all workspace crates.

Overall Assessment

This PR performs a workspace-wide version bump to 1.0.0. While seemingly straightforward, there are several concerns for a consensus client.

---

Issues Found

1. Semantic Versioning Implications (Cargo.toml:30, all Cargo.lock entries)

Bumping to 1.0.0 signals API stability. For a consensus client, this is premature unless:

• All consensus spec tests pass for target fork(s)
• Public APIs are frozen
• No breaking changes anticipated

Question: Is this coordinated with a release milestone? The commit message should clarify if this is a tagged release or arbitrary bump.

---

2. Missing CHANGELOG.md or Release Notes

No documentation changes in the diff. A 1.0.0 release requires:

• Supported consensus spec version (e.g., Capella, Deneb, Electra)
• Known limitations or unimplemented features
• Network compatibility status (mainnet, testnets)

Risk: Operators may deploy assuming production readiness without clarity.

---

3. Dependency Version Constraints (Cargo.toml workspace)

The workspace uses version = "1.0.0" but internal dependencies lack version pinning:

# Example pattern from Cargo.lock - ethlambda-blockchain depends on:
# "ethlambda-crypto" (no version requirement shown in lockfile)

Issue: If crates are published to crates.io, path dependencies must specify compatible version ranges. Check if ethlambda-blockchain/Cargo.toml uses:

ethlambda-crypto = { path = "../crypto", version = "1.0.0" }

Without version in path dependencies, publishing will fail or resolve incorrectly.

---

4. Cargo.lock Synchronization Verification

The lockfile changes appear mechanical, but verify:

• No transitive dependency updates were pulled in (check blst, c-kzg, libssz revisions)
• The diff shows only version fields changed, which is correct

Good: The lockfile changes are minimal and isolated to workspace crate versions.

---

5. Rust Version Compatibility (Cargo.toml:29)

rust-version = "1.97.1"

This is a very recent Rust version. Confirm 1.0.0 doesn't need to support slightly older compilers for broader deployment.

---

Consensus-Specific Concerns

Since this is a consensus client, version 1.0.0 implies:

Component	Concern
ethlambda-fork-choice	LMD GHOST/3SF-mini implementation audited?
ethlambda-state-transition	All spec tests passing?
ethlambda-crypto	XMSS aggregation reviewed for consensus safety?
ethlambda-ssz-tree	Merkleization matches reference tests?

The version bump itself doesn't affect correctness, but the release process should gate 1.0.0 on:

• Passing consensus-spec-tests for declared fork epochs
• Fuzzing corpus stability (no crashes in process_slots, process_block)
• Differential testing against Lighthouse/Prysm for block processing

---

Recommendations

1. Add release documentation before merge: CHANGELOG.md, docs/RELEASE.md, or GitHub release notes
2. Verify path dependency version fields in all Cargo.toml files (not just workspace root)
3. Tag with git tag v1.0.0 post-merge for reproducible builds
4. Consider 1.0.0-alpha.1 if spec compliance isn't complete

---

Verdict

The diff is mechanically correct but contextually risky without accompanying release process evidence. No code bugs introduced, but the versioning decision itself needs justification in commit message or PR description.

---

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

[github-actions]

🤖 Claude Code Review

Review: PR 712, bump version to v1.0.0

The diff is only a version bump. Cargo.toml goes from 0.1.0 to 1.0.0 in [workspace.package], and Cargo.lock updates all 15 workspace crates to match. I did not build or run tests.

Correctness

• The lockfile changes touch only the version lines of workspace members, so no dependency versions move.
• The crates I checked in the lockfile (ethlambda-validator, ethlambda-types, ethlambda-storage) all show 1.0.0. That fits them inheriting the workspace version.
• tooling/event-monitor keeps its own 0.1.0. It is a separate tool, so that looks fine.
• The 0.1.0 strings in docs/benchmarking.md, docs/rpc.md and the version.rs doc comment are sample output or format examples, not code. They are optional cleanup, not blockers.

Minor notes

• The PR description is still the unfilled template. It has no summary, no changes list, and unchecked fmt, lint and test boxes. Fill it in before merging.
• Check that the release flow in RELEASE.md expects the tag v1.0.0 to match this version. The runtime version string is built from version.rs and the git info through vergen.
• Nothing here affects consensus, networking or storage. DB_VERSION is separate from the crate version.

Looks good to merge once CI is green.

---

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

[github-actions]

🤖 Codex Code Review

Looks good overall. This PR appears to be a pure workspace version bump from 0.1.0 to 1.0.0, with no consensus, cryptography, SSZ, fork-choice, or state-transition code changes in the diff.

• Cargo.toml:30 changes the workspace package version to 1.0.0.
• Cargo.lock updates the locked workspace package entries correspondingly.

Review Notes

• No correctness risk in consensus logic: there are no changes to process_slots, process_block, attestation handling, fork choice, justification/finalization, XMSS, or SSZ code paths in the provided diff.
• No new security surface: no runtime logic, dependency graph shape, or feature flags change here.
• No performance impact: version metadata only.
• Rust style/readability is fine for the scope of this PR.

One thing to double-check

• Workspace consistency: the diff updates Cargo.lock package entries and the root Cargo.toml, but the crate manifests I scanned do not show explicit version = "1.0.0" lines in individual member crates. If those crates inherit version from the workspace, this is fine; if any publishable crates still pin 0.1.0 locally, that would create inconsistent release metadata. The relevant manifests include bin/ethlambda/Cargo.toml:1, crates/blockchain/Cargo.toml:1, and crates/common/types/Cargo.toml:1.

If you want, I can also do a quick follow-up pass on whether the workspace is using version.workspace = true consistently across member crates.

---

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