Recursive SNARKs Aggregation

• Recursive SNARKs are advanced cryptographic protocols that aggregate multiple proofs into one succinct proof, critical for scalable blockchain verification.
• They encode base verifiers into arithmetic circuits over pairing-friendly elliptic curves, leveraging Groth16 proofs and recursive arithmetization.
• The architecture significantly reduces on-chain gas costs by consolidating numerous expensive verifications into a constant-time check.

Recursive succinct non-interactive arguments of knowledge (recursive SNARKs) enable the composition and aggregation of multiple SNARK proofs into a single succinct proof, allowing verification of numerous statements or computation steps with minimal on-chain cost. At their core, recursive SNARKs exploit the ability to encode a verifier for one SNARK inside the circuit of another, typically leveraging pairing-friendly elliptic curves chained in a specific way. Recursive proof systems are fundamental for cryptographic scalability applications, especially in blockchain contexts emphasizing privacy and efficiency.

1. Formal Framework of Recursive SNARK Composition

Let $R \subset \{0,1\}^* \times \{0,1\}^*$ be an NP relation for which a zero-knowledge SNARK is already defined: $$\mathsf{SNARK}_n = (\mathsf{KeyGen}_n, \mathsf{Prove}_n, \mathsf{Verify}_n)$$ on a pairing-friendly curve $\mathcal{C}_n$ with prime-order scalar field $\mathbb{F}_{r_n}$. With $N$ base SNARK proofs $\pi_i = \mathsf{Prove}_n(\mathsf{crs}_n, x_i, w_i)$ for $i=1,\dots,N$, the objective is to aggregate them into a proof over a second curve $\mathcal{C}_w$, where $\mathbb{F}_{r_w}$ is the base field of $\mathcal{C}_n$.

The aggregation is defined via the aggregator relation: $$\mathsf{SNARK}_n = (\mathsf{KeyGen}_n, \mathsf{Prove}_n, \mathsf{Verify}_n)$$0 where $$\mathsf{SNARK}_n = (\mathsf{KeyGen}_n, \mathsf{Prove}_n, \mathsf{Verify}_n)$$1, $$\mathsf{SNARK}_n = (\mathsf{KeyGen}_n, \mathsf{Prove}_n, \mathsf{Verify}_n)$$2 is the verification key of the base SNARK, and $$\mathsf{SNARK}_n = (\mathsf{KeyGen}_n, \mathsf{Prove}_n, \mathsf{Verify}_n)$$3 is a collision-resistant hash function mapping to $$\mathsf{SNARK}_n = (\mathsf{KeyGen}_n, \mathsf{Prove}_n, \mathsf{Verify}_n)$$4. The aggregator SNARK's witness comprises the list $$\mathsf{SNARK}_n = (\mathsf{KeyGen}_n, \mathsf{Prove}_n, \mathsf{Verify}_n)$$5, and its public input is $$\mathsf{SNARK}_n = (\mathsf{KeyGen}_n, \mathsf{Prove}_n, \mathsf{Verify}_n)$$6.

In this construction, the base SNARK verifier is encoded as an arithmetic circuit (R1CS or QAP) over $$\mathsf{SNARK}_n = (\mathsf{KeyGen}_n, \mathsf{Prove}_n, \mathsf{Verify}_n)$$7, allowing the recursive step of "wrapping" base SNARKs within another SNARK proof (Rondelet, 2020).

2. System Architecture: Zecale Paradigm

The Zecale system exemplifies one-step recursive SNARK composition, structured around three roles:

1. Base Provers: Generate standard Groth16 proofs $$\mathsf{SNARK}_n = (\mathsf{KeyGen}_n, \mathsf{Prove}_n, \mathsf{Verify}_n)$$8 for individual state transitions or NP statements on $$\mathsf{SNARK}_n = (\mathsf{KeyGen}_n, \mathsf{Prove}_n, \mathsf{Verify}_n)$$9.
2. Off-chain Aggregator: Collects up to $\mathcal{C}_n$0 such $\mathcal{C}_n$1 pairs, constructs the aggregator circuit (an R1CS/QAP for $\mathcal{C}_n$2), and produces a "wrapping" Groth16 proof $\mathcal{C}_n$3 on the aggregator curve $\mathcal{C}_n$4.
3. On-chain Verifier: Receives one transaction containing $\mathcal{C}_n$5 and verifies $\mathcal{C}_n$6 using the Groth16 verification precompile on $\mathcal{C}_n$7. If valid, each $\mathcal{C}_n$8 is dispatched to the base application logic.

This architecture enables off-chain batching of expensive SNARK verification and reduces the on-chain verification task to a single succinct check.

3. Algorithms and Arithmetization

Key elements in the Zecale recursive construction:

