aere-research/research/specs/spec-recursive-aggregation-scale.md

AERE Network: Recursive Proof Aggregation at Scale

Chain: AERE Network mainnet, chain ID 2800 (Hyperledger Besu QBFT). Status date: 2026-07-11. Source of truth for addresses: sdk-js/src/addresses.ts. Contract source: contracts/contracts/zkverify/AereProofAggregator.sol. Guest and prover source: zk-circuits/recursive-aggregation-scale/. On-chain records: contracts/deployments/proof-aggregator.json (n=3) and contracts/deployments/proof-aggregator-scale.json (n=10). Scope: folding N heterogeneous SP1 proofs into a single Groth16 proof, verified once on-chain, and the gas-amortization argument that follows. This is a focused companion to spec-zk-stack.md, which covers the wider verification surface.

---

0. Honesty preamble (read this first)

Five points frame everything below.

1. This is a proof of approach, not a production rollup batcher. The largest run demonstrated on-chain folds ten inner proofs. That is enough to establish that the recursion, the composite binding, and the constant-cost on-chain verification all work end to end. It is not a claim of a high-throughput sequencing pipeline. n=16 is in progress and is not yet recorded on-chain.

2. The chain is small and centralized. AERE runs three QBFT validators under a single operator on a single client (Besu). There is no external security audit of the AERE-authored contracts. The aggregator is an ordinary EVM contract that any account can call; it does not touch consensus.

3. Proving happens off-chain and is heavy. The n=10 aggregation took roughly 1549 seconds of wall time on the prover box (CPU): about 988 seconds to produce the ten inner proofs and about 526 seconds for the final Groth16 wrap. Aggregation buys cheap, constant on-chain verification by spending real off-chain compute. It is not a low-latency path.

4. The inner statements in the scale run are constructed, not organic user traffic. The ELFs are the real production programs (their verifying keys are checked byte-for-byte against the on-chain vkeys before any proof enters the fold, and the run aborts if an ELF does not reproduce its published key). The proofs are genuinely produced and genuinely recursively verified. But the per-instance inputs (user addresses, attestation times, credential values) are deterministically derived for the demonstration so that each folded proof is a distinct statement. No claim is made that ten independent users generated these.

5. The aggregator stores one composite, not each inner statement's payload. The individual (vkey, publicValues-hash) pairs are bound into the composite and emitted in the verification event, but the contract does not persist each inner statement's semantic content. Consumers that need per-proof detail must read the event or re-supply the inner data.

---

1. The primitive

AereProofAggregator at 0x6a260238890E740dB12b371E0C5d17a2470F84C5 (canonical, addresses.ts; owner = Foundation 0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3) is an on-chain anchor for a single recursive SP1 "proof of proofs." One Groth16 proof attests that N inner SP1 proofs, each from a real, distinct AERE production program, were each verified inside the zkVM. The contract verifies that one Groth16 proof through the live SP1 gateway, recomputes a composite digest from the supplied inner data to bind the proof to exactly which programs were folded, and records the aggregation.

The design goal is amortization: pay for one on-chain verification and one Groth16 wrap, regardless of how many application proofs are folded underneath.

The verifier plumbing is shared with the rest of the ZK stack:

• SP1VerifierGateway: 0x9ca479C8c52C0EbB4599319a36a5a017BCC70628 (the aggregator holds this stable gateway address, not a concrete verifier, so new prover versions route in without redeploying the aggregator).
• SP1VerifierGroth16_v6_1_0: 0xb5456d48bFdA70635c13b6CBE1Ad0310Dc0171aD (the concrete verifier the Groth16 selector 0x4388a21c routes to).

---

2. Architecture: recursion in the guest, bind-and-verify in the contract

There are two halves: an SP1 guest that does the recursive verification off-chain, and the Solidity contract that verifies the resulting Groth16 proof on-chain.

2.1 The aggregation guest (recursive-aggregation-scale/agg-program/src/main.rs)

The guest reads a vector of inner verifying-key digests and a vector of inner public-value byte-strings. For each inner proof it:

