Published on Sat Aug 22 2026 00:00:00 GMT+0000 (Coordinated Universal Time) by Jacob Cavazos

Zero-knowledge proving systems are the cryptographic foundation of modern ZK applications. They let you prove that a computation was executed correctly without revealing the inputs and without requiring the verifier to re-run the computation.

The landscape of proving systems has expanded significantly. In 2020 there were essentially two options: Groth16 and PLONK. Today there are over a dozen production systems, each with different tradeoffs in proving time, proof size, verification cost, trusted setup requirements, and developer ergonomics.

This article compares eight proving systems that are in production or active production development: halo2, PLONK, Plonky2, STARKs (specifically the Stone prover), SP1, RISC Zero, Noir, and S-two. The goal is to give a developer enough information to choose the right system for their use case.

The Core Tradeoffs

Before comparing specific systems, it helps to understand the dimensions on which they differ.

Proving time is how long it takes to generate a proof. This depends on the size of the computation, the proving system’s algorithmic complexity, and how well the implementation is optimized. Proving time is usually the main bottleneck for ZK applications.

Proof size is how large the generated proof is. Smaller proofs are cheaper to store on-chain and cheaper to verify. Proof size matters most when proofs are published to a blockchain where storage is expensive.

Verification time is how long it takes to check a proof. Verification should be fast, but some systems have verification times that scale with computation size while others have constant verification time regardless of computation size.

Trusted setup is whether the system requires a structured reference string that must be generated by a trusted party or ceremony. Systems with trusted setups have a security assumption: if the setup is compromised, proofs can be forged. Systems without trusted setups remove this assumption but typically have larger proofs or slower proving.

Arithmetic field is the mathematical field the system operates over. Some systems use large prime fields (good for elliptic curve operations), some use binary fields (good for hash functions), and some use goldilocks fields (a balance between the two).

Developer ergonomics is how easy it is to write circuits or programs for the system. Some systems require writing constraints manually in a domain-specific language. Others let you write standard code in Rust or C and compile it to a proof.

SNARK vs STARK

The most fundamental division is between SNARKs and STARKs.

SNARK stands for Succinct Non-interactive Argument of Knowledge. SNARKs produce small proofs, typically a few hundred bytes, that can be verified in milliseconds. Most SNARK systems use elliptic curve cryptography and require a trusted setup. Examples include Groth16, PLONK, and halo2.

STARK stands for Scalable Transparent ARgument of Knowledge. STARKs do not require a trusted setup (the T stands for transparent). They use hash-based cryptography instead of elliptic curves. STARK proofs are larger than SNARK proofs, typically tens to hundreds of kilobytes, but proving can be faster for large computations and there is no trusted setup risk. The main STARK systems are those built on the FRI protocol.

The tradeoff is simple. SNARKs give you smaller proofs and faster verification but require a trusted setup (in most variants). STARKs give you transparency and potentially faster proving for large computations but produce larger proofs.

In practice, many production systems use a hybrid approach. They generate a STARK proof for the computation and then wrap it in a SNARK proof to compress the proof size. This gives you the transparency of STARKs with the compact proof size of SNARKs.

Halo2

Halo2 is a proving system developed by the Electric Coin Company (Zcash) based on the Halo recursive proof composition technique. It uses the PLONK arithmetization with no trusted setup, leveraging a cycle of elliptic curves for recursion.

Halo2 does not require a trusted setup. This is its main advantage over original PLONK and Groth16. The elimination of the trusted setup is achieved through a technique called the inner product argument, which replaces the polynomial commitment opening that normally requires a structured reference string.

Proving time is moderate. Halo2 is not the fastest prover, but it is not the slowest either. For typical circuits of a few million constraints, proving takes seconds to minutes on standard hardware. Hardware acceleration (GPU and FPGA) is available and significantly reduces proving time.

Proof size is small, typically a few kilobytes. This is larger than Groth16 proofs (a few hundred bytes) but small enough for on-chain verification on most chains.

Verification time is fast, typically a few milliseconds. Verification does not require a trusted setup.

