The Verification Problem

You built the proof. Now what?

Let's say you've built a ZK application. Your prover runs, the circuit compiles, and you have a valid proof sitting on your machine. It cryptographically confirms that some computation happened correctly without revealing the inputs.

Great. But a proof that nobody checks is worthless.

Someone has to verify it. And that "someone" has historically been Ethereum, which turns out to be a terrible fit for this job.

Why Ethereum struggles with proof verification

Ethereum is a general-purpose blockchain. It was designed to run smart contracts, not to be a verification engine for cryptographic proofs. When you ask it to verify a ZK proof, it does the job, but at a significant cost.

Verifying a single proof on Ethereum consumes between 200,000 and 300,000 gas units depending on the proof type. To put that in perspective: an ERC20 token approval costs 45,000 gas. Most rollup operations take under 300 gas for the same thing. Proof verification sits at an entirely different order of magnitude.

During network congestion, that translates to $20 to $60 per verification. For a single proof in a demo, that is annoying. For a ZK rollup processing thousands of proofs per day, it is a product-ending cost structure.

A peer-reviewed benchmark published at AFT 2024 measured this directly. zkSync Era batches from April to May 2024 showed a median batch verification cost of $18.93 for roughly 3,900 transactions. That is the real number, not a theoretical estimate.

The verification market is estimated to reach $1.5 billion in annual costs by 2028. The current approach does not scale to that.

Most modern zkVMs use STARK-based proving backends. STARKs produce proofs that are too large and too expensive to verify directly on the EVM. So teams have been forced into a workaround: wrap the STARK proof inside a Groth16 proof just to make it EVM-compatible. Both zkSync Era and Polygon zkEVM do this in production today — it is not an edge case, it is the standard approach. That wrapping step adds latency, complexity, and extra proving cost every single time.

There is also a structural constraint that rarely gets discussed. Ethereum standardized around the BN254 elliptic curve. Proof systems that use different curves are either unsupported or prohibitively expensive to verify. Every time a new proving system emerges, teams face the same question: can we even verify this on Ethereum without jumping through hoops?

This is becoming an Ethereum-level problem

What started as a Layer 2 cost issue is now showing up in Ethereum's core roadmap.

Ethereum's 2026 roadmap explicitly conditions gas limit increases on validators moving away from re-executing blocks and toward verifying ZK execution proofs instead. The base layer itself is planning to restructure around proof verification. That means the infrastructure for doing verification well is not a niche concern. It is becoming foundational to how Ethereum scales.

Over $40 billion sits in ZK-based rollups as of early 2025. The ZK proof market was valued at $1.28 billion in 2024 and is projected to reach $7.59 billion by 2033. The demand for verification is growing faster than the current infrastructure can handle it cheaply.

What the right solution looks like

The verification problem needs a purpose-built answer. Not a general-purpose blockchain doing its best, but infrastructure designed from the ground up to do one job well.

That solution needs to be:

Cheap — verification costs should be predictable and low regardless of network congestion elsewhere.

Proof-agnostic — it should support any proving system, not just the ones that happen to fit within EVM constraints.

Decentralized — verification results need to be trustworthy and publicly auditable, not reliant on a single operator.

Composable — the verification result should be usable by any smart contract on any chain, not locked to one ecosystem.

That is exactly what zkVerify was built to be. In the next lesson we will look at what it actually is and how it works.