Could You Explain How Proof Aggregation Can Cut Gas Costs for a Rollup I’m Launching?

---

Why this matters for decision‑makers

On Ethereum, after the Dencun upgrade dropped on March 13, 2024, you can post transaction data pretty cheaply using blobs. Just a heads up though: verifying proofs still munches through regular EVM gas. The neat part? By bundling up proofs, you only have to pay that “verification tax” once for the whole batch instead of for each proof individually. This is where a good chunk of those non-DA L1 costs tends to sneak in. (blog.ethereum.org)

---

First principles: where your L1 gas goes today

• Data Availability (DA)
  • With EIP‑4844 now in play, rollups can chuck their data into blobs. Each blob is a hefty 131,072 bytes, and you can squeeze out a maximum of 6 blobs per block. The goal is to average about 3 blobs per block, and there’s also a separate “blob base fee” that works similarly to EIP‑1559. This setup is a great way to keep DA costs on the down-low and separate from those annoying EVM gas spikes. Just keep in mind--you’ll still need to pay for the verifier execution with regular gas. (eips.wiki)
• Proof Verification
  • So, let’s talk about Ethereum's BN254 pairing precompile (EIP‑1108). The main pairing check is going to set you back about 45,000 gas, and for each additional pairing (let's call it k pairings), it’ll be an extra 34,000·k gas. Generally, if you're using a typical Groth16 verifier, you’re looking at a gas cost that usually falls between 200k to 300k, plus you'll need to factor in the cost for each public input. Check it out here: (eips.ethereum.org)
• Generally, the Groth16 verification cost comes in at about 207,700 + 7,160 × l gas, where l is the number of public inputs. This really shows how crucial it is to keep those public inputs to a minimum. (hackmd.io)
• Quick heads up: running raw STARK verification directly on-chain can really rack up the costs (think hundreds of operations beyond pairings) and people tend to steer clear of it on L1. Instead, most folks prefer the “STARK → SNARK” wrapping method. (jolt.a16zcrypto.com)

Bottom line: After EIP-4844, data availability (DA) is not just cheaper but way more flexible. Your verification gas is still that pesky fixed cost, though. Just remember, aggregation can really make a dent in that fixed cost.

---

What “proof aggregation” actually does

“Aggregation” really boils down to three key actions:

1. First up, we create a bunch of leaf proofs.
2. Next, we compress them--either by using a recursive method or a special aggregator--into one big “super-proof.”
3. Finally, all you have to do is verify that single proof on L1.

The L1 verify call doesn’t really make much of a difference whether you’re working with 2 or 2,000 leaf proofs. In fact, as you ramp up the batch size, the cost per proof on L1 drops so low that it’s nearly insignificant. If you're curious, you can take a look yourself here: (docs.electron.dev).

---

Three practical aggregation patterns (and when to use each)

1) Recursive accumulation and wrapping (STARK/FRI → SNARK/KZG)

• How it works
  • Leaf proofs, which are often STARKs from a zkVM or custom circuits, get verified within a recursion circuit. After that, the outcome is bundled into a super compact pairing-based SNARK. This way, Ethereum only needs to check this tiny wrapper proof. You can dive into more details here.
• What it costs on L1 (just for illustration)
  • If you're checking out the wrapped proof for Succinct SP1, it typically runs between 275k-300k gas on Ethereum, Bases, Arbitrum, and Scroll. Meanwhile, zkSync Era's Boojum upgrade has worked wonders, slashing their per-batch L1 verification from around 760k to roughly 460k gas. On the flip side, Jolt figures a raw on-chain STARK verifier could hit around 2M gas if it’s not wrapped up well. Want to dive deeper? Check out more details here.
• When to use
  • This is ideal for high-throughput rollups, especially when the leaf prover is either STARK-based or running on a zkVM. Lately, this method has become the favorite for Layer 2 solutions that want to keep L1 verification gas low and offer plenty of EVM compatibility.

Operational Tips:

• It's a good idea to keep your public inputs minimal. Aim to bundle them together into a single hash so that the wrapper verifier can work with something close to l ≈ 1. The team at Polygon’s FFLONK/Groth16 verifiers even recommends “hashing the publics” to sidestep that annoying ~7k gas fee for every public signal. You can take a look at the details here.

2) SNARK‑level aggregators (pack many SNARKs into one)

