Proof systems are usually introduced through their trust assumptions, which matters enormously to a cryptographer and only indirectly to the person paying the gas bill. On a public chain the recurring cost is not the ceremony; it is the bytes that have to be published and the arithmetic the verifier contract has to run, once, for every single user, forever.
A Groth16 proof is tiny, roughly 200 bytes regardless of how large the statement is, and verification is a handful of pairing checks. That combination gives the lowest on-chain verification cost available today, around 180000 gas on a typical EVM chain, and it is why early rollups and privacy applications converged on it. The setup, however, is per circuit: change the program and you must run a new ceremony with new toxic waste that must be destroyed.
The proof you publish is a recurring per-user cost, while the trusted setup is a one-off organisational cost, and mixing the two is the most common error in this comparison.
Part One: What is actually being compared
Strip the marketing away and the question in on-chain proof verification reduces to a threshold. Below a certain scale, transparent STARK-style proofs is cheaper because it avoids a commitment; above it, Groth16 with a per-circuit trusted setup wins because the commitment is amortised. Everything else in the debate is about where that threshold sits and how confident you are that the workload will stay on one side of it.
A useful way to see the trade is to ask which cost survives a bad quarter. Under Groth16 with a per-circuit trusted setup the committed cost stays even when utilisation collapses, so the effective unit price rises exactly when demand is weakest. Under transparent STARK-style proofs the cost falls with use, which is more comfortable operationally but removes the incentive to build spare capacity ahead of time.
Part Two: The arithmetic that decides it
Transparent systems remove the ceremony entirely and use public randomness plus hash-based commitments. The trade is size: proofs grow to tens or hundreds of kilobytes, and verification involves many hash operations rather than a few pairings. Publishing that much data is expensive on a chain where calldata is priced by the byte, and the gas cost of the verifier scales with the number of queries the soundness argument requires.
One second-order effect deserves its own line. Once Groth16 with a per-circuit trusted setup is deployed, teams begin designing around the property it makes cheap, and that induced demand can consume the entire saving within a couple of planning cycles. The same thing happens in reverse with transparent STARK-style proofs: a constraint that looks like a limitation often acts as a useful discipline, because it forces the design to stay inside a budget that everyone can see.
Part Three: Where the simple model breaks
This is where the analysis usually stops, but the cost structure has a second term that is easy to miss. A per-circuit setup creates organisational friction: every upgrade needs coordination, participants, an audit trail and a window in which the old circuit is still live. A transparent system can ship a program change like any other code change. For a product iterating weekly, that governance overhead can outweigh a 45 percent higher per-verification gas bill.
A 200-byte proof verified in about 180000 gas looks unbeatable until a 45 percent higher gas bill is weighed against a ceremony for every circuit revision.
Part Four: The cost that arrives later
Recursion changes the comparison again. Wrapping a large transparent proof in a small final proof compresses the on-chain payload while keeping transparency for the inner statement, at the price of an extra proving step off-chain. Off-chain compute is cheap and getting cheaper; on-chain bytes are scarce and getting relatively more expensive. Any comparison that ignores the direction of that price ratio will pick the wrong system two years from now.
The adoption curve is likely to be S-shaped and gated by tooling, not by the core technology. The physics or the algorithm is already good enough; what is missing is the boring layer of monitoring, migration and default configurations that lets an ordinary team choose Groth16 with a per-circuit trusted setup without hiring a specialist. That layer is usually what separates a conference result from a procurement line.
Part Five: What this changes outside the engineering team
The honest conclusion is that these are not two points on one quality scale. They are different allocations of cost across time and across parties: one front-loads a one-off coordination cost and minimises every future user's bill, the other removes coordination and charges each verification a little more. Which is cheaper depends on how many verifications you expect and how often the circuit changes.
Think of a prepaid transit card versus paying per ride with a phone. The card is cheaper per trip but requires a counter, an issuance process and a replacement when the design changes; the phone costs a little more each time and needs no counter at all. High-frequency commuters and occasional visitors should not be given the same advice.
A market sizing sanity check
On-chain verification and data-availability fees across rollups and privacy applications already amount to a multi-billion-dollar annual flow, while proving hardware and prover services are a much smaller but faster-growing market near 1 to 2 billion dollars. If proof-carrying applications reach mainstream volume by 2030, the split between verifier gas and prover compute plausibly becomes a 5 to 10 billion dollar annual allocation question, decided largely by proof size and upgrade cadence.
All figures here are an author's synthesis of published ranges and a stated model, not a measurement of a shipped system. The point of the arithmetic is to locate the crossover and expose which assumption drives it; a vendor quote will differ, and the direction of that difference is more informative than the final number.
The comparison that matters
Groth16 minimises the recurring user cost and charges a one-off coordination tax per program change. Transparent proofs eliminate the ceremony and charge extra bytes and gas on every verification. Pick by multiplying your expected verification count by the byte price, then adding the cost of every circuit upgrade you plan to make.
It is worth stating what would reverse this conclusion. If the cost of the scarce input falls sharply, or if a standard emerges that removes the integration overhead, the balance tips toward Groth16 with a per-circuit trusted setup far faster than a linear extrapolation suggests. Conversely, a single reliability incident in transparent STARK-style proofs can move the decision back by years, because trust is accumulated slowly and spent all at once.
As off-chain proving gets cheaper and on-chain bytes stay scarce, recursion that compresses the final payload becomes the economically obvious move.
SOL: HCqPmPJM3NVtS6YrmVaTZYnuP8XZ2PFgQZKT94VK1LkS
Creating this takes real effort — thank you for the support.
Top comments (0)