Skip to content

native-prover.md

Latest commit

 

History

History
75 lines (59 loc) · 3.57 KB

native-prover.md

File metadata and controls

75 lines (59 loc) · 3.57 KB
Raw

Native prover backend

Purpose: the preferred backend — proves by running the local snip36 CLI directly (no Docker, native speed, the user's own arch). Isolated in src/native_prover.rs; backend-independent logic is shared in src/snip36.rs. Status: current as of 2026-06-05. Verified — a native arm64 prove of a real mainnet tx produced a ~398 KB proof in ~30 s with the mainnet-accepted SNOS hash (0x3e98c2d7…), no container.

Why native (not Docker)

The earlier belief that arm64 proofs are mainnet-invalid was wrong — it was dependency skew (a stale RC.3 prover side-clone vs an RC.6 verifier), not architecture (see decisions.md, 2026-06-05). With a current prover stack, native arm64 proofs verify, so dinner proves natively by default and only falls back to the docker backend when no local stack is available.

Select it

DINNER_PROVER=native                          # or pick "native" in Settings
DINNER_SNIP36_BIN=…/snip-36-prover-backend/target/release/snip36   # default: sibling checkout
DINNER_SNIP36_WORK_DIR=…/snip-36-prover-backend                    # must contain deps/

/health reports "prover": "native"; prover_ready is true when the configured snip36 binary exists.

How it runs

Runs snip36 prove virtual-os … with cwd = WORK_DIR (so it finds deps/), the same env + flags as the docker backend (RPC + chain id; dummy 0x1 account/key — no real key, see the no-private-key invariant), reading back out.proof / out.proof_facts / out.raw_messages.json.

Keeping the stack current (important)

deps/sequencer is a side-clone, not a tracked dependency — git pull doesn't touch it. After the repo's prover pin moves (e.g. a new SEQUENCER_TAG), re-provision the side-clone to the matching tag and rebuild, or you'll silently prove with a stale snapshot that the on-chain verifier rejects (with no version hint in the error). This skew was the original "INVALID_PROOF" cause.

Bundling into the app (self-contained build)

For a distributable app the prover is bundled so no external checkout is needed:

  1. Stage the lean runtime set (~286 MB — CLI + sequencer runner + sierra compiler + the crates' resource JSONs; not the ~9.6 GB of build intermediates) into desktop/src-tauri/resources/prover/: 
    cd desktop && SNIP36_REPO=/path/to/snip-36-prover-backend ./scripts/stage-prover.sh
    The staged dir is gitignored. Verified: dinner's native backend proves against exactly this set.
  2. Bundle — tauri.conf.json ships resources/prover/**/*. At startup the desktop app resolves the bundled prover from its resource dir and sets DINNER_SNIP36_BIN / DINNER_SNIP36_WORK_DIR automatically (unless already set). In dev (unstaged) this is a no-op and the sibling-checkout default is used.
  3. npm run tauri build.

Caveats (not yet validated end-to-end in a packaged build):

  • Per-platform. The staged binaries are for the build machine's arch; stage from a checkout built for each target platform you ship.
  • Exec bit / signing. Bundled binaries must stay executable; on macOS they'll also need to be inside the app's code signature / notarization. Verify the runner launches from the installed .app.
  • Currency. Re-stage after the prover pin moves (see above).

Payload contract & result shape

Identical to the docker backend — see docker-prover.md: { transaction, block_number? } in, { proof, proof_facts, l2_to_l1_messages } out, with the same RPC-spec-≥0.10 requirement and nonce preflight.