Summary: Proof aggregation is now a first‑order lever for reducing rollup settlement costs and confirmation time on Ethereum. With Dencun’s blobs (EIP‑4844), Pectra’s blob‑throughput increase (EIP‑7691), calldata repricing (EIP‑7623), and BLS12‑381 precompiles (EIP‑2537), well‑designed aggregation pipelines routinely cut L1 gas by 10–100x per batch and meaningfully lower latency.

Proof Aggregation Gas Costs for Rollups: How Aggregated Proofs Reduce Fees and Latency

Decision‑makers evaluating L2 strategy today face a different set of constraints than they did even 18 months ago. Posting data to Ethereum is dramatically cheaper after Dencun’s blob market went live, and Pectra (May 7, 2025) further expanded blob capacity and re‑priced calldata to push data workloads out of the execution payload. But crucially, your validity proofs themselves do not live in blobs; they’re verified by EVM contracts and paid as execution gas and calldata. That’s where proof aggregation pays. (blocknative.com)

Below we quantify the gas you can actually budget for, show how aggregation changes both cost and latency, and give concrete patterns we use with clients rolling out L2s and high‑throughput proof systems.

---

1) What changed on Ethereum (2024–2025) and why it matters for proofs

• Dencun (Mar 13, 2024) introduced blobs (EIP‑4844): L2s post DA in a separate “blob gas” market, cutting L2 fees by 90–99% in many cases. Blobs are pruned after ~18 days and price independently from normal gas. (blocknative.com)

• Pectra (May 7, 2025) raised blob throughput (EIP‑7691) from a target/max of 3/6 to 6/9 blobs per block, smoothing fees and greatly increasing daily DA headroom. In parallel, calldata got a floor price for data‑heavy transactions (EIP‑7623), making blob usage the economic default for DA. (eips.ethereum.org)

• Pectra also added BLS12‑381 precompiles (EIP‑2537). Pairing checks and MSMs on BLS12‑381 are now native precompiles, with pairing gas ≈ 37,700 + 32,600·k. This unlocks cheaper on‑chain verification for BLS signatures and BLS‑based SNARK verifiers, and gives higher security than legacy BN254. (eips.ethereum.org)

Why you care as a rollup/operator:

• DA is cheaper and more abundant, so throughput pressures shift toward proving and settlement.
• Calldata floors punish “data‑heavy” transactions, further tilting economics against large on‑chain proof bytes (e.g., raw STARKs) and toward succinct wrapped/aggregated proofs. (eips.ethereum.org)

---

2) Baseline numbers: what a single proof costs on L1 today

When we plan L1 settlement budgets with clients, we start with the verifier’s gas model and calldata size:

• Groth16 on BN254 (post‑EIP‑1108 precompile prices):

  • Pairing check gas ≈ 45,000 + 34,000·k.
  • Empirically: Groth16 verify ≈ 207,700 + 7,160 × l gas, where l is number of public inputs. Most production verifiers land near 230k–300k gas. Proof bytes are tiny (~256–768 B), so calldata is a rounding error vs compute. (eips.ethereum.org)

• Halo2‑KZG aggregation verifiers (as used by shared aggregators) commonly measure ≈ 250k–350k gas per aggregated proof verification on L1. (blog.nebra.one)

• Raw STARK verification on L1 is expensive: 2.5–5.0M gas plus six‑figure‑byte proofs, i.e., hundreds of thousands to millions of gas just for calldata—precisely what EIP‑7623 makes more painful. This is why teams wrap STARKs in a succinct SNARK for L1. (community.starknet.io)

• BLS12‑381 vs BN254: with EIP‑2537 live, a BLS12‑381 2‑pairing check is ≈ 37,700 + 2×32,600 ≈ 102,900 gas—often cheaper per pair than BN254 post‑EIP‑1108, while offering ~128‑bit security. This matters for multi‑signature attestations and some SNARK verifiers. (eips.ethereum.org)

---

3) What “proof aggregation” actually buys you

There are two dominant aggregation patterns that reduce on‑chain costs:

• Recursive accumulation and wrap:

  • Generate many leaf proofs (e.g., per block or per chunk), verify them inside a recursion circuit, then emit a single succinct proof (Groth16/Plonk/Halo2‑KZG) that the verifier contract checks once. On‑chain cost becomes ≈200k–350k gas per batch, largely independent of batch size. (7blocklabs.com)

• Proof packers (e.g., SnarkPack for Groth16):

  • Aggregate n Groth16 proofs off‑chain into an O(log n) proof with O(log n) verifier time, turning “verify thousands” into “verify one” on‑chain. Useful when your leaves are already Groth16 and heterogeneous. (cryptonet.org)

Practical shared-aggregator numbers you can plan around:

• Electron Labs “super‑proof”: ~380k gas fixed to verify the batch; per‑proof inclusion/lookup via a cross‑contract call ≈16k gas, so per‑proof ≈ 16k + 380k/n. (docs.electron.dev)
• NEBRA UPA (Halo2‑KZG): verification ≈350k gas for the aggregated proof; per‑proof bookkeeping currently ≈18k gas and trending down with contract iterations. (blog.nebra.one)

Starknet’s long‑running example (STARK‑level aggregation):

• SHARP posts one big STARK (“train”) to L1 for many jobs; fixed cost ≈6M gas per train and ≈215k gas of fixed costs per L2 block. Upcoming “applicative recursion/SNAR trees” aims to further amortize fixed per‑block costs. While not EVM verification, it’s a concrete data point for how aggregation shifts economics. (community.starknet.io)

---

4) Cost modeling: three concrete scenarios with numbers

Use the following to size fees and to set internal SLOs for batch frequency and confirmation time.

A) ZK rollup settling every 2 minutes with recursive wrap (Groth16)

• Assumptions:
  • One succinct Groth16 per L2 batch, l = 6 public inputs (roots, bounds).
  • Verify gas ≈ 207,700 + 7,160×6 ≈ 250,660 gas.
  • Calldata for the SNARK ≈ 512 bytes; even if a data‑heavy floor applies, that’s ≈ 512×40 = 20,480 gas worst case; in practice, transactions with real execution often stay at 4/16. (hackmd.io)
• If you post 30 batches/hour, L1 settlement burn is ≈ 30 × 270k ≈ 8.1M gas/hour.
• At 20 gwei base gas, ETH=$2,500: ≈ 8.1M × 20e‑9 × 2,500 ≈ $405/hour—a cost you can amortize across all L2 transactions in those batches.

B) App rollup verifying many user proofs via a shared aggregator

• Assumptions (Electron‑style):
  • Aggregated batch verify: 380k gas; inclusion proof per user: 16k gas.
  • Batch size n = 512 user proofs.
• Per‑proof L1 cost ≈ 16k + 380k/512 ≈ 16k + 742 ≈ 16,742 gas—an order‑of‑magnitude reduction vs verifying 230k–300k gas per user proof directly on‑chain. (docs.electron.dev)

C) “Don’t do this” baseline: raw STARK on L1

• Single STARK verify 2.5–5.0M gas + 100–200 kB of calldata. With EIP‑7623’s calldata floor for data‑heavy posts, your calldata alone can cost 0.4–3.2M gas. That’s 10–30× a succinct wrap/verify. Unless your L1 has a FRI/hash precompile, wrap the STARK. (community.starknet.io)

---

5) Latency: aggregation reduces the number of L1 inclusions and queueing

Aggregation changes the critical path in two ways:

• Fewer on‑chain operations. One proof verification per batch instead of hundreds/thousands reduces mempool contention and the risk that some leaves spill to the next block. Even at 12s block times, “one proof per batch” tends to stabilize time‑to‑finality. Shared aggregators report constant verify time on‑chain (≈250–380k gas) and fast inclusion under normal conditions. (blog.nebra.one)

