ZK-SNARKs Explained:
Succinct Non-Interactive Proofs

Imagine being able to prove to anyone that you ran a computation correctly — a billion multiplications, a trillion hash evaluations, an entire machine-learning inference — and the verifier only needs to look at a few hundred bytes and spend a few milliseconds checking. No need to re-execute the computation. No need to see the input data. No need for any back-and-forth conversation. That is the promise of ZK-SNARKs, and after a decade of research, it is no longer theoretical. It is running in production systems that handle billions of dollars in value.

ZK-SNARKs are, in the most literal sense, the closest thing cryptography has to magic. They enable a prover to convince a verifier that a statement is true, while revealing absolutely nothing beyond the truth of the statement itself. The proof is tiny. The verification is fast. And the prover demonstrably knows the underlying secret (the "witness") rather than merely asserting its existence.

This article is a deep technical walkthrough. We will start by unpacking every letter in the acronym, then trace the full construction pipeline from a high-level computation all the way down to a polynomial commitment scheme. We will examine trusted setup ceremonies and their "toxic waste" problem, compare every major SNARK system in production, write real circuits in Circom and Noir, benchmark proof sizes and verification times, analyze the security model (including the critical quantum vulnerability), survey real-world deployments, and look at what comes next.

If you are new to zero-knowledge proofs in general, we recommend starting there first. This post assumes familiarity with the basic concept and dives into the machinery.

Unpacking the Acronym: zk-SNARK

The name "zk-SNARK" is an acronym within an acronym. It stands for Zero-Knowledge Succinct Non-interactive ARgument of Knowledge. Each word carries precise cryptographic meaning, and understanding them individually is the key to understanding the system as a whole.

Zero-Knowledge

A proof system is zero-knowledge if the verifier learns nothing beyond the single bit of information: "the statement is true." Formally, there must exist a simulator that can produce transcripts indistinguishable from real proof transcripts without ever seeing the witness. This property is what makes SNARKs useful for privacy: you can prove you are over 18 without revealing your birth date, prove you have sufficient funds without revealing your balance, or prove a biometric match without exposing the template.

Succinct

This is the property that separates SNARKs from earlier interactive proof systems. A SNARK proof is sublinear in the size of the computation being proved — typically constant-size or logarithmic. Groth16, the most widely deployed SNARK, produces proofs of exactly 128 bytes (three elliptic curve group elements) regardless of whether the underlying computation involves ten constraints or ten billion. This is what makes verification practical: the verifier does work proportional to the proof size, not the computation size.

Non-Interactive

Classical zero-knowledge proofs (like the original Goldwasser-Micali-Rackoff protocol) require multiple rounds of communication between prover and verifier. The prover sends a commitment, the verifier sends a random challenge, the prover responds, and so on. This works fine in real-time settings but is impractical for blockchains, where proofs must be verifiable by anyone at any time without the prover being online.

SNARKs achieve non-interactivity through the Fiat-Shamir heuristic: instead of receiving challenges from a verifier, the prover generates them by hashing the transcript so far. In the random oracle model (where the hash function is assumed to behave like a truly random function), this transformation preserves soundness. The result is a single message — the proof — that anyone can verify independently.

ARgument (not Proof)

The word "argument" is deliberate and distinct from "proof" in a cryptographic sense. A proof provides information-theoretic security: even an adversary with unlimited computational power cannot produce a false proof. An argument provides only computational security: soundness holds against adversaries bounded by polynomial time. If someone could break the discrete logarithm problem or the knowledge-of-exponent assumption, they could forge SNARK proofs.

In practice, this distinction matters less than it sounds. The computational assumptions underlying SNARKs (discrete log on elliptic curves, pairing-based assumptions) are well-studied and considered extremely hard for classical computers. The real concern is quantum computers, which we will address in the security section.

of Knowledge

This is the deepest property and the one most often glossed over. Ordinary soundness says "a cheating prover cannot convince the verifier that a false statement is true." Knowledge soundness says something stronger: "if the prover can produce a valid proof, then there exists an extractor that can extract the witness from the prover's internal state."

