aere-research/results/PROVEN-RESULTS-2026-07-11.md

# AERE Network: Proven Results (status as of 2026-07-11)

> **UPDATE (2026-07-16): two facts in this 2026-07-11 snapshot have since changed on
> mainnet and are corrected inline below.** (1) The validator set has grown from 3 to
> **7 QBFT validators** (f=2, quorum 5-of-7), confirmed live via
> `qbft_getValidatorsByBlockNumber`; still one operator, one client (Besu). (2) The
> native PQC precompiles (band `0x0AE1`-`0x0AE5`) and the extended EIP-2935 block-hash
> lookback are **now LIVE on mainnet**, activated at block 9,189,161. Where the body
> below says "3 validators" or "precompiles inactive on mainnet," read the corrected
> value. Everything else in this snapshot still holds. Consensus remains classical
> secp256k1 QBFT (not post-quantum); no external audit yet.

**Chain:** AERE Network mainnet, chain ID 2800 (Hyperledger Besu QBFT, ~0.5s blocks, 7 validators / f=2 as of 2026-07-16 [was 3 at this snapshot], single operator, one client).
**Source of truth for canonical addresses:** `sdk-js/src/addresses.ts`.
**Purpose:** one honest reference of what is actually real, at what scope, with the on-chain evidence and the explicit testnet-versus-mainnet, staged, and proof-of-approach boundaries. Nothing here is a marketing figure. Every measured number is from a repo artifact, an on-chain transaction, or a captured session log. Where a capability is demonstrated on an isolated testnet or scratch fork rather than on mainnet chain 2800, that is stated in the same breath as the result.

This document does not claim anything that mainnet chain 2800 does not do today, except where a result is explicitly labeled TESTNET, SCRATCH-FORK, or STAGED.

---

## 0. The honesty baseline that applies to everything below

AERE runs seven QBFT validators (f=2, quorum 5-of-7; three at the 2026-07-11 snapshot) under a single operator, one execution client (Hyperledger Besu), and has had no external security audit of its AERE-authored contracts or client changes. Real usage is thin. Consensus on mainnet is classical secp256k1 QBFT and is not post-quantum. Every result below sits on that foundation and is scoped against it. The strong results are real; the boundaries are real too.

---

## 1. Consensus post-quantum quorum certificate (TESTNET demonstration)

**What is proven.** A real gossiped `>= 2f+1` Falcon-512 quorum certificate, embedded in every block, verified by every node on import, and **blocking after a fork block**, demonstrated on an isolated N=4 QBFT testnet. Each validator holds a fresh Falcon-512 keypair and Falcon-signs the same commit hash the ECDSA committed seal signs, piggybacking the seal on the QBFT commit message; the block creator re-verifies, de-duplicates, and embeds the set of distinct valid seals as the block's certificate. ECDSA committed seals remain the decisive safety and liveness seal throughout.

**Evidence (isolated N=4 testnet, fresh keys, isolated chain, 2s blocks, Falcon fork block 20).**
- Full consensus unit suite green after the change (`consensus:common`, `consensus:qbft-core`, `consensus:qbft`).
- Block-hash preservation: the certificate is excluded from every signed pre-image, so a header is byte-identical to upstream with or without the certificate. Proven three ways (committed-seal and block-hash pre-images identical, `FalconAudit` on real headers, byte-identical stored encoding when empty).
- Healthy run #1: 229 blocks, all 4 nodes agreed at every height, blocks 20 onward post-fork BLOCKING each with a valid 3-of-4 certificate, 0 rejects, exact 2s cadence. Run #2: reproduced from fresh genesis.
- `FalconAudit` on real post-fork headers: the certificate validator set equals the ECDSA committer set on each block (proving genuinely gossiped, per-block-varying seals, not a static self-seal); genuine 9/9 ACCEPT, tampered-signature 9/9 REJECT, tampered-commit-hash 9/9 REJECT.
- Negative tests: (a) tamper one Falcon seal rejects it; (c) one validator with a wrong Falcon key, the chain still finalizes via the honest quorum with transient single-block retry, no halt; (b) two bad signers (more than f), the post-fork chain correctly HALTS at block 353 because the Falcon quorum cannot form, while an ECDSA quorum still existed. That halt is the blocking rule working as designed.

