feat: update zisk to v1.1.0-alpha - #404
Merged
Merged
Conversation
han0110
marked this pull request as ready for review
August 18, 2026 08:50
This was referenced Aug 18, 2026
spencer-tb
pushed a commit
to spencer-tb/ethrex
that referenced
this pull request
Aug 19, 2026
**Motivation** [ZisK v1.1.0-alpha](https://github.com/0xPolygonHermez/zisk/releases/tag/v1.1.0-alpha) is out. It carries soundness fixes (`MemAlign` on non-aligned memory operations, narrow unsigned loads leaving high bytes unconstrained, signed-division zero results in the Arith state machine, BLAKE2b message permutation, DMA transpilation under dynamic jumps), a reworked BLAKE2b arithmetization (24 → 8 rows per round), more efficient Main/Binary arithmetization, and a `.sbss`-aware linker script. Upstream's own upgrade note is explicit that ELFs must be rebuilt against it. **Description** Bumps the `ziskos` tag in `crates/guest-program/Cargo.toml` and `crates/guest-program/bin/zisk/Cargo.toml`, raises `ZISK_VERSION` in `.github/actions/install-zisk`, and refreshes the workspace and ZisK-guest lockfiles. The lock churn is larger than a version string because pil2-proofman moved to crates.io and several ZisK crates gained a `zisk-` prefix (`zkvm-interface` → `zisk-zkvm-interface`, `lib-c` → `zisk-lib-c`, `precompiles-helpers` → `zisk-precomp-helpers`, `circuit` → `zisk-circuit`). The one non-mechanical part is `ZISK_RUST_TOOLCHAIN`, re-pinned from `zisk-0.5.1` to `zisk-3.0.0`. That pin exists because ziskup installs whatever toolchain release is newest, and the two versions have to agree on who supplies the guest linker script. v1.1.0-alpha reverses the direction of that dependency: `zisk-build` now injects its own script (`-C link-arg=-T<zisk_linker_script.ld>`), so the toolchain must be one that embeds *none*. On the old pin the link takes both and fails: ``` rust-lld: error: rustc-riscv64-linkfile.ld:6: region 'rom' already defined >>> rom (xa) : ORIGIN = 0x80000000, LENGTH = 0x10000000 ``` No source changes were needed: - `zkvm-interface/zkvm_accelerators.h` is byte-identical between the two tags, so the hand-written `extern "C"` bindings in the ZisK crypto provider still match. - The `cargo-zisk` `build` / `execute` / `prove` / `verify` flags the prover backend drives are unchanged, and `ziskos::entrypoint!` stayed compatible with a plain `fn()`. - `zkvm_bls12_g1_msm` / `zkvm_bls12_g2_msm` / `zkvm_bls12_pairing` now return `ZKVM_EFAIL` on a zero-length pair list. Unreachable from here — all three levm precompiles reject empty calldata before building the pair vector. Two things worth flagging for reviewers: - **The guest ELF changes shape.** The new linker script rewrites the RAM layout (stack now at `0xa0000000`, `.output_data` at `0xa0410000` instead of `0xa0020000`), so any pinned ZisK verification key has to be regenerated. Nothing on-chain depends on it today — `ZiskBackend::prover_type()` is still `unimplemented!()`. - **The stateless-validator guest is out of scope.** It reaches ZisK through `ere-platform-zisk` at a pinned ere rev, which still resolves v1.0.0-alpha. eth-act/ere#404 bumps it upstream but landed after ere v0.15.0, so there is no release (and therefore no `ere-compiler-zisk` release image) carrying it yet, and moving the shared `ERE_REV` would also pull in unrelated sp1/openvm changes. Separate change once ere cuts a release. **Also in this PR: the `zkevm_bench` workspace** `tooling/zkevm_bench` landed on main after this branch was opened, and it carries its own ZisK coupling. Three things needed doing, none of them optional: - Its committed lockfile went stale the moment the `ziskos` tag moved, because it depends on `ethrex-guest-program` with the `zisk` feature. Its lint step runs `cargo clippy --locked` and then asserts the lock is unmodified, so this was a guaranteed CI failure on the first run after merging main in. That makes three lockfiles this bump has to touch. - `make zkevm-bench-setup` and the tool's README still said v1.0.0-alpha. Bumped, and the Rust toolchain the target installs is now pinned to the same release CI uses — ziskup takes whatever is newest, which for v1.0.0-alpha was already the wrong pairing, so that target could not have linked a guest as written. - The tool shells out to `ziskemu -X` and parses the AIR-cost report, and v1.1.0-alpha reworks emulator statistics. Rather than assume, I ran `ziskemu -X` from the new toolchain against a guest ELF built from this tree: the only structural change is an added `ROM USAGE` line. Every label `parse_air_cost` matches is still emitted unchanged and `ROM` is not one of them, so it is skipped like any unrecognised label. Noted in `docs/ziskemu-output.md`. Deliberately left on v1.0.0-alpha: the tool's test fixtures, its sample report, and the committed `fixtures/ziskemu_sample.txt`. Those record a real captured run rather than a version we install, so rewriting the strings would misdescribe the capture. **How to Test** No CI job builds the ZisK guest ELF — the prover lint job only runs `cargo check`/`clippy`, which do not enable `zisk-build-elf` — so the toolchain pairing above was verified by hand on an x86_64 Debian 13 box provisioned exactly like `install-zisk` does it (ziskup v1.1.0-alpha + `cargo-zisk toolchain install -t zisk-3.0.0`): ```bash # builds and links the guest ELF cd crates/guest-program cargo check --release -p ethrex-guest-program --features zisk-build-elf,ci # what the PR job runs cargo check -r -p ethrex-prover -F "zisk,ci" cargo clippy -r -p ethrex-prover --all-targets -F "zisk,ci" # lockfiles resolve as committed make check-cargo-lock ``` All pass. `readelf -lW` on the produced ELF shows the v1.1.0-alpha memory map, confirming the SDK's script won rather than a stale one from the toolchain. Re-pinning the toolchain back to `zisk-0.5.1` and rebuilding reproduces the `region 'rom' already defined` failure quoted above, so the pin change is load-bearing rather than cosmetic. **Checklist** - [ ] Updated `STORE_SCHEMA_VERSION` (crates/storage/lib.rs) if the PR includes breaking changes to the `Store` requiring a re-sync.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
zisktov1.1.0-alphaand use deps from crates.io