Summary: Proof aggregation has become a key player in bringing down rollup settlement costs and speeding up confirmation times on Ethereum. Thanks to Dencun’s blobs (EIP‑4844), Pectra’s boost in blob throughput (EIP‑7691), the updates to calldata pricing (EIP‑7623), and the BLS12‑381 precompiles (EIP‑2537), smartly crafted aggregation pipelines are now consistently slashing L1 gas usage by 10 to 100 times per batch, while also significantly reducing latency.

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

Decision-makers looking into L2 strategy today have a whole new set of challenges compared to just 18 months ago. Thanks to Dencun’s blob market going live, posting data on Ethereum has gotten a lot cheaper. Plus, with Pectra's update on May 7, 2025, we saw an increase in blob capacity and a re-pricing of calldata, which helps get those data workloads out of the execution payload.

But here’s the kicker: your validity proofs don’t actually reside in blobs. They’re verified by EVM contracts, and you still have to pay for them using execution gas and calldata. This is exactly where proof aggregation really shows its value. You can read more about it over at blocknative.com.

Below, we break down the gas you can realistically plan for, highlight how aggregation impacts both costs and latency, and share some specific patterns we’ve used with clients launching L2s and high-throughput proof systems.

---

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

• On March 13, 2024, Dencun rolled out blobs (EIP‑4844), which is a game changer! Now, Layer 2s can post Data Availability (DA) in a separate “blob gas” market, leading to a whopping 90-99% drop in L2 fees in many situations. These blobs are pruned after about 18 days and their pricing works independently from regular gas. Check out more details here: (blocknative.com)
• Pectra (May 7, 2025) upped the blob throughput (EIP‑7691) from a target/max of 3/6 to 6/9 blobs per block. This change not only helped smooth out fees but also significantly boosted the daily DA capacity. At the same time, calldata got a minimum price tag for those data-hungry transactions (EIP‑7623), making it more economical to go with blobs for DA. (eips.ethereum.org)
• Pectra has introduced BLS12‑381 precompiles (EIP‑2537). Now, pairing checks and multi-scalar multiplications (MSMs) on BLS12‑381 are included as native precompiles, with pairing gas costs coming in at around 37,700 + 32,600·k. This means cheaper on-chain verification for BLS signatures and BLS-based SNARK verifiers, plus it offers better security compared to the older BN254. Check out more details on this EIP here.

Why You Should Care as a Rollup/Operator:

• Decentralized Applications (DA) are getting cheaper and more available, which means that the focus is shifting towards proving and settling transactions more efficiently.
• With the rise of calldata floors, “data-heavy” transactions are facing penalties, making it less financially viable to rely on large on-chain proof bytes (like raw STARKs). Instead, there's a growing trend towards using succinct wrapped or aggregated proofs. Check it out here: (eips.ethereum.org)

---

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

When we're putting together L1 settlement budgets with our clients, we kick things off by looking at the verifier’s gas model and the size of the calldata:

• Groth16 on BN254 (right after EIP-1108's precompile pricing):
  • For the pairing check, you're looking at about 45,000 gas plus an extra 34,000 multiplied by k.
  • In practice, when you verify Groth16, it typically uses around 207,700 gas plus 7,160 times l, where l represents the number of public inputs. Most production verifiers usually sit somewhere between 230k and 300k gas. The proof bytes are pretty compact (roughly 256 to 768 B), so the calldata is almost negligible compared to the compute. (eips.ethereum.org)
• When it comes to Halo2‑KZG aggregation verifiers, which are the same ones shared by aggregators, they usually clock in at around 250k to 350k gas for verifying each aggregated proof on L1. You can check out more details here.
• Verifying raw STARKs on L1 can really hit your wallet hard, costing around 2.5-5.0M gas. On top of that, you’ve got these huge proof sizes, often in the six-figure-byte range. That means you're looking at hundreds of thousands to even millions of gas just for calldata--definitely not ideal, especially with how EIP‑7623 makes things even trickier. That's why many teams are opting to wrap STARKs in a more compact SNARK for L1. (community.starknet.io)
• BLS12‑381 vs BN254: Now that EIP‑2537 is live, a BLS12‑381 2-pairing check costs around 37,700 + 2×32,600, which comes out to roughly 102,900 gas. That’s often cheaper per pair compared to BN254 after EIP‑1108, all while providing about ~128-bit security. This is super important for multi-signature attestations and certain SNARK verifiers. Check it out here: (eips.ethereum.org)

---

3) What “proof aggregation” actually buys you

There are two main aggregation patterns that help cut down on on-chain costs:

