Every time you bridge assets to an EVM Layer 2 network, you are buying into a promise. The promise is simple: Ethereum security, but at a fraction of the cost. As explained in our guide on Ethereum layer 2 rollups, optimistic rollups work by assuming everyone is honest until proven otherwise. But for zero-knowledge (ZK) rollups, security is active. Every state transition must be proven mathematically on the base layer. This relies heavily on zero knowledge proofs in modern Web3 infrastructure to secure decentralized networks.
This proof verification is not free. In fact, it is one of the most expensive things you can ask the Ethereum Virtual Machine to do. When gas prices spike on Ethereum mainnet, the cost of verifying these proofs goes up too. L2 operators have to pay this gas in ether, and they pass those costs down to their users.
To understand why L2 fees behave the way they do, we have to look at what actually happens when a ZK proof hits the EVM. We need to look at the math, the opcodes, and the gas costs.
The Cost Breakdown of a Verification Transaction
When a ZK rollup operator wants to finalize a batch of transactions, they submit a transaction to a verification smart contract on Ethereum L1. This transaction contains the proof itself and the state updates (often represented as root changes in a Merkle tree; see Merkle trees explained for blockchain developers for how these structures work).
Before EIP-4844, posting data as calldata was incredibly expensive. It cost 16 gas per non-zero byte. With blobs, that cost dropped significantly, but the execution cost of the verification contract remained the same. The EVM still has to perform heavy math to check that the proof is valid.
This math consists of elliptic curve operations. The EVM has to execute additions and scalar multiplications. It also has to run pairing checks. These differ from standard arithmetic operations. They require specialized cryptography, which is why Ethereum has built-in helper contracts called precompiles.
Ethereum Precompiles and the Math of Verification
The EVM is too slow to run complex elliptic curve math in standard bytecode. If you tried to write a pairing check in Solidity and run it as raw EVM execution, it would hit the block gas limit instantly.
To solve this, Ethereum developers introduced precompiles. These are smart contracts hardcoded into the Ethereum client software itself. They run at native speed in Go or Rust, rather than inside the EVM interpreter.
For ZK verification, the most important precompiles are those for the alt_bn128 curve. These were introduced in EIP-196 and EIP-197. They live at specific addresses:
0x06for elliptic curve addition (ecAdd), costing 150 gas.0x07for elliptic curve scalar multiplication (ecMul), costing 6,000 gas.0x08for elliptic curve pairing checks (ecPairing), which costs a base fee of 45,000 gas plus 34,000 gas per point pair.
A typical Groth16 proof verification requires a pairing check with three pairs. That means the pairing precompile alone costs 147,000 gas. When you add the gas for contract overhead, input validation, and reading public inputs, the total verification cost rarely falls below 200,000 gas.
Let's look at a simplified Solidity structure for verifying a Groth16 proof using the ecPairing precompile.
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract Groth16Verifier {
address constant PAIRING_PRECOMPILE = address(0x08);
function verify(
uint256[2] memory a,
uint256[2][2] memory b,
uint256[2] memory c,
uint256[2] memory input
) public view returns (bool) {
// Format the inputs for the pairing precompile
// The precompile expects a series of 6-word (192 byte) coordinates
bytes memory pairingInput = abi.encodePacked(
a[0], a[1],
b[0][0], b[0][1], b[1][0], b[1][1],
c[0], c[1],
input[0], input[1]
);
uint256 size = pairingInput.length;
uint256[1] memory result;
assembly {
// Call the ecPairing precompile
let success := staticcall(
sub(gas(), 2000),
PAIRING_PRECOMPILE,
add(pairingInput, 0x20),
size,
result,
0x20
)
if iszero(success) {
revert(0, 0)
}
}
return result[0] == 1;
}
}This contract directly calls the precompile at address 0x08. If the pairing check succeeds, the precompile returns 1. If the proof is invalid or formatting is incorrect, it returns 0 or reverts.
Comparing Proof Systems: Groth16 vs. PLONK vs. STARKs
Different rollups use different cryptographic proof systems. Each system makes a trade-off between prover time, proof size, and verification gas.
Groth16
Groth16 is the oldest and most gas-efficient system on the EVM. It produces tiny proofs, usually just three group elements. Because the proofs are small, they require very few elliptic curve operations to verify.
A Groth16 verifier contract on Ethereum typically consumes between 200,000 and 230,000 gas. The downside is that Groth16 requires a trusted setup for every single circuit. If you update your L2 smart contract logic, you have to run a new trusted setup ceremony.
PLONK
PLONK solves the trusted setup problem by using a universal setup. You run it once, and you can use it for any circuit up to a certain size. However, PLONK proofs are slightly larger than Groth16 proofs.
Verifying a PLONK proof on Ethereum usually costs between 270,000 and 350,000 gas. For many L2s, this is an acceptable price to pay for the flexibility of updating their code without hosting a new ceremony.
STARKs
STARKs do not use elliptic curves at all. They rely on hash functions. This makes them quantum-resistant and eliminates the need for any trusted setup. The catch is that STARK proofs are massive. While a Groth16 proof is a few hundred bytes, a STARK proof can be tens of kilobytes.
Verifying a STARK proof directly on Ethereum is prohibitively expensive. It can cost millions of gas. To make STARKs viable for L2s, operators use recursive proof generation. They verify multiple STARK proofs inside another STARK proof, eventually producing a single proof that represents thousands of L2 transactions. Starknet and zkSync use variations of this technique to split the massive L1 verification fee across millions of user transactions.
The Impact of EIP-4844 on L2 Economics
Before EIP-4844, the cost of verifying a ZK proof was overshadowed by the cost of posting state differences. L2s had to push all their transaction data to L1 as calldata. If a rollup batch had a thousand transactions, the calldata cost was massive.
With EIP-4844, Ethereum introduced blobs. Blobs are separate data spaces that persist on Ethereum nodes for about two weeks before being pruned. They do not compete with execution gas, which means they are much cheaper.
This changed the economic equation for L2s. The cost of posting data dropped by 90% or more. But the cost of executing the verification contract did not change. The ecPairing check still costs the same amount of execution gas.
As a result, execution gas for proof verification has become a larger percentage of the total L1 cost for ZK rollups. When L1 gas fees spike, the cost of running the verification contract spikes too. This makes verification efficiency more important than ever.
Recursive Proofs and Aggregation
To combat high verification costs, L2 developers have turned to proof aggregation. Instead of submitting a proof for every batch of transactions, they aggregate multiple proofs into one.
Imagine you have ten different batches of transactions. Each batch has its own ZK proof. If you verify them individually, you pay 250,000 gas ten times, totaling 2.5 million gas.
Instead, you can write a ZK circuit that takes those ten proofs as inputs and outputs a single proof. This single proof proves that all ten inputs are valid proofs. When you submit this aggregated proof to Ethereum, the verifier contract only runs once. You pay 250,000 gas instead of 2.5 million.
This technique is called recursive proof verification. It is computationally heavy for the off-chain prover. The prover has to spend more CPU or GPU time generating the recursive proof. But it saves massive amounts of gas on-chain. Since off-chain computation is cheap compared to Ethereum gas, this is a winning trade-off.
Shared settlement layers are taking this a step further. Projects are building specialized layers where proofs from different rollups are aggregated together. A single proof can settle transactions for dozens of independent L2 networks at once, reducing the L1 verification cost per network to a trivial amount.
The Future of EVM Cryptography and EIP-2537
The current precompiles on Ethereum only support the alt_bn128 curve. This curve was chosen years ago, but it is no longer the industry standard for high-performance cryptography.
Modern ZK systems prefer the BLS12-381 curve. It offers a higher security margin and is better suited for recursive proof systems. However, because Ethereum lacks a precompile for BLS12-381, verifying proofs on this curve using EVM bytecode is extremely expensive.
There is a proposal to fix this: EIP-2537. This EIP introduces precompiles for BLS12-381 operations, similar to the existing alt_bn128 precompiles. Once EIP-2537 is activated, rollups will be able to verify modern ZK proofs natively on Ethereum at a reasonable gas cost.
This will open the door for more efficient proof structures, like those used in Halo2 and other advanced proof systems. It will also make recursive proof verification much cheaper, as the curve operations required for recursion will be natively supported by the EVM.
Analyzing the Real-World Costs
Let's look at the actual numbers. If Ethereum gas is at 20 gwei and ETH is priced at $3,000, how much does verification cost?
For a Groth16 verifier costing 220,000 gas:
220,000 * 20 * 10^-9 = 0.0044 ETH
At 3,000 per ETH, this is about 13.20. If gas spikes to 100 gwei, that same verification costs $66.00.
For a PLONK verifier costing 300,000 gas:
At 20 gwei, it costs 0.006 ETH, or 18.00. At 100 gwei, it costs 90.00.
These costs are fixed. It does not matter if the L2 batch contains 10 transactions or 10,000 transactions. The verification cost remains the same.
This explains why ZK rollups sometimes delay submitting batches when L2 activity is low. If they submit a batch with only a few transactions, the cost per transaction becomes incredibly high. They have to wait until there are enough transactions to split the fixed L1 verification cost down to cents per user.
This delay introduces a trade-off between cost and finality. Users want their transactions finalized quickly, but they also want low fees. Rollup operators must balance these competing demands by dynamically adjusting batch sizes and submission intervals based on L1 gas prices.
Prover Costs vs. Verifier Costs
When designing a ZK rollup, engineers cannot look at verification costs in a vacuum. They must also consider prover costs.
Groth16 is cheap to verify on-chain, but generating the proof off-chain requires a lot of memory and CPU power. PLONK is slightly more expensive to verify but offers faster proving times and more flexibility. STARKs have fast proving times and scale well for large batches, but they are expensive to verify on-chain without recursion.
As hardware acceleration improves, the cost of proving will continue to drop. FPGAs and ASICs are being developed specifically to generate ZK proofs quickly and cheaply. But on-chain verification costs are bound by the EVM's gas limits and Ethereum's block space.
This means the bottleneck for ZK rollups will always be on-chain verification. The industry must continue to optimize verifier contracts, push for new precompiles, and adopt recursive proof aggregation to keep L2 networks cheap and scalable.
