Skip to content

feat: feat-v0.9.0 - #11

Open
Thegaram wants to merge 1 commit into
mainfrom
feat-v0.9.0
Open

Thegaram wants to merge 1 commit into
mainfrom
feat-v0.9.0

Conversation

@Thegaram

Copy link
Copy Markdown
Contributor

What changed

v0.9.0 changes which contract is deployed, not just versions. v0.8.0 deployed the flat Halo2Verifier. v0.9.0 deploys OpenVmHalo2Verifier, a wrapper that inherits it. The source moves from openvm-solidity-sdk@v1.6 to v2.0-deferral
(Scroll's bundle circuit defers proof verification).

  • Bump OpenVM to v2.0.0, stark-backend to v2.0.0, snark-verifier-sdk to git v0.2.6, scroll-zkvm-verifier to v0.9.0.
  • Drop openvm-native-recursion (removed in OpenVM v2.0.0) and the halo2-axiom feature (removed in snark-verifier-sdk@v0.2.6).
  • Swap the openvm-sdk evm-prove feature for evm-verify, which subsumes it
  • Compile the three verifier sources with solc --standard-json. snark-verifier's compile_solidity reads one source from stdin, so it cannot resolve the wrapper's imports
  • Re-compute now uses Sdk::builder() with DeferralHookCommits, mirroring openvm-solidity-sdk's own generate-verifier
  • Bump the toolchain to nightly-2025-11-20. The new dependencies need Rust 1.91.1 or newer
  • Remove the forge fmt step and the Foundry v1.5.0 requirement. The SDK generator now emits canonical text

Why the solc settings matter

solc embeds a metadata hash that covers the source unit names and the compiler settings. Both modes therefore use the SDK's exact paths (src/v2.0-deferral/...) and settings: optimizer on with 100000 runs, constantOptimizer and the Yul optimizer off, evmVersion paris, and the forge-std/ remapping. Any change alters the codehash even when the executable code is identical.

Verification

generate-verifier and compute-digest both reproduce the deployed mainnet values exactly:

  • codehash 0x00dfb6855747412fa70b8a75aaa4950f1deafaace9d2a4e9923ad2e1a3589928 matches the plonkVerifier at 0x0d2A59fd7060460F07c30C2817b4E79576da01C6
  • digest-1 / digest-2 match verifierDigest1() / verifierDigest2() on the ZkEvmVerifierPostFeynman at 0x7966FE0De13e3B81533470640Ac489223476B254

cargo build, cargo clippy and cargo fmt --check are clean.

Not verified

--recompute is untested. It needs roughly 200 GB of RAM. Please run it on a large instance before merging.

Note for reviewers

Do not regenerate Cargo.lock from scratch. That drifts alloy-consensus from 1.1.2 to 1.8.3, whose CryptoProvider trait gains a required method that zkvm-prover v0.9.0 does not implement, and the build then fails in a dependency.

@Thegaram
Thegaram requested a review from lispc September 15, 2026 06:42
@Thegaram
Thegaram marked this pull request as ready for review September 16, 2026 08:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants