chore(l1,l2): bump version to 25.0.0

[ilitteri]

Motivation

Merges the release/v25.0.0 branch back into main now that v25.0.0 is published, per the last step of the release process.

The second commit matters on its own: main's release workflow is currently broken, and this is what fixes it. Any tag cut from main before this merges would build every artifact and then fail to publish a release.

Description

Two commits, no conflicts with main:

• chore(l1,l2): bump version to 25.0.0 — the 25 internal version pins across 9 Cargo.toml files, the regenerated lockfiles, and both --builder.extra-data defaults in docs/CLI.md.

  Includes the four crates/guest-program/stateless-validator/**/Cargo.lock files, which are each their own workspace and reach the ethrex crates through path dependencies, so they pin the workspace version and go stale on a bump. make update-cargo-lock does not cover them while check-cargo-lock does, so they were refreshed by hand — worth closing that asymmetry in a follow-up, since every future bump hits it.

• ci(l1,l2): stop the release asset download from matching docker build records — finalize-release downloaded artifacts with pattern: "*ethrex*", which also matches the build records the docker jobs upload as <org>~ethrex~<id>.dockerbuild. Those are not zip archives, so download-artifact exhausted its retries trying to extract them and the job died before publishing anything.

  This is a regression from feat(l1): unify guest programs and publish assets ourselves #7115, which widened the pattern to pick up the new stateless-validator-ethrex-* artifacts; the previous anchored pattern never matched the docker records. v25.0.0-rc.1 hit it — all 13 build jobs green, no release created. The dry-run rehearsal could not have caught it either: that job only waits on the guest builds, so it runs before any docker record exists.

  Fixed with two anchored patterns, ethrex* and stateless-validator-ethrex-*, verified against the run's real 17 artifacts to select exactly the 12 release assets. rc.2 published all 22 assets correctly.

Validation

v25.0.0 went through the full release checklist: three mainnet canaries paired with Prysm/Teku/Grandine, an eth-docker mainnet node, 13 consecutive successful multisync runs across hoodi/sepolia/mainnet, the SP1 GPU integration suite, and the L2 upgrade test — the last of which ran with a real SP1 GPU prover for the first time (see #7203).

Checklist

• Updated STORE_SCHEMA_VERSION (crates/storage/lib.rs) if the PR includes breaking changes to the Store requiring a re-sync.

[github-actions]

⚠️ Known Issues — intentionally skipped tests

Source: docs/known_issues.md

rpc-compat log-bearing cases excluded

Where: KNOWN_EXCLUDED_TESTS in .github/scripts/check-hive-results.sh counts out
eight hive rpc-compat cases — the four eth_getLogs cases, eth_getBlockReceipts/get-block-receipts-latest,
and three eth_getTransactionReceipt cases. They are exactly the cases whose recorded
response contains at least one log object; every case with an empty log array still runs.
Note this leaves eth_getLogs with no rpc-compat coverage at all, since all four of its
cases are in the set.

Why: ethrex populates blockTimestamp on log objects, as geth, besu, nethermind, reth
and erigon all do. hive's rpc-compat compares responses byte-exactly (jsondiff.FullMatch;
the lenient checkJSONStructure path applies only to cases upstream marks speconly), and
the corpus is pinned to execution-apis d08382ae (2025-02-10), whose recordings predate the
field — it entered the schema in execution-apis#639 and the fixtures in #846 (2026-07-22).
So the extra key cannot match, and this is a property of the pin rather than of the response.

The pin cannot move, and this is not temporary. The pin sits one commit before
execution-apis#627, which moved the test chain to a pre-merge genesis: the current corpus has
~36 proof-of-work blocks before its terminal total difficulty. ethrex does not support
pre-merge chains and will not, so importing that chain.rlp fails at block 1 —
validate_block_header has no pre-London base-fee path. Every revision carrying
blockTimestamp in its fixtures also carries that chain, so there is no revision that
satisfies both. Nor can the corpus be patched locally: rpc-compat's Dockerfile clones
ethereum/execution-apis by hard-coded URL, so the branch buildarg cannot point at a fork.

Coverage: the field itself is pinned by
block_timestamp_is_on_the_log_and_not_on_the_receipt in
crates/networking/rpc/types/receipt.rs, which asserts it is present on each log and absent
from the receipt level.

Removal: delete the entries if ethrex ever gains pre-merge chain import, or if upstream
marks these cases speconly so they are type-checked instead of compared byte-for-byte.

---

The stateless schema id does not identify the encoding

Where: STATELESS_INPUT_SCHEMA_ID in crates/common/types/stateless_ssz.rs.

Upstream keeps the stateless input schema id at 0x1501
(fork_index 0x15 << 8 | revision 0x01) across incompatible body changes. Three
encodings have now shipped under it: tests-zkevm@v0.6.2, then #3248 + #3278,
then #3356, which moved state, codes and public_keys from SszList to
ProgressiveList. ethrex speaks the last one.

