ZK Proof Gas Costs: 2026 SNARK vs STARK Developer Guide

Why ZK Proof Performance Matters in 2026

Zero-knowledge proofs have crossed the threshold from academic curiosity to production infrastructure. In 2026, ZK-powered rollups process billions of dollars in transaction volume daily. StarkNet, zkSync, Scroll, and Polygon zkEVM all rely on ZK proofs for their security model. Beyond Layer-2 scaling, ZK proofs are expanding into privacy-preserving identity, confidential DeFi, on-chain AI verification, and regulatory compliance proofs — each with radically different performance requirements.

For developers, the choice of ZK proving system is not abstract. It directly determines on-chain gas costs, end-user latency, and the security assumptions your application inherits. A Groth16 proof costs roughly 230,000 gas to verify on Ethereum L1. A STARK proof for the same computation costs over 2.5 million gas — more than 10x the cost. Choosing the wrong system can make your dApp economically nonviable on day one.

This guide compares the major ZK proof systems across the dimensions that matter for developers: proof size and its impact on gas costs, verification speed, trusted setup trade-offs, and circuit security considerations. Whether you are building a privacy-preserving identity solution, a ZK-rollup, or an on-chain compliance system, the benchmarks and decision framework below will help you pick the right proving stack.

The Benchmark Landscape: Proof Size, Gas, and Verification Time

The following benchmarks come from production-ready library implementations tested on an AMD EPYC 7763 processor as of March 2026, measuring a standardized SHA-256 hash preimage circuit with approximately 22,000 constraints. The gas estimates reflect Ethereum L1 verification costs, where calldata is priced at 16 gas per non-zero byte.

Groth16 produces the smallest proof at 192 bytes with a gas cost of approximately 230,000. PLONK follows at 576 bytes and 320,000 gas. SP1, which uses STARK-to-SNARK wrapping, achieves 768 bytes and 350,000 gas while maintaining transparent setup. Halo 2, despite eliminating the trusted setup entirely through recursive verification, comes in at 1.2 kilobytes and 450,000 gas. Nova's folding-based approach produces larger proofs at 10 kilobytes per step and 800,000 gas, but enables incremental verification that no other system matches. At the far end, a raw STARK proof weighs 42 kilobytes and costs approximately 2.5 million gas on Ethereum L1 — economically prohibitive for direct on-chain verification, which is why STARK-based rollups use recursive aggregation to compress proofs before L1 submission.

The constant proof size of Groth16 and PLONK is their defining advantage for on-chain applications. A Groth16 proof for a 10-million-constraint computation still occupies 192 bytes — the same as a proof for a 10-thousand-constraint computation. Verification time remains constant at 3.1 milliseconds regardless of computation complexity. This property makes SNARKs structurally superior for applications where verification must be fast and predictable, such as on-chain identity checks or real-time DeFi operations.

For proving time, however, the relationship inverts at scale. STARKs prove large computations faster than SNARKs because their quasilinear scaling outperforms SNARK linear scaling at high constraint counts. For a 10-million-constraint computation, STARK proves roughly three times faster than Groth16. This is why high-throughput rollups lean toward STARK-based architectures for the proving layer, then wrap the result in a SNARK for compact on-chain verification.

SNARK vs STARK: Convergence Is Accelerating

The original trade-off — small proofs with trusted setup (SNARK) versus large proofs with transparent setup (STARK) — is dissolving. Three developments are reshaping the landscape.

First, STARK-to-SNARK wrapping, as used by SP1 and Risc Zero, provides both properties. The prover generates a STARK proof internally for speed and transparency, then wraps it in a SNARK for the compact verification that Ethereum L1 requires. The result: transparent setup with near-SNARK proof sizes of under 1 kilobyte.

Second, Plonky3 has matched Groth16's prover speed while being post-quantum safe and requiring no trusted setup. The remaining gap is proof size — approximately 50 kilobytes versus 192 bytes — but recursive aggregation closes most of this gap at scale. Plonky3 currently powers SP1, Polygon's AggLayer, and the Valida zkVM, making it the fastest-growing proving backend in 2026.

Third, Halo 2's recursive approach provides SNARK-like proof sizes without any trusted setup ceremony. It underpins Zcash Orchard, Scroll, and Taiko — three of the largest production ZK deployments — and its developer ecosystem is the most mature among transparent systems.

The practical consequence for developers: the choice of ZK system is increasingly about developer experience and ecosystem maturity rather than fundamental cryptographic trade-offs. If you write Rust, SP1 lets you prove arbitrary programs without writing circuits. If you need maximum on-chain gas efficiency, Groth16 via circom and snarkjs remains the gold standard. If you need universal setup reusability across multiple circuits, PLONK is the pragmatic choice.

Trusted Setup: The Hidden Security Cost

The trusted setup ceremony is the most consequential security decision in ZK system selection — and the one developers most frequently underestimate. A compromised trusted setup allows an attacker to forge valid-looking proofs for false statements, completely undermining the security of any system that relies on those proofs.

Groth16 requires a circuit-specific trusted setup. Every time you modify your circuit, you must run a new multi-party computation ceremony where each participant contributes randomness. If any single participant destroys their contribution (the 'toxic waste'), the ceremony is secure. But if even one participant's randomness is recovered, proofs can be forged. Zcash's Powers of Tau ceremony mitigated this with over 87,000 participants — a scale that is impractical for most application developers.

PLONK improves on this with a universal structured reference string. One ceremony, such as the Ethereum KZG ceremony that attracted 141,416 participants, can be reused across any number of circuits. This dramatically reduces the operational burden, but the toxic waste problem still exists in principle.

