Two proof systems sit behind most of the zero-knowledge work shipping today: zk-SNARKs and zk-STARKs. Both let a prover convince a verifier that a computation was carried out correctly, without revealing the private inputs. Both are non-interactive. Both can be zero-knowledge. The differences that actually matter to engineers show up in three places: how many bytes a proof costs, how much work the verifier does, and what you have to trust for the whole thing to hold together.
Those three properties shape your architecture far more than the acronyms do. Here is the breakdown, with the practical consequences attached.
A zk-SNARK is a Succinct Non-interactive ARgument of Knowledge. A zk-STARK is a Scalable Transparent ARgument of Knowledge. Note that both are arguments rather than proofs in the strict cryptographic sense: soundness holds against computationally bounded adversaries, not against an adversary with unlimited computing power.
The words that carry weight are succinct versus scalable, and transparent. Succinct means proof size and verification time stay tiny relative to the size of the computation. Scalable means proving time grows roughly quasi-linearly with the computation, and verification grows only polylogarithmically. Transparent means there is no trusted setup ceremony required — a public random string is enough.
SNARKs produce constant-size proofs. Whether your circuit has ten thousand constraints or ten million, the proof is typically a few hundred bytes. That compactness comes from elliptic-curve-based polynomial commitment schemes such as KZG, or from inner-product arguments.
STARK proofs grow logarithmically with the computation. For realistic circuits, expect tens to hundreds of kilobytes. The reason is that STARKs commit to polynomials using hash-based techniques, and the verifier needs more opening data to be convinced.
Why should you care?
SNARK verification is constant and small: a handful of pairings and field operations, regardless of how big the underlying statement was. On Ethereum, verifying a Groth16 proof has long sat in the low hundreds of thousands of gas, with PLONK-style verifiers costing somewhat more because of their larger proof and setup structure.
STARK verification also stays cheap compared to re-executing the computation, but it does grow with the logarithm of the computation size and involves more hashing. For very large statements, a STARK verifier will cost more than a SNARK verifier.
Proving is usually the real bottleneck. STARK proving is dominated by hash functions, which parallelize well across GPUs. SNARK proving leans on multi-scalar multiplications and large FFTs over elliptic-curve fields. The gap is not fixed: implementation quality, field choice, and hardware often matter more than the family name. Benchmark on the machines you will actually run before committing to either.
This is where the two diverge most sharply.
Transparency removes the ceremony, not the assumptions. You still trust a hash function, a field, and a model of randomness.
Read the security section of any library's documentation before you adopt it. "Transparent" and "no trusted setup" are not the same as "no trust assumptions," and abstract threat models rarely match the deployment you have in mind.
FRI-based transparent SNARKs exist. Universal and updatable setups cut the cost of ceremonies. Lattice-based post-quantum SNARK constructions are an active research area. Folding schemes like Nova reduce prover work for incremental computation, and prove the point that the label on the box matters less than the properties inside it.
When you evaluate a system, ask four questions instead of one: what is the setup, what are the cryptographic assumptions, how large is the proof, and how expensive is verification in my target environment? That framing survives whatever the next round of naming conventions brings.
Write your circuit or program first, then measure. Constraint count, field choice, and the shape of your witness data will tell you more than any comparison table. Pick two candidate stacks, run the prover on hardware comparable to production, and record proof generation time, proof size, and verifier cost. Check the tooling: is the library maintained, are the security assumptions documented, has it been audited, and can you reproduce the setup parameters?
Then build the smallest end-to-end prototype you can: one proof, one verifier, one realistic input. Most regrets in this space come from choosing a system before understanding the workload. Proof systems are difficult to swap out later, so spend a day measuring rather than a month migrating.
Photo: congerdesign / Pixabay