Why does this matter? Consider a prover who claims "I know a pre-image of this hash." Simple soundness would only guarantee that such a pre-image exists. Knowledge soundness guarantees that the prover actually has it. This is the property that makes SNARKs useful for authentication, identity, and credential proofs: the prover cannot bluff.

The SNARK Construction Pipeline

Building a SNARK involves a series of transformations that progressively reduce a high-level computation into algebraic objects that can be checked efficiently with elliptic curve pairings. Each step is fascinating in its own right. Let us trace the full pipeline.

Step 1: Computation to Arithmetic Circuit

Every SNARK begins with a computation that we want to prove. This could be "I know two factors of N" or "this Merkle proof is valid" or "this neural network inference produced output Y on input X." The first step is to express this computation as an arithmetic circuit over a finite field F_p.

An arithmetic circuit is a directed acyclic graph (DAG) where each node is either an addition gate or a multiplication gate, and the edges carry field elements. There are no loops, no conditionals (they must be flattened), and no floating-point arithmetic — everything is modular arithmetic over a large prime field.

Let us work through a concrete example. Suppose we want to prove: "I know a and b such that a * b + a = 15."

// Original statement: a * b + a = 15
// Step 1: Introduce intermediate variable
let t1 = a * b     // multiplication gate
let out = t1 + a   // addition gate
// Constraint: out == 15

// Variables (witness): [1, a, b, t1, out]
// With a=3, b=4: [1, 3, 4, 12, 15]

The "flattening" process breaks every complex expression into primitive operations. Each multiplication consumes exactly two inputs and produces one output. Additions can be folded into the constraints for free (we will see why in R1CS). This flattened representation is the arithmetic circuit.

Step 2: Arithmetic Circuit to R1CS

The next step converts the circuit into a Rank-1 Constraint System (R1CS). An R1CS is a system of equations, each of the form:

⟨a_i, w⟩ × ⟨b_i, w⟩ = ⟨c_i, w⟩

Where w is the witness vector (all the variables in our computation), and ai, bi, ci are coefficient vectors. Each constraint captures one multiplication gate. The angle brackets denote inner products.

For our example (a * b + a = 15), the witness vector is w = [1, a, b, t1, out]. We need two constraints:

// Constraint 1: a * b = t1
a1 = [0, 1, 0, 0, 0]   // selects 'a'
b1 = [0, 0, 1, 0, 0]   // selects 'b'
c1 = [0, 0, 0, 1, 0]   // selects 't1'

// Constraint 2: (t1 + a) * 1 = out
a2 = [0, 1, 0, 1, 0]   // selects 't1 + a'
b2 = [1, 0, 0, 0, 0]   // selects '1' (constant)
c2 = [0, 0, 0, 0, 1]   // selects 'out'

// Verify with w = [1, 3, 4, 12, 15]:
// Constraint 1: (0+3+0+0+0) * (0+0+4+0+0) = (0+0+0+12+0) ✓
// Constraint 2: (0+3+0+12+0) * (1+0+0+0+0) = (0+0+0+0+15) ✓

Notice that additions are "free" — they are absorbed into the coefficient vectors (see how a2 adds t1 and a together by having both positions set to 1). Only multiplications generate constraints. This is why the number of constraints in an R1CS equals the number of multiplication gates in the circuit, and why circuit designers obsess over minimizing multiplications.

Step 3: R1CS to QAP

The Quadratic Arithmetic Program (QAP) transformation is the insight that made SNARKs possible. It converts the discrete constraint system into a single polynomial equation that can be checked with a single evaluation.

The key idea: we take each column of the R1CS matrices (A, B, C) and interpolate a polynomial through those values using Lagrange interpolation. If we have m constraints, we evaluate at points r1, r2, ..., rm.

For each variable j, we get three polynomials: Aj(x), Bj(x), Cj(x). Then we define:

This is the magic: an entire system of constraints collapses into one polynomial divisibility check. And the Schwartz-Zippel lemma tells us that checking this equation at a single random point is overwhelmingly likely to catch any cheating. If the polynomial identity does not hold, it will fail at almost every point in the field.

Step 4: QAP to Polynomial Commitments to Proof