STARKs and Halo 2 eliminate the trusted setup entirely. STARKs rely on collision-resistant hash functions, while Halo 2 uses recursive verification to bootstrap its own security without any ceremony. For privacy infrastructure where the entire value proposition depends on eliminating trust assumptions, transparent or recursive systems have a philosophical advantage that complements their technical properties.

The industry trend is unmistakable: newer systems are moving away from trusted setups. Binius, Circle STARKs, and the next generation of folding schemes all prioritize transparency. If your application has a security horizon beyond five years, factor this trajectory into your system selection now.

Circuit Security: What Developers Get Wrong

A valid ZK proof guarantees that a statement is true — but only within the constraints you defined. The most dangerous circuit bugs are not broken cryptography; they are missing constraints that allow a prover to generate a valid proof for an invalid computation.

Under-constrained circuits are the most common vulnerability class. If your circuit proves that output = f(input) but fails to constrain that input falls within a valid range, a malicious prover can choose any input that produces the desired output. In financial applications, this translates directly to theft. The ZK security community has documented dozens of real-world examples where under-constrained circuits led to exploits in production systems.

Arithmetic overflow and field mismatch bugs form the second category. ZK circuits operate over finite fields, typically a large prime like the BN254 scalar field used by Groth16. If your application logic assumes standard integer arithmetic but your circuit implements modular arithmetic, wrapping behavior can produce unexpected results. Developers coming from Solidity, where uint256 overflow is well-understood, frequently miss this when writing circom or Halo 2 circuits.

Input validation at the circuit boundary is the third common failure point. A ZK proof only verifies the relationship between public inputs and the witness. If your verifier contract accepts public inputs without checking them against application-level invariants — such as verifying that a Merkle root matches a known state root — the proof is valid but the transaction is malicious.

The emerging best practice is to treat ZK circuits with the same rigor as smart contracts: formal verification, independent audits, and fuzzing with tools like circom-ecdsa and Ecne. Trail of Bits, Spearbit, and Zellic now offer ZK-specific audit engagements, reflecting the maturing security posture of the ecosystem.

The Developer Decision Framework

Rather than prescribing a single system, here is the decision tree that maps your application's requirements to the right proving stack.

Step one: determine your post-quantum security requirements. If your application's security horizon extends beyond ten years — relevant for identity systems, long-term storage proofs, and regulatory compliance archives — eliminate all elliptic-curve-based systems, including Groth16, PLONK, and Halo 2. Your remaining options are STARK-based systems, Plonky2, Plonky3, and SP1.

Step two: assess your tolerance for trusted setup. If you can participate in or run a multi-party computation ceremony, Groth16 and PLONK become available. These offer the smallest proofs and fastest verification, making them ideal for Ethereum L1 applications where every gas unit matters. If you cannot accept the operational and security burden of a ceremony, restrict your options to transparent systems: STARKs, Halo 2, Plonky3, and SP1.

Step three: evaluate your proof size budget. For direct on-chain verification on Ethereum L1, proof size dominates cost. At 16 gas per calldata byte and a base gas price of 20 gwei, every kilobyte of proof data costs approximately 0.00032 ETH. The 42-kilobyte STARK proof costs roughly 0.013 ETH in calldata alone, compared to 0.00006 ETH for the 192-byte Groth16 proof. If your proofs are verified on L2 or off-chain, proof size constraints relax significantly.

Step four: match your programming model. The tooling ecosystem has bifurcated into circuit-native and zkVM approaches. If your team writes Solidity and is comfortable with circom, Groth16 and PLONK via snarkjs provide the most mature path. If your team writes Rust, SP1 and Risc Zero let you write normal Rust programs and compile them to ZK provable executables — no circuit design required. If you need maximum performance and are willing to write custom gates, Halo 2 and Plonky3 give you full control over the constraint system.

Where to Start Building

The ZK development ecosystem has matured dramatically in 2026. Circom and snarkjs remain the most widely used toolchain for Groth16 and PLONK circuits, with extensive documentation, an audited Solidity verifier generator, and a large library of pre-built circuit components. For teams building privacy-preserving applications on Ethereum, this is the pragmatic starting point.

SP1 has emerged as the fastest-growing zkVM, powering Ethereum light client proofs and cross-chain bridges in production. Its Rust-native programming model dramatically lowers the barrier to entry — you write standard Rust, and the zkVM handles proof generation. For teams that need ZK capabilities without deep cryptographic expertise, SP1 is the most accessible path in 2026.

Halo 2 and Plonky3 serve the performance-critical segment. If you are building a zk-rollup, a high-throughput privacy protocol, or any application where prover speed determines user experience, these systems provide the raw performance that general-purpose zkVMs cannot yet match.

For developers ready to deploy ZK-verified contracts on Ethereum, choosing the right infrastructure is as important as choosing the right proving system. thirdweb provides developer tooling that simplifies smart contract deployment, gas optimization, and on-chain verification — allowing you to focus on your ZK circuit logic rather than infrastructure plumbing. If you are building the next generation of privacy-preserving applications, thirdweb offers developer plans that scale with your project from testnet to mainnet.

The Bottom Line

ZK proofs are no longer a theoretical differentiator — they are table stakes for scalable, privacy-preserving blockchain applications. The benchmark data is clear: Groth16 dominates on proof compactness and verification cost, Plonky3 has caught up on prover speed while being post-quantum safe, and zkVMs like SP1 are democratizing access by letting developers prove computations in Rust rather than building circuits from scratch.

The system you choose should reflect your application's specific constraints: on-chain verification cost, trusted setup tolerance, post-quantum security horizon, and your team's development expertise. There is no universally optimal system — but for any given application, the optimal choice is increasingly clear. The benchmarks and decision framework in this guide give you the data to make that choice with confidence.