**Honest scope.** This is a TESTNET demonstration only. Mainnet chain 2800 consensus is classical secp256k1 QBFT and is NOT post-quantum; this work does not change what mainnet validators sign. Making the Falcon quorum blocking raises the liveness requirement to `2f+1` Falcon-valid validators and is most acute at small N (at N=4 a single faulty Falcon signer forces all three honest validators to commit each block). The recommendation is to ship the always-on additive certificate (log-only, full gossip and verification) and to defer blocking activation until the validator set has slack over the quorum (N >= 7). Blocking must not be activated on chain 2800 without an explicit founder go.

**Artifacts:** `consensus-pqc/` (`QUORUM-DESIGN.md`, quorum patch, run logs), held in the internal working repository and not published.

---

## 2. Full-EVM validity: real revm-in-SP1 proofs of real chain-2800 blocks

**What is proven.** A real AERE mainnet block, re-executed with the real `revm` execution stack (SP1-patched `reth` 1.9.3 / `revm`, tag `reth-1.9.3-sp1-6.1.0`, SP1 v6.1.0) inside the SP1 zkVM, reproduces the canonical post-state root, and the resulting Groth16 proof verifies on chain 2800 through the live SP1 gateway. Full opcode set, call frames, `SLOAD`/`SSTORE`, `LOG`, EIP-1559 fee split, and the Cancun/Prague/Osaka system calls all execute and all affect the proven root. This is the real EVM, not a bounded subset.

**On-chain evidence (mainnet chain 2800).**
- Single block, `AereEVMValidity` `0x1f2CB0ebDBb21500e99868DbF1dB3abCcDd7DF26` (canonical in `sdk-js/src/addresses.ts`): block **9073073** recorded via `recordBlock` tx `0xb28a39507f8c03e6ffcfed307f9848814dd9d35268f01983825b658cbc56415c` (submit block 9074454, status 1), gasUsed 460,015, well under the EIP-7825 per-transaction cap of 16,777,216. A second block **9075035** was proven fresh in the same session. Tamper test: flipping one byte of `postStateRoot` makes the on-chain-equivalent verifier reject the proof.
- 16-block contiguous batch, `AereEVMValidityBatch` `0x49D30a5999eA5b7f6eFf12196AB006316683Ff3C` (canonical): real chain-2800 blocks **9111008..9111023** proven in one Groth16 (batch program vkey `0x00418c4f40178103cc75ae57b63703f6075cabdce23582fed6043ceae819192e`), each block's recomputed post-state root threaded into the next block's pre-state, recorded via `recordBatch` tx `0x074a4e6c17855b78db4c56808e253d4c00a7b392cf0d141e4aa0e6e299ded9ec` (submit block 9114536, status 1), gasUsed 460,817, under the cap.

**New this session: dense workload proof (removes the low-tx-density caveat at demonstrated scale).** Historical mainnet blocks are low-density and the live node prunes state (Bonsai), which limited earlier witnessable batches to a handful of transactions. To remove that caveat, a genuinely dense real-EVM workload was proven with the same batch prover and verified read-only against the same live mainnet gateway:
- A single ultra-dense block with **155 real transactions and 460 SSTOREs** (52 freshly-created EOAs, 52 fresh ERC-20 holder slots), 29,572,987 guest cycles: local SP1 Groth16 verify PASS, tampered `postStateRoot` REJECTED; the live mainnet SP1 gateway `0x9ca479C8c52C0EbB4599319a36a5a017BCC70628` accepted the real proof read-only and reverted both a tampered-public-values and a tampered-proof call.
- A 2-block contiguous, state-continuity-chained dense batch (310 txs, 920 SSTOREs, 27,050,310 gas, 61,366,308 cycles; the guest enforces `post_root(N) == header.stateRoot` and `pre_root(N+1) == post_root(N)`): same live-gateway acceptance read-only, both tampers reverted.
- These proofs bind to the same batch-program vkey the mainnet batch anchor uses. No mainnet transaction was sent; verification was `eth_call` only.