The final step is the most cryptographically sophisticated. We need to evaluate these polynomials at a secret random point s (chosen during the trusted setup) without the prover knowing s. This is accomplished through elliptic curve pairings.

During the trusted setup, the ceremony generates "encrypted" powers of s: the values [s]1, [s2]1, ..., [sd]1 where [x]1 denotes the elliptic curve point x · G (G being the generator). The prover can compute [A(s)]1, [B(s)]2, [C(s)]1, and [H(s)]1 using these encrypted values, without ever learning s.

The verifier then checks the pairing equation:

e([A]₁, [B]₂) = e([C]₁, [1]₂) · e([H]₁, [T(s)]₂)

If this pairing equation holds, the verifier is convinced that the prover knows a valid witness. The proof consists of just three group elements: [A]1, [B]2, and [C]1. That is 128 bytes in Groth16 over BN254.

Trusted Setup Ceremonies

The trusted setup is the most controversial aspect of SNARKs. It is also the most misunderstood. Let us be precise about what it is, why it is necessary, and how the cryptographic community has mitigated its risks.

What is "Toxic Waste"?

During the trusted setup, a random value s (and often additional randomness α, β, γ, δ) is used to compute the structured reference string (SRS). The SRS contains elliptic curve points encoding powers of s, but s itself must be destroyed. If anyone retains s, they can forge proofs for false statements. This secret randomness is called toxic waste.

Powers of Tau Ceremony

The solution to the toxic waste problem is a multi-party computation (MPC) ceremony. The idea is beautifully simple: instead of one party generating s, have N parties each contribute randomness. Party 1 picks s1, party 2 picks s2, and so on. The final secret is effectively s = s1 · s2 · ... · sN. For the toxic waste to be compromised, every single participant must collude or be compromised.

The "Powers of Tau" ceremony (named after the Greek letter τ often used for the secret) is the most common format. Each participant:

1. Downloads the current state of the ceremony (the SRS computed so far)
2. Multiplies in their own secret randomness
3. Destroys their randomness (ideally on air-gapped hardware)
4. Publishes the updated SRS along with a proof of correct contribution

As long as one honest participant destroys their randomness, the overall setup is secure. This is the "1-of-N trust assumption" — dramatically better than trusting a single entity.

Circuit-Specific vs. Universal Setup

There are two categories of trusted setup, and the distinction is critical for practical deployment:

Notable Ceremonies

Zcash Sprout (2016): The first large-scale trusted setup. Six participants in a carefully orchestrated ceremony. Each participant used a different operating system and hardware configuration. One participant famously incinerated their computer afterward.

Zcash Powers of Tau (2018): An open ceremony with 87 participants from around the world. Anyone could participate. The entropy sources ranged from radioactive decay measurements to readings from lava lamps.

Hermez / Polygon zkEVM (2022): Over 100 participants in a ceremony for their ZK-rollup circuits. Automated tooling made participation accessible to non-experts.

Perpetual Powers of Tau: An ongoing ceremony maintained by the Ethereum Foundation's PSE (Privacy and Scaling Explorations) team. Hundreds of contributions over multiple years, with new contributions still accepted.

Major SNARK Systems Compared

The SNARK landscape has evolved rapidly since the first practical construction. Each system makes different trade-offs among proof size, verification time, prover performance, setup requirements, and security assumptions. Here is a detailed comparison of the systems that matter today.

Groth16 (2016)

Groth16 remains the gold standard for applications where proof size and verification speed are paramount. It produces the smallest proofs of any SNARK system: exactly three group elements on BN254, totaling 128 bytes. Verification requires three pairing operations, which take approximately 3-5 milliseconds on modern hardware.

The downsides are well-known: a circuit-specific trusted setup (new ceremony for every circuit change) and reliance on pairing-based assumptions (not post-quantum secure). Groth16 is used by Zcash Sapling, Tornado Cash, and numerous DeFi protocols.

PLONK (2019)

PLONK (Permutations over Lagrange-bases for Oecumenical Non-interactive arguments of Knowledge) introduced the universal and updateable structured reference string. One ceremony supports any circuit up to the SRS size. PLONK's key innovations include:

• Permutation arguments for wire routing (copy constraints)
• Custom gates that allow specialized constraints beyond simple R1CS
• Lookup arguments (extended in PlonkUp/Plookup) for efficient range checks and table lookups

Proofs are larger than Groth16 (~400-600 bytes) and verification is slower (~6-8 ms), but the universal setup makes PLONK far more practical for evolving applications. It powers Aztec, zkSync, Polygon zkEVM, and Scroll.

Marlin (2020)

Marlin achieves a universal setup through algebraic holography — encoding the circuit structure as a polynomial that the verifier can query. It operates on top of polynomial commitment schemes (typically KZG), and its proof size and verification time fall between Groth16 and PLONK. Marlin is used by Aleo's snarkVM for private smart contract execution.

Halo 2 (2020-2021)

Halo 2, developed by the Electric Coin Company (the team behind Zcash), is a landmark achievement: it eliminates the trusted setup entirely by using the Inner Product Argument (IPA) commitment scheme instead of KZG pairings. This comes at the cost of logarithmic proof size and verification time, but the removal of toxic waste is a significant security improvement.

Halo 2 also supports recursive proof composition — proofs that verify other proofs — enabling incremental verifiable computation. Zcash Orchard uses Halo 2, and it is the basis for Scroll's zkEVM. Read more in our recursive ZK proofs deep dive.

Note the final row: STARKs are not technically SNARKs (the "S" in STARK stands for "Scalable," not "Succinct"), but they are the primary alternative and the only production ZK system that is post-quantum secure. We will compare them in detail later.

Writing SNARK Circuits

Understanding SNARK theory is one thing. Writing actual circuits is another. Circuit development is a specialized skill that requires thinking in constraints rather than sequential instructions. Let us walk through real examples in the two most popular circuit languages.

Circom + snarkjs: Proving Knowledge of Factors

Circom is the most widely used circuit language in the Ethereum ecosystem. A Circom circuit defines templates with signals (wires) and constraints. Here is a circuit that proves knowledge of two factors of a public number:

pragma circom 2.1.6;

// Prove: I know a, b such that a * b = c
// where c is public and a, b are private
template Factor() {
    signal input a;       // private: first factor
    signal input b;       // private: second factor
    signal output c;      // public: the product

    // The constraint: a * b must equal c
    c <== a * b;

    // Ensure factors are non-trivial (> 1)
    signal a_minus_1;
    a_minus_1 <== a - 1;
    signal a_check;
    a_check <== a_minus_1 * a;  // non-zero if a > 1

    signal b_minus_1;
    b_minus_1 <== b - 1;
    signal b_check;
    b_check <== b_minus_1 * b;  // non-zero if b > 1
}

component main {public []} = Factor();

Compiling and generating a proof with snarkjs:

# Compile the circuit
circom factor.circom --r1cs --wasm --sym

# Generate witness (a=7, b=13, so c=91)
echo '{"a": "7", "b": "13"}' > input.json
node factor_js/generate_witness.js factor_js/factor.wasm \
     input.json witness.wtns

# Groth16 setup (in production, use MPC ceremony)
snarkjs groth16 setup factor.r1cs pot12_final.ptau \
        factor_0000.zkey

# Generate proof
snarkjs groth16 prove factor_0000.zkey witness.wtns \
        proof.json public.json

# Verify
snarkjs groth16 verify verification_key.json \
        public.json proof.json
# Output: [INFO] snarkJS: OK!

Noir: Proving Knowledge of a Hash Pre-image

Noir is a newer circuit language from Aztec that offers a more familiar Rust-like syntax. Here is a circuit that proves knowledge of a SHA-256 pre-image:

use dep::std::hash::sha256;

// Prove: I know 'secret' such that sha256(secret) = hash
fn main(secret: [u8; 32], hash: pub [u8; 32]) {
    let computed = sha256(secret);
    assert(computed == hash);
}

// The prover provides 'secret' (private witness)
// The verifier only sees 'hash' (public input)
// The proof convinces the verifier that the prover
// knows a pre-image, without revealing it

