Hello ZK Robot

This repo shows the minimal end-to-end pattern for proving a robot safety constraint with a real ZK (Zero-Knowledge) system (a zkVM).

• Robot / Prover side (host): reads a run log, computes a run_hash, feeds the run into the zkVM, and generates a proof.
• Verifier side: checks the proof using only the program's verification key + public outputs (including run_hash).

We use SP1, a zero-knowledge virtual machine (zkVM) that proves correct execution of Rust programs compiled to RISC-V.

_{Illustration / branding: Inversed}

Zero-Knowledge Proof (ZKP) Context

If you are new to cryptography, the core idea is:

• You have a run log (trajectory, controls, sensor-derived state, etc.).
• You want to convince someone a safety check passed.
• You do not want to reveal the full run log.

A zero-knowledge proof (ZKP) lets you do exactly that:

• Prover (robot/operator) computes a proof.
• Verifier checks the proof quickly.
• The verifier learns only the public facts you choose to reveal (for example: run_hash, parameters, and ok=true).

Mental model

Think of this as:

• "I ran this exact safety-check program"
• "on some private trajectory"
• "and the result was ok=true"
• "and that private trajectory is bound to this public commitment (run_hash)"

The verifier does not need the trajectory itself.

What is a zkVM?

A zkVM (zero-knowledge virtual machine) is a system that can prove the execution of a normal program.

In this repo:

• The zkVM program is Rust code in program/src/main.rs.
• The host code in script/src/main.rs feeds inputs and asks SP1 to execute/prove/verify.

This is useful for robotics because you can express safety checks as ordinary deterministic code instead of writing custom cryptographic circuits.

Why the run_hash matters

Without a commitment, a proof could say "some hidden trajectory passed" without giving anyone a way to refer to which trajectory was checked.

run_hash is a public fingerprint of the run:

• The host computes it from the trajectory.
• The zkVM recomputes it internally from the private points.
• The proof is only valid if those match.

That binds the proof to one specific run while keeping the run private.

Terminology (minimal)

• Witness / private witness: secret inputs to the proof (here, the trajectory points).
• Public inputs: values the verifier sees and checks against (here, run_hash, n, vmax).
• Public outputs: values the program commits so the verifier can read them from the proof (here, ok and run_hash).
• Proof: a cryptographic object showing the zkVM program executed correctly.
• Verification key: public key/material needed to verify proofs for this program.

What this demo does not try to solve

• Sensor authenticity (garbage-in, garbage-out still applies)
• Real-time proving on embedded hardware
• Continuous-time dynamics or full physics constraints
• Multi-robot coordination/privacy policies

This demo is only about the core pattern: "prove check_run(log) without revealing log."

What is being proven?

Given a hidden 2D trajectory p[0..n-1], the zkVM program checks:

1. Bounds: each position stays within a public bounding box [0..MAX_X] x [0..MAX_Y]
2. Forbidden zone avoidance: no position enters a public axis-aligned forbidden rectangle
3. Speed bound (L1): for each step, |dx| + |dy| <= VMAX

The zkVM program also recomputes run_hash = SHA256(positions_bytes) and asserts it matches the provided public run_hash.

Public inputs/outputs

• run_hash (32 bytes): commitment to the run
• n (u32), VMAX (u32), bounds + forbidden rectangle (public parameters)
• ok (bool): whether safety checks passed (committed as a public output)

Private witness

• The full trajectory points (x_i, y_i).

Requirements

This demo uses SP1, a zero-knowledge virtual machine.

1) Install SP1 toolchain

Follow the official SP1 installation instructions:

https://docs.succinct.xyz/docs/sp1/getting-started/install

The recommended way is:

curl -L https://sp1up.succinct.xyz | bash
sp1up

SP1 uses the cargo prove workflow. Install via sp1up (recommended by SP1 docs) and confirm:

cargo prove --version

Quickstart

1) Run (execute only, no proof)

cd script
RUST_LOG=info cargo run --release -- --execute --run ../examples/sample_run.json

2) Prove + verify

cd script
RUST_LOG=info cargo run --release -- --prove --run ../examples/sample_run.json

You should see:

• the computed run_hash
• executed program ... cycles
• generated proof
• verification success
• committed public outputs (including ok=true for the sample run)

How to change the safety constraint

The safety property being proven is defined by the zkVM program in program/src/main.rs.

In this demo, a run is considered safe if:

• The robot stays inside a bounding box
• The robot avoids a forbidden rectangular region
• The robot does not exceed a maximum step speed

You can modify this logic to define your own safety property. Common changes include:

• Changing the allowed operating region (bounding box)
• Moving or adding forbidden zones / obstacles
• Modifying the motion constraint (e.g., speed, acceleration, or smoothness)
• Implementing a completely different safety condition

The proof will then attest that your modified safety-checking program executed correctly on a hidden trajectory.

Then rerun cargo run in script/ (the build step is handled by script/build.rs).