The arithmetic field is a large prime field (typically the Pasta curve fields). This makes Halo2 efficient for elliptic curve operations but less efficient for hash-based operations like Keccak or SHA-256, which require many constraints when expressed over a prime field.

Developer ergonomics is moderate. Halo2 circuits are written in Rust using the halo2 crate. You define your circuit as a set of gates and regions. There is a learning curve. It is not as ergonomic as writing plain Rust, but it is more flexible than Groth16’s circuit DSL.

Halo2 is used in production by Zcash (the Orchard protocol), by the Ethereum Foundation for the KZG ceremony tooling, and by several L2s for proof generation. It is a mature, well-audited system.

Use halo2 when you want a trusted-setup-free SNARK with small proofs and you are comfortable writing circuits in Rust. It is a strong default choice for production ZK applications.

PLONK

PLONK is a proving system introduced in 2019 by Ariel Gabizon, Zachary Williamson, and Oana Ciobotaru. It uses a universal trusted setup, meaning a single setup ceremony can be used for all circuits up to a certain size, rather than requiring a new setup for each circuit.

The universal setup is PLONK’s key innovation over Groth16. With Groth16, every circuit needs its own trusted setup. With PLONK, one setup serves all circuits. This makes the trusted setup much more practical because a single well-run ceremony benefits all users.

PLONK uses the KZG polynomial commitment scheme, which requires a pairing-friendly elliptic curve. The most common implementation uses the BN254 curve.

Proving time is moderate, similar to halo2. PLONK proving is dominated by polynomial operations and FFTs. For circuits of a few million constraints, proving takes seconds to minutes.

Proof size is small, around a few hundred bytes to a kilobyte. This is one of PLONK’s strengths. The proofs are compact enough for cheap on-chain verification.

Verification time is fast, a few milliseconds, and requires a pairing check on the elliptic curve.

The main downside is the trusted setup. While the universal setup is more practical than per-circuit setups, it is still a trusted setup. If the setup ceremony is compromised, an attacker could forge proofs. The KZG ceremony run by the Ethereum Foundation in 2022-2023 had over 140,000 participants, making it one of the largest and most secure trusted setups ever conducted. But the trust assumption remains in principle.

PLONK is used in production by Aztec, zkSync (early versions), and various other projects. It is well-understood and well-documented.

Use PLONK when you want the smallest possible proofs and fast verification and you are comfortable with the universal trusted setup. If the trusted setup is a dealbreaker, use halo2 instead.

Plonky2

Plonky2 is a proving system developed by Polygon (formerly Polygon Zero). It is designed for fast recursive proof composition. Plonky2 combines the PLONK arithmetization with the FRI polynomial commitment, eliminating the trusted setup while keeping fast recursion.

The key innovation in Plonky2 is the use of a small Goldilocks field (a 64-bit prime field) combined with FRI. The Goldilocks field is small enough that field operations are fast on standard CPUs, but large enough to support the FRI protocol without extension fields. This makes Plonky2 significantly faster than halo2 or PLONK for proving.

Proving time is fast. Plonky2 can generate proofs for circuits of a few million constraints in under a second on standard hardware. This is substantially faster than halo2 or PLONK, which typically take seconds to minutes for similar circuits.

Proof size is moderate, a few kilobytes to tens of kilobytes. Larger than PLONK but smaller than raw STARKs. The use of FRI rather than KZG means proofs are larger, but the elimination of the trusted setup is the tradeoff.

Verification time is fast, a few milliseconds. Plonky2 is designed for recursive composition, so verification is optimized to be cheap enough that one proof can verify another inside a circuit.

The main advantage of Plonky2 is recursion. You can generate many proofs and aggregate them into a single proof. This is useful for rollups that need to aggregate many transaction proofs into a single proof posted on-chain.

Plonky2 is used in production by Polygon for their zkEVM. It is also used by several other projects that need fast recursion.

Use Plonky2 when you need fast proving and fast recursive aggregation and you do not want a trusted setup. It is the best choice for applications that require aggregating many proofs.