Constraints and Witnesses

Every circuit has two categories of values:

• Public inputs/outputs: Known to both prover and verifier. These are embedded in the proof and checked during verification.
• Private inputs (witness): Known only to the prover. The proof guarantees their existence and correctness without revealing them.

The constraint count is the primary metric of circuit complexity. More constraints mean longer proving time and more memory. Some operations are cheap in constraints (addition, constant multiplication) while others are expensive (comparisons, hash functions, range checks). A single SHA-256 evaluation costs approximately 25,000 R1CS constraints. An entire Ethereum transaction verification costs millions.

Common Circuit Patterns

Performance Characteristics

SNARK performance is fundamentally asymmetric: proving is expensive (seconds to minutes), while verification is cheap (milliseconds). This asymmetry is by design and is exactly what makes SNARKs useful — the heavy computation is done once by the prover, and the lightweight check is done by every verifier.

Proof Size

Proof size is where SNARKs truly shine compared to other proof systems. Groth16 proofs are constant-size regardless of the computation being proved:

Verification Time

Verification time is the other critical metric, especially for on-chain applications where every millisecond costs gas:

Proving Time and Memory

Proving is the expensive side of the asymmetry. The prover must perform multi-scalar multiplications (MSMs) over elliptic curves, which are computationally intensive. Here are representative benchmarks for common circuit sizes:

These numbers explain why proving is often done on beefy cloud machines (64+ cores, 256+ GB RAM) while verification happens on constrained devices and smart contracts. GPU acceleration (using CUDA or Metal for MSMs) can cut proving time by 5-10x, and projects like Ingonyama's ICICLE library are pushing this further.

Security Analysis

SNARK security rests on a tower of cryptographic assumptions. Understanding these assumptions — and their limitations — is essential for evaluating whether SNARKs are appropriate for a given application.

Cryptographic Assumptions

Discrete Logarithm Problem (DLP): Given g and gx on an elliptic curve, finding x is computationally infeasible. This is the foundation of all pairing-based SNARKs. On BN254 (128-bit security) and BLS12-381 (128-bit security), the best known classical attacks require approximately 2¹²⁸ operations.

Knowledge-of-Exponent Assumption (KEA): If the prover is given (g, ga) and produces (c, ca), then the prover must "know" the exponent relating c to g. This non-falsifiable assumption is required by Groth16 and is stronger than standard DLP. It is the assumption that gives us the "K" (of Knowledge) in SNARK.

Bilinear Diffie-Hellman Assumptions: Various assumptions about the hardness of computing certain values given pairings. These underlie the verifier's ability to check polynomial evaluations without seeing the polynomials directly.

The Quantum Vulnerability

This is where we must be direct: pairing-based SNARKs are not post-quantum secure. Shor's algorithm, running on a sufficiently powerful quantum computer, can solve the discrete logarithm problem in polynomial time. This would break every SNARK system that relies on elliptic curve pairings — Groth16, PLONK with KZG commitments, Marlin, and any system using BN254 or BLS12-381.

The quantum vulnerability of SNARKs is precisely why STARKs exist. STARKs replace elliptic curve pairings with hash functions (typically SHA-256 or BLAKE3), which are believed to be quantum-resistant. The trade-off is larger proofs, but for applications requiring long-term soundness, this is the correct choice.

At H33, our production ZKP pipeline uses STARK-based proofs with SHA3-256 hashing, achieving 0.067 microsecond verification with full post-quantum security. We made this architectural decision specifically because authentication proofs may need to remain valid for years or decades, well into the quantum computing era.

Soundness Guarantees

Even setting aside quantum concerns, it is worth understanding the level of soundness SNARKs provide:

• Statistical soundness error: Negligible in the security parameter (e.g., 2^-128 for BN254). The probability of a random cheating prover succeeding is astronomically small.
• Computational soundness: Depends on the hardness assumptions holding. If DLP is broken (classically or quantumly), soundness fails.
• Trusted setup integrity: If the toxic waste is compromised, soundness fails for that specific SRS. This is an additional trust assumption beyond pure cryptographic hardness.

Real-World Deployments