The consequence is that the 2-byte prefix cannot be used to detect a stale or
mismatched bundle. A wrong-dialect input is accepted by the id check and then
fails later — in SSZ decode, or on a root that does not match — rather than being
rejected up front for what it is. only_amsterdam_schema_id_decodes therefore
proves less than its name suggests.

Worth raising upstream: a revision field that does not move across a body change
provides no version negotiation at all.

---

ZisK guest program hash changes with the unsync_cell gate

Where: crates/common/types/block.rs, transaction.rs.

The gate on the single-threaded unsync_cell::OnceCell moved from
all(feature = "eip-8025", target_arch = "riscv64") to
all(feature = "zisk", target_arch = "riscv64") when the eip-8025 feature was removed.

The guest ELFs were previously built --features "<zkvm>-build-elf,ci", which never enabled
eip-8025, so they compiled the atomic once_cell variant. bin/zisk/Cargo.toml does enable
ethrex-common/zisk, so the ZisK guest now compiles the unsafe impl Sync cell instead.
That changes the ELF bytes and therefore the program hash and verification key.

This is intended (the guest is single-threaded, so the unsync cell is sound and cheaper), but it
is a VK change rather than a no-op refactor, and the diffstat presents it as a file rename
(eip8025_cell.rs → unsync_cell.rs). Anyone pinning a ZisK VK across this change must
re-register it. The stateless-validator crate now forwards ethrex-common/zisk from its own
zisk feature so the two ZisK guests do not disagree on the cell type.

---

Release signing key is an unprotected repository secret

Where: .github/workflows/tag_release.yaml.

MINISIGN_SECRET_KEY is a plain repository secret. There is no environment: on
finalize-release or dry-run-release-assets, and gh api repos/lambdaclass/ethrex/rulesets
shows only branch-targeted rulesets, so the github.ref_type == 'tag' condition is a workflow
check rather than an enforced boundary: anyone who can push a tag can reach the signing key.

This is a repository-settings change, not a code change, so it is recorded here rather than
fixed in the tree. Recommended:

1. Move MINISIGN_SECRET_KEY / MINISIGN_PASSWORD into a GitHub Environment with required
   reviewers, and add environment: to the two jobs that sign.
2. Add a ruleset targeting refs/tags/v* restricting who may create release tags.

Until then, the compromise of that key is silent and durable: signatures would still verify
against the committed .github/minisign.pub.

[github-actions]

🤖 Kimi Code Review

This PR contains a routine workspace version bump (24.0.0 → 25.0.0) and a critical CI fix for the release workflow. Here's the review:

CI/CD Fixes (.github/workflows/tag_release.yaml)

Lines 507–525 and 604–625: The artifact download pattern fix is correct and addresses a real release failure mode.

• Problem: The unanchored pattern *ethrex* matched Docker build records (<org>~ethrex~<id>.dockerbuild) which are not ZIP archives, causing download-artifact to fail.

• Solution: Split into two anchored patterns:

  1. ethrex* — matches binaries and contracts tarball (starts with "ethrex")
  2. stateless-validator-ethrex-* — matches guest ELF/VK artifacts

• Security/Reliability: This prevents the release job from failing due to artifact name collisions with Docker build records, ensuring release assets are published reliably.

Version Bump Verification

Cargo.toml (line 43): Workspace version updated correctly.

Dependency consistency: All internal crate versions are synchronized to 25.0.0:

• ethrex-metrics in crates/blockchain/Cargo.toml (line 20)
• ethrex-sdk-contract-utils in crates/l2/sdk/Cargo.toml (lines 17, 37)
• ethrex-levm in crates/vm/Cargo.toml (line 14)

Guest programs: All guest program lock files (openvm, risc0, sp1, zisk, stateless-validator) are updated. Note that stateless-validator/Cargo.lock jumps from 23.0.0 → 25.0.0 (catching up from a previous missed bump), which is correct.

Documentation: docs/CLI.md (lines 304, 518) — version strings in help text examples updated to match.

Conclusion

No issues found. The CI fix is well-documented with inline comments explaining the rationale. The version bump is comprehensive across all workspace crates and guest program lock files.

---

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

[github-actions]

🤖 Claude Code Review

This confirms only crates that already carried version = pins in path deps needed the bump — the ones without a version field (which don't need it since they're not published) were correctly left alone. The version bump is consistent.

I have enough to write the review now.

Review: PR #7215 — chore(l1,l2): bump version to 25.0.0

This is a release-management PR (merge of release/v25.0.0 back to main) with two commits: a mechanical version bump and a CI fix for the release-publishing workflow. No product/consensus code is touched — the diff is version strings, regenerated lockfiles, and one workflow file.

