ZK-SNARK

The verifier learns nothing about the secret witness beyond the single fact that the statement is true. The proof reveals zero information about the private input.

• Perfect Zero-Knowledge: The verifier's view can be simulated without access to the witness, meaning no information is leaked.
• Computational Zero-Knowledge: A more practical variant where leakage is computationally infeasible to extract.

Example: Proving you know the preimage of a hash without revealing the preimage itself. The verifier only learns that you possess the secret, not the secret's value.

The proof size is constant and small (often a few hundred bytes), regardless of the complexity or size of the computation being proven. Verification time is also constant or logarithmic relative to the computation.

• Proof Size: Typically 128–288 bytes for pairing-based SNARKs like Groth16.
• Verification Cost: Often measured in milliseconds, even for computations that took minutes to prove.

Example: A ZK-Rollup compresses thousands of transactions into a single 200-byte validity proof posted to Ethereum, achieving massive scalability gains.

The proof is a single, self-contained message from the prover to the verifier. No back-and-forth interaction or challenge-response protocol is required.

• Fiat-Shamir Heuristic: Transforms interactive proofs into non-interactive ones by replacing the verifier's random challenges with the output of a cryptographic hash function.
• Benefit: The prover generates the proof offline, and anyone can verify it at any time without coordinating with the prover.

Example: A single SNARK proof can be broadcast on a blockchain and verified asynchronously by thousands of nodes without any direct communication with the original prover.

The proof is an argument (computationally sound) rather than a proof (unconditionally sound). It demonstrates that the prover actually knows the witness, not just that the statement is true.

• Knowledge Soundness: An extractor algorithm exists that can recover the witness by interacting with a successful prover, proving the prover must possess the secret.
• Computational Soundness: A cheating prover with bounded computational power cannot forge a valid proof for a false statement.

Example: Proving ownership of a private key corresponding to a public key. The proof demonstrates knowledge of the discrete logarithm without revealing it, and a computationally bounded adversary cannot fake this proof.

Many ZK-SNARK constructions require a one-time trusted setup ceremony to generate a Common Reference String (CRS). The security of the system depends on the honest destruction of the toxic waste generated during this phase.

• Toxic Waste: Secret randomness that, if retained, could be used to forge proofs.
• Multi-Party Computation (MPC) Ceremony: A protocol where multiple participants contribute randomness sequentially. Security holds as long as at least one participant destroys their secret.
• Transparent Alternatives: ZK-STARKs and newer SNARKs like Spartan eliminate the trusted setup entirely, relying instead on public randomness from hash functions.

Example: The Zcash cryptocurrency conducted a multi-party ceremony with hundreds of participants to generate its initial parameters, ensuring no single entity could counterfeit shielded transactions.

ZK-SNARKs prove statements expressed as arithmetic circuits over a finite field. Any computation must first be compiled into a system of rank-1 constraints (R1CS) or a similar polynomial representation.

• R1CS: A set of quadratic constraints of the form (A·w) × (B·w) = (C·w), where w is the witness vector.
• Circuit Languages: Domain-specific languages like Circom and Noir compile high-level code into arithmetic circuits.
• Constraint Count: The number of constraints directly impacts proving time. Optimizing circuit design is critical for performance.

Example: A SHA-256 hash verification circuit contains approximately 25,000 constraints. Proving knowledge of a valid preimage requires satisfying all constraints without revealing the preimage.

Zcash was the first major deployment of ZK-SNARKs, using them to enable shielded transactions where the sender, receiver, and amount remain encrypted on a public blockchain. The protocol proves transaction validity—no double-spending, correct input/output balance—without revealing any identifying information. This established the blueprint for on-chain privacy and demonstrated that SNARKs could operate within practical block time constraints.

ZK-rollups like zkSync Era, StarkNet, and Polygon zkEVM batch thousands of off-chain transactions and submit a single validity proof to Ethereum. The L1 contract verifies the SNARK proof in constant time, inheriting Ethereum's security without processing each transaction individually. This architecture reduces gas costs by orders of magnitude while maintaining self-custody and censorship resistance.

ZK-SNARKs enable selective disclosure of identity attributes. A user can prove they are over 18 without revealing their birth date, or prove citizenship without exposing a passport number. Projects like Polygon ID and Worldcoin use SNARKs to generate proofs about biometric or government-issued credentials, allowing verifiers to check claims without accessing raw personal data.

zkML applies SNARKs to prove that a specific ML model produced a given output from a given input. Use cases include:

• Proving an on-chain credit score was computed by a specific model without revealing financial data
• Verifying that a medical diagnosis came from a certified AI without exposing patient records
• Demonstrating model fairness audits without disclosing proprietary weights

Succinct cross-chain bridges use ZK-SNARKs to prove consensus of a source chain to a destination chain without requiring the destination to replay every block. Projects like Succinct Labs and Polymer generate SNARK proofs of validator signatures and state transitions, enabling trust-minimized bridging where a single constant-size proof replaces gigabytes of block headers.