aere-docs/AERE-BENCHMARK-REPORT.md

# Aere Network: Reproducible Benchmark Report (spec-18)

**Status date:** 2026-07-19
**Chain:** Aere Network mainnet, chain ID 2800 (Hyperledger Besu QBFT).
**Scope:** chain performance, zkVM proof-verification economics, and post-quantum
cryptographic-operation gas, stated with a hard separation between what is
freshly measured, what is cited from a committed repo artifact, and what still
needs a measurement command run.

## The absolute rule this report obeys

No performance number (TPS, latency, gas, proof size, proving time) appears here
unless it was either (a) freshly measured by running a command this session, or
(b) found in a committed repo artifact that is cited by path. Anything that
cannot be measured or sourced is written as a measurement command and marked
`[MEASURE]`. Anything sourceable only from memory and not yet confirmed against
code is marked `[VERIFY]`. A fabricated benchmark would be a catastrophic
failure of this document, so the labels below are load-bearing, not decoration.

### Label legend

| Label | Meaning |
|---|---|
| `[MEASURED-FRESH]` | Run by this report on this machine, output shown or summarized. |
| `[CITED: path]` | Value read from a committed repo artifact at the cited path. |
| `[MEASURE: cmd]` | Not measured here. The command that would measure it is given. |
| `[VERIFY: note]` | Sourceable but needs confirmation against live code or a live node. |

### Scope boundary that never moves

Aere Network validators sign classical secp256k1 QBFT consensus messages.
Nothing in this report makes Aere consensus post-quantum. The post-quantum work
is an application and account layer capability. Any claim of post-quantum
consensus would be false and is not made here.

---

## PART A: CHAIN PERFORMANCE

### A.0 The one honesty point, stated first

The "273,000 TPS" figure is an ARCHITECTURAL CEILING derived from block-space
arithmetic under ideal conditions. It is NOT the live mainnet transaction rate,
it has never been a measured result, and it is not asserted as one. Three
distinct quantities must never be conflated:

| Quantity | Value | Label |
|---|---|---|
| Architectural ceiling (design maximum) | ~273,000 TPS | `[CITED]`, explicitly labeled a ceiling |
| Testnet-measured L1 throughput | none exists | see A.1 |
| Live-mainnet-observed throughput | far below the ceiling, demand-limited | see A.1 |

`[CITED: aerenew/docs/WHITEPAPER-V2.md lines 73, 117, 633; aerenew/docs/wp2-sections/01-overview.md:59; 02-architecture.md:21; 09-governance-roadmap.md:294]`
The whitepaper states it verbatim: the block parameters "admit a design ceiling
on the order of 273,000 transactions per second; this is a theoretical maximum
implied by the gas and block configuration, not a measured or sustained figure,
and realized throughput on the live network is a small fraction of it." It is
described as "a design ceiling derived from block-space arithmetic under ideal
conditions" that "has never been a measured result."

**On the derivation itself.** The repo labels 273,000 as a block-space-arithmetic
ceiling but does not publish the explicit factors. The two facts that are
sourceable:

- Block period 0.5 s. `[CITED: aerenew/docs/wp2-sections/02-architecture.md:19; genesis-subsecond.json (blockperiodmilliseconds: 500)]`
- Genesis block gas limit is ambiguous across genesis artifacts: `0x2625a00`
  (40,000,000) in `aerenew/genesis.json`, versus `0x1fffffffffffff`
  (9,007,199,254,740,991, effectively unbounded) in `aere-genesis-current.json`
  and `genesis-subsecond.json`. `[VERIFY: which gas limit is live on 2800]`

Implied arithmetic (transparent, not a new claim): 273,000 TPS at a 0.5 s block
is 136,500 tx per block, and at the 21,000-gas simple-transfer floor that is
about 2.87 billion gas per block. That is far above the 40M limit and far below
the effectively-unbounded limit, so the ceiling presumes an effectively-
unbounded block gas limit AND the cheapest possible transaction, not the
EIP-7825-capped realistic workload the chain actually runs. `[VERIFY: publish the
explicit block-space arithmetic behind 273,000 so the ceiling is reproducible]`

### A.1 Testnet-measured and live-observed throughput (the honest gap)

**There is no testnet measurement that validates 273,000 TPS for L1.** The
closest measured throughput number in the repo is a rollup-executor
microbenchmark, and the artifact that produces it says plainly it neither
reaches nor implies the ceiling.

`[CITED: aerenew/parallel-executor/BLOCKSTM-ENDTOEND-THROUGHPUT-2026-07-13.md section 7]`
The Block-STM end-to-end harness measured about 247,000 to 270,000 TPS at
`gas=80` on a 16-vCPU box, but this is (a) the rollup executor with a light
commit proxy, not L1, not a real Merkle Patricia Trie, and (b) entirely a
function of the assumed per-transaction cost: the same box reports 115,000 to
500,000 TPS as the per-transaction weight changes. The `gas=80` proximity to
273,000 is called out in the artifact as a coincidence, not a validation.

**Live mainnet 2800 runs far below the ceiling, and this is by demand, not by
capacity.** `[CITED: aerenew/research/specs/spec-zk-stack.md section 0.2; aerenew/docs/wp2-sections/01-overview.md:59]`
On-chain usage is thin (single-digit proof records for most verifiers; six
genesis user wallets per project memory). Real throughput is demand-limited, not
capacity-limited: the chain has ample block-space headroom and almost no load to
fill it. `[MEASURE: sample a live window with eth_getBlockByNumber over N recent
blocks against https://rpc.aere.network and divide total tx by elapsed time to
publish an observed sustained TPS; expected result is near zero on an idle chain]`

### A.2 Block time and finality

Deterministic single-slot QBFT finality at a 0.5 s block period. Because QBFT
finalizes on commit rather than by accumulation of work, a transaction is
irreversible in well under a second from inclusion, with no confirmation count
and no reorg. `[CITED: aerenew/docs/wp2-sections/02-architecture.md:19]`

The 0.5 s period was reached by a mid-chain QBFT parameter change at block
2,138,451, halved from the launch value of one second, with no re-genesis.
`[CITED: aerenew/docs/wp2-sections/01-overview.md:59; aerenew/docs/WHITEPAPER-V2.md:73; genesis-subsecond.json (blockperiodseconds: 0, blockperiodmilliseconds: 500)]`

Finality is a latency-to-irreversibility claim and is separate from throughput.
The 0.5 s finality claim follows mechanically from QBFT plus the block period; it
says nothing about TPS.

### A.3 Parallel execution (Block-STM): the honest result

The honest result has three parts, and only the first is a mainnet-relevant
guarantee. No end-to-end L1 throughput win is claimed, and Block-STM is NOT
enabled on L1.

**(1) Correctness proven bit-identical to sequential.** `[MEASURED-FRESH]` This
session ran the executor's `bench` on this Windows dev machine. The
`parallel==sequential` gate (committed state and keccak state root identical to
the sequential oracle) passed on all four conflict profiles:

```
LOW-CONFLICT      parallel==sequential check: PASS
MEDIUM-CONFLICT   parallel==sequential check: PASS
HIGH-CONFLICT     parallel==sequential check: PASS
PATHOLOGICAL      parallel==sequential check: PASS
```

This corroborates the cited larger runs: a 6,000-comparison correctness harness
with 0 mismatches, and a re-import plus validation of 253 real exported blocks
with zero state-root mismatch. `[CITED: aerenew/parallel-executor/BLOCKSTM-ENDTOEND-THROUGHPUT-2026-07-13.md section 3 and section 8]`

**(2) Near-linear execution-phase scaling on parallelizable workloads.**
`[MEASURED-FRESH]` on this machine (fewer physical cores than the reference
16-core Linux box, so absolute speedup is lower, which is expected and honest):