• How it works
  • So, if you're already pumping out a ton of Groth16/Plonk proofs (you know, those mixed statements), you can easily group them together using tools like SnarkPack or some of the latest folding techniques. What's great about this? The verifier works in O(1) or O(log n) time. Take a look for more details: (research.protocol.ai)
• Real‑world numbers
  • SnarkPack really showed its strength by cranking out 8,192 Groth16 proofs in about 8-9 seconds on a powerful 32-core CPU. Verification didn't take long either, just a few milliseconds off-chain, followed by a single call to the L1 verifier. On top of that, the new "folding" methods, like Mira and SnarkFold, are even more impressive--they reduce prover memory and latency while keeping the verification size constant or even log-sized. You can dive into more details here: (research.protocol.ai)
• When to use
  • This is ideal for multi-app proof hubs or rollups with several independent circuits (like per-transaction membership proofs) where you’re looking to keep things simple without having to overhaul the entire stack for a zkVM.

Operational Tips:

• If you're trying to budget for gas, there's a simple formula you can follow: per‑proof L1 gas ≈ (base_verifier_gas / N) + per‑proof bookkeeping. For Groth16, the base_verifier_gas usually falls between 200k and 300k. If you keep the aggregate verifier around l ≈ 1, you'll find that bookkeeping stays pretty straightforward. You can dive deeper into this over at hackmd.io.

3) External verification/aggregation networks (AVS and shared provers)

How it works

• You can lighten the load of verification by using an AVS (Actively Validated Service) or a shared prover network. This setup provides you with an attestation, similar to an aggregated BLS signature, and/or a compressed proof. By going this route, you can really cut down on those on-chain gas fees--think reductions of ten times or even more! Just remember, this does change up your trust and latency dynamics a little. (blog.alignedlayer.com)

Examples and numbers

• Aligned’s Proof Verification Layer is really something else! It manages to verify thousands of proofs off-chain and then just sends one result back. They say this can slash L1 gas costs per proof by about 90-99%. And when you need those on-chain final proofs, they’ve got a handy “Proof Aggregation Service” all set up. (blog.alignedlayer.com)
• Next up is StarkWare’s SHARP. It’s like “UberPool for proofs” since it gathers a ton of different Cairo programs into one neat package. They’ve pulled off the impressive feat of bundling around 220,000 transactions into a single STARK proof! The best part? The on-chain costs are split among everyone involved. (starkware.co)

When to Use:

• You should consider this option if you want to minimize on-chain verification gas costs right from the start. It's a great fit if you're comfortable with AVS assumptions. Plus, if you're keen on pooling resources across different apps to cut down on expenses, this could work well for you.

---

Worked examples you can budget against

You plan to post a proof every 2 minutes

• Without aggregation:
  • Picture this: you’re churning out 12 tiny Groth16 proofs every 2 minutes. Each time you verify a proof, it’ll set you back about 207,700 + 7,160·l gas. If we take l to be around 4 for each proof, that rounds us up to about 236k gas per proof. In total, you’re looking at around 2.8M gas every 2 minutes.
• With recursion/wrapping:
  • If you take those 12 proofs and bundle them into a single streamlined wrapped SNARK with l = 1, you're looking at a total Layer 1 cost of about 275k-300k gas. That’s an impressive saving of over 90%! And honestly, the gas cost per proof turns into a minor detail. You can see more about it here: (succinct.xyz).
• Interpretation:
  • Basically, you've taken a verification cost that increases linearly and turned it into a straightforward flat fee. Instead of shelling out more gas on Layer 1 for every proof, you'll just manage a bit more proving time off-chain.

Cross‑app aggregator (shared service among 10 dapps)

• Baseline:
  • Every dapp sends in a Groth16 proof every hour. When you crunch the numbers, that adds up to 250k gas times 10, making it around 2.5M gas each hour just for verification. (hackmd.io)
• Using an aggregator service:
  • Instead of having each dapp handle its own proofs, you can lump them together into one big “super-proof.” This nifty approach cuts the base cost down to around 300k gas per hour. Breaking it down per dapp, you'd be looking at about 30k gas for each one hour. And if you want to add per-dapp attestations, just keep in mind you'll need to budget around 16k to 25k gas for every query or inclusion call. (docs.electron.dev)

---

How EIP‑4844 changes the calculus (and how it doesn’t)

