Proof System

1. Groth16 Protocol Overview

Given an arithmetic circuit C encoding a relation R(x, w) -- for example, "commitment C is in the Merkle tree with root R, and nullifier N is correctly derived" -- the Groth16 prover and verifier interact as follows:

(pk, vk) <- Setup(C)          // trusted setup, once per circuit
π        <- Prove(pk, x, w)    // client-side, via snarkjs
b        <- Verify(vk, x, π)   // on-chain, via alt_bn128 precompile

Why Groth16

Groth16 was chosen for Zera because it offers the smallest proof size and fastest verification time of any deployed SNARK system:

• Proof size: ~200 bytes (2 G1 points + 1 G2 point on BN254) -- smallest of any SNARK
• Verification: Single pairing equation check, constant time regardless of circuit complexity
• On-chain cost: ~200k compute units on Solana via the alt_bn128 precompile
• Trade-off: Requires a per-circuit trusted setup (powers of tau + phase 2), unlike universal/transparent systems like PLONK or STARKs

Security Properties

• Completeness: Honest prover with valid witness always produces an accepted proof
• Knowledge Soundness: Any prover that produces a valid proof must "know" the witness (under the KEA assumption on BN254)
• Zero-Knowledge: A simulator with the trapdoor can produce proofs indistinguishable from real ones -- no information about w leaks

Interactive Proof Flow

Explore how proofs flow through each of Zera's four circuit types. Click a circuit to see the step-by-step proof generation and verification pipeline:

2. Four Circuit Types

Zera has four circuit types, each with its own (pk, vk) pair:

• Deposit: Proves the commitment is correctly formed from (amount, secret, blinding, asset, memo)
• Withdraw: Proves Merkle membership, correct nullifier derivation, and amount consistency
• Relayed Withdraw: Same as withdraw, plus relayer fee deduction and recipient designation
• Transfer: Proves spending of input notes and creation of output notes with value conservation

Circuit Architecture

3. Transaction Flow: Withdraw Example

A user withdrawing from the privacy pool proceeds through the following steps. Click each step to explore:

4. Trusted Setup

4.1 How It Works

Zera's four Groth16 circuits each require a structured reference string (SRS) generated by a trusted setup ceremony. The ceremony uses the "powers of tau" protocol followed by circuit-specific phase-2 contributions:

SRS = (pk, vk) ← Setup(C)
where C is the arithmetic circuit (R1CS) for each operation

4.2 Security Guarantee

The standard Groth16 trust assumption: at least one participant in the ceremony must have honestly destroyed their toxic waste (the secret randomness used during their contribution). If this holds, the SRS is sound and no party can forge proofs.

4.3 On-Chain Verification

Groth16 proofs are verified on Solana using the alt_bn128 precompile, which natively supports BN254 pairing operations. The verification key (vk) is stored on-chain; each proof verification requires a single pairing check:

e(A, B) = e(α, β) · e(L, γ) · e(C, δ)
where e is the BN254 optimal Ate pairing

5. Groth16 Security Properties

6. State Transitions & Double-Spend Prevention

S_(i+1) = MerkleInsert(S_i, C_new)
Root_(i+1) = Poseidon(... path from new leaf to root ...)

Nullifier-Based Double-Spend Prevention

Zera prevents double-spends through deterministic nullifiers. When a note is spent:

• The spender computes N = Poseidon(secret, commitment) and reveals N on-chain
• The on-chain program checks N against a nullifier set -- if N already exists, the transaction is rejected
• The Groth16 proof demonstrates that N was correctly derived from a valid commitment in the Merkle tree
• No party can spend the same note twice without producing the same nullifier

Concurrent Transaction Tolerance

7. Post-Quantum Considerations

8. Deployed System Parameters

9. Performance & Implementation

10. Research Direction: Perpetual Genesis Ceremony