| Workload (this box, 16 threads) | speedup vs sequential | abort% |
|---|--:|--:|
| Low-conflict (~2%) | 4.36x | 0.3% |
| Medium-conflict (~15%) | 4.96x | 2.3% |
| High-conflict (single hot counter) | 1.92x | 24.8% |
| Pathological (all same slot) | 0.43x (correctly slower) | 11.5% |

`[CITED: same artifact, section 4-5]` The reference 16-core Linux box measured
about 8.3x to 9.4x execution-phase and about 8.3x to 9.1x end-to-end on realistic
0 to 50 percent conflict. The pathological all-same-slot profile is honestly
slower than sequential (correct Block-STM behavior), on both boxes.

**(3) No end-to-end throughput win claimed, and not on L1.**
`[CITED: aerenew/research/specs/spec-parallel-execution.md section 9; BLOCKSTM-ENDTOEND section 7-8]`
The Aere L1 mainnet executes sequentially on Besu. The parallel executor is a
bounded four-kind VM (Transfer, Sweep, Increment, AmmSwap) over a balance and
storage map, not a full EVM, and its measured speedups are single-machine
microbenchmarks, not a network throughput or TPS claim. The real forked client's
commit path was separately measured to anti-scale (parallel commit was slower
than sequential), so the real-client end-to-end ceiling is tighter than the Rust
harness, not looser. The invariant deliverable is the correctness gate plus the
speedup curve and its Amdahl bound, not an absolute TPS.

---

## PART B: ZKVM COMPARATIVE (SP1 vs RISC Zero vs Halo2)

Every cell is labeled. Gas and proof-size values that are cited come from repo
deployment artifacts and are measured single-run values, not benchmarked
averages (the source spec states this explicitly). `[CITED: aerenew/research/specs/spec-zk-stack.md footer]`

### B.1 Comparison table

| Prover (version) | Proving time (off-chain) | On-chain gas to verify | Proof size | Verification latency |
|---|---|---|---|---|
| SP1 Groth16 (v6.1.0) | app-dependent, CITED single-runs: zkscreen ~72 to 75 s, over18 ~71 to 73 s, zkml-mnist ~200 to 205 s, aggregation Groth16 526.1 s `[CITED: contracts/deployments/proof-aggregator-scale.json]` | ~300k typical `[CITED: spec-zk-stack section 2]`; measured records: storage-proof 348,345, zkML 326,492, aggregation ~390k flat `[CITED: proof-aggregator-scale.json, zkml/storage-proof artifacts]` | ~260 to 356 bytes `[CITED: spec-zk-stack section 2]` | one staticcall, final at next block (~0.5 s) `[MEASURE: time eth_call wall-clock]` |
| SP1 Plonk (v6.1.0) | `[MEASURE: prove a fixture with the Plonk prover]` | "somewhat higher than Groth16" `[CITED: spec-zk-stack section 2]`, exact `[MEASURE]` | `[MEASURE]` | one staticcall `[MEASURE]` |
| RISC Zero Groth16 (5.0.0-rc.1) | `[MEASURE: r0vm prove the factor-guest]`, not recorded in repo | `[MEASURE: eth_call gas on RiscZeroVerifierRouter.verify]`, no gas number committed | seal 260 bytes `[CITED: contracts/deployments/risc0-verifier-fix.json sealLen]` | one staticcall `[MEASURE]` |
| Halo2 (bn254 / KZG, SHPLONK) | `[MEASURE: halo2 prover on the cubic circuit]` | ~449,517 gas `[CITED: contracts/deployments/halo2-cubic.json; spec-zk-stack section 6]` (revm gas ~300,144) | 1,152 bytes `[CITED: same]` | one call `[MEASURE]` |
| KZG / EIP-4844 point-eval precompile (0x0A) | n/a (precompile, no prover) | ~255,719 gas `[CITED: contracts/deployments/kzg-verifier.json; spec-zk-stack section 5]` | 192-byte precompile input `[CITED: same]` | one staticcall |

