Generating Proofs
Zero-knowledge proofs (ZK proofs) are a core component of the ZKAP protocol. They allow developers to prove that an action is valid without revealing the action itself, the identity of the sender, or any metadata.
This file explains how ZK proofs work within ZKAP, what needs to be proven, and how to generate proofs using the SDK.
1. Why ZK proofs are required
Because ZKAP uses:
anonymous identities
encrypted payloads
stateless execution
no signatures
no public calldata
the blockchain cannot validate requests using traditional methods.
ZK proofs solve this by showing:
the sender followed protocol rules
the payload is valid
the nullifier is correctly generated
the expiry is within range
the commitment root matches the payload
Proofs allow the validator contract to trust the request without seeing any data.
2. What the proof must guarantee
A valid ZKAP proof enforces:
Identity is correctly formed
Payload hash is correct
Payload commitment matches encrypted payload
Nullifier was derived correctly
Expiry block is valid
No disallowed parameters exist
Action type satisfies required constraints
These conditions form the core of the ZK circuit.
3. Structure of a ZKAP ZK circuit
The proof is generated against a circuit containing the following private inputs:
identity (ephemeral)
payload hash
nonce
expiry
optional action constraints
And public outputs:
nullifier
commitment root
Private inputs stay hidden; public outputs go on-chain.
4. Supported proof systems
ZKAP supports multiple proof backends:
Groth16 (recommended for performance)
Plonk
Halo2
STARK-based systems
The SDK allows developers to choose the backend that fits their needs.
5. Generating a proof using the SDK
The SDK provides a high-level helper function:
const proof = await generateProof({ identity, payloadHash, nonce, expiry });
The SDK handles:
witness generation
circuit execution
proof construction
serialization
Developers don’t need deep ZK knowledge to use it.
6. Required inputs for proof generation
You must supply:
identity — ephemeral, generated via SDK
payloadHash — hash of the encrypted or plain payload
nonce — ensures unique nullifier
expiry — prevents delayed execution
prover backend — SnarkJS, Plonk, Halo2, etc.
Optional inputs depend on application constraints (e.g., swap checks, limit checks).
7. Steps inside the proof generation process
The generation process follows these internal steps:
Step 1 — serialize payload Step 2 — compute payload hash Step 3 — compute commitment root Step 4 — generate identity witness Step 5 — generate circuit witness Step 6 — run the circuit Step 7 — produce zero-knowledge proof Step 8 — return proof + public outputs
Only the final proof and public outputs go on-chain.
8. Example: proof generation (concept code)
import { generateProof } from "@zkap/sdk";
const payloadHash = poseidonHash(payload); const proof = await generateProof({ identity: id, payloadHash, nonce: 42, expiry: 12345678 });
console.log("Proof generated:", proof);
The SDK abstracts all cryptographic logic.
9. Proof verification (optional)
Developers may want to verify proofs locally during development:
const valid = await verifyProof(proof, commitmentRoot);
if (valid) console.log("Proof is valid");
This is not necessary for production, as validation happens on-chain.
10. Performance considerations
Groth16 proofs are the fastest to verify
Plonk and Halo2 may be slower but support richer circuits
STARKs offer transparency but larger proof sizes
WASM backend helps run proofs client-side in browsers
Backend servers can cache proving keys for faster generation
For high-frequency agents, batching proof generation may be used.
11. Troubleshooting proof errors
Common issues include:
mismatched circuit and proving key
using the wrong payload hash
incorrect expiry
incorrect identity or entropy reuse
nonce reuse leading to nullifier conflict
The SDK provides detailed error messages.
12. Security properties of ZKAP proof generation
ZKAP proofs provide strong guarantees:
no identity leakage
no payload leakage
no parameter leakage
no metadata leakage
no ordering leakage
no cross-request correlation
Even with full access to proofs, nobody can reconstruct:
the sender
the action
the amounts
the intent
Last updated