Economics of Zero-Knowledge Proofs: Why Verification Costs Matter More Than Proof Generation

Good design serves its purpose with nothing unnecessary.

The blockchain industry obsesses over proof generation time. Milliseconds saved. Hardware optimized. Parallelization strategies. This misses what matters.

The prover runs once. The network verifies once. That verification cost is permanent, recorded on-chain forever.

A zero-knowledge proof system is only as efficient as its verification cost.

Everything else is secondary.

The Verification Efficiency Ratio

I propose a simple metric for comparing ZK systems:

VER = (Batch Size ÷ Verification Gas) × 1,000,000

This answers one question: How many transactions can you verify per million gas units?

Higher VER means more efficient verification. As data posting becomes cheaper, VER determines economic viability.

Note: VER is a framework proposed in this article for comparing ZK systems, not an established industry standard.

Why verification dominates

Every zero-knowledge proof system has two cost profiles:

Proving costs (one-time, off-chain):

• -Computational: CPU/GPU cycles
• -Memory: RAM required
• -Time: Latency to proof completion

Verification costs (permanent, on-chain):

• -Gas: Ethereum computation units
• -Calldata: Bytes posted to Layer 1
• -Storage: Persistent state modifications

The proving costs are paid once by the operator. The verification costs are paid by the network—permanently inscribed in the blockchain's economic history.

On Ethereum, where every byte costs gas and every computation replicates across thousands of nodes, verification economics determine viability at scale.

This is not theoretical. This is mathematics governing financial reality.

What verification costs

Based on mainnet deployments:

StarkEx (STARK-based, empirical data):

• -Rollup mode: 315 gas per transaction
• -Total: 94.47M gas across ~300,000 transactions
• -Validium mode: <17 gas per transaction

zkSync (SNARK-based, 2024 estimates):

• -~$0.09-$0.22 per transaction
• -Variable cost depending on batch size
• -Uses recursive SNARK proofs

Polygon zkEVM (SNARK-based, 2024 estimates):

• -~$0.19-$2.75 per transaction
• -Calldata: ~80% of total cost
• -Verification: relatively cheap

The pattern is clear: calldata dominates. The cryptographic verification—validating Merkle proofs, checking polynomial commitments, verifying FRI rounds—consumes relatively little gas.

Most of the cost is posting proof bytes to Ethereum.

For STARKs, verification grows poly-logarithmically with batch size. For SNARKs, verification is constant. Both are dwarfed by the 16 gas per non-zero calldata byte.

The fixed cost reality

Consider a typical ZK verification:

The insight: ~70-80% of costs are fixed, regardless of batch size.

This creates economies of scale:

Note: These figures demonstrate the economic principle of fixed cost amortization. Actual values vary by system implementation.

The verification cost barely increases. You amortize the same fixed overhead across more transactions. The marginal cost of adding one transaction to a batch approaches zero.

Batch size is the most important parameter in ZK economics.

EIP-4844: The phase transition

On March 13, 2024, Ethereum activated EIP-4844, introducing "blob space"—a separate data availability layer priced independently from calldata.

Before EIP-4844:

• -Calldata: 16 gas per non-zero byte
• -Posting 100 KB proof: ~1.6M gas
• -Data availability: 80-95% of total costs

After EIP-4844:

• -Blob space: ~128 KB per blob, separate market pricing
• -Gas cost: ~2-10× cheaper than calldata (market-dependent)
• -Observed reductions: 2-60× cost decrease

Real-world impact (primarily from Layer 2 systems):

• -zkSync: Estimated 2-10× reduction depending on blob market prices
• -Observed L2 cost reductions: 30-60× in some cases

Note: While comprehensive ZK rollup-specific post-EIP-4844 data is still emerging, early evidence suggests significant cost reductions consistent with optimistic rollup observations.

This fundamentally changes ZK economics. The expensive component—data posting—just became dramatically cheaper. The verification logic, already relatively cheap, now dominates the cost structure.