STARKs (Stone Prover)

STARKs are a class of proving systems based on the FRI protocol and polynomial commitment schemes that use hash functions instead of elliptic curves. The Stone prover is the production STARK implementation developed by StarkWare, used in StarkNet and other StarkWare products.

STARKs do not require a trusted setup. This is their defining feature. The security of STARKs relies on the collision resistance of hash functions, which is a weaker and more standard cryptographic assumption than the discrete logarithm problem used in SNARKs.

Proving time is fast for large computations. STARKs scale well with computation size. The proving time grows quasi-linearly with the computation size, meaning STARKs are particularly efficient for large computations. For small computations, the overhead of the STARK protocol can make them slower than SNARKs.

Proof size is the main downside. STARK proofs are typically tens to hundreds of kilobytes. This is much larger than SNARK proofs. On-chain verification of raw STARK proofs is expensive because of the size. This is why many STARK-based systems wrap their STARK proofs in a SNARK before posting on-chain.

Verification time is fast but scales with the size of the proof. For large proofs, verification can take tens of milliseconds. For wrapped proofs, verification is as fast as the wrapping SNARK.

The arithmetic field for STARKs is typically a large prime field (the Cairo VM uses a 252-bit prime). This is good for general-purpose computation but not optimal for elliptic curve operations.

StarkWare’s Stone prover is used in production for StarkNet, the StarkEx validity rollups (used by dYdX, Immutable, and Sorare), and other StarkWare products. It is the most production-tested STARK implementation.

Use STARKs when you want transparency (no trusted setup), you are proving large computations, and you can tolerate larger proof sizes or plan to wrap the proof in a SNARK. STARKs are the best choice for general-purpose computation at scale.

SP1

SP1 is a zero-knowledge virtual machine developed by Succinct Labs. It lets you write programs in standard Rust, compile them to RISC-V, and generate a proof that the program executed correctly. SP1 is a type of zkVM, a virtual machine with an attached proving system.

The key feature of SP1 is developer ergonomics. You do not write circuits. You write Rust code. You use standard Rust libraries. You compile and run your program, and SP1 generates a proof of correct execution. This is a dramatic improvement in usability over circuit-based systems like halo2 or PLONK.

Proving time depends on the number of RISC-V cycles your program takes. SP1 uses a STARK-based proving system internally, so proving time scales with computation size. For programs that take a few million cycles, proving takes seconds to minutes. For larger programs, it can take longer.

Proof size is moderate. SP1 generates STARK proofs and then wraps them in a PLONK proof for compact on-chain verification. The final wrapped proof is a few kilobytes.

Verification time is fast after wrapping, a few milliseconds for the SNARK verification.

The tradeoff with SP1 is that you are proving the execution of a general-purpose CPU (RISC-V) rather than a custom circuit. This means you pay overhead for the CPU abstraction. A custom halo2 circuit for a specific computation will typically be faster to prove than the same computation expressed as a RISC-V program and proved with SP1. But the development time for the SP1 version is dramatically lower.

SP1 is open source and has been gaining adoption. It is used by several projects for proof generation, particularly for applications where the computation is complex enough that writing a custom circuit would be impractical.

Use SP1 when you want to prove the execution of a complex program without writing circuits, and you can tolerate the proving overhead of the VM abstraction. It is the best choice for rapid development and for computations that are hard to express as circuits.

RISC Zero

RISC Zero is another zkVM, similar in concept to SP1. It also uses RISC-V as the target architecture and generates proofs of correct execution. RISC Zero was the first production zkVM and has been available since 2022.

RISC Zero uses a custom STARK proving system. The proving system is optimized for the RISC-V instruction set and includes a precompile system for common operations like hash functions and signature verification.

Proving time is similar to SP1, scaling with the number of RISC-V cycles. RISC Zero has invested heavily in proving optimization, including GPU acceleration and parallel proving. For programs that fit within the precompile set, proving can be fast.

