feat: update `zisk` to `v0.17.0` by han0110 · Pull Request #351 · eth-act/ere

han0110 · 2026-05-04T08:25:43Z

Update ZisK to v0.17.0, a patch is still needed to recover from prover error
- han0110/zisk@9499da6
  Set complete for the ASM service so there is no dangling threads that causes memory leak, without this the prover restart will end up out of memory
- han0110/zisk@4c38059
  Expose a function to cleanup ASM services when it fails and exits (e.g. guest program panics)
- han0110/zisk@6d09f8e
  Expose a function to compute program vk without starting the ASM services
- han0110/zisk@4019fa3
  Patch the ziskfloat.elf by extracting from the released cargo-zisk in upstream repo, and disable the build.rs script of lib-float crate to avoid ziskfloat.elf gets updated (which makes the program vk different). This ensures the ZisK prover in Ere to compute the same program vk as the official released cargo-zisk does.
Update the ZiskProof format to match the format expected by proofman-verifier, and do strict constant size check to avoid the verifier panics

Update the ZiskPlatform implementation, now the profile syscall reads string as naming instead of requiring a constant tag. However, the AOT compilation process doesn't support ELF with the profile syscall (depended by prover), so currently the cycle_scope_* functions are left no-op.

@jsign This breaks the zisk profilng flow in zkevm-benchmark-workload, we probably need a custom build for the guests to do profiling, or we adapt to the Function-Level Profiling that works for prover and enabled by default like:

ziskemu -e <elf-path> -i <input-path> -X -S -D

...

  TOP STEP FUNCTIONS (STEPS, % STEPS, CALLS, STEPS/CALL, FUNCTION)
----------------------------------------------------------------
            475   3.93%          1             475 <ere_platform_zisk::platform::ZiskPlatform as ere_platform_core::platform::Platform>::write_whole_output
            474   3.92%          1             474 <ere_util_test::program::basic::BasicProgramOutput<ere_util_test::codec::BincodeLegacy> as ere_codec::encode::Encode>::encode_to_vec
            470   3.89%          1             470 ziskos::io::commit_slice
            443   3.67%          1             443 <ere_util_test::program::basic::BasicProgramOutput<…> as serde_core::ser::Serialize>::serialize::<bincode::features::serde::ser::SerdeEncoder<…>>
            291   2.41%          3              97 <alloc::raw_vec::RawVecInner<_>>::reserve::do_reserve_and_handle::<alloc::alloc::Global>
            241   1.99%          1             241 <ere_util_test::program::basic::BasicProgramInput<ere_util_test::codec::BincodeLegacy> as ere_codec::decode::Decode>::decode_from_slice
            206   1.70%          1             206 <bincode::features::serde::de_borrowed::SerdeDecoder<…> as serde_core::de::Deserializer>::deserialize_struct::<<…>::deserialize::__Visitor<…>>
            184   1.52%          3              61 <alloc::raw_vec::RawVecInner>::finish_grow
             63   0.52%          1              63 <ere_platform_zisk::platform::ZiskPlatform as ere_platform_core::platform::Platform>::read_whole_input
             42   0.35%         14               3 memcpy
             40   0.33%          2              20 __rustc::__rust_realloc
             40   0.33%          1              40 ziskos::io::read_input_slice
             32   0.26%          2              16 __rustc::__rust_alloc
             16   0.13%          1              16 __rustc::__rust_alloc_zeroed
              3   0.02%          3               1 __rustc::__rust_dealloc
              3   0.02%          3               1 __rustc::__rust_no_alloc_shim_is_unstable_v2
              2   0.02%          2               1 zkvm_init

...

Update the ZiskClusterClient API, adds function create_prove_job, wait_prove_job, and cancel_prove_job, and prove is built by composing the async endpoints with an optional deadline.

han0110 · 2026-05-05T07:18:57Z

 [features]
 default = []
-cuda = ["zisk-sdk/gpu"]
+cuda = []


