zk-SNARKs vs zk-STARKs: What Benchmark Data Shows About Speed, Size, and Quantum Risk

Verifying that a computation ran correctly, without re-running it and without trusting whoever ran it, used to force a choice between speed and transparency. Two zero-knowledge proof systems now split that choice in opposite directions, and a December 2025 benchmark study puts real numbers on what each side gives up, though not every number in the literature agrees.

What a SNARK Proof Costs That a STARK Proof Doesn't

zk-SNARKs (the Groth16 construction, specifically) and zk-STARKs both let a prover convince a verifier that a statement is true without revealing the underlying data. They diverge on how that proof gets built and what it costs to check.

An implementation-level comparison run on a consumer-grade ARM platform reported zk-SNARK proofs generating 68 times faster than zk-STARK proofs, at 123 times smaller size, and recorded its zk-SNARK proofs as verifying slower on that platform. That verifier-time reading runs against the more commonly reported behavior of Groth16-style SNARKs. A separate comparative table built for a decentralized-identity framework paper describes SNARK verification as near-constant, because a Groth16 verifier checks only a small, fixed number of pairing operations regardless of circuit size, while STARK verification is polylogarithmic and slower in absolute terms, since it has to check many FRI queries and Merkle authentication paths, even though it scales better into very large circuits. The two sources disagree specifically on this point. The ARM study's proving-speed and proof-size numbers line up with the wider literature; its verifier-time result looks like an artifact of that particular implementation and circuit size, not a reversal of Groth16's well-established fast, cheap verification.

That same decentralized-identity paper's table adds the scaling detail worth keeping alongside the correction above: SNARK proof size holds near-constant at roughly 100 to 200 bytes regardless of computation complexity, while STARK proof size grows logarithmically into the tens of kilobytes. SNARK prover time is super-linear and gets expensive fast on complex computations; STARK prover time is quasi-linear and tends to close the gap, or overtake it, as circuits scale into millions of gates, since STARK proving leans on hardware-friendly FFT-style computation rather than the heavier multiscalar multiplication SNARK proving depends on.

The trusted-setup gap is the part developers weigh most. SNARKs require a Structured Reference String generated through a multi-party "Powers of Tau" ceremony; if a participant fails to destroy their portion of the secret parameters, that leftover "toxic waste" could be used to forge valid-looking proofs. STARKs skip that ceremony entirely, deriving their public parameters from verifiable randomness instead.

Quantum resistance follows a similar split, and it's where the two systems' underlying math actually matters. SNARKs rely on elliptic-curve pairings, carrying the same long-run quantum exposure already examined in an earlier comparison of RSA and elliptic-curve key strength. STARKs rely on collision-resistant hash functions instead, and no efficient quantum attack against that assumption is currently known.

How a ZK-Rollup Turns That Tradeoff Into Cheaper Transactions

A ZK-Rollup is where the proof-size difference stops being academic. A sequencer collects thousands of individual transactions off-chain, orders them, and batches them together. Rather than replaying every transaction on Ethereum's base layer, a prover generates one succinct validity proof attesting that the entire batch executed correctly, and only that proof plus compressed transaction data gets posted to Ethereum's Layer 1.

Verifying a zero-knowledge proof on Ethereum Mainnet costs approximately 500,000 gas. That figure covers the full on-chain verification step, including any proof-wrapping or aggregation logic and the calldata needed to update the state root, not the cost of a single pairing check in isolation. That fixed verification cost, combined with data compression rather than simply moving computation off-chain, is what actually drives the fee reduction users see. And because the proof is a mathematical guarantee rather than an assumption open to dispute, ZK-Rollups skip the multi-day challenge window that optimistic rollups rely on: once Ethereum accepts the validity proof, the batch is final and withdrawals clear at the next block.

Which proof system a rollup uses shapes what gets posted at that fourth step. zkSync Era and Polygon zkEVM lean on SNARK-style succinctness, where the compact proof keeps L1 verification cheap. Starknet uses STARKs through its Cairo language and StarkWare's SHARP prover, but it doesn't post a raw STARK proof to Ethereum: SHARP recursively aggregates and wraps the STARK proof into a smaller succinct layer before submission, since posting a full STARK proof running tens of kilobytes would cost far more L1 calldata gas than the network's economics reward.

Selective Disclosure Outside Blockchains: Identity, Health Records, and Compliance

The same underlying trick, proving a fact without revealing the data behind it, shows up wherever an organization needs to verify a claim without collecting more information than it needs.

In decentralized identity systems built on W3C Verifiable Credentials, a ZKP lets a person prove they are over 18 without disclosing their date of birth, or prove they passed a KYC check without handing over the underlying documents each time. That selective-disclosure property is the specific reason ZKPs, rather than plain digital signatures, keep coming up in identity architecture: a signature proves a document is authentic, but it still reveals the whole document.

In healthcare, published research describes ZKP-based anonymous authentication for patients moving across public and private blockchains, letting a diagnostic specialist confirm a patient's identity and access rights without exposing the medical record itself. A related academic-credential verification system, built on zkEVM smart contracts and decentralized identifiers, lets an employer confirm a degree is genuine without the university disclosing the full transcript.

In corporate finance, a joint Deutsche Bank and Nethermind report names four live use cases: private on-chain transactions that keep trading positions confidential while still proving compliance, KYC and AML verification through verifiable credentials rather than raw documents, Proof of Reserves, and general blockchain scaling. Binance's proof-of-reserves system compresses customer account balances into a single Merkle-tree commitment, letting the exchange prove total client assets match total liabilities without revealing any individual balance. Mina Foundation and Mirae Asset Group have built a proof of concept, STOPE, for issuing tokenized securities under the same logic: preserve the confidentiality of who owns what while still satisfying a regulator's disclosure requirements. The report ties the timing to two regulatory shifts specifically, the EU's eIDAS 2.0 verifiable-credential framework and the US GENIUS Act's stablecoin rules, both of which push institutions toward proof-based reporting instead of handing over bulk data.

Why zk-STARKs Haven't Displaced zk-SNARKs Despite the Quantum Argument

STARKs are transparent and quantum-resistant, and SNARKs are neither. On paper that should settle the question. In practice, most L1-anchored rollups still lean on SNARK-style succinctness for their final on-chain proof, and the proof-size numbers above point to a structural reason why: Ethereum's on-chain verification and data-availability costs scale with how much proof and calldata actually gets posted, and a native SNARK proof at 100 to 200 bytes costs far less to post than a raw STARK proof running tens of kilobytes.

Starknet's SHARP prover shows how STARK-based systems work around that cost rather than eliminate the tradeoff: it keeps STARK's transparent, quantum-resistant proving off-chain, then recursively wraps the result into a smaller succinct proof for the actual L1 submission. That closes most of the raw size gap, but it also means the proof Ethereum ultimately checks inherits whatever properties its final wrapping layer has, which is worth confirming case by case rather than assuming "STARK-based" and "quantum-resistant all the way to L1" mean the same thing. Whether recursive wrapping fully resolves the tradeoff, or just relocates it, is still an open design question that depends on how much weight a given system puts on hedging against a cryptographic risk that hasn't arrived yet.