1. CI fix — finalize-release / dry-run-release-assets artifact download pattern (.github/workflows/tag_release.yaml)

The fix is correct and well-targeted:

• The old unanchored pattern: "*ethrex*" matched both the intended release artifacts (ethrex-*, stateless-validator-ethrex-*) and the docker jobs' <org>~ethrex~<id>.dockerbuild build records. Since those records aren't zip archives, download-artifact exhausted retries trying to extract them and failed the whole job before any release asset was published.
• Splitting into two anchored patterns (ethrex* and stateless-validator-ethrex-*) resolves this cleanly: neither pattern matches names like <org>~ethrex~<id>.dockerbuild since neither is a prefix of that string. I verified against the actual artifact names in the workflow (ethrex${{ matrix.l2_suffix }}-..., ethrex-contracts.tar.gz, stateless-validator-ethrex-${{ matrix.zkvm }}-${VERSION}) — both patterns line up exactly with what's expected downstream (the signing step, the elfs/vks count assertions, and files: ./bin/**/* in the final softprops/action-gh-release step).
• The two patterns are mutually exclusive (no artifact matches both), so running download-artifact twice into the same ./bin path is safe — no overwrite/merge collision, consistent with the pre-existing default (per-artifact subdirectories, since merge-multiple isn't set).
• Applying the identical fix to dry-run-release-assets is good — that job would otherwise have silently diverged from finalize-release's behavior and stopped being a faithful rehearsal.
• The comments explaining why the anchoring matters (and why the dry-run couldn't have caught this, since it doesn't wait on the docker jobs) are genuinely useful for future maintainers — good call documenting the root cause instead of just the fix.

Nothing to flag here; this is a solid, narrowly-scoped fix for a real production incident (confirmed by the PR description: rc.1 built all 13 jobs green but published nothing).

2. Version bump commit

• All internal ethrex-* crate versions and workspace-level path-dependency version pins are bumped consistently from 24.0.0 → 25.0.0 across Cargo.toml/Cargo.lock files, including the four independent stateless-validator/**/Cargo.lock workspaces that make update-cargo-lock doesn't cover (I spot-checked: the only remaining 24.0.0 string left in the tree is an unrelated third-party crate, revm-interpreter, which coincidentally shares that version number — not a missed ethrex crate).
• docs/CLI.md's two --builder.extra-data default snippets were correctly regenerated to match.
• The PR description itself flags the manual-lockfile-refresh asymmetry (make update-cargo-lock vs check-cargo-lock) as tech debt for a follow-up rather than silently living with it — reasonable to defer given this PR's scope is just unblocking the release.

Other notes

• The STORE_SCHEMA_VERSION checklist item is left unchecked, which is correct — this PR has no Store schema changes.
• No consensus, EVM, RLP, trie, or networking code is touched, so the usual correctness/security/gas-accounting concerns don't apply here.

Overall: a clean, low-risk PR. The CI fix is the substantive part and it's correct; the version bump is purely mechanical and consistent throughout.

---

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

[github-actions]

🤖 Codex Code Review

No findings.

The workflow change in .github/workflows/tag_release.yaml and .github/workflows/tag_release.yaml looks correct: the new anchored patterns still cover the actual release artifacts (ethrex*, ethrex-contracts.tar.gz, stateless-validator-ethrex-*) while excluding the Docker .dockerbuild records that were breaking download-artifact. The downstream signing and publish steps still recurse under ./bin, so the split download remains compatible.

The rest of the PR is a mechanical version bump in manifests/locks plus the generated CLI docs update in docs/CLI.md. No EVM, consensus, trie, RLP, transaction validation, or gas-accounting paths are touched.

Residual risk: I did not execute the GitHub Actions workflow from this environment, so this is a static review only.

---

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

[github-actions]

Benchmark Results Comparison

No significant difference was registered for any benchmark run.

Detailed Results

Benchmark Results: BubbleSort

Command	Mean [s]	Min [s]	Max [s]	Relative
main_revm_BubbleSort	2.506 ± 0.016	2.484	2.536	1.14 ± 0.02
main_levm_BubbleSort	2.200 ± 0.031	2.176	2.264	1.00
pr_revm_BubbleSort	2.513 ± 0.016	2.486	2.541	1.14 ± 0.02
pr_levm_BubbleSort	2.209 ± 0.026	2.193	2.278	1.00 ± 0.02

Benchmark Results: ERC20Approval

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
main_revm_ERC20Approval	814.0 ± 19.0	799.3	863.0	1.02 ± 0.02
main_levm_ERC20Approval	799.9 ± 4.4	796.5	811.8	1.00
pr_revm_ERC20Approval	820.2 ± 16.9	806.0	853.1	1.03 ± 0.02
pr_levm_ERC20Approval	816.5 ± 9.1	807.4	833.8	1.02 ± 0.01

Benchmark Results: ERC20Mint

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
main_revm_ERC20Mint	109.0 ± 0.6	108.3	109.9	1.00
main_levm_ERC20Mint	123.1 ± 1.6	121.5	125.7	1.13 ± 0.02
pr_revm_ERC20Mint	111.3 ± 1.8	109.3	114.1	1.02 ± 0.02
pr_levm_ERC20Mint	124.5 ± 1.6	123.3	128.8	1.14 ± 0.02

Benchmark Results: ERC20Transfer

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
main_revm_ERC20Transfer	192.3 ± 1.7	190.6	195.9	1.00
main_levm_ERC20Transfer	207.2 ± 6.7	203.3	225.6	1.08 ± 0.04
pr_revm_ERC20Transfer	196.2 ± 3.8	193.6	205.8	1.02 ± 0.02
pr_levm_ERC20Transfer	210.8 ± 5.8	207.5	226.5	1.10 ± 0.03

Benchmark Results: Factorial

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
main_revm_Factorial	174.7 ± 2.5	173.0	179.8	1.00
main_levm_Factorial	200.9 ± 1.4	199.0	202.8	1.15 ± 0.02
pr_revm_Factorial	175.4 ± 2.6	173.7	180.6	1.00 ± 0.02
pr_levm_Factorial	201.6 ± 1.9	199.1	206.0	1.15 ± 0.02

Benchmark Results: FactorialRecursive

Command	Mean [s]	Min [s]	Max [s]	Relative
main_revm_FactorialRecursive	1.274 ± 0.037	1.212	1.320	1.00 ± 0.04
main_levm_FactorialRecursive	7.422 ± 0.036	7.374	7.489	5.84 ± 0.16
pr_revm_FactorialRecursive	1.271 ± 0.034	1.217	1.319	1.00
pr_levm_FactorialRecursive	7.418 ± 0.052	7.344	7.506	5.84 ± 0.16

Benchmark Results: Fibonacci

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
main_revm_Fibonacci	161.6 ± 1.4	159.0	164.3	1.00
main_levm_Fibonacci	181.4 ± 5.1	175.1	188.8	1.12 ± 0.03
pr_revm_Fibonacci	162.1 ± 0.7	161.2	163.1	1.00 ± 0.01
pr_levm_Fibonacci	184.3 ± 8.5	175.6	204.7	1.14 ± 0.05

Benchmark Results: FibonacciRecursive

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
main_revm_FibonacciRecursive	690.2 ± 13.4	668.7	713.7	1.22 ± 0.03
main_levm_FibonacciRecursive	568.0 ± 5.1	560.9	576.5	1.00 ± 0.01
pr_revm_FibonacciRecursive	698.8 ± 5.9	688.3	708.1	1.23 ± 0.01
pr_levm_FibonacciRecursive	567.1 ± 4.0	563.2	577.1	1.00

Benchmark Results: ManyHashes

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
main_revm_ManyHashes	7.1 ± 0.1	7.0	7.2	1.00 ± 0.02
main_levm_ManyHashes	7.9 ± 0.3	7.8	8.6	1.13 ± 0.04
pr_revm_ManyHashes	7.1 ± 0.1	7.0	7.2	1.00
pr_levm_ManyHashes	7.9 ± 0.1	7.8	8.0	1.12 ± 0.02

Benchmark Results: MstoreBench

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
main_revm_MstoreBench	215.5 ± 4.0	212.5	225.6	1.32 ± 0.03
main_levm_MstoreBench	163.7 ± 3.5	160.1	169.2	1.00 ± 0.03
pr_revm_MstoreBench	215.5 ± 3.4	212.0	223.6	1.32 ± 0.03
pr_levm_MstoreBench	163.5 ± 2.6	160.7	167.9	1.00

Benchmark Results: Push

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
main_revm_Push	244.9 ± 1.3	243.3	247.7	1.21 ± 0.02
main_levm_Push	203.3 ± 4.1	199.7	211.6	1.00 ± 0.03
pr_revm_Push	246.1 ± 3.7	243.4	255.2	1.21 ± 0.03
pr_levm_Push	203.0 ± 3.6	199.6	211.6	1.00

Benchmark Results: SstoreBench_no_opt

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
main_revm_SstoreBench_no_opt	136.3 ± 2.1	132.8	138.4	1.53 ± 0.03
main_levm_SstoreBench_no_opt	89.0 ± 0.4	88.4	89.7	1.00
pr_revm_SstoreBench_no_opt	134.9 ± 2.1	132.7	138.9	1.52 ± 0.02
pr_levm_SstoreBench_no_opt	89.4 ± 0.4	88.5	89.8	1.00 ± 0.01