In v0.17.0 ZisK has cuda enabled by default (by detecting if nvcc is available), and a cpu-only feature flag is available to force cuda disabled. If we try to initialize gpu prover without nvcc available, it'd show a runtime error, so we add a build.rs to turn that into a compile time error.

han0110 · 2026-05-05T08:03:30Z

+    fn validate_format(&self) -> Result<(), Error> {
+        if self.0.len() != PROOF_WORDS {
+            return Err(Error::InvalidProofFormat(format!(
+                "proof has {} u64 words, expected to be {PROOF_WORDS}",
+                self.0.len(),
+            )));
+        }
+        if self.0[0] != PROOF_PREFIX_WORDS as u64 {
+            return Err(Error::InvalidProofFormat(format!(
+                "proof n_publics is {}, expected to be {PROOF_PREFIX_WORDS}",
+                self.0[0],
+            )));
+        }
+        Ok(())
+    }


Always validates the constant proof size and metadata, otherwise the verify function in proofman-verifier might be tricked to panic.

Uhm, panicking on verifying untrusted bytes sounds more like a bug to me. Prob we should ask them to avoid this eventually.

han0110 · 2026-05-05T08:06:03Z

+    libclang-dev \
+    clang \


Added for ZisK's zkvm-interface crate compilation.

han0110 · 2026-05-05T08:06:55Z

    clang \
    # Used to kill the ASM services when prover panics
-    psmisc \
+    procps \


We use pkill for defensive ASM service cleanup now (previously using fuser)

han0110 · 2026-05-05T08:12:47Z