1. computes pv_digest = sha256(publicValues[i]), the exact digest the SP1 recursion verifier binds an inner proof to;
2. calls sp1_zkvm::lib::verify::verify_sp1_proof(&vkeys[i], &pv_digest), which recursively verifies, inside this zkVM, that a valid inner SP1 proof exists for that verifying key and those public values. If any inner proof is missing or invalid, the aggregation proof cannot be produced at all;
3. folds (koalabear_vkey_digest_i || pv_digest) into a running SHA-256.

After the loop it commits a single 32-byte composite. The guest is unchanged from the n=3 version, which is why its verifying key is stable and already registered on-chain. The host asserts the rebuilt guest reproduces the registered aggregation vkey 0x003a70854f258b13c6612b0272421f2d7d97f90eee63e124864c80be61a2672c and aborts otherwise, since the Foundation, not the prover operator, controls which aggregation vkey the contract will route.

Inner proofs are generated as compressed SP1 (STARK) proofs. The final aggregation is Groth16-wrapped for the on-chain gateway. This is the key economic move: N compressed inner proofs plus one Groth16 wrap of the recursion, rather than N separate Groth16 wraps.

2.2 The contract (AereProofAggregator.sol)

recordAggregation(aggVKey, innerVKeyDigests[], innerPvHashes[], publicValues, proof) is permissionless. It:

1. requires aggVKey to be a registered aggregation program (isAggProgram);
2. checks array lengths match, N is non-zero, and publicValues is exactly 32 bytes;
3. recomputes the composite from the supplied inner digests using the exact same byte layout as the guest, and requires it to equal the committed 32-byte publicValues (reverts CompositeMismatch otherwise);
4. calls ISp1Verifier(SP1_VERIFIER).verifyProof(aggVKey, publicValues, proof) inside a try/catch, translating the gateway's revert-on-invalid convention into a typed InvalidProof();
5. counts how many folded inner programs are recognized (registered via registerInnerProgram) and stores the aggregation keyed by composite, incrementing aggregationCount.

SP1_VERIFIER is immutable, set at deploy. Recorded aggregations cannot be altered or removed. A verifyAggregation(...) view performs the same recompute-then-verify without recording, so any caller can re-check an aggregation via eth_call.

Because the contract recomputes the composite from caller-supplied inner data and requires it to match the proof's own committed output, a caller cannot lie about which programs were folded: changing the claimed inner set changes the recomputed composite, which then fails to equal what the proof committed. The record-aggregation-scale.js driver exercises exactly this: tampering the proof body reverts, and dropping one child (so the recomputed composite no longer matches the committed value) reverts. Both rejections are recorded in proof-aggregator-scale.json.

---

3. The composite binding and the two vkey encodings

The composite is byte-identical between guest and contract:

composite = sha256(
    u32_be(n)
    || (koalabearVKeyDigest_0 || sha256(publicValues_0))
    || ...
    || (koalabearVKeyDigest_{n-1} || sha256(publicValues_{n-1}))
)

Each inner program is identified by two different encodings of the same key. The koalabearVKeyDigest is the SP1Field (KoalaBear) digest that verify_sp1_proof actually checks (SP1VerifyingKey::hash_u32, serialized big-endian). The onChainVKey is the BN254 bytes32 the program publishes for gateway verification. These are not the same 32 bytes. The Foundation registers the mapping between them (registerInnerProgram(innerVKeyDigest, onChainVKey, label)), so each folded program can be labelled and cross-checked against its published on-chain key. Binding the KoalaBear digest, rather than the BN254 key, is the sound choice: it is the value the recursion verifier truly checked.

---

4. Heterogeneity: three different programs, one proof

The folded set is not N copies of one circuit. The n=10 run folds three distinct programs with three distinct verifying keys:

• zkscreen (allowlist / sanctions-screening membership proof), on-chain vkey 0x006a211015aee2b90b82d266bef3aa6944551b06c488d86e895489b1dde3e5b7, paired with the live AereZKScreen verifier 0x3A097A459FD26aC79573aCB5adB51430e473C2f1.
• over18 (age-credential proof over a Merkle-committed birth year), on-chain vkey 0x005aa94ac711bc65d0755b3a94f3622a6e8c76e2cdd708c29869587f633343c5.
• zkml-mnist (a 784 to 256 to 10 MLP MNIST classifier run inside the zkVM on a private image), on-chain vkey 0x0061443ce273455d0afcdaf1103ea0a52b970d979896dc83d989e71ba7c4bceb, paired with the live AereZKMLVerifier 0xf1BF15d5018a35D21FBB4Ec868f062DF7C06783c.