SNARKs have moved far beyond academic papers. Billions of dollars in value are secured by SNARK proofs today. Here are the most significant deployments.

Zcash: The Pioneer

Zcash was the first production deployment of SNARKs, launching in October 2016 with Groth16 proofs over BN254. Zcash has gone through three major proof system upgrades:

• Sprout (2016): Original launch. BCTV14 proving system. Proofs took ~40 seconds to generate and ~1.5 KB in size. The trusted setup involved just six participants.
• Sapling (2018): Upgraded to Groth16. Proving time dropped to ~7 seconds, proof size to 192 bytes. The Powers of Tau ceremony had 87 participants.
• Orchard (2022): Migrated to Halo 2, eliminating the trusted setup entirely. Uses the Pallas/Vesta curve cycle for recursive proof composition.

Zcash has proven that privacy-preserving transactions are viable at scale, though adoption of shielded transactions remains a fraction of total Zcash usage.

ZK-Rollups: Scaling Ethereum

The largest deployment of SNARKs by transaction volume is in ZK-rollups — Layer 2 scaling solutions that execute transactions off-chain and post a validity proof to Ethereum. Major projects include:

Identity and Privacy

Worldcoin / World ID: Uses Groth16 proofs to verify that a user is a unique human (via iris scan) without revealing their identity. The Semaphore protocol enables anonymous group membership proofs.

Semaphore: A protocol for anonymous signaling. Users prove membership in a group (via a Merkle proof) and emit a signal, without revealing which group member they are. Uses Groth16 with Poseidon hashing for efficient Merkle tree operations.

Zupass / Zukit: Used at Zuzalu and subsequent events for zero-knowledge event tickets. Attendees prove they have a valid ticket without revealing their identity to the venue.

Morgan Stanley / JPMorgan (pilot programs): Several major financial institutions are piloting SNARK-based KYC verification, where customers prove they have passed KYC with one institution without re-sharing their documents with another.

SNARKs vs STARKs: When to Choose Which

The SNARK vs STARK debate is one of the most important architectural decisions in zero-knowledge system design. Both are zero-knowledge proof systems, but they make fundamentally different trade-offs. Here is a comprehensive comparison.

Choose SNARKs When:

• Proof size is critical — On-chain verification where every byte costs gas (Groth16's 128 bytes is unbeatable)
• Verification must be minimal — Constrained environments, embedded devices, high-throughput verification
• Recursive composition is needed — SNARK-based curve cycles (Pasta, BN254/BLS12) enable efficient proof-of-proof recursion
• Existing ecosystem — Most ZK tooling (Circom, Noir, Arkworks) targets SNARK backends

Choose STARKs When:

• Post-quantum security is required — Any application where proofs must remain sound for 10+ years
• Transparent setup is mandatory — Regulatory environments, government applications, or any context where trusted setup ceremonies are unacceptable
• Prover scalability matters — STARKs scale quasi-linearly with computation size, while SNARK provers scale super-linearly due to MSM
• Large computations — For circuits with billions of constraints, STARK provers are dramatically faster

In practice, many production systems combine both: StarkNet uses STARKs for the primary proof and then wraps the STARK proof in a Groth16 SNARK for on-chain verification (a technique called "STARK-inside-SNARK" or "proof wrapping"). This gets the best of both worlds: transparent setup and post-quantum prover, with minimal on-chain verification cost.

Future Directions

The SNARK landscape is evolving at a pace that rivals deep learning research. Several active research directions promise to transform what is possible.

Folding Schemes: Nova, SuperNova, and HyperNova

Folding schemes represent a paradigm shift in how we think about incremental verifiable computation (IVC). Instead of generating a full SNARK proof at each step and recursively verifying it, folding schemes "fold" two computation instances into one, deferring the expensive SNARK proof to the very end.

Nova (2022), introduced by Abhiram Kothapalli, Srinath Setty, and Ioanna Tzialla, achieves IVC with zero overhead per step beyond a single group scalar multiplication. The prover does minimal work at each step and only generates one final SNARK proof. This makes it dramatically faster than recursive SNARK composition for long-running computations.

SuperNova extends Nova to support non-uniform computations (different circuits at different steps), which is essential for virtual machine execution. HyperNova generalizes further using CCS (Customizable Constraint Systems) to fold more expressive constraint types.

For deeper coverage, see our article on recursive ZK proofs.

Lookup Arguments and Lookup Singularity

Lookup arguments (Plookup, LogUp, Lasso) allow circuit designers to replace expensive arithmetic computations with table lookups. Instead of computing SHA-256 with 25,000 constraints, you precompute a table and prove that each intermediate value appears in the table. Recent advances (particularly Lasso/Jolt from a]16z Research) are pushing toward the "lookup singularity" — the idea that every computation can be expressed purely as lookups, eliminating the need for custom circuits entirely.