Notes on the two recursion facts worth keeping, both `[CITED: proof-aggregator-scale.json; spec-zk-stack section 7]`:
- A 10-proof recursive SP1 aggregation records on-chain in ~393,844 gas, roughly
  flat versus the 3-proof fold (~387,858 gas). Constant on-chain verification cost
  regardless of fold count is the point of recursion.
- The proving side of that same 10-fold cost 526.1 s for the aggregation Groth16
  plus 988 s of inner proving (measured, off-chain, single run).

### B.2 Routing logic (which prover for which job, and why)

`[CITED: aerenew/research/specs/spec-zk-stack.md sections 1-3, 7-11]` Routing is
by selector: the first 4 bytes of the proof pick the concrete verifier.

- `SP1VerifierGateway` routes SP1 proofs by leading selector (Groth16 route
  `0x4388a21c`, Plonk `0x5a093a2f`).
- `RiscZeroVerifierRouter` routes a RISC Zero seal by leading selector
  (`0xef6cb709` for 5.0.0-rc.1).

Which prover is chosen:

- **SP1 is the workhorse.** Every Aere application circuit routes through SP1:
  zk-KYC screen, over-18, zkML MNIST, compliance pool, storage-proof coprocessor,
  rollup validity anchor, and the recursive aggregator. The reason is concrete:
  smallest proofs (~260 to 356 bytes), lowest typical verify gas (~300k), one Rust
  guest toolchain, and native recursion via `verify_sp1_proof` inside the zkVM.
- **RISC Zero is the diversity path.** A second independent RISC-V zkVM, kept so
  the verification surface is not single-prover; a real Groth16 factorization
  receipt is recorded on-chain.
- **Halo2 / KZG is the direct-circuit path.** For circuits authored directly as a
  PLONK arithmetization (bn254 / KZG / SHPLONK), plus the raw EIP-4844
  point-evaluation precompile for blob and commitment openings.

The honest framing the source insists on: this is a multi-prover verification
surface behind one gateway, unusual to have in one place, but not a claim that no
other chain can verify any one of these.

### B.3 Why the on-chain-gas column motivates the STARK-verifier roadmap

SP1 Groth16, RISC Zero Groth16, and Halo2 all terminate their on-chain check in a
**BN254 pairing** (Groth16 or KZG). Two problems live in that column: the check
costs ~300k to ~450k gas, and BN254 pairing security rests on
discrete-log / pairing hardness, which is **Shor-breakable**. That single
elliptic-curve link is the only quantum-vulnerable step in an otherwise
hash-based SP1 proof chain.

Roadmap item: replace the BN254 Groth16 wrap with a direct hash-based STARK
verifier. `[CITED: aerenew/pqc-fork/pq-stark/README.md; aerenew/docs/PQ-STARK-VERIFIER-PRECOMPILE-2026-07-18.md]`
The design is a native precompile at `0x0AE8`. The generic verifier skeleton built
so far verifies a BabyBear / Plonky3 FRI STARK directly, with no BN254 wrap, so its
security rests only on hash collision-resistance and Reed-Solomon proximity gaps.