verify_sp1_proof verifies any inner SP1 proof regardless of which program produced it, so heterogeneous folding requires no special handling: the guest simply calls it once per inner proof with that proof's own vkey digest. This is the meaningful capability. One settlement event can attest a mixed batch of an identity screen, an age proof, and an ML inference, drawn from unrelated circuits, in a single on-chain verification.

---

5. Proven results

5.1 First aggregation, n=3 (proof-aggregator.json)

One zkscreen, one over18, one zkml-mnist folded into one Groth16 proof.

• composite 0x8e246396a2f40c837501d06c965163db644284ffc877d7cd0d38681b612b4e36
• on-chain verify tx 0xde4c102ab86567bfb7b384a784c049bf6ded33378e0b71acc0bfe97b7b8d4b39, block 8811943
• on-chain gas used: 387,858, result true
• aggregation program registered via tx 0x223960cbd60299dc9e09d1609d9be6195067257e70894f1df4460b4bc5e4876c; inner programs registered for zkscreen, over18, and zkml-mnist.

5.2 Aggregation at scale, n=10 (proof-aggregator-scale.json)

Four zkscreen, four over18, two zkml-mnist, each instance a distinct statement (distinct derived user address, attestation time, and credential value), folded into one Groth16 proof.

• composite 0x11ee0c089c223aca62a6db85a3299e9d8160c72bdeb83e84e44642a4a37aa1fb, committed as the proof's 32-byte public values, proof selector 0x4388a21c
• record tx 0xd1fd4d60635fbafe8b269ea156a6bbc65e2b6ff8b886eb7910569a9c9344d978, block 8930005
• on-chain gas used: 393,844, status 1
• read-back: exists = true, count = 10, recognized = 10 (all ten inner programs registered), aggregationCount now 2
• tamper checks: tampered proof reverts; dropped child reverts

Off-chain proving timings for the n=10 run: inner proofs about 988 seconds total, the Groth16 aggregation about 526 seconds, total wall time about 1549 seconds. Per-program the cost is uneven: each zkscreen and over18 inner proof took roughly 71 to 75 seconds, while each zkml-mnist inner proof took roughly 200 to 205 seconds. The two ML proofs alone account for over 400 of the 988 inner-proving seconds, which is worth noting for anyone planning a batch mix.

---

6. Constant on-chain cost

The headline is that the on-chain cost of recording an aggregation is essentially flat in N. The two measured points bracket a 3.3x increase in N:

N	on-chain gas	tx
3	387,858	0xde4c102a...
10	393,844	0xd1fd4d60...

Going from three to ten folded proofs raised on-chain gas by about 5,986, roughly 1.5 percent, for more than triple the work folded underneath. The bulk of the cost, roughly 390k gas, is the fixed Groth16 verification through the gateway, which is independent of N. The small residual growth comes from the parts that do scale with N: the calldata for the two bytes32[] arrays, the SHA-256 recompute of the composite over N entries, and the loop that counts recognized programs. None of that is the proof check. As N grows further, the per-record gas stays anchored near the single Groth16 verify cost; the marginal on-chain cost of one more folded proof is a few hundred gas of calldata and hashing, not another proof verification. Every record is comfortably under the EIP-7825 (Fusaka) per-transaction gas cap of 2^24 = 16,777,216; the driver estimates gas and asserts it is under the cap before sending.

---

7. The amortization argument

The value of aggregation is that many proofs settle behind one verification, on two axes.

On-chain gas. The honest baseline is: how much would it cost to get the same N proofs verified on-chain individually? SP1 Groth16 verification through the gateway is on the order of 300k gas per proof. Ten separate verifications is therefore on the order of 3,000,000 gas, before per-record storage overhead. The single aggregated record cost 393,844 gas. That is roughly an 87 percent reduction at n=10, and the saved fraction grows with N, because the aggregated cost is fixed while the individual-verification baseline is linear. Put as a marginal cost: an individually verified proof costs about 300k gas; a folded proof costs a few hundred gas of extra calldata and hashing on top of a shared, one-time 390k.