Proof size is moderate. RISC Zero also wraps its STARK proofs in a Groth16 or PLONK SNARK for compact verification. The wrapped proof is a few hundred bytes to a kilobyte.

Verification time is fast after wrapping, a few milliseconds.

RISC Zero differs from SP1 in implementation details and ecosystem. RISC Zero has a more mature Bonsai network for remote proving, which lets you offload proof generation to a distributed network of provers. SP1 has been more focused on the open-source prover itself.

RISC Zero is used in production by several projects for proof generation, including applications in gaming, identity, and DeFi.

Use RISC Zero when you want a mature zkVM with remote proving capabilities and precompile support. The choice between SP1 and RISC Zero often comes down to ecosystem fit and specific performance characteristics for your workload.

Noir

Noir is a domain-specific language for ZK circuits developed by Aztec. It is not a proving system itself. It is a circuit language that compiles to multiple backends, including halo2, Plonky2, and Marlin.

The key feature of Noir is that it provides a higher-level abstraction for writing circuits than writing constraints directly. You write Noir code that looks similar to Rust, and the compiler generates the underlying constraints for your chosen backend.

Noir abstracts over the proving system. You write your circuit once in Noir and can compile it to different backends. This means you are not locked into a specific proving system. If a better backend emerges, you can switch without rewriting your circuit.

Proving time, proof size, and verification time depend on the backend you choose. If you compile to halo2, you get halo2’s characteristics. If you compile to Plonky2, you get Plonky2’s characteristics.

The main advantage of Noir is developer ergonomics for circuit writing. It is higher-level than writing halo2 circuits directly but lower-level than writing Rust for a zkVM. You still need to think about constraints, but the language handles much of the boilerplate.

Noir is used in production by Aztec for their privacy-focused L2 and by other projects that want backend flexibility.

Use Noir when you want to write circuits at a higher level than raw constraint systems but do not want the overhead of a full zkVM, and when you want the flexibility to switch proving backends.

S-two

S-two is a newer proving system that has emerged as an evolution of STARK-based approaches. It focuses on improving the proving efficiency of STARKs while maintaining transparency.

S-two uses optimized polynomial commitment schemes and improved FRI variants to reduce proving time compared to earlier STARK implementations. The goal is to bring STARK proving times closer to SNARK proving times while keeping the no-trusted-setup property.

Proving time is competitive with the fastest SNARK systems for medium to large computations. For small computations, SNARKs may still be faster due to lower protocol overhead.

Proof size is similar to other STARK systems, typically tens of kilobytes. S-two can be paired with a SNARK wrapper for compact on-chain verification.

Verification time is fast, similar to other STARK systems, and can be wrapped in a SNARK for constant-time verification.

S-two is newer than the other systems in this comparison and has a smaller production track record. It is worth watching for applications that need STARK transparency with better proving performance.

Use S-two when you want the transparency of STARKs with improved proving performance and you are comfortable with a newer, less battle-tested system.

Comparison Summary

Here is how the systems compare on the key dimensions.

For proving speed, Plonky2 and S-two are the fastest for medium to large computations. SP1 and RISC Zero are fast for programs that fit their precompile and optimization profiles. Halo2 and PLONK are moderate. Raw STARKs (Stone) are fast for large computations but have overhead for small ones.

For proof size, PLONK produces the smallest proofs (a few hundred bytes). Halo2 is small (a few kilobytes). Plonky2 is moderate (a few to tens of kilobytes). SP1 and RISC Zero with SNARK wrapping are small to moderate. Raw STARKs are the largest (tens to hundreds of kilobytes).

For trusted setup, PLONK requires a universal trusted setup. Halo2, Plonky2, STARKs, SP1, RISC Zero, and S-two do not require a trusted setup. Noir depends on the backend chosen.

For developer ergonomics, SP1 and RISC Zero are the easiest because you write standard Rust. Noir is next, offering a higher-level circuit language. Halo2 and PLONK require writing circuits in Rust with explicit constraint definitions. Plonky2 and STARKs require similar circuit-level work.

