Abstract

Zero-knowledge rollups that submit a STARK proof to Ethereum L1 for every batch face a fundamental cost pressure: on-chain STARK verification is cheaper than re-executing transactions, but it is not cheap in absolute terms. Proof aggregation, the technique of producing a single proof that attests to the validity of multiple sub-proofs, reduces L1 gas costs by amortizing verification across many batches. This article examines how aggregation is implemented in practice, focusing on recursive STARKs and the tradeoffs between proof size, prover latency, and finality time.

The Verification Cost Problem

A single FRI-based STARK proof on Ethereum L1 costs roughly 300,000 to 500,000 gas to verify, depending on the circuit and the security level. At mid-2025 gas prices this is manageable for high-throughput rollups, but for low-activity chains or application-specific rollups the fixed overhead per batch becomes prohibitive. If a rollup produces 10 batches per hour, each requiring separate L1 verification, the annual verification gas bill scales linearly. Aggregation addresses this by combining N proofs into one, so L1 sees a single verification call regardless of how many sub-proofs were aggregated.

Recursive STARKs and the Inner-Outer Architecture

Recursive proof composition works by writing a STARK verifier circuit and then proving that circuit’s execution. The “inner” proofs are the per-batch execution proofs; an “outer” aggregation proof attests that all inner proofs verified correctly. StarkWare’s proof system, used in StarkEx and Starknet, employs this pattern. The outer prover must be able to represent the inner verifier as an algebraic constraint system, which is nontrivial because FRI-based STARK verifiers involve Merkle hash operations and field arithmetic that produce large circuits. StarkWare’s STARK-friendly hash function Rescue-Prime (and its variant RPO) is designed to minimize this overhead by being efficient to represent as polynomial constraints.

Polygon’s zkEVM takes a different approach, using a PLONK-based recursion layer that aggregates batches before submitting a single Groth16 proof to L1. The outermost proof is a SNARK rather than a STARK, trading the trusted-setup requirement of Groth16 for its smaller on-chain verification footprint (around 230,000 gas).

Aggregation Latency Tradeoffs

Aggregating N proofs before finalizing on L1 introduces latency: the aggregation proof cannot start until all N inner proofs are ready. For rollups serving financial applications where finality latency matters, this is a concrete cost. Operators must tune the aggregation batch size based on throughput: a rollup generating 20 inner proofs per hour can aggregate 5 at a time to reduce L1 calls by 5x while keeping finality within 15 minutes per outer batch. The prover infrastructure must also scale horizontally, since aggregation adds a second prover stage with its own GPU or FPGA requirements.

Current Implementations

As of mid-2025, proof aggregation is production-deployed on Starknet (via the SHARP shared prover, which aggregates proofs from multiple StarkEx applications into a single L1 statement), and on Polygon zkEVM’s mainnet beta. Scroll and Linea are evaluating recursive aggregation tiers. The shared-prover model, where multiple independent rollups contribute inner proofs to a common aggregator, further amortizes L1 costs and is an active area of development under the “proof marketplace” framing explored by projects like Succinct Labs’ SP1.