• Off‑chain prover parallelism. Modern stacks parallelize leaf proving and do recursion in a tree; folding/IVC systems (Nova/HyperNova) offer O(1) incremental step cost and finalize with a small compression SNARK—useful for steady streams (bridges, oracles). Succinct reports production‑grade real‑time proving on commodity GPUs, making frequent batch proof publication viable. (7blocklabs.com)

Net: you trade some off‑chain compute for fewer, predictable L1 verifications—lowering both average and tail latencies.

---

6) Best emerging practices we recommend (2026 edition)

1. Keep public inputs tiny
   Minimize l in Groth16/Plonk. Every public input adds ≈7.1k gas; hash large statements into one field element. Where you need per‑proof inclusion, store commitments and let consumers verify inclusion off‑chain or via succinct lookups. (hackmd.io)

2. Prefer succinct wrappers for L1, especially post‑EIP‑7623
   Given calldata floors for data‑heavy transactions, avoid posting large proof bytes on L1. Wrap STARKs in SNARKs; treat big proofs as an internal format, not an L1 deliverable. (eips.ethereum.org)

3. Use BLS12‑381 precompiles when signatures or verifiers allow
   With EIP‑2537, multi‑pairing checks and MSMs on BLS12‑381 are cheaper and higher‑security than BN254. This is particularly relevant for bridge committees, DA attestations, and SNARK verifiers that can target BLS curves. (eips.ethereum.org)

4. Choose your aggregation topology deliberately

• Recursive tree + final SNARK: best for high‑throughput rollups; on‑chain verify ~200–350k gas once per batch. (7blocklabs.com)
• SnarkPack‑style packers: great when you already produce many Groth16s for heterogeneous statements. (cryptonet.org)
• Shared aggregators (Electron/UPA): lowest integration lift if you’re an app consuming user proofs; expect ~16–20k gas per user inclusion plus one ~350–380k gas batch verify. (docs.electron.dev)

1. Right‑size the batch to balance fees and UX

• Bigger batches amortize the fixed ~250–380k gas, but add proving latency. For user‑facing apps, we see sweet spots at 32–512 leaves; for rollups, 1–2 minute batch intervals with recursion provide good UX/cost trade‑offs. Use moving windows: shrink batches during spikes to keep tail latency bounded. (blog.nebra.one)

1. Budget blobs separately from proof verification
   Post‑Pectra, target 6 blobs/block and max 9 means ≈5.3–7.9 GiB/day capacity. Blob fees tend to be “near floor” when network usage is below target. Verify once per batch; keep blobs for DA. Don’t rely on calldata as a fallback except during short blob spikes. (eips.ethereum.org)

2. Plan for 2025–2026 fee dynamics
   As clients adopt EIP‑7623 and blob limits increase, expect further divergence: blobs get cheaper, calldata floors bite more for DA‑like usage. Aggregation that minimizes calldata (small SNARKs, tiny public inputs) ages well under these rules. (eips.ethereum.org)

---

7) Example playbooks

A) OP Stack chain modernizing to ZK proofs

• Target: one succinct proof per L2 block or per few blocks.
• Design:
  • Leaf: zkEVM or zkVM traces per block.
  • Recursion: Halo2‑KZG or equivalent; wrap in Groth16/Plonk.
  • On‑chain: single ~250–350k gas verify per batch; blob(s) carry DA.
• Outcome: material L1 savings vs verifying multiple leaves; faster finality than fault‑proof windows; blob costs low after EIP‑7691. Providers like Succinct report production‑grade throughput to support this path. (blog.succinct.xyz)

B) Cross‑chain oracle updates every block

• Without aggregation: thousands of individual proof or signature verifications per hour; on‑chain cost and queueing explode.
• With aggregation:
  • Aggregate signatures with BLS12‑381 and verify with 2 pairing checks (~103k gas) per destination chain; or
  • Aggregate ZK attestations into one Halo2‑KZG or Groth16 proof (~250–350k gas).
• Outcome: sub‑block inclusion most of the time, smoother tail latency, predictable budget. (eips.ethereum.org)

C) App that accepts user proofs (KYC, ML, computation)