• Recursive accumulation and wrap:
  • You can create a bunch of leaf proofs--like for each block or chunk--then check them out in a recursion circuit. After that, you get to spit out a single slick proof (using Groth16/Plonk/Halo2‑KZG) that the verifier contract looks over just once. This keeps the on-chain cost pretty steady at around 200k-350k gas per batch, no matter how big that batch is. (7blocklabs.com)
• Proof packers (like SnarkPack for Groth16):
  • Combine n Groth16 proofs off-chain into a single proof that takes O(log n) time to verify, making it possible to go from “verify thousands” to just “verify one” on-chain. This is super handy when your leaves are already Groth16 and vary in nature. (cryptonet.org)

Here are some practical numbers for shared-aggregator planning that you might find helpful:

• Electron Labs “super-proof”: To verify the entire batch, we're looking at about 380k gas. If you're doing a per-proof inclusion or lookup with a cross-contract call, that’ll run you around 16k gas. So, each proof comes out to roughly 16k + 380k/n. Check out more details here.
• NEBRA UPA (Halo2-KZG): For the aggregated proof verification, you’ll need about 350k gas. Right now, the cost for bookkeeping per proof is sitting at around 18k gas, but that number is on a downward trend as the contracts get refined. For more info, head over to this blog post.

Starknet has a great example when it comes to STARK-level aggregation:

• SHARP publishes one big STARK, which is like a “train,” to L1 for numerous jobs. The fixed cost for this is around 6M gas per train and about 215k gas for fixed costs each L2 block. They've got something on the horizon called “applicative recursion/SNAR trees,” which is looking to reduce those fixed per-block costs even more. While it's not exactly EVM verification, it does give us a solid insight into how aggregation can impact economics. (community.starknet.io)

---

4) Cost modeling: three concrete scenarios with numbers

Use the information below to determine fees and establish internal service level objectives (SLOs) for how often batches should run and the time it takes to confirm them.

A) ZK Rollup Settling Every 2 Minutes with Recursive Wrap (Groth16)

• Assumptions:
  • We’re using one concise Groth16 for each L2 batch, with ( l = 6 ) public inputs (roots, bounds).
  • The gas cost for verification is roughly ( 207,700 + 7,160 \times 6 \approx 250,660 ) gas.
  • Calldata for the SNARK is around 512 bytes; even if we hit a data-heavy floor, it’s about ( 512 \times 40 = 20,480 ) gas at most. But in reality, transactions with actual execution usually hover around 4/16. (hackmd.io)
• If you’re posting 30 batches an hour, the L1 settlement burn comes out to be around ( 30 \times 270k \approx 8.1M ) gas per hour.
• At a 20 gwei base gas price and ETH at $2,500, that’s about ( 8.1M \times 20e^{-9} \times 2,500 \approx $405 ) an hour. Not too shabby, right? You can spread that cost across all L2 transactions in those batches.

B) App Rollup Verifying Multiple User Proofs Through a Shared Aggregator

• Assumptions (Electron-style):
  • When we aggregate, we’re looking at a batch verification cost of about 380k gas, while each user’s inclusion proof adds another 16k gas.
  • Let’s consider a batch size of n = 512 user proofs.
• Per-proof L1 cost: Roughly calculated, we get about 16k + 380k/512 ≈ 16k + 742 ≈ 16,742 gas. This is a significant drop compared to verifying each user proof directly on-chain, which can range from 230k to 300k gas. (docs.electron.dev)

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

• A single STARK verification munches through about 2.5-5.0M gas and takes up 100-200 kB of calldata. With EIP‑7623 putting a minimum on calldata for data-heavy posts, just your calldata could set you back anywhere from 0.4 to 3.2M gas. That’s a whopping 10 to 30 times more than a succinct wrap/verify! If your L1 doesn’t have a FRI/hash precompile, you're better off wrapping the STARK. (community.starknet.io)

---

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

Aggregation alters the critical path in a couple of key ways:

• Less on-chain action. Instead of dealing with hundreds or thousands of proof verifications, we only have one per batch. This cutback really helps with mempool congestion and lowers the chances of some leaves getting pushed to the next block. Even with block times around 12 seconds, doing “one proof per batch” usually makes the time-to-finality pretty steady. Shared aggregators show a consistent verification time on-chain (about 250-380k gas) and quick inclusion when everything’s running smoothly. (blog.nebra.one)
• Off‑chain prover parallelism. Nowadays, modern stacks are all about parallelizing leaf proving while handling recursion in a tree structure. Systems like folding/IVC (think Nova/HyperNova) provide an O(1) incremental step cost and wrap things up with a compact compression SNARK. This is super handy for consistent data streams, like bridges or oracles. Plus, Succinct reports that you can pull off real-time proving on regular GPUs, which makes frequently publishing batch proofs totally doable. (7blocklabs.com)

