Key takeaways
– ZK‑SNARK = Zero‑Knowledge Succinct Non‑Interactive Argument of Knowledge: a cryptographic proof that one party (the prover) knows some secret information or can perform a computation correctly, without revealing the secret and without interaction with the verifier.
– Common uses: privacy-preserving blockchain transactions (e.g., Zcash), zk‑rollups and scaling, identity/credential proofs, confidential computations.
– Important tradeoffs: zk‑SNARKs are succinct and fast to verify but many constructions require a trusted setup (risk of “toxic waste”). Newer systems (PLONK, Halo/Halo2, STARKs) reduce or remove trusted setup at different costs.
– Practical work flow: design a circuit that expresses the statement, generate/setup parameters, produce a witness, generate the proof, and verify it (on‑chain or off‑chain).
Introduction — why ZK‑SNARKs matter
ZK‑SNARKs let someone prove they know a secret or that a computation’s output is correct without revealing the secret or internal details. That property enables privacy (shielded blockchain transactions), scale (succinct proofs verified quickly on chain), and new privacy-preserving apps (selective disclosure, anonymous credentials).
Understanding the acronym
– Zero‑Knowledge: the verifier learns nothing beyond the validity of the statement.
– Succinct: the proof is short and quick to verify even if the computation was large.
– Non‑Interactive: no back‑and‑forth between prover and verifier (proof can be sent once).
– Argument of Knowledge: a computationally bounded prover cannot make a valid proof without actually possessing the witness/secret (security based on cryptographic assumptions).
Zero‑knowledge proofs — the intuitive idea
Classic analogy: proving you know a password without revealing it — instead of handing over the password, you provide a mathematical proof that you know it. Early theoretical work on zero‑knowledge proofs dates to the 1980s (Goldwasser, Micali, Rackoff). ZK‑SNARKs are concrete, practical realizations designed to be succinct and non‑interactive.
How a zk‑SNARK works (high level)
1. Express the statement as a computation/circuit: the prover defines a function f(x, w) → y where x is public input, w is secret witness, and y is the public output/claim.
2. Commit to the computation: the prover and verifier use a proof system and public parameters (sometimes requiring a trusted setup).
3. Prover computes a witness w and generates a short proof π that “I know w such that f(x, w)=y.”
4. Verifier checks π (quickly) and accepts if valid. The verifier learns nothing about w beyond its existence.
Fast facts
– Zcash used zk‑SNARKs to enable shielded transactions (private amounts/addresses).
– Many zk‑SNARK constructions (e.g., Groth16) require a “trusted setup” ceremony to generate public parameters. If the setup’s secret (“toxic waste”) is retained by an attacker, they could forge proofs.
– Newer constructions (PLONK, Sonic, Marlin, Halo/Halo2) reduce or eliminate trusted setup needs or enable universal setups and recursion for scalable proofs.
– zk‑STARKs (Scalable Transparent ARgument of Knowledge) avoid trusted setup and are post‑quantum secure, but usually result in larger proofs and heavier prover computation.
A simple example (intuitive)
Safebox analogy: A safe deposit box at a bank contains a signed note. You want to prove to a friend that you know the combination and the note’s contents without opening the box. Using a zero‑knowledge proof you demonstrate you can access the note and know its contents without revealing them — the friend gets assurance without seeing the secret.
ZK‑SNARK example on blockchains: Zcash
Zcash uses zk‑SNARKs to allow shielded transactions where sender, recipient, and amount can remain private while the network still enforces no double‑spend and balance correctness. The proof shows that the spender knows the secret key and that the transaction preserves protocol rules, but does not reveal the keys or amounts.
What is a ZK‑SNARK circuit?
– Circuits: A statement is compiled to an arithmetic circuit (or constraint system) that formalizes the computation. Common forms:
• R1CS (Rank‑1 Constraint System): popular intermediate representation for zk systems.
• Arithmetic circuits: gates performing addition/multiplication over a finite field.
– Components:
• Public inputs: values revealed to the verifier (e.g., root hash, public key, output).
• Private witness: secret values you prove knowledge of (e.g., secret key, preimage).
• Constraints/gates: equations that must hold for the witness to be valid.
– The prover supplies the witness; the prover’s proof convinces the verifier the constraints are satisfied without exposing the witness.
Practical steps — building and deploying a zk‑SNARK (developer workflow)
Below is a practical, typical flow using the popular circom + snarkjs toolchain (Groth16). There are alternative toolchains and proving systems (PLONK, Halo2, Bellman/Arkworks, etc.) — those are discussed after.
Prerequisites
– Familiarity with Node.js, basic command line, and smart contract deployment (if you want on‑chain verification).
– Install tools: circom (circom compiler), snarkjs (proof/playground), plus libraries for other proving systems as needed.
High‑level steps
1. Design the computation and test vectors
• Decide what you want to prove (e.g., “I know the preimage of this hash”).
• Write simple inputs and expected outputs for testing.
2. Write the circuit
• Use a DSL such as circom to describe the arithmetic circuit and constraints.
• Mark which values are public inputs vs. private witnesses.
3. Compile the circuit
• Compile the circuit to R1CS, WASM (for witness generation), and symbol files:
• circom myCircuit.circom –r1cs –wasm –sym
• Output: myCircuit.r1cs, myCircuit_js/ (WASM), myCircuit.sym
4. Trusted setup (Groth16 example)
• If using Groth16, perform a multi‑party ceremony (powers of tau) to create a universal parameter and then a circuit‑specific key:
• snarkjs powersoftau new bn128 12 pot12_0000.ptau
• snarkjs powersoftau contribute pot12_0000.ptau pot12_0001.ptau –name=”First contrib”
• snarkjs powersoftau prepare phase2 pot12_0001.ptau pot12_final.ptau
• snarkjs groth16 setup myCircuit.r1cs pot12_final.ptau circuit_0000.zkey
• snarkjs zkey contribute circuit_0000.zkey circuit_final.zkey –name=”key contribute”
• snarkjs zkey export verificationkey circuit_final.zkey verification_key.json
• Notes:
• The “contribute” steps are ceremony participants adding randomness; best practice is many independent contributors to reduce chance of a single malicious actor retaining toxic waste.
• PLONK/other systems support universal or transparent setups, simplifying this step.
5. Generate the witness
• Create an input.json with public and private inputs.
• Use the compiled WASM to generate witness.wtns:
• node generate_witness.js myCircuit_js/myCircuit.wasm input.json witness.wtns
6. Create the proof
• For Groth16:
• snarkjs groth16 prove circuit_final.zkey witness.wtns proof.json public.json
7. Verify the proof
• Off‑chain verification:
• snarkjs groth16 verify verification_key.json public.json proof.json
• On‑chain verification:
• Export solidity verifier: snarkjs zkey export solidityverifier circuit_final.zkey Verifier.sol
• Deploy the Verifier.sol contract to Ethereum (or compatible chain).
• Call verifyProof(proof, publicInputs) from your application or smart contract.
8. Integration and optimization
• Minimize public inputs to keep on‑chain calldata small.
• Optimize circuits (reduce multiplications/constraints).
• Use batching/aggregation or recursive SNARKs for advanced scaling.
Alternatives and toolchains
– Proving systems:
• Groth16: very small proof sizes and fast verification; requires per‑circuit trusted setup.
• PLONK/Sonic/Marlin: universal/aggregate setups (less frequent trusted setup), flexible.
• Halo/Halo2: no trusted setup, recursion-friendly (used to remove trusted setup in Zcash via Halo2).
• zk‑STARKs: transparent (no trusted setup), post‑quantum secure, generally larger proofs, heavier prover workloads.
– Toolchains/libraries:
• circom + snarkjs: popular for learning and many zk projects.
• Bellman, arkworks (Rust): high‑performance libraries.
• Halo2 (Rust): recursion and no trusted setup, used in Zcash evolution.
• Zokrates: another higher‑level toolbox for building proofs.
– On‑chain verifier generation:
• snarkjs can export Solidity verifiers for Groth16; other toolchains produce verifier contracts or deployable verifier code for different chains.
Security considerations and criticisms
– Trusted setup risk: If the setup secret is retained, attacker could forge proofs (create tokens, spend without authorization). Mitigation: multi‑party ceremonies, universal/transparent setups (PLONK/Halo2/STARK).
– Complexity and bugs: circuits and implementations are complex — require rigorous audits, testing, and formal verification where possible.
– Selective centralization risks: coin designs sometimes allocate founder rewards or have control features that undermine guarantees (e.g., criticisms of early Zcash “founder’s tax”).
– Regulatory concerns: strong privacy attracts scrutiny; mixing privacy with illicit use is a policy consideration.
– Performance tradeoffs: choices between succinctness, transparency, prover time, proof size, and post‑quantum resistance.
ZK‑SNARK vs ZK‑STARK — main differences
– Trusted setup:
• SNARK: many constructions (e.g., Groth16) require a trusted setup; there are SNARK variants (PLONK, Halo2) that avoid or reduce this need.
• STARK: transparent — no trusted setup.
– Cryptographic assumptions:
• SNARKs typically rely on elliptic curve pairings and number theoretic assumptions.
• STARKs rely on collision‑resistant hash functions and algebraic techniques; STARKs are considered more post‑quantum resistant.
– Proof size and verification:
• SNARKs (Groth16) produce very small proofs (e.g., ~192 bytes) and are very cheap to verify.
• STARK proofs are larger (kilobytes to megabytes depends on statement and optimizations) but verification remains relatively fast and can be optimized.
– Prover cost:
• SNARK provers can be faster for some constructions.
• STARK provers are often heavier computationally, though hardware and algorithmic improvements are changing that.
– Transparency and auditability:
• STARKs advantage in transparency because there is no setup to compromise.
Best practices for practitioners
– Prefer transparent constructions or multi‑party ceremonies for any system requiring a setup.
– Keep private witnesses confidential; never include secrets in logs or public testnets.
– Minimize public inputs to reduce on‑chain gas/costs.
– Use audited libraries and follow community‑maintained frameworks (e.g., circom, snarkjs, arkworks, Halo2).
– Test thoroughly with unit tests, property tests, and fuzzing. Get independent code and cryptographic audits before production deployment.
– Consider the application’s needs: if post‑quantum resistance or full transparency is needed, evaluate STARKs or transparent SNARK variants.
Use cases beyond private payments
– zk‑rollups: aggregate many transactions off‑chain and publish succinct proofs to the layer‑1 chain (scaling).
– Identity and credentials: prove age or membership without revealing identity attributes.
– Voting and auctions: verifiable correctness with voter privacy.
– Confidential supply chains and computations: attest correct computation over sensitive data.
The bottom line
ZK‑SNARKs provide powerful, practical zero‑knowledge proofs that enable privacy and scalability on blockchains and beyond. They trade off trusted setup and cryptographic assumptions against succinctness and verification efficiency. Recent advances (PLONK, Halo/Halo2, STARKs) reduce trusted setup concerns and expand the toolset. For developers, well‑designed circuits, transparent parameter ceremonies, audited libraries, and careful integration are essential to build secure, practical zk applications.
References and suggested reading
– Investopedia. “What Is ZK‑SNARK?” (source provided):
– Zcash Foundation. “What Are ZK‑Snarks?” (Zcash docs/blog).
– JTRiley. “Constructing ZK SNARK Circuits” (tutorials and examples).
– Goldwasser, S., Micali, S., Rackoff, C. (1985). “The knowledge complexity of interactive proof systems.” (Foundational paper on zero‑knowledge.)
– Ben‑Sasson, E., et al. (2014–2018). Papers on SNARK/STARK constructions (e.g., “Scalable, Transparent, and Post‑Quantum Secure Computational Integrity” for STARKs).
– circom + snarkjs documentation and tutorials (toolchain examples).
– Zcash blog posts on Halo and Halo2 (implementation removing trusted setup).
Editor’s note: The following topics are reserved for upcoming updates and will be expanded with detailed examples and datasets.