Post-Quantum SNARKs

Active research is exploring SNARKs that achieve succinctness without relying on pairings or elliptic curves:

• Lattice-based SNARKs: Replace elliptic curves with lattice-based assumptions (LWE, SIS). Still largely theoretical, with proof sizes in the kilobyte range.
• Hash-based polynomial commitments: Schemes like FRI (used in STARKs) and DARK (using groups of unknown order) avoid pairings entirely. The distinction between "SNARK" and "STARK" is blurring as these techniques converge.
• Code-based SNARKs: Using error-correcting codes as the underlying algebraic structure. Promising early results from Brakedown and Orion.

Hardware Acceleration

The proving bottleneck has spawned a hardware acceleration race:

• GPU proving: ICICLE (Ingonyama), CUDA-accelerated MSM and NTT. 5-10x speedup over CPU.
• FPGA proving: Custom pipelines for modular arithmetic and NTT. Projects from Supranational and Cysic.
• ASIC proving: Purpose-built silicon for ZK proving. Fabric Cryptography and Accseal are building dedicated ZK chips.

These developments will reduce proving times from minutes to seconds and from seconds to milliseconds, making ZK practical for latency-sensitive applications.

Client-Side Proving

The ultimate vision is proving on the user's device — phone, browser, or embedded system. This requires:

• WASM-compatible provers (snarkjs already works in the browser)
• Sub-second proving for common circuits (~10K-100K constraints)
• Memory-efficient proving (mobile devices have 4-8 GB RAM)

Projects like Halo 2 in WASM, Circom WASM witnesses, and Noir's Barretenberg WASM backend are making this real. The day is approaching when every authentication event, every credential check, every privacy-preserving computation happens on the user's own device with zero round-trips to a server.

Conclusion

ZK-SNARKs are one of the most consequential inventions in cryptography since public-key encryption. They transform the fundamental relationship between computation and verification: any program can be proved in constant size and verified in constant time, while revealing nothing about the inputs. The construction pipeline — from arithmetic circuits to R1CS to QAP to polynomial commitments — is an intellectual triumph that converts algebraic structure into practical privacy.

But SNARKs are not a silver bullet. The trusted setup requirement, while mitigable through MPC ceremonies and universal SRS constructions, remains an operational burden and a philosophical concern. More critically, every pairing-based SNARK is vulnerable to quantum computers. Shor's algorithm will eventually break the discrete logarithm problem on elliptic curves, and when it does, the soundness of every Groth16 and PLONK proof generated with those curves will be retroactively destroyed.

This is not a reason to abandon SNARKs — they remain the best tool for many applications today. But it is a reason to plan for the transition. Systems that require long-term soundness should consider STARKs or hybrid approaches. Infrastructure should be built with crypto-agility, ready to swap proof backends when post-quantum SNARKs mature.

At H33, we have already made this transition. Our authentication pipeline is fully post-quantum: BFV fully homomorphic encryption for biometric matching (~50 microseconds per authentication), STARK-based zero-knowledge proofs for verification (0.067 microseconds), and Dilithium signatures for attestation. The entire stack — 1.2 million authentications per second on production hardware — has zero dependence on pre-quantum assumptions.

Whether you are building with SNARKs today or planning the migration to post-quantum proofs, the core principle is the same: prove everything, reveal nothing. The mathematics are ready. The tooling is maturing. The future of authentication, identity, and privacy is zero-knowledge.