Net result: you’re swapping a bit of off-chain computing for a smaller number of predictable L1 verifications. This leads to a drop in both average latencies and those pesky tail latencies.

---

6) Best emerging practices we recommend (2026 edition)

1) Keep public inputs tiny

When working with Groth16/Plonk, it's super important to minimize your public inputs (let’s call it l). Remember, each public input tacks on about 7.1k gas to your transaction. So, if you can, try hashing those big statements down into just one field element. For situations where you need to prove inclusion for each proof, consider storing the commitments and then let the consumers verify inclusion off-chain or through quick lookups. Check out more details here.

2) Go for Brief Wrappers on L1, Especially After EIP-7623

With calldata costs being a real concern for data-heavy transactions, it’s best to steer clear of posting huge proof bytes on L1. Instead, consider wrapping STARKs in SNARKs. Think of those large proofs as an internal format rather than something to be delivered on L1. Check out more details here.

3) Use BLS12‑381 Precompiles When Signing or Verifying

Thanks to EIP‑2537, using BLS12‑381 for multi-pairing checks and multi-scalar multiplications (MSMs) is not only more cost-effective but also offers better security compared to BN254. This is especially important for bridge committees, DA attestations, and SNARK verifiers that can take advantage of BLS curves. You can dive into more details here.

4) Choose Your Aggregation Topology Wisely

• Recursive tree + final SNARK: This combo is a solid pick for high-throughput rollups. You’re looking at on-chain verification costs of about 200-350k gas for each batch. Check it out for more details! (7blocklabs.com)
• SnarkPack-style packers: If you’re already cranking out a bunch of Groth16s for mixed statements, these packers are your best friend. Dive deeper into the benefits here: (cryptonet.org).
• Shared aggregators (Electron/UPA): These come with the least hassle for apps that use user proofs. You can expect around 16-20k gas for each user inclusion and then another large batch verification costing roughly 350-380k gas. More info can be found here. (docs.electron.dev)

5) Right-size the batch to balance fees and UX

• Larger batches can help spread out the fixed gas costs, which hover around ~250-380k, but keep in mind they can also slow down proving times. For apps that users directly interact with, we've found that hitting the sweet spots between 32 and 512 leaves works best. When it comes to rollups, maintaining batch intervals of 1-2 minutes and using recursion offers a nice balance between user experience and cost. A good tip is to use moving windows: shrink those batches during busy times to keep tail latency in check. (blog.nebra.one)

6) Budgeting Blobs Separately from Proof Verification

After the Pectra update, aim for about 6 blobs per block and a maximum of 9. This gives you a capacity of roughly 5.3 to 7.9 GiB per day. You'll find that blob fees usually hover around the "near floor" level when network usage dips below the target. Just verify once for each batch and keep those blobs handy for Data Availability (DA). It's best not to count on calldata as a backup, except during those brief moments when blob demand spikes. Check out more details here: eips.ethereum.org.

7) Plan for 2025-2026 Fee Dynamics

As clients start using EIP-7623 and blob limits go up, we’re likely to see more differences in fee structures. Blobs are going to become more affordable, while the costs associated with calldata will hit harder for usage that resembles DA. To navigate this landscape, aggregation techniques that cut down on calldata--like using small SNARKs and minimal public inputs--will hold up well under these new rules. (eips.ethereum.org)

---

7) Example playbooks

A) OP Stack Chain Upgrading to ZK Proofs

• Goal: Create one neat proof for every L2 block or for a handful of blocks.
• Design:
  • Leaf: Use zkEVM or zkVM traces for each block.
  • Recursion: Implement Halo2‑KZG or something similar, with wrapping in Groth16/Plonk.
  • On-chain: A single verification takes about 250-350k gas per batch, while blobs will handle data availability.
• Outcome: You'll see significant L1 savings compared to verifying multiple leaves, plus quicker finality than what you'd find with fault-proof windows. Blob costs will be pretty low after EIP‑7691 kicks in. Providers like Succinct are already reporting good production-grade throughput to back this approach. (blog.succinct.xyz)

B) Cross-chain Oracle Updates Every Block

• Without Aggregation: We're talking about thousands of individual proof or signature verifications popping up every hour. This can really balloon the on-chain costs and create quite the backlog.
• With Aggregation:
  • You can aggregate signatures using BLS12-381 and then verify them with just 2 pairing checks, which costs around ~103k gas for each destination chain; or
  • You can bundle ZK attestations into a single Halo2-KZG or Groth16 proof, which runs you about ~250-350k gas.
• Outcome: This setup means we often achieve sub-block inclusion, resulting in smoother tail latency and a more predictable budget. Check out more details here.

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