**Honest scope.**
- This is a **proof-of-approach on real blocks, not a continuous production rollup cadence.** The mainnet-recorded blocks and batch are real chain-2800 blocks but small; the anchors record isolated proven blocks and ranges rather than a sequenced chain. There is no sequencer, no forced inclusion, no data-availability commitment, and no withdrawal settlement.
- The dense workload is an **isolated, engineered** dense chain produced on a throwaway single-validator node running the AERE fork profile (chain-config 2800), in archive mode so heavy state is witnessable. It is NOT a replay of historical mainnet blocks. Its value is to remove the "low tx density" limitation at the demonstrated scale (roughly two full-density blocks / ~61M cycles was the practical ceiling on the box used; a longer dense batch is a pure prover-resource matter, not an approach question). Compatibility was confirmed: the reth-in-SP1 guest reproduced Besu 26.4.0's exact `header.stateRoot` for every dense block, the same agreement already established on real chain-2800 blocks.
- **Canonical pre-state binding V2, CORRECTED 2026-07-14: LIVE, not staged, and unused.** This bullet originally said V2 "must not be deployed yet." That was true when written (2026-07-11) and is no longer true: the AerePQC `futureEips` fork activated at mainnet block 9,189,161 (bringing EIP-2935 history storage live), and `AereEVMValidityV2` (`0x4884ad66…768D9B`, deploy block 9,257,558) and `AereEVMValidityBatchV2` (`0xe154B899…9E690aE`, deploy block 9,257,566) were then deployed with the re-proved vkeys wired in, per the sequence this document's own §"Conclusion / go condition" in `rollup-evm-validity/NOTE.md` specified. Verified live on 2026-07-14 via a direct `eth_getCode` read against `https://rpc.aere.network` (non-empty bytecode both addresses) and a `PROGRAM_VKEY()` read-back matching `sdk-js/src/addresses.ts` exactly. The V1 anchors above remain honest about attesting only self-consistent execution; V2 now genuinely binds to the canonical chain. **However, live reads of both V2 contracts on 2026-07-14 show `provenCount() == 0` on each**, no `recordBlock` or `recordBatch` call has actually succeeded against either V2 contract yet, despite `addresses.ts`'s inline comment on `AereEVMValidityV2` claiming "batch path proven, see AereEVMValidityBatchV2." That comment is stale/inaccurate as of this correction; treat the V2 canonical-binding pipeline as deployed but never yet exercised end-to-end on mainnet. See the "2026-07-14 reconciliation" section of the internal `VALIDITY-ROLLUP-SEQUENCER-PLAN.md` (not published) for the full picture, including a separate, still-open gap: no batch-guest source (the program behind the 320-byte `AereEVMValidityBatchV2` layout) is checked into this repo at all, only the single-block guest is.
- The crypto is classical (SP1 Groth16 over BN254, classical QBFT keys); this validity path is not itself post-quantum.

**Artifacts:** `rollup-evm-validity/` (host/guest/spec), `dense-batch-2026-07-11/` (dense proofs + gateway verifications), `NOTE.md` (V2 staging), `contracts/deployments/evm-validity*.json`. These are held in the internal working repository and are not published; the on-chain transactions and addresses cited above are independently checkable against chain 2800 without them.

---

## 3. Recursive proof aggregation at scale (LIVE on-chain, n=10)

**What is proven.** Ten real, heterogeneous inner SP1 proofs, drawn from three distinct real production programs (zkscreen sanctions-screening, over18 age credential, zkml-mnist inference), folded into a single Groth16 proof and verified once on-chain. The aggregator recomputes a composite digest from caller-supplied inner data and requires it to equal the proof's committed output, so a caller cannot lie about which programs were folded.