**Scope caveat (2026-07-19 research finding)** `[CITED: aerenew/docs/AERE-STARK-SP1-RECURSION-AIR-PORT-SPEC-SUMMARY.md]`:
the six generic components confirmed so far verify **BabyBear + FRI STARKs**
(Aere's OWN Plonky3 circuits), NOT SP1 6.1.0 proofs. The pinned SP1 6.1.0 is a
**Hypercube** release (KoalaBear multilinear: BaseFold plus sumcheck-zerocheck
plus LogUp-GKR), so its inner proof is hash-based but NOT a BabyBear FRI STARK, and
FRI plus DEEP-ALI do not apply to it. Replacing the SP1 BN254 Groth16 wrap on real
SP1 proofs is therefore a SEPARATE ~22 to 32 person-week retarget and a founder
decision, not a completion of the skeleton below.

**Honest status of that roadmap item, stated plainly** `[CITED: same README, "HONEST STATUS"]`:
it is a REFERENCE SKELETON plus DESIGN. It is NOT audited, NOT a working
verifier for SP1 proofs, and NOT activated on any Aere network. It fail-closes
(returns "not verified" for every input, cannot emit a false accept). The
SP1-recursion-specific crypto core is un-ported, and per the caveat above the
SP1 target is a different (Hypercube) proof system entirely. Mainnet 2800 has
exactly the five PQC precompiles `0x0AE1..0x0AE5`; `0x0AE8` is not live anywhere.

---

## PART C: CRYPTO-OP GAS (PQC vs ECDSA)

### C.1 Table (measured marginal precompile verify-op gas, with sources)

| Operation | Address | Marginal gas | Full verify-and-record tx gasUsed | Source |
|---|---|--:|--:|---|
| ECDSA (ecrecover) | 0x01 | ~3,000 | n/a | protocol constant `[VERIFY: G_ecrecover = 3000 is a fixed EVM constant, not Aere-specific]` |
| P-256 / passkey (RIP-7951, aka RIP-7212) | 0x100 | ~3,450 | n/a | `[CITED: aerenew/docs/wp2-sections/02-architecture.md:36; aerenew/research/aip-draft-pqc-precompiles.md section 4, "repo-sourced from the Fusaka notes"]` |
| SHAKE256 (FIPS 202) | 0x0AE5 | 60 base + 12/word | 21,470 | `[CITED: aerenew/pqc-fork/precompiles/HashToPointPrecompiledContract.java lines 51-52 (BASE_GAS=60, GAS_PER_WORD=12); aip-draft section 3 table]` |
| Falcon-512 (NIST round-3) | 0x0AE1 | 40,000 | 86,336 | `[CITED: aip-draft section 4 and Reference table]` |
| ML-DSA-44 (FIPS 204) | 0x0AE3 | 55,000 | 351,050 | `[CITED: aip-draft section 6 and Reference table]` |
| ML-KEM-768 (FIPS 203, encapsulation) | 0x0AE6 | 60,000 (fixed) | n/a (KEM, testnet-only) | `[CITED: aerenew/pqc-fork/precompiles/MLKEM768PrecompiledContract.java line 73 (GAS = 60_000)]` |
| Falcon-1024 (NIST round-3) | 0x0AE2 | 75,000 | 145,496 | `[CITED: aip-draft section 5 and Reference table]` |
| SLH-DSA-SHA2-128s (FIPS 205) | 0x0AE4 | 350,000 | 558,276 | `[CITED: aip-draft section 7 and Reference table]` |

All marginal-gas values are the scratch-fork (chain 28099) measured constants;
the verify-and-record tx gasUsed values are on-chain receipts. `[CITED: aerenew/research/aip-draft-pqc-precompiles.md Reference Implementation table]`
The five signature and hash precompiles (`0x0AE1..0x0AE5`) are live on mainnet
2800, activated at block 9,189,161. ML-KEM-768 (`0x0AE6`) and Falcon HashToPoint
(`0x0AE7`) are KAT-validated on an isolated testnet and remain founder-gated for
mainnet. `[CITED: aerenew/pqc-fork/README chain, pqc-fork memory]`

Scope reminder attached to this table: these precompiles are an application and
account layer capability. They do not make Aere consensus post-quantum.

### C.2 Two fresh cross-checks run this session

`[MEASURED-FRESH]` The SHAKE256 gas schedule (60 base plus 12 per word) is
confirmed present in source, and the HashToPoint precompile's own gas was freshly
computed from that exact source formula (`gasRequirement`, lines 78-93):

```
Falcon-512  (n=512)  32-byte message, 73-byte input:  words=38  -> gasRequirement = 516
Falcon-1024 (n=1024) 32-byte message, 73-byte input:  words=73  -> gasRequirement = 936
```

516 gas matches the source javadoc's "one ~500-gas staticcall" claim, which is
the mechanism by which HashToPoint cuts a full Solidity Falcon-512 verify. This
is the precompile's own intrinsic gas; it is distinct from the end-to-end verify
gas below, and the two must not be conflated.

`[CITED: aerenew/pqc-fork/results/bench-results.json]` The HashToPoint-precompile
optimization measured on the scratch fork (chain 28777), full Falcon-512 verify:
9,140,858 gas in pure EVM dropping to 7,186,367 gas with the precompile, a 21.4
percent reduction across 8 test vectors, all accept and tamper-reject checks
passing.

### C.3 The honest story the numbers tell

Post-quantum verification is materially more expensive than ECDSA. Ratios below
are fresh arithmetic from the cited marginal-gas constants divided by the
3,000-gas ecrecover:

| Scheme | Marginal gas | Cost vs ECDSA (3,000) |
|---|--:|--:|
| Falcon-512 | 40,000 | ~13.3x |
| ML-DSA-44 | 55,000 | ~18.3x |
| ML-KEM-768 | 60,000 | ~20.0x |
| Falcon-1024 | 75,000 | ~25.0x |
| SLH-DSA-SHA2-128s | 350,000 | ~116.7x |

So PQC verification runs roughly 13x (Falcon-512) to about 117x
(SLH-DSA-SHA2-128s) the cost of an ECDSA recover. That premium is exactly what
motivates two roadmap directions:

- **Aggregation.** Amortize one expensive PQC verify across many authentications
  rather than paying per signature. `[VERIFY: the specific "AerePQAggregate"
  contract name is not found in the repo; PQC aggregation is a documented roadmap
  direction, see aerenew/docs/FRONTIER-PROGRAM-2026-07-12.md]`
- **Finality certificate.** Carry post-quantum finality as a certificate over a
  finalized block rather than re-verifying PQC signatures per transaction. This
  ties to the dual-quorum PQ-consensus design work. `[CITED: aerenew/docs/PQ-CONSENSUS-STEP2-2026-07-18.md]`
  Note the scope line: this is design and attestation alongside QBFT, it does not
  make consensus post-quantum.

---

## PART D: INDEPENDENT REPRODUCTION

### D.1 The strongest benchmarks should be third-party reproduced

The credibility of every number above rises sharply when a party other than Aere
reruns it. The honest reproduction candidates, in priority order:

- **The Nethermind team (warmest angle).** Aere already runs a patched Nethermind
  as a second client that validates and follows live chain 2800, and it runs the
  PQC precompiles and can produce QBFT blocks Besu accepts. `[CITED: aerenew/docs/wp2-sections/09-governance-roadmap.md:199, 253; NETHERMIND-2ND-CLIENT-LIVE memory]`
  That existing relationship makes them the natural first ask for an independent
  client-side reproduction of the precompile gas and the consensus behavior.
- **A university lab.** Cheap under a research grant and citable in a way a vendor
  benchmark is not; a good fit for the Block-STM correctness-and-scaling harness
  and the zkVM proving-time measurements, which are self-contained and need no
  Aere infrastructure.
- **Explicitly NOT the expensive audit firms.** The audit-firm budget is reserved
  for the security audit, which is a different deliverable from a performance
  reproduction. `[CITED: aerenew/docs/mainnet_authority context; AUDIT-OUTREACH-2026-07-12.md]`

The outreach kit is prepared by us. The actual third-party run and the
relationship are founder and business gated, not something this report initiates.

### D.2 The run-it-yourself manifest (REPRODUCE)

This report is the NUMBERS and how they were measured. The run-it-yourself
commands live in the reproducibility bundle. Today that bundle is split across
several committed files rather than one consolidated `REPRODUCE.md`; the honest
recommendation is to consolidate them, but each is real and runnable now:

| Domain | Where to run it | File |
|---|---|---|
| Block-STM correctness + scaling (Part A.3, freshly run here) | `cd aerenew/parallel-executor && cargo test --release && cargo run --release -- bench` and `-- endtoend` | `aerenew/parallel-executor/BLOCKSTM-ENDTOEND-THROUGHPUT-2026-07-13.md` section 10 |
| PQC precompile KATs + gas (Part C) | `aerenew/pqc-fork/run-kats.sh`, `aerenew/pqc-fork/bench/bench.py` | `aerenew/pqc-fork/` (results in `results/bench-results.json`, `results/kat-results-*.json`) |
| Reproducible Besu client build | `docker build ... -f aerenew/node/Dockerfile.reproducible` then `aerenew/scripts/verify-besu-image.sh` | `aerenew/node/REPRODUCIBLE.md` (note: public digest manifest publication is still roadmap, so the third-party comparison step is not yet live) |
| PQ-consensus reproduction | committed harness | `aerenew/research-stage/formal-consensus/REPRODUCE.md`, `aerenew/audit-package-pq-consensus/REPRODUCE.md` |

`[MEASURE: create a single top-level aerenew/REPRODUCE.md that indexes all four
domains above with pinned commands, so a third party has one entry point]`

---

## Appendix: provenance summary of every number

**Freshly measured this session `[MEASURED-FRESH]`:**
- Block-STM `parallel==sequential` gate: PASS on all 4 conflict profiles (this Windows box).
- Block-STM 16-thread execution-phase speedup this box: low 4.36x, medium 4.96x, high 1.92x, pathological 0.43x.
- HashToPoint precompile intrinsic gas from source formula: 516 gas (Falcon-512, 32-byte message), 936 gas (Falcon-1024).

**Cited from committed repo artifacts `[CITED]`:**
- 273,000 TPS is a design ceiling, never measured (WHITEPAPER-V2, wp2-sections).
- 0.5 s block period, halved at block 2,138,451, single-slot QBFT finality (wp2-sections, genesis-subsecond.json).
- Rollup end-to-end harness ~247k to 270k TPS at gas=80, swinging 115k to 500k, not the L1 ceiling (BLOCKSTM-ENDTOEND section 7).
- Reference 16-core Block-STM ~8.3x to 9.4x exec, ~8.3x to 9.1x end-to-end (same artifact).
- SP1 Groth16 ~300k gas, ~260 to 356 byte proofs; measured records storage-proof 348,345, zkML 326,492, aggregation ~390k (spec-zk-stack; deployment artifacts).
- SP1 proving times: zkscreen ~72 to 75 s, over18 ~71 to 73 s, zkml-mnist ~200 to 205 s, aggregation Groth16 526.1 s (proof-aggregator-scale.json).
- RISC Zero Groth16 seal 260 bytes, 5.0.0-rc.1 (risc0-verifier-fix.json).
- Halo2 ~449,517 gas, 1,152-byte proof; KZG point-eval ~255,719 gas (deployment artifacts, spec-zk-stack).
- PQC marginal gas: Falcon-512 40,000, Falcon-1024 75,000, ML-DSA-44 55,000, SLH-DSA-128s 350,000, ML-KEM-768 60,000, SHAKE256 60+12/word; verify-and-record tx: 86,336 / 145,496 / 351,050 / 558,276 / 21,470 (aip-draft, precompile source, bench-results.json).
- P-256 ~3,450 gas (wp2-sections, aip-draft).
- HashToPoint optimization 9,140,858 to 7,186,367 gas, -21.4% (bench-results.json).

**To measure `[MEASURE]` or verify `[VERIFY]` (open items):**
- `[MEASURE]` Observed live mainnet sustained TPS over a real block window.
- `[MEASURE]` SP1 Plonk proving time, gas, proof size.
- `[MEASURE]` RISC Zero on-chain verify gas and proving time.
- `[MEASURE]` Halo2 proving time.
- `[MEASURE]` Wall-clock verification latency per prover.
- `[MEASURE]` Consolidated top-level aerenew/REPRODUCE.md.
- `[VERIFY]` The explicit block-space arithmetic behind 273,000 TPS.
- `[VERIFY]` Which genesis gas limit is live on 2800 (40M vs effectively unbounded).
- `[VERIFY]` ECDSA ecrecover 3,000 is a fixed protocol constant (not Aere-specific).
- `[VERIFY]` The "AerePQAggregate" contract name (not found in repo; aggregation is a documented roadmap direction).