• Connect to a shared aggregator:
  • Upload user proofs either on-chain or off-chain to the aggregator.
  • It's gonna cost around 16-20k gas for each user that gets included, while the aggregator typically posts a proof that runs about 350-380k gas regularly.
• This method usually slashes the per-user verification gas by about 10×-15× compared to doing direct on-chain verifications. (docs.electron.dev)

---

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

• Are we checking more than one proof for each L2 batch on L1? If so, let’s aggregate them.
• Are our public inputs kept to a minimum? Try hashing those bulky inputs down to a single field element. (hackmd.io)
• Are we still sending large proof bytes in calldata? It’s time to switch to succinct wraps and keep that calldata nice and small. (eips.ethereum.org)
• Would using BLS12-381 precompiles help cut down on our on-chain checks? Let’s consider migrating from BN254 where we can. (eips.ethereum.org)
• Is our batch size optimized for our UX SLOs? If we see latency issues, let’s shrink n and implement a rolling window. (blog.nebra.one)
• Are we using blobs for data availability in all typical situations? Following EIP-7691, let’s treat calldata as a backup solution only. (blog.ethereum.org)

---

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

Let’s break it down:

• Gbatch: This is the fixed gas needed to check an aggregated proof, and it typically ranges from about 250k to 380k.
• Gincl: This refers to the gas for each proof when you need on-chain inclusion, usually sitting around 16k to 20k.
• n: This stands for the number of proofs included in a batch.

Then:

• For each proof, the L1 gas cost is roughly Gincl + Gbatch / n.
• If you're checking one SNARK for each L2 batch without including any per-user costs, your total cost for that batch boils down to just Gbatch.

Take this example: n = 512, Gbatch = 350k, Gincl = 18k → each proof costs about 18,684 gas. That's often over 10 times cheaper compared to the direct 230-300k gas needed for verifying each proof. You can check it out here: (blog.nebra.one)

---

10) Why this matters more after Pectra

• With more, cheaper blobs (EIP‑7691), the bottleneck moves from data availability to proof and settlement, which is a big deal.
• Calldata floors (EIP‑7623) add a bit of a penalty for those large on-chain proof bytes, encouraging everyone to keep things succinct.
• The introduction of BLS12‑381 precompiles (EIP‑2537) makes it more affordable to handle aggregated signatures, attestations, and certain SNARK verifiers. This really opens up the design space for bridges, light clients, and multi-chain rollups. Check out more about it on blog.ethereum.org!

In a nutshell, aggregation isn’t just some fancy term--it's actually the smart way to achieve lower fees and quicker finality times on Ethereum by 2026.

---

11) How 7Block Labs can help

• Cost modeling and architecture: We take a close look at your current verifier costs and develop a customized aggregation plan with specific gas and latency goals in mind.
• Migration playbooks: We've got you covered with migration strategies from BN254 to BLS12‑381, minimizing public inputs, and creating recursion trees designed specifically for your stack.
• Integration: Whether it's a quick setup with shared aggregators like Electron or UPA or crafting unique aggregation contracts for your rollup or app, we make it seamless.

For a quick snapshot, we’ll put together a 2-page memo that covers:

• Your estimated gas usage per batch for three different sizes (like 64, 256, and 1024),
• Suggested latency SLOs based on 12s, 24s, and 60s block-finality expectations, and
• A step-by-step plan to achieve your cost and user experience goals.

---

Sources and further reading

• Dencun and blobs (EIP‑4844) are changing the game for Layer 2 fees. It's all about blob mechanics and pricing. Check it out here: (blocknative.com)
• The Pectra mainnet brings some exciting updates, like an increase in blob throughput thanks to EIP‑7691. There's a lot of thought behind the rationale, blob fee responsiveness, and capacity math involved. Dive into the details here: (blog.ethereum.org)
• Let's talk about calldata repricing with EIP‑7623 and what inspired this move. You can find all the info here: (eips.ethereum.org)
• BLS12‑381 precompiles (EIP‑2537) are all about gas for pairing and MSM. If you're curious about the specifics, take a look: (eips.ethereum.org)
• Ever wondered about the Groth16 verification gas formula? Or how BN254 pairing costs are changing after EIP‑1108? You can find the answers here: (hackmd.io)
• The Halo2‑KZG aggregator (UPA) is making waves with its gas efficiency, along with Electron super-proof gas. Get all the insights here: (blog.nebra.one)
• Lastly, let's unpack the economics of STARK vs SNARK and take a look at SHARP costs. It’s all laid out here: (community.starknet.io)

Got a specific model in mind for your chain or app? At 7Block Labs, we’ll crunch the numbers based on your unique circuits, batch cadence, and traffic patterns. Plus, we can deliver a solid implementation plan in less than two weeks!