**On-chain evidence (mainnet chain 2800).** `AereProofAggregator` `0x6a260238890E740dB12b371E0C5d17a2470F84C5` (canonical, owner Foundation).
- n=10 record tx `0xd1fd4d60635fbafe8b269ea156a6bbc65e2b6ff8b886eb7910569a9c9344d978`, block 8930005, gasUsed **393,844**, read-back `count = 10`, `recognized = 10`.
- n=3 record tx `0xde4c102ab86567bfb7b384a784c049bf6ded33378e0b71acc0bfe97b7b8d4b39`, block 8811943, gasUsed **387,858**.
- On-chain cost is essentially flat in N: raising N by 3.3x raised gas by about 1.5%, because the cost is dominated by the fixed Groth16 verification, not by the number folded. Tamper checks: a tampered proof reverts, and dropping one child (so the recomputed composite no longer matches) reverts.

**Honest scope.** This is a proof-of-approach attestation aggregator, not a production rollup batcher. The inner statements in the scale run are deterministically derived for the demonstration, not organic traffic from ten distinct users (the ELFs are the real programs, checked byte-for-byte against their on-chain vkeys before folding). Proving is heavy and off-chain (about 1549s wall time for n=10). No run beyond n=10 is recorded on-chain yet (n=16 in progress). Soundness rests on Groth16 over BN254 and the SP1 recursion, which are classical, not post-quantum.

**Artifacts:** `research/specs/spec-recursive-aggregation-scale.md`, `contracts/deployments/proof-aggregator*.json`.

---

## 4. Parallel execution: Block-STM executor and forked-client commit prototype (TESTNET / benchmark)

**What is proven.**
- A real from-scratch Block-STM optimistic-concurrency parallel executor (`aere-block-stm`, Rust, zero external dependencies) that executes a transaction batch across many cores and commits a keccak256 state root **bit-identical to sequential execution**. Correctness is proven over **6000 randomized adversarial comparisons with zero mismatches** (6 workload profiles x 200 batches x {1,2,4,8,16} threads), including fully-conflicting adversarial cases.
- Measured execution-bound speedup on a 16-core box is roughly **8.6x to 9.3x** on low and medium-conflict batches (versus the single-threaded sequential oracle), degrading gracefully to about 4.6x under a hot single-counter and correctly falling below 1.0x on a pathological all-conflict batch where no parallelism exists.
- New this session: a parallel state-root **commit** prototype in the forked Besu client (Bonsai world-state), self-checked to produce a commit root **bit-identical to the sequential-commit root** across correctness reps (independent transfers, commit-heavy SSTORE, deletions, mixed kitchen-sink).

**Honest boundary (the important part).** The state-root COMMIT does **not** parallelize for a throughput win: it is measured to be allocation and memory-bandwidth bound, and adding commit worker threads (widths 2 to 16) makes it slower than a single worker, not faster. What does help is a single-threaded commit rewrite: at width 1 the AERE commit is roughly **2x cheaper than the stock parallel-trie commit** (for example, on medium tries about 316.98ms stock versus 142.38ms at width 1). End-to-end, Block-STM execution plus the width-1 commit gives a modest win on commit-heavy load (about 1.27x to 1.42x versus stock sequential exec plus sequential commit), and the real execution-side win is the ~9x above. An end-to-end network throughput win is gated on real execution-heavy load, and none of this runs on mainnet.

**On-chain adjacent (live).** `AereBlockSTMRegistry` `0x98E2C3e615841919d173D8FF642514c5902E8A28` is a live, advisory, opt-in hint registry (holds no funds, changes no execution semantics, has no L1 consumer yet). The bounded-VM validity anchor `AereRollupValidity` `0x38772063572DF94E90351e44ccbBEefD5F497fbd` has epoch 0 recorded from a real proof of the same deterministic executor.

**Honest scope.** AERE L1 (Besu) executes **sequentially** on mainnet today; nothing here changes that. The speedups are single-machine microbenchmarks, not TPS or network-throughput claims. Promoting Block-STM into base consensus is a multi-month Java-client effort; the commit prototype and benchmark are a research control surface, not a mainnet-active feature.

**Artifacts:** `parallel-executor/` (published in this repository, including the end-to-end throughput report and its raw run logs), `research/specs/spec-parallel-execution.md` (published). The forked-client commit patch and its benchmark logs are held in the internal working repository and are not published.

---

## 5. Native PQC precompiles and EIP-2935 lookback in the Besu fork (SCRATCH-FORK, staged for mainnet)