For STARK-based systems, this matters. The larger proof sizes that made STARKs "expensive" are now posted to cheap blob space. The verification gas—which scales poly-logarithmically—becomes the primary cost driver.

The new reality: Verification efficiency matters more than proof size.

STARKs vs SNARKs through the VER lens

The industry debate often focuses on the wrong metrics.

SNARKs:

• -Smaller proof size (~200-400 bytes)
• -Constant verification time
• -Requires trusted setup
• -Lower verification cost for small batches

STARKs:

• -Larger proof size (~100-200 KB)
• -Poly-logarithmic verification scaling
• -No trusted setup (post-quantum secure)
• -Better verification scaling for large batches

The question is not "which is better." The question is: what are you optimizing for?

For small batches (10-50 transactions), SNARKs are cheaper. The constant verification cost is lower than STARK's logarithmic cost for small inputs.

As batch size grows, STARKs' poly-logarithmic scaling becomes compelling. A SNARK verifying 1,000 transactions costs the same as verifying 100. A STARK's verification grows slowly—but the proof generation parallelizes better, and you avoid the trusted setup security assumption.

VER comparison (illustrative framework):

¹Transactions verified per million gas units
²Illustrative approximations for comparison, not specific production measurements

The crossover point depends on your constraint system and batch economics. There is no universal answer. Only tradeoffs.

What this means for builders

If you are building a ZK system, the implications are clear:

1. Optimize verification first

Proof generation can run on specialized hardware, in parallel, off-chain. Verification runs on every Ethereum node. A 10% reduction in verification gas saves more money than a 50% reduction in proving time.

2. Batch size determines viability

The economics do not work for small batches. You need to amortize fixed costs across hundreds or thousands of transactions. Design your system to accumulate sufficient volume.

3. Calldata is now cheap

Post-EIP-4844, do not over-optimize proof size at the expense of verification complexity. A 200 KB STARK proof costs almost nothing to post to blob space. The verification gas matters more.

4. Security assumptions have a price

SNARKs' trusted setup is a security assumption you carry forever. STARKs avoid this with larger proofs and slightly higher verification costs. Choose based on your threat model and economic constraints, not cargo-cult reasoning.

5. The future favors verification efficiency

As Ethereum scales (sharding, verkle trees, future EIPs), data posting will get cheaper. Verification gas costs will remain. Design for the equilibrium, not the current state.

The path forward

The zero-knowledge proof industry is maturing past the research phase. We are now in the engineering phase, where economics determine success.

The systems that will succeed are not necessarily the ones with the fastest provers or the smallest proofs. They will be the systems with the best verification economics—the ones that can process the most transactions per unit of gas consumed.

This requires:

• -Constraint systems designed for verification efficiency
• -Batch aggregation strategies that maximize VER
• -Honest accounting of total costs (verification + calldata + storage)
• -Architectural choices that align with Ethereum's economic roadmap

Good design is as little design as possible. In cryptographic systems, this means: prove off-chain, verify efficiently on-chain.

The verification cost is the cost that matters.

The rest is noise.

Sources & Further Reading

Data Sources:

• -L2Fees.info - Real-time L2 transaction cost tracking
• -StarkWare - StarkEx
• -EIP-4844 - Shard Blob Transactions
• -Etherscan - On-chain gas cost verification

Technical References:

• -Consensys - Zero-Knowledge Proofs: STARKs vs SNARKs
• -Alchemy - SNARKs vs STARKs
• -Nethermind - StarkNet and zkSync: A Comparative Analysis

EIP-4844 Impact Analysis:

• -Consensys - Ethereum Evolved: Dencun Upgrade Part 5 (EIP-4844)
• -Taiko Labs - EIP-4844 Analysis

All gas costs and economic data reflect 2024-2025 mainnet conditions and are subject to change with network upgrades and market dynamics.

Questions about ZK economics or verification optimization?