• Plug into a shared aggregator:
  • Post user proofs on‑chain or off‑chain to the aggregator.
  • Pay ~16–20k gas per user inclusion; aggregator posts one ~350–380k gas proof regularly.
• This routinely cuts per‑user verification gas by ~10×–15× vs direct on‑chain verifies. (docs.electron.dev)

---

8) “Are we leaving money on the table?” The quick audit checklist

• Are we verifying more than one proof per L2 batch on L1? If yes, aggregate.
• Are our public inputs minimal? Hash bulky inputs to a single field element. (hackmd.io)
• Are we still posting big proof bytes in calldata? Move to succinct wraps; keep calldata tiny. (eips.ethereum.org)
• Could BLS12‑381 precompiles reduce our on‑chain checks? Migrate from BN254 where feasible. (eips.ethereum.org)
• Is our batch size tuned to our UX SLOs? If latency spikes, reduce n and use a rolling window. (blog.nebra.one)
• Are we using blobs for DA in all normal cases? After EIP‑7691, treat calldata only as emergency relief. (blog.ethereum.org)

---

9) Putting it together: a budgeting formula you can take to finance

Let:

• Gbatch = fixed gas to verify an aggregated proof (≈ 250–380k).
• Gincl = per‑proof inclusion/lookup gas if you need on‑chain inclusion (≈ 16–20k).
• n = proofs per batch.

Then:

• Per‑proof L1 gas ≈ Gincl + Gbatch / n.
• If you verify one SNARK per L2 batch with no per‑user inclusions, your per‑batch cost is just Gbatch.

Example: n = 512, Gbatch = 350k, Gincl = 18k → per‑proof ≈ 18,684 gas—often >10× cheaper than direct 230–300k gas per proof verifies. (blog.nebra.one)

---

10) Why this matters more after Pectra

• More, cheaper blobs (EIP‑7691) shift the bottleneck from DA to proof/settlement.
• Calldata floors (EIP‑7623) penalize large on‑chain proof bytes, pushing toward succinctness.
• BLS12‑381 precompiles (EIP‑2537) make aggregated signature/attestation and some SNARK verifiers cheaper, widening the design space for bridges, light clients, and multi‑chain rollups. (blog.ethereum.org)

In short: Aggregation isn’t just academic polish—it’s the practical path to lower fees and faster time‑to‑finality on Ethereum in 2026.

---

11) How 7Block Labs can help

• Cost modeling and architecture: We benchmark your current verifier costs and design an aggregation plan with concrete gas/latency targets.
• Migration playbooks: BN254→BLS12‑381 migration, public‑input minimization, and recursion trees tailored to your stack.
• Integration: Plug‑and‑play with shared aggregators (Electron/UPA) or bespoke aggregation contracts for your rollup/app.

If you want a quick readout, we’ll deliver a 2‑page memo with:

• Your modeled per‑batch gas at three batch sizes (e.g., 64/256/1024),
• Latency SLO recommendations under 12s/24s/60s block‑finality assumptions, and
• A phased plan to hit your cost and UX targets.

---

Sources and further reading

• Dencun and blobs (EIP‑4844) and impacts on L2 fees; blob mechanics and pricing. (blocknative.com)
• Pectra mainnet; blob throughput increase (EIP‑7691) and rationale; blob fee responsiveness; capacity math. (blog.ethereum.org)
• Calldata repricing (EIP‑7623) and motivation. (eips.ethereum.org)
• BLS12‑381 precompiles (EIP‑2537) and gas for pairing/MSM. (eips.ethereum.org)
• Groth16 verification gas formula; BN254 pairing costs after EIP‑1108. (hackmd.io)
• Halo2‑KZG aggregator (UPA) gas; Electron super‑proof gas. (blog.nebra.one)
• STARK vs SNARK economics and SHARP costs. (community.starknet.io)

Need a tailored model for your chain or app? 7Block Labs can run the numbers on your exact circuits, batch cadence, and traffic patterns and ship an implementation plan in under two weeks.