• Base Proof Generation: Standard Groth16 proofs $\mathcal{C}_n$9, where $\mathbb{F}_{r_n}$0.
• Aggregator Circuit Construction: The aggregator circuit reserves $\mathbb{F}_{r_n}$1 slots, each enforcing Groth16 verification for a pair $\mathbb{F}_{r_n}$2. The core verification equation per slot is:

$\mathbb{F}_{r_n}$3

Valid proofs are marked by $\mathbb{F}_{r_n}$4, packed as $\mathbb{F}_{r_n}$5.

• Recursive Proving: The aggregator generates $\mathbb{F}_{r_n}$6, re-executing Groth16 verification logic and hash consistency in the R1CS over $\mathbb{F}_{r_n}$7.

The transformation of aggregation to an arithmetized form extends the R1CS/QAP of the wrapping circuit by $\mathbb{F}_{r_n}$8, ensuring scalability in prover workload while maintaining succinctness in verification (Rondelet, 2020).

4. Complexity Analysis and On-chain Verification

The costs and scalability of recursive SNARKs in this paradigm are:

• Base Proofs: Each Groth16 proof $\mathbb{F}_{r_n}$9 on $N$0 is 3 group elements (1 in $N$1, 1 in $N$2, 1 in $N$3), approximately 192 bytes. Base verifier cost on-chain is approximately 320 kGas per proof (Ethereum, post EIP-2028).
• Aggregator Proof: The wrapping proof $N$4 on $N$5 is likewise 3 group elements, with on-chain verification at 320 kGas, independent of $N$6.
• Prover Complexity: Aggregator R1CS has size $N$7; practical prover time is $N$8.
• Verifier Scalability: Verifier work is constant in $N$9—4 pairings plus minor operations.
• Block Gas Savings: Gas saved per block compared to individual verification is

$\pi_i = \mathsf{Prove}_n(\mathsf{crs}_n, x_i, w_i)$0

This constant-time on-chain verification property is a primary scalability advantage.

5. Security and Assumptions

Security of recursive SNARKs hinges on:

• Soundness: Adversarial forgery requires either breaking the base SNARK, finding a collision in $\pi_i = \mathsf{Prove}_n(\mathsf{crs}_n, x_i, w_i)$1 (hash function), or breaking the aggregator SNARK. Each has negligible success probability under standard cryptographic assumptions.
• Zero-Knowledge: Only base proofs $\pi_i = \mathsf{Prove}_n(\mathsf{crs}_n, x_i, w_i)$2 need to be zero-knowledge for privacy in applications like ZETH payments; the wrapping proof $\pi_i = \mathsf{Prove}_n(\mathsf{crs}_n, x_i, w_i)$3 need not be zero-knowledge as it publicly aggregates already-public statements.
• Trusted Setup: Two separate CRS setups are needed—for $\pi_i = \mathsf{Prove}_n(\mathsf{crs}_n, x_i, w_i)$4 (base SNARK) and $\pi_i = \mathsf{Prove}_n(\mathsf{crs}_n, x_i, w_i)$5 (aggregator SNARK). The use of multi-party or updatable ceremonies is recommended.

6. Comparative Analysis: Alternative Recursive Protocols

Alternative recursive SNARK approaches exhibit varying trust requirements, proof sizes, and verification times:

System	Trusted Setup	Proof Size	Verification Cost
Zecale (one-step)	Two CRS	3 elements	Constant (4 pairings)
Halo/TurboPlonk/Spartan	Universal SRS	$\pi_i = \mathsf{Prove}_n(\mathsf{crs}_n, x_i, w_i)$6-size	Polylogarithmic
Bulletproofs	None	Linear	Linear in $\pi_i = \mathsf{Prove}_n(\mathsf{crs}_n, x_i, w_i)$7

Halo/TurboPlonk/Spartan utilize polynomial commitment schemes to avoid trusted setup, trading for moderately larger proofs and slower recursion. Bulletproofs also avoid trusted setup but incur linear scaling with size. Zecale's approach is optimal for settings requiring only one level of recursion, such as aggregating $\pi_i = \mathsf{Prove}_n(\mathsf{crs}_n, x_i, w_i)$8 proofs into a single succinct Ethereum transaction (Rondelet, 2020).

7. Applications and Design Tradeoffs

The primary motivation for recursive SNARKs lies in scaling privacy-preserving state transitions in blockchain systems. By converting $\pi_i = \mathsf{Prove}_n(\mathsf{crs}_n, x_i, w_i)$9 expensive on-chain verifications into a single succinct check, recursive SNARKs enable cash-like, scalable, and private rollup mechanisms on Ethereum. The minimal proof size (3 group elements) and constant-time verification bolster practicality in resource-constrained smart contract environments.

A plausible implication is that, while multi-step infinite recursion (e.g., for deep compositional proof systems) requires different architectures, Zecale's one-step recursive SNARKs form a critical building block for layer-2 rollup designs, specifically where only periodic batch verification is needed and trusted setup can be managed efficiently (Rondelet, 2020).