**What is proven.** A fork of Hyperledger Besu 26.4.0 (source tag 26.4.0, commit `d2032017`) adds five native precompiles wrapping the audited Bouncy Castle 1.83 BCPQC verifiers already on the client classpath (Falcon-512, Falcon-1024, ML-DSA-44 FIPS 204 internal, SLH-DSA-SHA2-128s FIPS 205 internal, SHAKE256 FIPS 202), introducing zero new dependencies and zero hand-rolled cryptography, plus a native EIP-2935 8191-block history-storage lookback written by consensus. Every scheme is validated against the same official NIST KAT and ACVP vectors the pure-Solidity verifiers use, positive and negative, including 15/15 ML-DSA-44 ACVP cases and 14/14 SLH-DSA-SHA2-128s ACVP cases (12 negatives each).

**Measured on the isolated scratch fork (chain 28099), full verify-and-record transactions:** Falcon-512 86,336 gas; Falcon-1024 **145,496** gas (0.87% of the 16,777,216 cap); ML-DSA-44 **351,050** gas (2.09%); SLH-DSA-SHA2-128s 558,276 gas; SHAKE256 21,470 gas. This moves the two schemes that are view-only in pure Solidity on mainnet (Falcon-1024 at roughly 21.7M gas, ML-DSA-44 at roughly 52.9M gas) to record-on-chain with wide margin.

**Keyless statefork rehearsal against real 2800 state.** On the infra host, a keyless two-axis rehearsal (no real validator keys copied anywhere, verified) confirmed a second non-validating follower running the fork binary validated the real 2800 chain to head under the fork's rules, and an isolated single-validator network proved the five PQC precompiles plus EIP-2935 activate on Osaka-format blocks (futureEips activated at block 182: precompiles inactive before, active after; Falcon-1024 gasUsed 172,720, ML-DSA-44 351,970, records=1; EIP-2935 history read equals the actual block hash; block format identical before and after). The live node was untouched.

**Honest scope.** These precompiles and the EIP-2935 write path are **STAGED for a supervised mainnet fork (the AerePQC futureEips activation), NOT active on chain 2800 today.** On mainnet the reserved precompile band addresses are empty, Falcon-1024 and ML-DSA-44 remain view-only in pure Solidity, and the EIP-2935 history contract has no code (the deployed anchor falls back to the 256-block `blockhash()` window). Activation is a coordinated, client-only, flag-day hard fork with no re-genesis and no state migration, and must be externally audited before it secures material value. It requires an explicit founder go.

**Artifacts:** `research/aip-draft-pqc-precompiles.md`, `research/specs/spec-eip2935-lookback.md`, and `statefork-test-results/` (internal working repository, not published).

---

## 6. Application and account layer PQC verifier suite (LIVE on-chain)

**What is proven.** A suite of post-quantum signature verifiers, in pure Solidity on the live chain's own EVM, covering both families NIST is standardizing: the hash-based WOTS+, XMSS-SHA2_10_256 (RFC 8391), and SLH-DSA-SHA2-128s (FIPS 205), and the lattice-based Falcon-512, Falcon-1024 (NIST round-3), and ML-DSA-44 (FIPS 204). Each is validated bit-for-bit against official NIST KAT or ACVP fixtures committed to the repository, in both directions (valid vectors accept, crafted-invalid vectors reject). Four of the six record a full verification on-chain within the EIP-7825 per-transaction gas cap (XMSS 1,561,963 gas; SLH-DSA 1,812,066 gas; Falcon-512 demonstrated inside a full ERC-4337 userOp at 10,278,313 gas and hybrid auth at 10,299,873 gas; WOTS+ well under the cap). Falcon-1024 and ML-DSA-44 are verifiable today as read-only `eth_call` views because a recording transaction would exceed the cap in pure Solidity (this is the exact gap the precompile fork of section 5 closes).

On top of the verifiers sit a hybrid ECDSA-plus-Falcon-512 authorizer and a Falcon-512-owned ERC-4337 smart account, both recording on-chain.