For recursion, Plonky2 is the strongest, designed specifically for fast recursive composition. Halo2 supports recursion through its cycle of curves. STARKs support recursion through wrapping. SP1 and RISC Zero support recursion through recursive proof aggregation.

Choosing a System

The right system depends on your use case — for a structured decision framework for choosing a ZK proving system, see our companion guide.

If you are building a rollup and need to aggregate many transaction proofs, use Plonky2. Its recursion performance is the best in production.

If you are proving general-purpose programs and want fast development, use SP1 or RISC Zero. The ability to write standard Rust and generate proofs is a massive productivity win.

If you need the smallest possible proofs for on-chain verification and can accept a trusted setup, use PLONK. The KZG-based universal setup is well-established and the proofs are tiny.

If you need no trusted setup and want a mature, well-audited SNARK, use halo2. It is the production-tested choice for trusted-setup-free SNARKs.

If you are proving very large computations and want transparency, use STARKs (Stone prover). The scaling behavior is the best for large workloads.

If you want to write circuits at a higher level and keep backend flexibility, use Noir. It lets you switch proving systems without rewriting your circuit.

If you want the newest STARK performance improvements and are comfortable with a newer system, evaluate S-two.

Final Notes

The ZK proving landscape is moving fast. The systems compared here are the ones in production or active production development as of 2026. New systems will emerge and existing systems will improve.

The practical advice is this: do not over-optimize your proving system choice upfront — and if your use case involves client-side ZK proofs, browser constraints may narrow your options. Start with the system that has the best developer ergonomics for your team. If you are a Rust shop, start with SP1 or RISC Zero. If you have ZK circuit expertise, start with halo2. Get a working proof, measure performance, and then optimize if needed.

The biggest mistake teams make is choosing a proving system based on theoretical performance numbers — for browser-based proof generation, see our guide on client-side zero-knowledge proofs and then spending months writing circuits when they could have had a working proof in days with a zkVM. Proving performance matters, but time to working proof matters more for most projects.

The second biggest mistake is ignoring the trusted setup question until it becomes a problem. If your application’s security model cannot tolerate a trusted setup assumption, eliminate PLONK and Groth16 early. Do not get deep into implementation and then discover the trust model is incompatible with your requirements.

Choose based on your actual constraints: development speed, proof size budget, trusted setup tolerance, and computation size — the same principle applies to deterministic AI, where the architecture must match the problem. The systems above cover the full range of tradeoffs. There is no single best system. There is the best system for your specific problem.

Frequently Asked Questions

What is a ZK proving system?

A ZK proving system is a cryptographic protocol that allows one party (the prover) to convince another party (the verifier) that a statement is true without revealing the underlying data. Different systems use different mathematical techniques to generate and verify proofs, with tradeoffs in proof size, proving time, verification time, and trusted setup requirements.

What is halo2?

Halo2 is a zero-knowledge proof system based on the PLONKish arithmetization and the inner product argument. It was developed by the Electric Coin Company for use in Zcash and is now widely used across the ZK ecosystem. Halo2 supports recursive proofs and does not require a universal trusted setup ceremony for each circuit.

What is Plonky2?

Plonky2 is a ZK proving system designed for fast recursive proof generation. It combines PLONK-based arithmetization with the FRI protocol to achieve fast proving times, particularly for recursive SNARKs. Plonky2 is optimized for performance and is used in projects that require efficient recursive proof composition.

What are STARKs?

STARKs (Scalable Transparent Arguments of Knowledge) are a class of ZK proofs that do not require a trusted setup, using only publicly verifiable randomness. They rely on hash functions rather than elliptic curve cryptography, making them post-quantum secure. STARKs produce larger proofs than SNARKs but offer faster proving for large computations.

Which ZK proving system is fastest?

There is no single fastest proving system, as performance depends on the specific use case, circuit size, and whether recursion is needed. Plonky2 is optimized for fast recursion, STARKs excel for large computations, and Groth16 produces the smallest proofs. The best choice depends on your constraints around proof size, proving time, and trusted setup tolerance.

Written by Jacob Cavazos