- Published on
Zero-Knowledge Proof Tooling 2026 Deep Dive - Circom, Noir, Aztec, Cairo, StarkNet, Risc Zero, SP1, Plonky3, Halo2
- Authors

- Name
- Youngju Kim
- @fjvbn20031
Prologue — In 2026, ZK Moved From a Theory We Believe in to a Tool We Use
Back in 2020, zero-knowledge proofs (ZKPs) were "theoretically elegant." Writing a single line of a circuit required mathematical intuition and PhD-grade patience. A single proof took minutes to generate.
The 2026 landscape is entirely different.
- zkVMs (zero-knowledge Virtual Machines) are mainstream. Ordinary Rust or Go code is proven directly. Risc Zero, SP1, Jolt, and Plonky3 let any engineer ship zkVM code.
- DSLs like Circom, Noir, and Cairo make circuits feel like "another language." Circom 2.2, Noir 0.40, and Cairo 2.x are now stable toolchains.
- Proof systems — HALO2, PLONK, FRI, STARK, Groth16 — are not academic papers anymore but libraries.
- Rollups — zkSync Era, Linea, Polygon zkEVM, Scroll, Taiko, Mantle — already process billions of dollars on mainnet.
- Privacy, identity, and web2 bridges — Aztec, Aleo, Penumbra, Manta, zkPassport, Anon Aadhaar, Reclaim, Sismo, TLSNotary, zkEmail — are pulling ZK past the wallet.
ZK is no longer mysticism. It is a tool. This article maps the entire toolscape at once.
One-line summary: "What are you proving, who verifies it where, and what does it cost?" These three questions decide 90 percent of your ZK tooling choices.
Chapter 1 · ZK Fundamentals — SNARKs, STARKs, and Everything Between
A ZK system must formally satisfy three properties.
| Property | Meaning |
|---|---|
| Completeness | If the prover knows the truth, the verifier accepts |
| Soundness | If the prover lies, the verifier rejects with overwhelming probability |
| Zero-Knowledge | The verifier learns the fact but not "how" |
Add the practical traits of succinctness (short proofs) and non-interactivity (one-shot, no back-and-forth) and you get the ZK proof system we usually mean.
The two-line core taxonomy:
- SNARK — Succinct Non-interactive ARgument of Knowledge. Short and fast verification. Most are pairing-based.
- STARK — Scalable Transparent ARgument of Knowledge. No trusted setup (transparent), and post-quantum.
Compressed into a table:
| Item | SNARK | STARK |
|---|---|---|
| Setup | Trusted setup required, or universal | Transparent, no setup |
| Proof size | Small (a few hundred bytes) | Large (tens to hundreds of KB) |
| Verifier cost | Very cheap | More expensive |
| Prover cost | Moderate | Generally cheaper |
| Math basis | Pairings, discrete log | Hashes, FRI |
| Post-quantum | Usually no | Yes |
In 2026 it is no longer a one-or-the-other world. Rollups build the proof with STARKs and compress it with SNARKs via recursion — hybrid stacks are the norm.
Chapter 2 · Polynomial IOPs and Commitment Schemes — The Shared Backbone
Almost every modern ZK system shares the same blueprint.
- Build an arithmetic circuit or an AIR (Algebraic Intermediate Representation).
- Reduce it to a polynomial.
- The prover sends a commitment to the polynomial, locking in its values without revealing the polynomial itself.
- The verifier sends a random challenge. The prover opens the value at that point.
- The verifier checks that the value satisfies the circuit constraints.
The branching choice here is the polynomial commitment scheme.
| Commitment | Basis | Systems |
|---|---|---|
| KZG | Pairings, trusted setup | PLONK, Sonic |
| IPA | Discrete log, transparent | HALO2, Bulletproofs |
| FRI | Hashes, transparent | STARK, Plonky2/3, SP1 |
| Brakedown | Hashes | Spartan, Brakedown |
Even with the same top-level protocol, swapping commitments swaps the performance curve. "PLONK over KZG" and "PLONK over FRI" are different systems.
Chapter 3 · Groth16 — The 2016 Classic Still Alive in 2026
Groth16 is a pairing-based SNARK published by Jens Groth in 2016. Proof size is about 192 bytes and verification is a few pairings, making on-chain verification dirt cheap. The downside is that you need a circuit-specific trusted setup (Powers of Tau ceremony).
The canonical tools are snarkjs and ZoKrates. Write the circuit in Circom, run Powers of Tau with snarkjs, then generate the proving key.
# Pseudo-command flow — Groth16 + Circom + snarkjs
circom mycircuit.circom --r1cs --wasm --sym
snarkjs powersoftau new bn128 14 pot14_0000.ptau
snarkjs powersoftau contribute pot14_0000.ptau pot14_0001.ptau
snarkjs groth16 setup mycircuit.r1cs pot14_final.ptau circuit.zkey
snarkjs groth16 prove circuit.zkey witness.wtns proof.json public.json
snarkjs groth16 verify verification_key.json public.json proof.json
Groth16 still has the "cheapest on-chain verification" property. That is why Tornado Cash, Semaphore, RAILGUN, and first-generation rollups like zkSync Lite all used it. In domains where the circuit-specific setup is tolerable — meaning a single fixed circuit — Groth16 remains a sensible choice in 2026.
Chapter 4 · PLONK — Aztec's 2019 Generalization
PLONK (Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge) was published in 2019 by Ariel Gabizon, Zac Williamson, and Oana Ciobotaru at Aztec Network. Its key feature is a universal trusted setup — one setup handles every circuit of a given size. You change the circuit without redoing the ceremony.
PLONK ignited an explosion of custom gates and lookup arguments (Plookup, cq, lasso, and so on). Expressiveness is far higher than plain R1CS (Rank-1 Constraint System). Heavy ops like hashes, ECDSA, and EVM instructions encode efficiently.
The deeper point of PLONK was "shared setup + diverse circuits." That opened the door to zkRollups that prove an entire language (EVM-compatible).
Groth16: circuit_A -> setup_A circuit_B -> setup_B ...
PLONK: setup once -> circuit_A, circuit_B, ... (universal SRS)
Aztec, Polygon zkEVM, zkSync Era (pre-Boojum), and Halo2 (PLONK-ish) — half the mid-decade ZK landscape sits on PLONK variants.
Chapter 5 · HALO2 — No Trusted Setup, Zcash's Pick
HALO2 is a PLONK-family proof system built by Electric Coin Company (Zcash). It uses IPA (Inner Product Argument) instead of KZG, so there is no trusted setup at all. Removing the ceremony removes a trust assumption.
HALO2's other strength is recursion. It can prove its own proofs inside its own circuit, making proof aggregation natural.
Major 2026 systems using HALO2:
- Zcash Halo2 — Orchard pool, the de facto standard after NU5.
- Scroll zkEVM — HALO2-based EVM-compatible proof circuits.
- Penumbra — A private DEX on Cosmos, built on HALO2.
- Filecoin — Uses HALO2 in parts of Proof-of-Replication.
The weakness is that verification is more expensive than KZG-based schemes. The common pattern is "produce the proof in HALO2, then wrap once more in KZG-PLONK before going on-chain."
Chapter 6 · STARK and FRI — Eli Ben-Sasson's Path
STARK (Scalable Transparent ARgument of Knowledge) was formalized in 2018 by Eli Ben-Sasson and collaborators at StarkWare. The core technology is FRI (Fast Reed-Solomon Interactive Oracle Proof of Proximity). It proves that a polynomial has degree below a bound using only Merkle trees over hashes.
STARKs have three appeals:
- Transparent — No trusted setup. No ceremony.
- Post-quantum — Relies only on hash functions, so it resists quantum computers.
- Prover-friendly — Using small FFT-friendly fields (for example Goldilocks at
p = 2^64 - 2^32 + 1) makes the prover much cheaper than SNARKs.
The trade-off is proof size (tens of KB) and on-chain verification cost. In practice, the standard pattern is "build the proof with STARK, wrap with SNARK, then publish on-chain." Polygon zkEVM, Boojum (zkSync Era), and Plonky2 all follow this pattern.
Chapter 7 · Circom 2.2 — The Original Circuit DSL
Circom is the circuit DSL from iden3. As of 2026 the 2.2.x line is maintained, and it remains the de facto language for writing R1CS circuits.
pragma circom 2.2.0;
template Multiplier() {
signal input a;
signal input b;
signal output c;
c <== a * b;
}
component main = Multiplier();
Properties:
- Lives in a finite field
F_p, not the integers — every arithmetic op is modular. - Compiles to R1CS plus a WASM witness calculator.
- Pairs with snarkjs for both Groth16 and PLONK proving.
- Thick library ecosystem — circomlib (hashes, Merkle trees, EdDSA), circom-ecdsa, semaphore, and more.
Circom still has a steep learning curve. You have to think of a circuit as a set of constraints, not a program. That demand led to Noir.
Chapter 8 · Noir 0.40 — Aztec's Rust-Style DSL
Noir is Aztec's Rust-style ZK language. The 0.40.x line in 2026 evolves rapidly and lets you write circuits like functional Rust.
// Noir example — prove the product of two values, with the factors hidden
fn main(a: Field, b: Field, c: pub Field) {
assert(a * b == c);
}
Noir's strengths:
- Backend independence — The same Noir code runs against multiple backends like Barretenberg (PLONK, HONK), Plonky2, or RecursionProver.
- Standard library — Hashes (Poseidon, Pedersen), signatures (ECDSA, Schnorr), and Merkle trees out of the box.
- DX — Rust syntax, an LSP, the
nargoCLI (build, test, prove), andnoirjsJavaScript bindings. - Aztec integration — All private contract functions on Aztec L2 are written in Noir.
# Noir workflow
nargo new my_project
cd my_project
nargo check
nargo execute # generate the witness
nargo prove # generate the proof
nargo verify # verify
Noir's limits: you cannot escape circuit reality (finite-field arithmetic). Programmer instincts like dynamic-length arrays or arbitrary loops still translate into circuit cost. Still, the entry barrier is much lower than Circom.
Chapter 9 · Cairo 2 + StarkNet — A STARK-Friendly Full Stack
Cairo is StarkWare's STARK-friendly programming language. Cairo 0 was close to assembly. Cairo 2.x is a proper high-level language with strong Rust influence.
Core Cairo concepts:
- Cairo-VM — Every Cairo program runs on this STARK-friendly VM. Its execution trace is exactly what the STARK proof attests.
- Sierra IR — An intermediate representation between Cairo source and Cairo-VM bytecode. Guarantees the program is always "provable."
- Starknet 0.13.x — The L2 where Cairo contracts run. After the Stwo prover rollout in 2024 to 2025, throughput jumped dramatically.
// Cairo example — felt252 (an element of `F_p`) is the default type
fn main(a: felt252, b: felt252) -> felt252 {
a * b
}
Starknet hosts dYdX v4 (formerly v3), the Argent X wallet, Briq, and games like Realms. In 2026, Cairo is roughly the only "STARK from end to end in one language" experience.
Chapter 10 · Risc Zero 1.x — Proving RISC-V
Risc Zero essentially defined the zkVM category after its 2022 launch. The 2026 1.x line includes:
- zkVM — Proves the RISC-V (rv32im) instruction set. Run
cargo risczero buildon plain Rust code and you get a provable ELF binary. - Bonsai — Risc Zero's cloud prover service. Offload heavy proofs.
- Steel — Executes EVM contract view calls inside the zkVM and produces proofs of EVM state. Effectively an "EVM precompile."
- Boundless — A distributed prover network released in late 2025. Anyone can contribute GPU capacity, run proofs, and earn rewards.
// Host-side — run guest code inside the zkVM
use risc0_zkvm::{default_prover, ExecutorEnv};
fn main() {
let env = ExecutorEnv::builder()
.write(&42_u32).unwrap()
.build().unwrap();
let prover = default_prover();
let receipt = prover.prove(env, MY_GUEST_ELF).unwrap();
receipt.verify(MY_GUEST_ID).unwrap();
}
The value of Risc Zero is that you "do not write circuits." You prove already-working Rust code as is. For example, run an Ethereum light client like Helios inside the zkVM and that run itself becomes the proof that "this Ethereum header at this height is valid."
Chapter 11 · SP1 — Succinct Labs' Rust-First zkVM
SP1 (Succinct Processor 1) is a RISC-V zkVM from Succinct Labs. Released in 2024 and rapidly mainstream through 2025 to 2026.
SP1's signature traits:
- FRI-based — Proofs live on STARK-friendly small fields. Significantly more prover-efficient than circuit-based approaches like Risc Zero.
- Pure Rust — Standard Rust on both host and guest. Use the
sp1-zkvmcrate to mark IO only. - Precompiles — Heavy ops like Poseidon, Keccak, sha256, secp256k1, BN254/BLS12-381 pairings are accelerated at the circuit level.
- On-chain verifier — With Groth16 or PLONK wrapping, the proof verifies on Ethereum mainnet directly.
// SP1 guest code — everything inside main is proven
#![no_main]
sp1_zkvm::entrypoint!(main);
fn main() {
let n: u32 = sp1_zkvm::io::read();
let mut sum: u32 = 0;
for i in 1..=n {
sum += i;
}
sp1_zkvm::io::commit(&sum);
}
On benchmarks SP1 is often faster than Risc Zero on the same workload. That is why "Helios light client zkVM proofs," "EVM block proofs," and "consensus proofs" PoCs migrated to SP1 quickly.
Chapter 12 · Plonky3 — Polygon Labs' STARK Toolkit
Plonky2 (2022) from Polygon Zero was a PLONK plus FRI hybrid. Plonky3 (2024) is its successor, a "modular toolkit that lets you build any STARK system."
Plonky3 components:
- field — A collection of small prime fields like Goldilocks, BabyBear, and Mersenne31.
- STARK framework — AIR definitions, trace generation, FRI prover.
- Commitment scheme — Merkle, FRI, and recursive aggregation.
- Backend compatibility — RISC-V zkVMs like Valida and custom AIRs all sit on top of Plonky3.
+------------------------------+
| Plonky3 core |
| Field, AIR, FRI, Merkle |
+---------+--------------+-----+
| |
zkVM impl (Valida) Custom AIR (Polygon zkEVM type 1)
You rarely write Plonky3 directly, yet it accounts for half of "why SP1 and Polygon zkEVM are fast." It is the invisible spine of 2026 ZK infrastructure.
Chapter 13 · Powdr, Jolt, EZKL — The Next-Generation Toolkits
Three interesting projects that add one more abstraction layer on top of the existing stack.
- Powdr — A "factory tool" for building zkVMs. Use it to build a domain-specific zkVM (for example, a Bitcoin-verification-only zkVM). Write AIRs, define instruction sets, and pick prover backends from one tool.
- Jolt — A zkVM from a16z crypto. Centers on Lasso (lookup singularity) and Spartan (R1CS sumcheck). Its fresh idea is to handle nearly every RISC-V instruction with a single lookup-table read.
- EZKL — The de facto standard tool for ZKML (ZK Machine Learning). Take an ONNX model, reduce it to a circuit, and produce a proof. Privately attest that "this ML model produced this output for this input."
These three show that ZK is no longer one system but a layer cake. Someone builds a zkVM with Plonky3, someone builds a domain-specific zkVM on Powdr, someone lays ML inference on top of it with EZKL.
Chapter 14 · Helios, zkEmail, zkTLS — Pulling web2 On-Chain
A new wave of ZK applications is not "data inside the chain" but "web2 data pulled into the chain."
- Helios — An Ethereum light client from a16z. Run it inside a zkVM and you get a proof of "the Ethereum state at this height." A foundation for cross-chain trust.
- zkEmail — Prove DKIM-signed emails with ZK. Prove "this email came from abc at google.com" without revealing the content. Used for signup, social recovery, and KYC.
- TLSNotary and zkTLS — Seal data received over a TLS session in a form a third party can verify. Prove "at this time the response from nytimes.com contained this sentence." Reclaim Protocol popularizes this.
- Anon Aadhaar and zkPassport — Verify the signature on India's Aadhaar QR or an ICAO 9303 e-passport with ZK. Reveal only facts like "I am over 18" or "I am Korean" without exposing the ID.
This category grew the fastest among ZK applications from 2024 to 2026. It proves off-chain facts, not on-chain assets.
Chapter 15 · The L2 zk-Rollup Landscape — ZK Running on Mainnet
In 2026 the biggest production use of ZK is still L2 rollups. Major players summarized.
| Rollup | Proof system | Notes |
|---|---|---|
| zkSync Era | Boojum (STARK plus SNARK wrap) | Largest TVL, custom EraVM |
| Linea | gnark-based PLONK | ConsenSys, EVM type 2 |
| Polygon zkEVM | Plonky2 then Plonky3 | EVM type 2 to 3 |
| Scroll | HALO2 | EVM type 2, modular circuits |
| Taiko | SGX plus ZK multi-proof | Based rollup, EVM type 1 target |
| Mantle | OP Stack plus EigenDA plus ZK | Optimistic-zk hybrid |
| Aztec | Noir plus PLONK plus UltraHONK | Privacy-first L2 |
| Starknet | Cairo plus Stwo | Non-EVM, the most different path |
Most rollups follow the same recipe — build the proof with STARK, wrap with SNARK, post on-chain. The differences are "which EVM-compat target" (type 1 through 4) and "which circuit library."
Chapter 16 · EigenLayer and EigenDA — Modular Infrastructure Adjacent to ZK
EigenLayer is not ZK itself, but it reshapes the cost structure of ZK rollups. Stake on Ethereum gets restaked to lend its security to other services (AVSs, Actively Validated Services).
EigenDA is a Data Availability layer that sits on EigenLayer. Rather than posting calldata to Ethereum mainnet, the rollup posts it to EigenDA and leaves only the KZG commitment on mainnet. The cost falls by an order of magnitude.
For ZK rollups, EigenDA solves the 2024 to 2025 bottleneck of "proof generation is no longer the issue, but data is still expensive." Mantle and Celo L2 already adopted EigenDA, and in 2026 Linea and Scroll support it as an option.
Chapter 17 · Privacy Applications — The Landscape After Tornado Cash
The 2022 OFAC sanctions on Tornado Cash were a major shock to all ZK privacy tools. The landscape since has split in two.
One side — push the "applications are legal, tools are neutral" framing. Aztec Network (separates private and public notes on an L2), Aleo (privacy built into layer 1), Penumbra (a private DEX on Cosmos), Manta (an EVM-compatible privacy L2). They selectively expose user identity, AML, and traceability via ZK.
The other side — RAILGUN and Privacy Pools (proposed by Vitalik and others in 2023) screen funds via ZK so only "legal funds" enter the pool. You must prove via ZK that "this money is unrelated to known hacks or crimes" to join.
Technically both sit on the same tooling — Poseidon hashes, Merkle trees, nullifiers. They split on policy.
Chapter 18 · ZK Identity — zkPassport, Anon Aadhaar, Sismo
One of the most intuitive ZK applications is identity. Prove a fact like "I am over 18" without showing the entire ID.
- zkPassport — ZK-verifies digital signatures from ICAO 9303 e-passports. Reveal only attributes like nationality, birth year, or sex. Ships with iOS and Android apps and a web SDK.
- Anon Aadhaar — ZK-verifies the RSA signature on India's Aadhaar QR. Proves only "I am an Indian resident" while keeping the 12-digit Aadhaar number private.
- Reclaim Protocol — Uses TLSNotary to ZK-prove data from web2 services like Uber, LinkedIn, and KakaoTalk. Proves facts like "I am a 5-star Uber driver."
- Sismo — ZK attestations derived from on-chain data. Issues ZK badges like "this wallet voted in the ENS DAO."
- World ID — Worldcoin's ZK-based sybil-resistant identity. Iris scans give one human one ID, used only via ZK at the point of consumption.
ZK identity finally answers the question of "who really owns this wallet" — without exposure.
Chapter 19 · ZK Projects in Korea and Japan — The East Asian Landscape
The ZK landscape looks U.S. and Europe-centric, but East Asia matters.
Korea:
- Krust (Klaytn ZK) — Kakao-affiliated Klaytn's ZK rollup research. After the 2024 Kaia merger, ZK security research lines continue.
- Sphinx Labs — ZK applications on Cosmos and Ethereum, especially gaming and identity.
- Sygnum Korea — The Korean arm of Swiss digital-asset bank Sygnum. PoCs on ZK-based private payments and institutional trading.
- Theta Labs Korea — ZK applied to video streaming (content rights proofs).
- Onther and EIP-4337 Korea group — ZK applied to account abstraction.
Japan:
- Astar Network (ZK stack) — Polygon CDK-based Astar zkEVM. Alongside Soneium L2, one of the two main axes of Japan's 2024 web3 infrastructure.
- Soneium — An OP Stack L2 from Sony Block Solutions Labs. Not yet a ZK chain, but a 2026 roadmap to a ZK phase is public.
- zkSync Japan and Polygon Japan — Both run Japan entities for gaming and payments pilots.
- Oasys and imToken Japan — A gaming chain plus ZK identity integration.
- Startale Labs — The founder of Astar's follow-on project, gaming and payments on a ZK stack.
ZK usage in East Asia weighs more on gaming, payments, and identity than DeFi as in the U.S. The regulatory environment is different.
Chapter 20 · Proof Costs — Who Is How Fast
Approximate prover cost (per RISC-V cycle on a single GPU) for representative zkVMs in 2026:
| System | Relative speed | Notes |
|---|---|---|
| Plonky3-based SP1 | Fastest tier | FRI plus small fields plus precompiles |
| Risc Zero 1.x | Fast tier | Circuit-based, GPU-friendly |
| Jolt | Experimental but very promising | Lasso plus Spartan |
| Plain Circom and Groth16 | Slow (for small circuits only) | Needs a per-circuit setup |
Key: even on the same workload, zkVMs differ by an order of magnitude based on whether they include precompiles. Half the reason SP1 is fast is that it bakes Poseidon, sha256, secp256k1, and other heavy ops into the circuit upfront.
Boundless, Succinct Prover Network, and Nethermind ZK Prover establish a prover marketplace, so a prover becomes a resource "bought from the market" rather than "GPUs I own." 2026 sits in the middle of that transition.
Chapter 21 · ZK Plus AI — Verifiable ML and Data Provenance
ZK and AI meet in two directions.
- Verifiable Inference — Prove via ZK that "this model produced this output for this input." EZKL is the flagship. Keep the model weights private and prove the inference. Powerful where the model cannot be published, like healthcare or finance.
- Verifiable Training and Provenance — Prove the integrity of training data, training procedure, and the resulting model. Still academic from 2024 to 2026, but Modulus Labs, Giza, and Spectral are shipping PoCs.
The ZK and LLM crossover is even more interesting. On-chain ML inference for small LLMs and classifiers is practical in 2026. The cryptographic attestation of "this response really came from GPT-X" sits in a domain OpenAI and Anthropic are evaluating.
ZK is likely to become the verifiable-trust layer for AI governance.
Chapter 22 · Practical Pitfalls When Writing Circuits
Everyone falls into the same traps when first writing circuits.
| Pitfall | Symptom | Mitigation |
|---|---|---|
| Missing constraints (under-constrained) | Other values also pass | Explicit === or <== on every signal |
| Private and public confusion | Secrets leak into the proof | Mark inputs private or public |
| Large-integer overflow | Modular F_p arithmetic fights intuition | Use range-check circuits like LessThan |
| Non-deterministic witness | Same input yields different witnesses | Make witness computation deterministic |
| Huge-circuit blowup | Compilation or proving never ends | Split circuits, recursion, switch to a zkVM |
| Hash misuse | sha256 circuits are huge | Use ZK-friendly hashes like Poseidon |
| Nullifier collision | Double-spend possible | Include a unique seed in nullifiers |
| Wrong domain | Nullifiers collide across services | Domain separation |
Circuit-audit firms — Veridise, 0xPARC ZK Audits, Zellic, and Spearbit — grew fast from 2024 to 2026. The consensus is that ZK code needs more delicate review than standard Solidity audits.
Chapter 23 · Seven Practical ZK Scenarios — Which Tool Fits
Concrete scenarios with recommended tools.
| Scenario | Recommendation |
|---|---|
| Single circuit, minimum on-chain verification cost | Circom plus Groth16 |
| EVM-compatible zkRollup | Polygon zkEVM (Plonky3), Scroll (HALO2), or Linea (gnark) |
| Prove arbitrary Rust code | SP1 or Risc Zero zkVM |
| Private contracts (privacy DeFi) | Aztec plus Noir |
| Full STARK stack | Cairo plus Starknet |
| ZKML (model-inference proofs) | EZKL |
| Web2 data into ZK | TLSNotary, Reclaim, or zkEmail |
The most common mistake is one-tool maximalism. zkRollup teams operate three tools at once — a circuit tool, a zkVM tool, and a ZK-identity tool. Tools follow the problem.
Chapter 24 · The Next Five Years — ZK Goes Truly Mainstream
A closing look at the five-year trajectory.
- zkVMs absorb circuits. Nobody writes hash circuits in Circom anymore. SP1 and Risc Zero precompiles absorb that work.
- Prover marketplaces become normal. Provers become a market resource. Boundless, the Succinct Prover Network, Nethermind ZK Prover, and others.
- L2s converge on type 1. Every major zkRollup moves toward EVM-equivalent.
- Privacy becomes selective. The "default private, selectively public" model proven by Aztec, Aleo, and Penumbra becomes the standard.
- ZK identity becomes the bridge between web2 and web3. zkPassport and Anon Aadhaar style options become login options in ordinary apps.
- ZK plus AI — Verifiable inference accelerates ML adoption in healthcare, finance, and law.
- Post-quantum security matters more. STARK-family schemes start to gain ground over SNARK.
- Standardization — At the IRTF and NIST level, ZK primitives become standardized, and ZK joins the "menu of crypto libraries."
ZK is no longer mysticism. It is a tool. And the tool is becoming something ordinary engineers ship.
Epilogue — Where to Start
If the catalog feels overwhelming, here is a recommended learning path.
- Theory — Vitalik Buterin's "How does a zero-knowledge proof work?" series and Justin Thaler's book "Proofs, Arguments, and Zero-Knowledge."
- DSL practice — Prove a multiplication circuit with
circomplussnarkjs. Then go through the Semaphore tutorial. - zkVM practice — Run the fibonacci example on SP1 or Risc Zero. Feel Rust become a circuit.
- L2 practice — Deploy a small contract on Scroll or zkSync Era. Use ZK without seeing a circuit.
- Applications — Try the zkEmail or Anon Aadhaar demo. Feel ZK "beyond the wallet."
"What are you proving, who verifies it where, and what does it cost?" Walk back through the chapters with those three questions, and tool choices clarify quickly.
— ZK Tooling 2026, end.
References
- Buterin, V. (2022). "How does a zero-knowledge proof work? An ELI5 explanation." https://vitalik.eth.limo/general/2022/06/15/using_snarks.html
- Thaler, J. (2023). "Proofs, Arguments, and Zero-Knowledge." https://people.cs.georgetown.edu/jthaler/ProofsArgsAndZK.html
- Groth, J. (2016). "On the Size of Pairing-based Non-interactive Arguments." https://eprint.iacr.org/2016/260
- Gabizon, A. et al. (2019). "PLONK: Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge." https://eprint.iacr.org/2019/953
- Electric Coin Co. "HALO2." https://zcash.github.io/halo2/
- Ben-Sasson, E. et al. (2018). "Scalable, transparent, and post-quantum secure computational integrity." https://eprint.iacr.org/2018/046
- iden3. "Circom 2 Documentation." https://docs.circom.io/
- Aztec. "Noir Documentation." https://noir-lang.org/docs
- StarkWare. "Cairo Book." https://book.cairo-lang.org/
- Starknet Foundation. "Starknet Documentation." https://docs.starknet.io/
- Risc Zero. "zkVM Overview." https://dev.risczero.com/api/zkvm/
- Succinct Labs. "SP1 Book." https://docs.succinct.xyz/
- Polygon Labs. "Plonky3 GitHub." https://github.com/Plonky3/Plonky3
- a16z crypto. "Jolt: A simple, fast, modular SNARK." https://a16zcrypto.com/posts/article/building-jolt/
- ZKonduit. "EZKL." https://docs.ezkl.xyz/
- zkSync. "Boojum Whitepaper." https://zksync.io/research
- Scroll. "Scroll Architecture." https://scroll.io/blog
- Aztec Network. "Aztec Protocol Specification." https://docs.aztec.network/
- EigenLayer. "EigenLayer Whitepaper." https://docs.eigenlayer.xyz/
- Reclaim Protocol. "TLSNotary and Reclaim." https://reclaimprotocol.org/
- zkPassport. "Documentation." https://zkpassport.id/
- Anon Aadhaar. "Anon Aadhaar Protocol." https://anon-aadhaar.pse.dev/
- Astar Network. "Astar zkEVM." https://astar.network/
- Soneium. "Soneium Documentation." https://soneium.org/
- Veridise. "ZK Audit Reports." https://veridise.com/