Skip to content

ci: run the ZisK guest vectors - #108

Merged
Gabriel-Trintinalia merged 4 commits into
Consensys-Incorporated:mainfrom
Gabriel-Trintinalia:ci/zisk-guest-vectors
Sep 4, 2026
Merged

ci: run the ZisK guest vectors#108
Gabriel-Trintinalia merged 4 commits into
Consensys-Incorporated:mainfrom
Gabriel-Trintinalia:ci/zisk-guest-vectors

Conversation

@Gabriel-Trintinalia

Copy link
Copy Markdown
Collaborator

Problem

zesu CI never builds the rv64im object, let alone runs it. The whole class of "compiles fine, passes every native suite, aborts in the guest" is invisible here.

That is exactly how #97 landed: green on this workflow, and every mainnet block aborting under ziskemu with a write below the stack region. It took a day to trace, and nothing in this repo would have caught it.

Change

A ZisK Guest Vectors job that:

  1. builds zig build rv64im-object -Doptimize=ReleaseFast — riscv64-freestanding, no atomics, no libc, bump allocator; a target no other job touches
  2. links it against zesu-zkvm's host object and linker script
  3. executes a real mainnet block in the emulator (make test, the mainnet_fusaka_24758573 vector)

Step 3 is the one that matters — a build step alone would not have caught #97, which compiled cleanly.

One pin, not two

Only ZKVM_REF is pinned. The ZisK version is read out of that commit's own workflow instead of being duplicated here:

v=$(grep -m1 'ZISK_VERSION:' zesu-zkvm/.github/workflows/ci.yml | sed 's/.*"\(.*\)".*/\1/')

The ziskos runtime and the linker script are coupled through their heap symbols — a v1.0.0-alpha ziskos requires _kernel_heap_bottom/_top, which the 1.1.0 script no longer provides, and the mismatch surfaces only as an undefined symbol at link time. Duplicating the version here would let the two drift silently, so it is derived.

The staticlib cache key includes the resolved version, so bumping ZKVM_REF to a commit on a different ZisK evicts the stale archive rather than reusing it.

Cost

~3 min: ziskup install, one cargo build of libziskos_staticlib.a (cached on the ZisK version), one guest build, one block.

This PR is expected to be RED

Deliberately based on main rather than stacked on the fix, so the first run demonstrates the job working. main still allocates through std.heap.ArenaAllocator, whose atomics are unusable in a guest built without the A extension, and the first call exhausts the 4 MiB stack:

Mem::write_silent() invalid addr=9ffffff8 write section start=a0000000 end=c0000000

That is the bug #97 shipped and this workflow missed. Merge #107 and this goes green.

🤖 Generated with Claude Code

Gabriel-Trintinalia and others added 4 commits September 4, 2026 09:51
zesu CI never builds the rv64im object, let alone runs it, so the entire
class of "compiles, passes every native suite, aborts in the guest" is
invisible here. That is how Consensys-Incorporated#97 landed: it was green on this workflow and
broke every mainnet block under ziskemu.

Add a job that builds the guest object and executes a real mainnet block
in the emulator, using zesu-zkvm for the linker script, host object and
vectors.

Only ZKVM_REF is pinned. The ZisK version is read out of that commit's own
workflow rather than duplicated here, because the runtime and the linker
script are coupled through their heap symbols — a v1.0.0-alpha ziskos wants
_kernel_heap_bottom/_top, which the 1.1.0 script no longer provides, and
the mismatch only shows up as an undefined symbol at link time.

This job is expected to FAIL on main as it stands: main still allocates
through std.heap.ArenaAllocator, whose atomics are unusable in a guest
built without the A extension, and the first call exhausts the 4 MiB
stack. That failure is the job demonstrating what it is for.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Bare `ziskup` resolves "latest" when the step runs, so the emulator drifts
independently of the staticlib and the linker script it has to agree with.
The first run of this job hit exactly that: a >=1.1.0 emulator rejected the
RWX text segment that zesu-zkvm's 1.0.0-era script emits.

    Error during emulation: PT_LOAD segment at 0x80000000 is both writable
    and executable (W^X violation)

v1.0.0-alpha has no such check; v1.1.0-alpha added it. Pin the emulator to
the resolved version so all three move together.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
GITHUB_PATH additions only take effect in subsequent steps, so the check
ran before ziskemu was on PATH.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@Gabriel-Trintinalia
Gabriel-Trintinalia merged commit 83f6b2b into Consensys-Incorporated:main Sep 4, 2026
10 of 11 checks passed
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.

1 participant