---
title: "An Opinionated Overview of ZK Tooling and Proof Systems Right Now"
date: 2023-09-01T02:12:03.284Z
authors: ["yush_g"]
type: posts
draft: false
slug: "zk"
category: "30 min read"
tags: ["crypto", "zk"]
description: "Proof systems, ecosystems, proving stacks, and why we chose the ones we did."
aliases:
- /posts/takes
- /posts/zk
- /takes
- /zk
math: true
---

# An Opinionated Overview of ZK Tooling and Proof Systems Right Now
View [this post on my blog](https://blog.aayushg.com/posts/zk) for the most up-to-date version!

When entering the ZK space, it's easy to be overwhelmed. Everyone is shilling their own protocol, and there are a ton of different proving standards and papers coming out every day. Folks often have similar questions on how to think about different ideas and protocols security, efficiency, and tradeoff wise. Unfortunately, its very hard to quickly distinguish what is worth investing into, and all of the precise security guarantees or undisclosed "gotchas". I will summarize how I am personally currently thinking about the space of ZK tech, especially as we make decisions for what to prioritize for our own code and protocols. I am not perfectly versed in all of the tradeoffs of all of the recent ideas, but this will be a live doc updated as I read and learn more, and folks comment corrections.

This is NOT an indictment of the ideas/protocols I don't highlight or cover favorably, nor does this represent the opinions of anyone I cite or credit (they are my interpretations only). I am aiming to make an intellectually honest survey, and so if I misunderstand something, please tell me ([telegram](https://t.me/yush_g), [twitter](https://twitter.com/yush_g)) -- I am very open to continual changes and improvements, especially as the space and this tech rapidly evolves. You can leave comments on [this hackmd](https://hackmd.io/@yush/rJBqa1YC2/edit). Thanks to Nalin, John, Yi, Richard, Sora, Ratan, [ShuklaAyush](https://github.com/shuklaayush), and Vivek for thoughts on this post, in addition to the countless folks behind these protocols themselves, and folks who I've had conversations with regarding zk over the last 2 years! Thanks to Richard and Sachin for touching on many of these points in their [ZK Summit London talk](https://www.youtube.com/watch?v=gX6smLsA0ko) as well.

Last updated Nov 5, 2023.

## ZK Proving Languages and Stacks

Two benchmarks for server-based ZK proof stacks are [Celer's benchmarking](https://blog.celer.network/2023/08/04/the-pantheon-of-zero-knowledge-proof-development-frameworks/) and [Modulus Labs' graphs](https://medium.com/@ModulusLabs/chapter-5-the-cost-of-intelligence-da26dbf93307). There is extremely high variance in how much they were able to optimize each circuit to the quirks of the individual proving systems, but they give a decent grounding to start looking at tradeoffs. I've summarized some here as well, and provide a conclusion at the end.
- **Circom**: This is the language that has historically been used by the main zk apps in production, including [Dark Forest](https://zkga.me) and Tornado Cash. It is commonly used because it has the fastest browser proving time due to optimized WASM proofs in the browser, super-fast server side proving via [rapidsnark](https://github.com/iden3/rapidsnark) which is only about [10% slower than gnark](https://blog.celer.network/2023/08/04/the-pantheon-of-zero-knowledge-proof-development-frameworks/), and extremely small and fast on-chain verification (8 uint256s verified in about ~300K gas). The language is relatively easy to pick up and experiment with (i.e. at [zkrepl.dev](https://zkrepl.dev)) and has a good developer community that has contributed a [significant number of circuits](https://github.com/iden3/circomlib/blob/master/circuits/). There's a number of unofficial, unaudited backends including [Nova](https://github.com/nalinbhardwaj/Nova-Scotia), a very slow PLONK, FFLONK which is like PLONK but with a 10x slower prover and a 33x cheaper verifier, and even [unaudited, untested, unmaintained] [STARKs](https://github.com/vimwitch/circom-stark). [zkrepl.dev](https://zkrepl.dev) makes development more accessible.
- **Halo2**: This is the library originally developed by zcash for generating PLONKish ZK proofs, and currently maintained by PSE and z.cash, and built upon by Axiom and EZKL. For us, much of the speedup is due to PLONK supporting lookups. It's built to support multiple backends [KZG](https://github.com/axiom-crypto/halo2) which is better for on-chain verification, and IPA -- this makes the circuits future-proof in case the latest and greatest proving system changes, or lookup arguments get faster. It's approachable to learn via [Axiom's crash course](https://docs.axiom.xyz/zero-knowledge-proofs/getting-started-with-halo2) and [0xPARC's class](https://learn.0xparc.org/halo2). When prover optimized (i.e. k under 13), our circuits have sub minute proofs in browser (about 10x faster than circom) with downloads < 500MB (5x smaller than circom), primarily driven by lookups saving constraints. To prove on chain, there are direct [solidity verifiers](https://github.com/han0110/halo2_solidity_verifier) for millions of gas on an L2, or GPU-accelerated ([repo](https://github.com/DelphinusLab/halo2-gpu-specific)) [server-side recursive provers](https://github.com/axiom-crypto/snark-verifier/blob/c36ff8c18c46d9b36d0a780ccaaf88185cf333a7/Cargo.toml#L38) with [recursive verifiers](https://github.com/axiom-crypto/snark-verifier/) that make arbitrary proofs only [~450K gas onchain](https://demo.axiom.xyz/). There are various circuits subparts that make new circuits easy to build, at Axiom's [halo2-lib](https://github.com/axiom-crypto/halo2-lib) and [zk-email's circuits](https://github.com/zkemail/?q=halo2&type=all&language=&sort=). [halo2repl.dev](https://halo2repl.dev) makes development more accessible, but doesn't support external imports yet.
- **PIL**: Jordi's second project after Circom was to build a STARK proving language optimized around VM computations. Due to the way they define certain operations and primitives, it's not suitable for circuits that aren't VMs. They are verified on chain via recursive [PIL STARKs](https://github.com/0xPolygonHermez/pil-stark/tree/main/circuits.gl), and [PIL2 STARKs](https://github.com/0xPolygonHermez/pil2-stark-js/tree/main/circuits.bn128) in circom.
- **plonky2**: Plonky2 is quite fast on baremetal. Unfortunately, you do take a risk since the security of Deep-FRI [hasn't yet been formally proven in an academic paper](https://twitter.com/nibnalin/status/1626824962299527169) -- Fiat-Shamir was [just proved](https://eprint.iacr.org/2023/1071.pdf), but novel ideas like grinding have no academic proof yet. We should expect browser-based implementations to have 4-8x slowdown because WASM does not get the main vectorized speed gains (which mostly come from the Goldilocks field size being small enough to fit elements in single vectorized registers). Unfortunately, vectorization for in-browser WASM is still pending standardization. Rumor is that plonky2 potentially has some fast closed-source browser implementations, but this cannot be verified or benchmarked yet. However, on baremetal macbook it completes pretty large proofs (1000 poseidon hashes so ~300K constraints) in less than a second, so perhaps this slowdown isn't that bad. Proofs are closer to 250kB, which is a no-go for on-chain proofs, though Succinct is working on a WIP promising recursive verifier in circom groth16 (40M constraints, so < 1 minute in cloud) for plonky2 without lookups. Plonky2 has a lot of optimizations, for instance skipping the top hashes in the Merkle tree, in exchange for longer commitments and proofs -- they also recently added LogUp lookups. plonky2 is going to be replaced by plonky3 which isn't ready yet, so it's a bit unclear what to implement in if you were to start now. We are optimistic for a recursive FRI verifier in PLONK -- [this one is right-field specific, so doesn't work for Goldlocks](https://github.com/maxgillett/halo2-fri-gadget), but [this WIP one](https://github.com/shuklaayush/halo2-fri-verifier) should be flexible to any field like Goldilocks.
- **plonky3**: Unlike what you might expect, there is no PLONK in plonky3. It is a STARK implementation. It is work in progress so no info on it yet.
- **Starky**: Again STARKs, which due to hashing are faster proving than PLONK. It is super early; i.e. plonky2/starky keccak is still [underconstrained](https://github.com/mir-protocol/plonky2/issues/1150).
- **Winterfell**: Early STARK implementation that is very well written with good documentation and is easier to use and learn, but due to it's earliness we don't expect it to be as fast. Maybe Polygon Miden has some closed source implementations.
- **GKR/Sumcheck**: This seems to perform very well in Modulus Labs' tests. It was a SNARK precursor from 2008 that has recently been combined with SNARK work to lead to some big speedups. Thaler has a [good breakdown](https://people.cs.georgetown.edu/jthaler/GKRNote.pdf) -- GKR and sumcheck is still very relevant, and in fact is one of the main advances that Lasso uses to beat the usual grand product argument. We hear that one of the big plans for proving system improvements is migrating the default lookups (usually grand product style via the PLONK paper) to a [LogUp](https://eprint.iacr.org/2023/1284.pdf)-based scheme based on GKR. Lasso/Jolt is also based on GKR, and they point out accurately that small scalar MSMs do in fact lead to decent (but not the claimed 10-40x) efficiency gains. Their work has been reasonably criticized since its [not as novel as they imply](https://twitter.com/SuccinctJT/status/1691092769261920256), mostly a synthesis of existing techniques, and their open source code is incomplete. I can see it this line of work continuing to evolve in the future, and we expect the state of the art to be added to halo2 when ready. Custom lookups along this line of work (like cq for instance) may be fruitful if you need to squeeze efficiency out of your prover for massive proofs, like ML proofs.
- **Noir**: This is an experimental new compiler by Aztec, that compiles a higher level language into any number of proving backends. It's probably the easiest language to get started in -- a lot of docs, optimized dev experience, and more intuitive mental models (i.e. if statements are supported). Unfortunately, multiple backends isn't actually a big gain over circom right now, as circom in practice has more: [Nova](https://github.com/nalinbhardwaj/Nova-Scotia), a very slow PLONK, and [STARKs](https://github.com/vimwitch/circom-stark) as well even though it wasn't built for them. Richard ran an [RSA benchmark]((https://github.com/SetProtocol/noir-rsa/actions/runs/6055065654)) in which Noir circuits took 5-50x longer to prove (i.e. ~6 minutes to prove browser-side in Circom, take about ~4 hours in Noir). Apparently the problem is with their unconstrained witness generation speed and (now fixed) immutable arrays -- the library is not very optimized, and we don't expect it to be faster than circom for the next 3-6 months (though we will update this post if we see improved benchmarks), especially not for wrong-field math. Noir is the only language I know with Honk/Goblin Plonk as a WIP default backend, which has potential to have extremely fast proving with only 16 kB proofs. I can see a hybrid system with the Noir-generated R1CS and circom's optimized provers being a great combination, but I haven't seen it tried yet.
- **Folding Schemes**: Nova-based schemes, [explained excellently by Taiko](https://taiko.mirror.xyz/tk8LoE-rC2w0MJ4wCWwaJwbq8-Ih8DXnLUf7aJX1FbU), are expected to be the fastest client-side provers due to [parallelizable recursion in schemes like ParaNova](https://zkresear.ch/t/towards-a-nova-based-zk-vm/105#parallelizing-nova-11). You can also prove in any curve with a cycle (including secp256k1, Ethereum's curve) directly, making most computation faster by avoiding wrong-field arithmetic. Projects including [Nova Scotia](https://github.com/nalinbhardwaj/Nova-Scotia) have made making circuits with repeated structure (like hashing or regex matching) accessible to developers via circom, but [direct on-chain verification needs a 8-10 million constraint recursive proof](https://github.com/jbaylina/nova-circom-verifier) server-side right now, which takes under 10 seconds on a large machine. [HyperNova](https://twitter.com/asn_d6/status/1667238765650124811) is more efficient by combining Nova with sumcheck and CCS, and Nova even has [lookups](https://medium.com/@ingonyama/a-brief-history-of-lookup-arguments-a4eeeeca2749). [Protostar](https://eprint.iacr.org/2023/620.pdf) generalizes Nova from R1CS to PLONK style systems, and Lev is working on a WIP implementation. Most folding folds two instances into one; however, ProtoGalaxy folds multiple at once into one more efficiently -- the [paper for ProtoGalaxy](https://eprint.iacr.org/2023/1106) is reportedly the most accessible folding paper, so if you're interested in the academic details we recommend starting there. The [sensationalized bug](https://www.zksecurity.xyz/blog/posts/nova-attack/) in the Nova implementation has been fixed -- contrary to Twitter, this is NOT an existential bug and can be easily remedied. Looking forwards to seeing more accelerated Nova benchmarks (Nexus?) and generalized compilers to convert arbitrary existing ZK code into HyperNova etc as well, which will probably help with large circuits like zkevms in Nova, which are currently untenably slow.
- **Spartan**: Lets you do right-field arithmetic on ECDSA because it supports more elliptic curves, so [spartan-ecdsa](https://personaelabs.org/posts/spartan-ecdsa/) is both fast and performant. Circuits are harder to write and there isn't much tooling, but for just proof of Ethereum signatures, this is pretty good.
- **[Goblin Plonk](https://hackmd.io/@aztec-network/BkGNaHUJn/%2FdUsu57SOTBiQ4tS9KJMkMQ)**: This has no implementation yet, but is being worked on in Noir. It has great power to speed up PLONKish type systems for recursive PLONK proofs with repeated structure (like hashes or regex). Honk (Aztec) plans to release this combined with ProtoGalaxy ([WIP ProtoGalaxy Aztec progress here](https://github.com/AztecProtocol/barretenberg/blob/340a25673099eee4ae38d4b4a24e2df1cce0c5d0/cpp/src/barretenberg/honk/proof_system/protogalaxy_prover.cpp#L4)).

In conclusion, for writing a new circuit of your own we recommend:
- **circom** if your client side proofs in browser are very small (i.e. hashing), or server-side proofs you want to prove on-chain, where privacy is less critical. Best tooling, lectures to learn ([more general](https://zkiap.com), [circom-specific](https://learn.0xparc.org/circom)), ease of switching to Nova/STARKs, [simple repl](https://zkrepl.dev) to get started, and library of existing circuits.
- **halo2** for fast client-side proofs (so proofs are likely primarily used for privacy, not succinctness). On-chain verification can be done [on L2s without recursion](https://github.com/han0110/halo2-solidity-verifier/commits/), or cheaper via recursive proofs on servers with GPUs. Even with recursion, still be faster than circom overall. Has a growing library of existing circuits as well as [accessible lectures and exercises to learn](https://learn.0xparc.org/halo2).
- **nova-based folding schemes** for ultra-fast client side proofs if you are confident that you will only have one repeated operation in the circuit, like many rounds of hashing. On-chain Nova verification will require this [unfinished server-side circom recursive verifier](https://github.com/jbaylina/nova-circom-verifier) that scales with the size of the Nova circuit.
- **plonky2** for ultra-fast server side proofs (where privacy is less important) and you are OK taking the risk on the unproven theoretical advances like grinding. Best for things like ZK EVMs.

I try to drink my own Kool-Aid, so we have used this logic to prioritize what to put into production for [zk email](https://github.com/zkemail/), which is halo2 for client side proofs and circom on the server side. In practice, we haven't really regretted it yet, and expect that within the next year we will have to rewrite our circuits in whatever the newest fastest proving language is.

More bespoke systems may be marginally faster, but harder to learn and you may have to build more core circuit logic yourself. There are many, many other proof systems that I haven't mentioned nor gotten time to look at (Lurk, Kimchi/Pickles, [Boojum](https://mirror.xyz/0x70DF15b0208eFCeFaA541Da9A0ED6C4A884554Fc/gNi8coqXjd1ybFsQBAG7QARUkPHZECu7ihIRkpiVx2Y), etc) -- until they are more mainstream, many of the core primitives (big int, signatures, hashing algorithms, etc) are likely still being built out, so they are not high priority for us to explore. In addition, they have not been audited as rigorously yet, so security of the implementation is often unproven (i.e. plonky2/starky keccak is still [underconstrained](https://github.com/mir-protocol/plonky2/issues/1150)). I am open to seeing fair, comparative benchmarks for new proof systems on common operations however, and adding to this list!

## ZK Ecosystems and Products
This landscape has a [great breakdown](https://flyingnobita.com/posts/2022/11/27/zkp-landscape) of what all of the different prover, networks, L1s, and ZKEVMs are doing. It does a great job breaking down the technical stacks, so I've opted to focus on open source ethos here instead.

- **Ethereum**: constantly has a high ethos of working in public, novel ideas, critical public-goods aligned ideological drive, [and consistently intellectual honest technical direction](https://vitalik.ca/). Thusly attracts an [extremely high quality of publicly discussed open source protocol and cryptography research](https://ethresear.ch/), and basically every other chain is playing catch up. Cost per proof will plummet over time as L2s and ZKEVMs reach production. I count all EVM-compatible chains in this as well, including Optimism, Arbitrum, ZK rollups, etc.
- **[Risc0](https://dev.risczero.com/)**: Has MIT licensing, but seeing some of their non-obfusticated code requires signing documents -- this means you have to trust their audits for security, not the code itself. Uses a custom implementation of STARKs (FRI) to prove RISC-V instruction set directly from Rust. STARKs inherently have larger proof sizes (see their [datasheet](https://dev.risczero.com/datasheet.pdf)) (~250 kB) -- they are quick to generate (seconds on consumer hardware, less on their cloud cluster), and verification on-chain requires their [recursive groth16 prover](https://www.risczero.com/news/on-chain-verification) which can run on a server and doesn't need to be client-side. As this becomes more efficient i.e. via better lookup algorithms, I hope it becomes the de-facto way that servers prove they are executing the correct open source code. They have a pretty insane 100 GPU cluster for fast, non-private proving. It would actually be pretty cool to publicly verify all Rust server executions via this protocol, and their new thing [Bonsai](https://dev.risczero.com/bonsai/) with infra for on-chain calls of arbitrary programs is a pretty interesting model. In general, because of the overhead from not having bespoke circuits, it will be much slower than rolling your own circuits and will be even slower in browser (for the same aforementioned reasons as small field FRI), but we are excited to see how it evolves.
- **Starkware/Cairo**: They were the first in the STARK space and made insane tech breakthroughs and speed benchmarks years before others. I hear Cairo is easy to learn because it is [Rust syntax inspired](https://starkware.co/tech-stack/). Unfortunately, all the good teams I knew building on it (i.e. Modulus Labs) left due to poor tooling and poor scaling, and I know other teams for which dealing with the verifier is a bottleneck to their shipping velocity. They claim transpilation can make it compatible with Solidity, but making this process auditable seems near impossible so it is hard to verify full EVM-compatibility (not their fault, mostly inherent with the decision to use a non-Solidity compatible language). Regardless, prior to Sept 2023, I had [not recommended using](https://medium.com/zeroknowledge/zero-knowledge-virtual-machines-the-polaris-license-and-vendor-lock-in-ab2c631cf139) Starkware because [of vendor lock-in and since Cairo code had non-commercial restrictions and weird licensing](https://web.archive.org/web/20230712020152/https://starkware.co/licenses/) with Polaris, but this choice is worth reconsidering now that the [code is open source Apache](https://starkware.co/licenses/).
- **Sismo**: I'm glad consumer companies are trying to take stabs at adding zk into user facing apps and auth. Unfortunately, the cost of this is centralization -- the core of the protocol that actually verifies the claims is Sismo's [commitment mapper](https://docs.sismo.io/sismo-docs/data-vault/commitment-mapper), which is a trusted offchain service that Sismo runs that verifies all the data. This means that Sismo themselves can claim anything they want; since proofs of membership are anonymous, no one has any idea whether or not Sismo has exercised this power. While this assumption may be ok for users in the short term, we expect that in the long term, fully decentralized alternatives will prove more lindy and reliable. To give them credit, their docs (but not their marketing) are [transparent](https://docs.sismo.io/sismo-docs/data-vault/commitment-mapper#security-model) about this assumption.

I think it's clear that on-chain apps should be built in the Ethereum ecosystem for the time being -- we expect more things to be EVM compatible over time so this will be a good bet regardless. Other nascent zk ecosystems include Aztec, Mina, and Miden, but they inherently have less developers and ecosystem activity [and for the most part, have yet to adopt permissive OSS licenses for their end to end stack]. I am excited to see results, benchmarks, and progress from these teams, as they all have commendable and ambitious goals.

## Places to Learn

I usually recommend our lecture series at [zkiap.com](https://zkiap.com) to start writing your first ZK circuits in circom.

---

For transparency, I have asked for and accepted grants from 0xPARC and the Ethereum Foundation PSE for my work. I sought them out and not the other way around, so I don't think it explicitly sways my thinking. However, it does give me an availability bias to the tech that I see people near me working on. They are also optimizing for speed in an intellectually honest way that I think it doesn't sway my opinions, but I acknowledge that it makes me less privvy to details of other ecosystems.

If you are excited by zk and want support to help get oriented in the space, I am happy to [answer any questions over Telegram](https://t.me/yush_g). If you're looking for ideas, we have open sourced our [best ideas for zk email](https://github.com/zkemail/) and [best ideas for noval projects in crypto generally](https://github.com/Divide-By-0/ideas-for-projects-people-would-use#Crypto), and will support any open source developer who wants to build them or any other ambitious idea.