• Blobs are a game changer when it comes to DA! You can work with blobs that are 131,072 bytes in size and aim for about 3 per block, with a max of 6. And don’t forget about that separate EIP-1559 fee--it usually stays on the lower side unless there’s a sudden spike in blob activity. So, it’s a smart move to pack your batch data into those blobs; you definitely don’t want to pay for capacity that you're not using. (eips.wiki)
• On the other hand, proof verification still runs on regular gas. That’s why aggregation remains super important even after 4844--it's how we handle those non-DA costs. (blocknative.com)

---

Engineering moves that cut real gas today

1. Minimize public inputs to your outer verifier

• Quick tip: piling on extra public signals can hike up gas fees by about 7k when using Groth16/FFLONK verifiers. To keep things efficient, think about hashing your public I/O with Keccak and just passing along a single field element. You can find the details in the Aggregator docs for Polygon’s zkEVM. (hackmd.io)

2) Choose the Right Wrapper and Curve

• Thanks to EIP-1108, Ethereum's BN254 pairings are now quite budget-friendly. Usually, you'll find that just 2 to 3 pairings cover most of the fixed costs. If you don't need 128-bit security for your top-level proof, sticking with BN254 is definitely a wise choice for reducing L1 verification expenses. (eips.ethereum.org)

3) Use Recursion Trees Sized for Your Prover Topology

• If your prover fleet is loaded with GPUs and you need to keep latency low, consider using those shallow trees alongside a fast zkVM like SP1. You can hit around ~275k-300k gas on L1. And if you’re juggling different proofs, it might be a good idea to add a fold/aggregate phase (like SnarkPack, Mira, or SnarkFold) before you finalize everything. This could really help reduce your overall proving time and keep your contract size nice and tidy. (succinct.xyz)

4) Finding Your Sweet Spot with Batch Sizing Formula

Alright, let’s get into the batch sizing formula and figure out what works best for you. Here’s a simple way to break it down:

• To estimate the per-proof L1 gas, you can use this rough formula: (Gbase / N) + Gmeta.

Let’s break down an example: imagine your outer verifier is consuming around 300k gas, and you're tacking on roughly 7k gas for every proof you include. Here’s how that adds up:

• For N = 32:
  • You’re looking at around 9.4k plus 7k, which totals roughly 16.4k gas for each proof.
• For N = 256:
  • In this case, it adds up to about 1.2k + 7k, which lands you at roughly 8.2k gas per proof.

Make sure you use constants that match your system. For example, Nebra states it costs around 18k for verify per proof, and then you’ll have an extra 22k-25k for result queries per proof, which really depends on your flow. You can check out more details here: (docs.nebra.one).

5) Sync Blob Posting with the Aggregator Schedule

• To keep costs down, try to send complete blobs. When you're setting up posts during peak L2 times, shoot for a target of 3 blobs, but you can go up to 6 if necessary. If you see the blob base fee climbing, think about delaying any non-urgent posts or switching to calldata for those important anchors. (eips.wiki)

6) Choose Audited Verifier Templates and Monitor Per-Chain Precompiles

• Stick with trusted verifier generators such as gnark’s audited verifiers or the Halo2/Solidity toolchain from PSE. If you’re diving into zkVMs, definitely use the verifiers offered by the vendors. And just a quick tip: don’t assume that all EVM chains have the same precompile gas rates as Ethereum. Some might adjust their pairing costs, which could throw off your hardcoded gas stipends. Take a look at this link for more details: github.com

---

“How much will aggregation save me?” -- concrete scenarios

• So, we're talking about a ZK rollup that uses a small circuit for each block (Groth16), with l set at 4.
  • If we decide not to aggregate, we’re hitting around 236k gas for each block, which, when you multiply that by 60 blocks per hour, adds up to roughly 14.2 million gas in an hour.
  • But if we go for aggregation every hour, it’s just one verification that costs about 300k gas, plus some extra bookkeeping costs. With N at 60 and around 7k gas for proof metadata, we could break it down like this: 300k + 420k, which brings us to around 720k gas per hour. That’s a huge saving of more than 94%! You can dive deeper into it here: (hackmd.io)
• zkVM rollup (STARK proofs), wrapped to SNARK
  • Verifying STARK proofs straight on L1 can really hit your wallet, costing around ~2M gas for each proof. But here’s the cool part: when you wrap it, that fee drops to about ~275k-300k for each batch. So, if you’re cranking out 6 batches every hour, you’re looking at savings of roughly 10.2M gas/hr compared to going the direct STARK verification route. (jolt.a16zcrypto.com)