**Honest scope.** This is application-layer and account-layer post-quantum security. It does not make consensus post-quantum; mainnet validators still sign classical secp256k1 QBFT. The verifiers are unaudited (their assurance rests on bit-for-bit agreement with the official NIST vectors and independent from-scratch cross-checks, which is strong evidence of correctness but is not an audit). Only the smallest ML-DSA and SLH-DSA parameter sets and only the internal interfaces are implemented. With those caveats stated honestly, and to the best of our present knowledge, we are not aware of any other public chain that verifies all of these on-chain.

**Canonical addresses (verbatim from `sdk-js/src/addresses.ts`):** AerePQCVerifier `0x1cE2949e8cE3f1A77b178aF767a4455c08ec6F82`, AereXmssVerifier `0x77b14E264D0bb08d304d4e0E527F0fCdFc88B112`, AereSphincsVerifier `0xAfFc9F8d950969b46b54e77758BbFf7e000c87e6`, AereFalcon512Verifier `0x4E8e9682329e646784fB3bd01430aA4bA54D8fFC`, AereFalcon1024Verifier `0xF0aFA59BaB2058e4B6e6B424b7f76750F1F66e36`, AereMLDSA44Verifier `0xf1F7A6Acd82D5DAf9AF3166a2F736EE52C5F85AE`, AereHybridAuth `0xc20390C9656ECe1AE37603c84E395bC898b3FAA1`, AerePQCAccountFactory `0xd5315Ea7caa60d320c4f34b1bEd70dd9cc02CE58`.

**Artifacts:** `research/pqc-onchain-verification.md`, `aips/AIP-4.md`.

---

## 7. Proof of reality: independent adversarial read-only sweep of mainnet 2800

An independent adversarial read-only sweep of mainnet chain 2800 returned **zero claim violations**. Specifically, and consistent with everything above:

- The SP1 gateway `0x9ca479C8c52C0EbB4599319a36a5a017BCC70628` verifies real proofs and rejects tampered ones.
- Recorded validity batch roots equal the canonical block `stateRoot` values.
- Block time is about **0.506s**, there were **3 validators** at this 2026-07-11 snapshot (now **7**, f=2, per the update banner), and the native token supply is exactly **2,800,000,000 AERE**.
- At this snapshot the PQC precompiles were **inactive** on mainnet. **This has since changed:** the native PQC precompiles (band `0x0AE1`-`0x0AE5`) and the extended EIP-2935 lookback were activated on mainnet at block 9,189,161 and are now live. The section 5 "staged, not live" wording reflects the 2026-07-11 state, not the current one.

The sweep confirms the split this document draws throughout: the live-on-mainnet claims (the verifier suite, the aggregator, the validity anchors, the block time, the validator count, the supply) hold on chain 2800, and the then-not-yet-on-mainnet claims are labeled testnet, scratch-fork, or staged (of these, the native precompiles and EIP-2935 lookback have since gone live on mainnet per the update banner; the consensus PQC quorum, canonical-binding V2, and parallel L1 execution remain testnet/scratch-fork/staged).

---

## 8. One-line summary of scope

Live on mainnet chain 2800: the pure-Solidity PQC verifier suite, the recursive proof aggregator at n=10, the single-block and 16-block full-EVM validity anchors (proof-of-approach), the Block-STM hint registry, ~0.506s blocks, 7 validators (f=2; was 3 at this 2026-07-11 snapshot), 2.8B supply, and (since block 9,189,161, added after this snapshot) the native PQC precompiles and the extended EIP-2935 8191-block lookback. Proven on isolated testnet or scratch fork and staged for a supervised mainnet fork, not active today: the gossiped Falcon-512 consensus quorum certificate, canonical-binding validity V2, and the parallel-commit client prototype. Consensus on mainnet remains classical secp256k1 QBFT and is not post-quantum. No external audit yet.

---

*Every canonical address is verbatim from `sdk-js/src/addresses.ts`. Testnet, scratch-fork, and staged results are labeled as such and are cited from the named repo artifacts. No gas figure, transaction hash, block number, or measured result in this document is invented; each is drawn from an on-chain transaction or a committed artifact.*