Off-chain proving. The saving is not only gas. Inner proofs are produced as compressed STARKs; only Groth16 and Plonk proofs are gateway-verifiable on-chain. To verify each inner proof individually on-chain, each would need its own Groth16 wrap, and a Groth16 wrap is the expensive step (the single aggregation wrap here took about 526 seconds). Aggregation replaces N Groth16 wraps with exactly one wrap of the recursion. So the amortization is real on both sides: one Groth16 wrap and one on-chain verify stand in for N of each.

The trade, stated plainly. Aggregation moves cost from on-chain gas and per-proof settlement events to off-chain proving latency and to a single coarse-grained record. It is the right tool when many application proofs can share one settlement point and one verification event (a periodic attestation batch, a compliance roll-up, a mixed identity-and-inference bundle). It is the wrong tool when each proof must be independently and immediately queryable on-chain with its own stored record, because the aggregator persists one composite, not N per-statement payloads. The inner (vkey, publicValues-hash) pairs are recoverable from the AggregationVerified event's innerVKeyDigests array, but the statement semantics are not stored in contract state.

---

8. What is and is not proven

Proven, on-chain, recorded in the repo:

• Recursive verification of ten real, heterogeneous inner SP1 proofs (three distinct programs) folded into one Groth16 proof, verified once on-chain.
• The composite binding is sound and enforced: the contract recomputes it from caller-supplied inner data and rejects any mismatch; tampering the proof or altering the claimed inner set reverts.
• On-chain cost is flat in N to within about 1.5 percent across a 3.3x increase, anchored at the single Groth16 verify cost.
• Every folded program's ELF was checked against its published on-chain vkey before proving, and the aggregation guest was checked against its registered vkey.

Not proven, and not claimed:

• No run beyond n=10 is recorded on-chain yet. n=16 is in progress.
• The scale-run inner statements are deterministically derived for the demonstration, not organic traffic from ten distinct users.
• This is not a production rollup or a sequencing pipeline. It is an attestation aggregator for application-layer proofs. (AERE's separate rollup-validity work, the bounded-VM AereRollupValidity and the newer full-EVM AereEVMValidity anchor, is documented elsewhere and is distinct from this contract.)
• No external audit. Three-validator, single-operator chain.

---

9. Trust boundary

The cryptographic check is the immutable concrete Groth16 verifier the gateway routes to. Neither the aggregator nor the gateway can forge a verification; both revert on an invalid proof. Two centralization facts remain honest to state. First, the gateway is Ownable (Foundation), so route management is Foundation-controlled, though a route can only point at a real verifier, never fabricate a pass. Second, registerAggProgram and registerInnerProgram are owner-only, so the set of aggregation programs the contract will route, and the human labels attached to inner digests, are Foundation-curated. The recognized counter reflects that curation and nothing stronger: an unrecognized-but-cryptographically-valid aggregation would still verify and record, it would simply show recognized < count. recordAggregation itself is permissionless: anyone holding a valid aggregation proof can record it without a Foundation signature.

---

10. Post-quantum note

The aggregation soundness rests on Groth16 over BN254 and on the SP1 recursion, both of which rely on classical hardness assumptions (elliptic-curve pairings and the underlying STARK-to-SNARK stack). They are not post-quantum. This is the standard trade for succinct, constant-size on-chain verification today. AERE's post-quantum hedging lives in a separate signature-verification suite (the Falcon, ML-DSA, SLH-DSA, and XMSS verifiers) rather than in the proof-aggregation path. A future migration of the succinct verifier to a post-quantum SNARK would be a wholesale swap of the concrete verifier behind the gateway, which the route-by-selector design is built to accommodate without redeploying the aggregator.

---

11. Roadmap

• Record n=16 on-chain (in progress) and confirm the on-chain gas stays anchored near the single Groth16 verify cost.
• Fold additional registered programs already wired into the host (eujur, accred) to widen the heterogeneous mix beyond the current three.
• Add an optional per-statement event index for consumers that need per-proof queryability without re-supplying inner data.
• Promote a documented batch-attestation flow (a scheduled aggregation of a period's application proofs) once organic proof traffic exists to batch.