• Multi‑chain relay/oracle network
  • So, let’s be real--trying to verify thousands of micro‑proofs one by one every hour just isn’t going to cut it. With Ethereum's gas limit hovering around 45 million per block, you'd only manage about 15 Groth16 verifications per second. But here’s the silver lining: if you can bundle those verifications into a single on-chain outcome or hand them over to an Aggregation Verification Service (AVS), you can shift that challenging throughput limit into something more about making smart policy choices. Want to dive deeper? Check it out here: (blog.alignedlayer.com)

---

Implementation checklist (rollup founder edition)

• Proof system
  • If STARKs are your jam, you might want to consider wrapping them to fit into SNARKs for Layer 1. On the other hand, if SNARKs are more your style, you’ll have to decide whether to dive into direct recursion or use an external aggregator like SnarkPack. (zksync.io)
• Public I/O Discipline
  • Stick to one public hash and keep the rest under wraps. This helps you keep your outer verifier at level 1. Check it out here!
• Choosing a Verifier Contract
  • If you’re diving into Halo2/KZG or PLONK, it’s a smart move to stick with audited Solidity verifiers or take a peek at their generator toolchains. On the flip side, if you’re dealing with zkVMs such as RISC Zero or SP1, just roll with the vendor’s basic Groth16 verifier contracts. And hey, don’t forget to deploy those only once! (github.com)
• Batch size and cadence
  • Try to choose a size N that fills those blobs while still hitting your latency SLOs. It’s a good idea to take a look at this again once you have actual traffic data to work with. A good starting point for N is somewhere between [32 and 256] to keep your per-proof costs manageable, ideally in the tens of k-gas range. (eips.wiki)
• Monitoring and fallback
  • Stay alert for changes in blob base fees and any sudden spikes in gas prices. If blobspace starts to get limited, be prepared to adjust your batch timings or utilize temporary calldata anchors. (blocknative.com)
• Multi-chain readiness
  • If you're planning to verify proofs on different EVMs, it's a good idea to retest your verifier gas there. Don’t take it for granted that EIP-1108 behaves the same way everywhere. Remember, pricing for pairings can differ from one network to another. (infsec.io)

---

Emerging practices you can adopt in 2026 builds

• FFLONK/FF Systems as Outer Verifiers
  • These systems come with a constant term akin to Groth16, but they really cut costs for each public input. Polygon has introduced an FFLONK verifier and recommends sticking with single-input designs. You can dive into the details here: (docs.polygon.technology)
• Folding-based aggregators
  • Tools like Mira and SnarkFold are working to maintain a steady verifier cost while also keeping memory usage in check. This is super useful when you’re dealing with those large mixed batches before you finalize everything into a pairing SNARK. So, if you find yourself managing thousands of different circuits in your batches, these tools are definitely worth checking out! You can read more about it here: (eprint.iacr.org)
• High‑performance zkVM stacks
  • SP1 is really making waves with its wrapped proof verification, clocking in around 275k-300k gas while pushing for real-time proving. This means your workflow could get a major upgrade! You can write programs in Rust, do some recursion within the VM, and then kick out a single proof that's super compatible with L1. Check out more details here: (succinct.xyz)

---

Pitfalls we see (and how to avoid them)

• If we assume that calldata got a bit cheaper after 4844
  • It seems like only blob data (DA) saw a price cut; calldata prices are still holding steady. So, it’s smart to lean on blobs for DA and keep those verifiers efficient on gas. (blocknative.com)
• Over‑exposing public inputs
  • Quick note: each additional public input can set you back about ~7k gas. It's way smarter to hash them instead. (hackmd.io)
• Setting gas stipends for pairings across different chains
  • Just a heads up: Ethereum's BN254 pairings stick to EIP‑1108, but not all EVM chains do. So, it might be a good idea to parameterize or check things at runtime to dodge any DoS problems that could pop up from not having enough gas. (infsec.io)
• Ignoring contract size limits
  • Watch out for simple code-generation verifiers since they might bump up against EVM bytecode limits. It's a good idea to stick with compact, audited templates from trusted toolchains like gnark/PSE or zkVM-provided verifiers. You can check them out here.

---