+        let result = panic::catch_unwind(AssertUnwindSafe(|| {
+            self.prover
+                .prove(&self.program, stdin)
+                .wrap_proof(ProofKind::VadcopFinalMinimal)


Wrap into the minimal stark proof for smaller proof size (~256 KiB instead of ~329 KiB), this is also the default proof kind.

jsign

LGTM, left just some comments/questions.

jsign · 2026-05-05T13:19:34Z

-        )));
+fn parse_proof(bytes: &[u8]) -> Result<ZiskProof, Error> {
+    #[derive(Default, Serialize, Deserialize)]
+    pub struct Proof<'a> {


Are all these structs not exported by Zisk?

Yes, there is structure for the proof, but the proof is eventually flatten into the format added in this PR, and in the verifier they don't check the size, so a malformed proof will trigger index out of bounds.

Will file an issue in upstream as well.

jsign · 2026-05-05T13:23:41Z

-    fn cycle_scope_start(name: &str) {
-        let tag = SCOPE_REGISTRY.get_or_assign_tag(name);
-        dispatch_profile!(start, tag);
+    fn cycle_scope_start(_name: &str) {


@jsign This breaks the zisk profilng flow in zkevm-benchmark-workload, we probably need a custom build for the guests to do profiling, or we adapt to the Function-Level Profiling that works for prover and enabled by default like:

Uhm, function level profiling is a bit annoying since doesn't allow to undesrtand more cleanly where the cost is comming from in the app level logic.

By "custom build" you mean compiling the guest program or running it with Zisk with some feature enabled, or you mean actually re-implementing all the logic to have custom scopes as they had before?

Got a bit lost since you also mention they now support string scope names instead of constants, so "scope profiling" is still supported in some official way?

By "custom build" you mean compiling the guest program or running it with Zisk with some feature enabled, or you mean actually re-implementing all the logic to have custom scopes as they had before?

custom build I mean build with ziskos::ziskos_syscall!(ziskos::SYSCALL_PROFILE_ID, ...) uncommented, it's commented out becuase with these syscalls, the ELF can't be proved (but can be used with ziskemu to do the profiling we used to do)

Got a bit lost since you also mention they now support string scope names instead of constants, so "scope profiling" is still supported in some official way?

Scope profiling is supported by ziskemu, but the ELF can't be proved anymore.

Oh, I see. so the ziskos crate that teh guest program needs to add these scope markers needs a fork that uncomment some code. And we can use normal ere code (i.e non-modified) to emulate the elf run?

If that's the case, ere and workload isn't strictly affected but more like the guest program ziskos dependency used?

This assuming that we put the markers manually in guest with ziskos.

If we rely on ere for cycle-scoping, I agree that prob means custom ere which maybe is the most elegant thing now that strings names are supported?

This assuming that we put the markers manually in guest with ziskos.

I thought this might be the solution, but I just had another idea: Add a feature flag in ere-platform-zisk to enabling these profiling, so we can keep the same guest code and no forking, just need to enable a feature flag to generate the ELF for profiling only.

Will add a commit soon

Added in 1810ac4, so I think in ere-guests we can release another ELF with the feature on for the profiling (need to change the ere-compiler to accept feature flags first, will add a follow up PR soon)

Sounds good 🙏

jsign · 2026-05-05T13:28:29Z

+/// Clear the program cache so the next `setup` spawns fresh ASM services, then SIGTERM any orphan
+/// ASM child still bound to our `ZISK_{pid}_*` shmem prefix.


Tangent question: do you feel the cluster setup is more elegant in how setup/teardown works?

I checked the teardown logic in zisk and it looks like there are still some chance the ASM services get dangling, and the start function doesn't cleanup them, so I would prefer to keep the pkill for now

Ah but I was wondering in cluster mode -- that setup also needs these kind of services teardown stuff? (mainly asking for curiosity)

Ah I see, just tested and it seems if the worker ASM services die (guest program panics), it'll remain in bad status and coordinator doesn't remove the worker from the pool, so the whole cluster is also paralyzed...

Will need to figure out a way to check if the worker is still healthy so the supervisor can restart it if needed (e.g. docker-compose health check by grepping the asm services).

jsign · 2026-05-05T13:33:10Z

+    fn validate_format(&self) -> Result<(), Error> {
+        if self.0.len() != PROOF_WORDS {
+            return Err(Error::InvalidProofFormat(format!(
+                "proof has {} u64 words, expected to be {PROOF_WORDS}",
+                self.0.len(),
+            )));
+        }
+        if self.0[0] != PROOF_PREFIX_WORDS as u64 {
+            return Err(Error::InvalidProofFormat(format!(
+                "proof n_publics is {}, expected to be {PROOF_PREFIX_WORDS}",
+                self.0[0],
+            )));
+        }
+        Ok(())
+    }


Uhm, panicking on verifying untrusted bytes sounds more like a bug to me. Prob we should ask them to avoid this eventually.

han0110 added 10 commits May 2, 2026 13:15

feat: update ere-verifier-zisk

425c426

feat: update ere-cluster-client-zisk

2b9271e

feat: update ere-platform-zisk

260f1b1

chore: add cycle scope to Program for testing

151b4aa

feat: update ere-prover-zisk

1109f35

chore: update test guest

844d56f

feat: update zisk cluster docker image and example

0ccfab8

chore: udpate README.md

1727c18

chore: sync Cargo.lock

d2a2c11

fix: review

c09e714

han0110 force-pushed the han/feature/zisk-v0.17.0 branch from d7a71fa to c09e714 Compare May 4, 2026 15:02

Andrurachi mentioned this pull request May 5, 2026

ci: prevent github api rate limits using docker buildkit secrets #350

Open

han0110 added 3 commits May 5, 2026 02:56

fix: multiple zisk prover instances

39b0534

chore: fix typo

5de1867

chore: refine

8a4761a

han0110 marked this pull request as ready for review May 5, 2026 04:36

feat: compile time check for cuda feature

62303ed

han0110 commented May 5, 2026

View reviewed changes

han0110 requested a review from jsign May 5, 2026 11:04

jsign approved these changes May 5, 2026

View reviewed changes

feat: add cycle-scope feature in ere-platform-zisk

1810ac4

		/// Clear the program cache so the next `setup` spawns fresh ASM services, then SIGTERM any orphan
		/// ASM child still bound to our `ZISK_{pid}_*` shmem prefix.

Conversation

han0110 commented May 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jsign left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

han0110 May 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

han0110 May 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

han0110 commented May 4, 2026 •

edited

Loading

han0110 May 5, 2026 •

edited

Loading

han0110 May 5, 2026 •

edited

Loading