Quick decision flow

• Are you more of a fan of STARKs, or are you leaning towards zkVM?
  • If you picked yes → Go ahead with recursion + SNARK wrapping; shoot for something like ~275k-300k gas for the outer verifier. (succinct.xyz)
• Do you have a SNARK-native setup with a collection of small, mixed proofs?
  • If so, definitely consider using a SNARK-level aggregator (like SnarkPack or folding), and then just do one final outer verification. Check out this resource for more details: (research.protocol.ai)
• If you're after minimizing on-chain gas for each proof and are cool with some external verification assumptions,
  • you should definitely take a look at an AVS (like Aligned). You can periodically validate it with a wrapped proof. Check it out here: (blog.alignedlayer.com)

---

Implementation pointers

• Ethereum verification cost model: To maintain control, use the EIP‑1108 pairing formula (45,000 + 34,000·k) when checking verifier gas. If you want to learn more about it, check it out here.
• Groth16/FFLONK gas budgeting: We’re estimating around 207,700 + 7,160·l for Groth16. Just a heads up to make sure the outer circuit is set up so that l = 1. You can find more details here.
• zkVM stacks with ready verifiers:
  • SP1: This one's doing around 275k-300k gas on EVM chains for wrapped proofs, and the cool part? It’s got production verifiers already up and running on mainnet L1s. Check it out here.
  • RISC Zero: The Bonsai setup is cranking out Groth16 receipts that come with a solid on-chain verifier interface. Dive into the details here.
• SNARK aggregator references:
  • SnarkPack: This one's all about Groth16 aggregation, really diving into log‑size/log‑time stuff. If you're curious, check it out here.
  • Mira/SnarkFold: This project focuses on folding for pairing‑based arguments and emphasizes a constant‑size verifier. Want to know more? You can find the details here.

---

The executive‑level takeaway

• EIP‑4844 has really taken the stress out of data availability issues; these days, the main expense on Layer 1 is just proof verification.
• Thanks to proof aggregation, instead of needing O(n) verifier calls, you're only looking at O(1) per batch now--huge difference!
• In practice, well-optimized stacks usually use around 200k to 300k gas for each batch on Ethereum. And guess what? The cost per proof on Layer 1 is dropping into the low tens of k-gas--heck, it could even be nearly zero if you decide to pass verification off to an AVS and just anchor every now and then. (succinct.xyz)

If you’re getting ready to launch a rollup in 2026, there are a few important points you should definitely keep in mind:

• Tiny Outer Public Inputs: Keep those outer public inputs nice and compact.
• Wrapped Proofs: Consider going for a wrapped proof that only needs to be verified once for each batch.
• Blob-aware Batching: Make sure to use blob-aware batching to streamline your workflow.
• Aggregator Plans: Be clear about whether you’ll share an aggregator or if you’re planning to manage your own.

Nailing these elements will put you on the path to success!

---

Appendix: reference facts and constants (for your team’s calculators)

• If you're looking at EIP‑1108 for BN254 pairing, be ready to spend around 45,000 plus 34,000·k gas. For more details, check it out here.
• Now, when it comes to verifying Groth16, the typical cost is around 207,700 plus 7,160 times l gas. You can get more info here.
• Regarding EIP‑4844, each blob can be up to 131,072 bytes, targeting 3 blobs max and a total of 6 per block, all with their own blob-gas market. Check out the specifics here.
• If you're curious about wrapped zkVM proofs (SP1), the verification cost is around 275k to 300k gas on the EVM. For more details, you can look here.
• When it comes to Boojum (zkSync Era), verifying each batch will run you about 460k gas, which is a sweet drop from the previous 760k. Get the full scoop here.
• If you’re diving into aggregation services like Nebra or UPA, expect to pay around 18k for verification/proof and about 22k-25k for each proof query/read. Electron Labs notes a base cost of about 380k for an aggregated batch, plus around 16k per proof for inclusion checks. Learn more here.
• Lastly, StarkWare's SHARP lets you bundle up to hundreds of thousands of transactions per proof, with costs shared among participants. Check out the details here.

---

7Block Labs is here to manage the entire process of building, profiling, and running your pipelines from beginning to end. We take care of all the details--everything from leaf circuits and zkVM integration to outer verifiers and blob-aware posting schedules. With us on your side, you can get a solid grip on your gas budget well ahead of the mainnet traffic.