dd1410c266
The published line and the local line of this repository had no common ancestor: the public one carried the hygiene pass (no host names, no internal paths), the local one carried a month of corrections that never shipped. This commit ports the local work onto the public line, keeping the public hygiene wording wherever the two touched the same sentence, and keeping the public version of AERE-CROSS-CLIENT-DETERMINISM.md entirely. Carried: LICENSE/LICENSING corrections, VERIFY-POLICY.md, CITATIONS-UNRESOLVED.md remeasured 2026-08-11, the 'audited' adjective removed from next to Bouncy Castle, citation paths rewritten to published form, AIP-8, the QA consolidation report, the second EIP validation pass, fork-height corrections, the AereSink / threshold-factory correction, the forge test floor, and the architecture-map updates.
107 lines
12 KiB
Markdown
107 lines
12 KiB
Markdown
# Aere Network Architecture Map
|
|
|
|
Aere Network is a public, EVM-compatible Layer 1 (chain ID 2800). One diagram replaces pages of prose here: the architecture is best read as a layered stack (Consensus at the bottom, then Execution, Accounts, and Applications on top) with a set of cross-cutting concerns (post-quantum cryptography, zero-knowledge verification, and crypto-agility) that traverse every layer rather than sitting in any single one. This is deliberately not one linear top-to-bottom column: the layers stack, and the transversal concerns cut across all of them.
|
|
|
|
The single most important honesty point, stated up front: consensus today is classical ECDSA (secp256k1) QBFT. Only signatures, accounts, and precompiles are post-quantum. There is no post-quantum consensus live on mainnet, and the on-chain zero-knowledge verifiers are classical BN254 (Shor-breakable) today. Everything below is marked LIVE (on mainnet 2800) or "(roadmap)" (built and tested, but not activated on mainnet).
|
|
|
|
## Diagram
|
|
|
|
```mermaid
|
|
flowchart TB
|
|
classDef live fill:#e7f6ec,stroke:#1a7f37,color:#0b2b16;
|
|
classDef road fill:#fff3e0,stroke:#b26a00,color:#3d2600,stroke-dasharray:5 3;
|
|
classDef cross fill:#eaeefb,stroke:#3b46c4,color:#1a1f5c;
|
|
|
|
legend["Legend. Green solid, LIVE on mainnet 2800. Orange dashed, roadmap (built and tested, not yet live). Blue, cross-cutting concern. Suffix (roadmap) also marks any not-yet-live item inside a label."]:::cross
|
|
|
|
subgraph APP["Applications layer"]
|
|
direction TB
|
|
app_defi["DeFi. lending, sAERE staking, AereSink burn"]:::live
|
|
app_settle["Settlement. SettlementHub, state channels, AERE402 machine payments"]:::live
|
|
app_bridge_l["Bridge and interop. Hyperlane-compatible bus, zk light clients inbound and outbound"]:::live
|
|
app_bridge_r["ERC-7683 intent settlement route (roadmap)"]:::road
|
|
app_id_l["Identity and compliance. ZKScreen, compliant privacy pool, AereProof registry"]:::live
|
|
app_id_r["zk-KYC and over-18 attribute proofs (roadmap)"]:::road
|
|
app_ai_l["AI agents. AgentDID, AIReputation, agent bond, InferNet audit log"]:::live
|
|
app_ai_r["AI runtime and zk proof of inference (roadmap)"]:::road
|
|
end
|
|
|
|
subgraph ACC["Accounts layer"]
|
|
direction TB
|
|
acc_eoa["EOA"]:::live
|
|
acc_pk["WebAuthn P-256 passkey accounts"]:::live
|
|
acc_4337["ERC-4337 v0.7 smart accounts"]:::live
|
|
acc_7702["EIP-7702 EOA delegation"]:::live
|
|
acc_falcon["Falcon-512 and hybrid ECDSA plus Falcon accounts"]:::live
|
|
acc_thr["t-of-n PQC threshold accounts"]:::live
|
|
acc_note["Note. flawed originals superseded, some V2 redeploys founder-gated"]:::cross
|
|
end
|
|
|
|
subgraph EXE["Execution layer"]
|
|
direction TB
|
|
exe_evm["EVM. Pectra plus Fusaka parity"]:::live
|
|
exe_pqc["PQC precompiles 0x0AE1 to 0x0AE5"]:::live
|
|
exe_pqc2["PQC precompiles ML-KEM-768 and HashToPoint, 0x0AE6 to 0x0AE7 (roadmap)"]:::road
|
|
exe_stm["Parallel execution, Block-STM (roadmap)"]:::road
|
|
exe_zk["zk validity rollup, revm in SP1 (roadmap)"]:::road
|
|
end
|
|
|
|
subgraph CON["Consensus layer"]
|
|
direction TB
|
|
con_qbft["QBFT, classical ECDSA secp256k1"]:::live
|
|
con_besu["Hyperledger Besu producer, N equals 7"]:::live
|
|
con_fin["about 0.5s deterministic finality"]:::live
|
|
con_nm["Nethermind 2nd client, validate and follow"]:::live
|
|
con_nmp["Nethermind live block producer (roadmap)"]:::road
|
|
end
|
|
|
|
subgraph XC["Cross-cutting concerns, span all layers"]
|
|
direction TB
|
|
x_pqc["PQC. precompiles, accounts, signatures LIVE. Consensus PQC (roadmap)"]:::cross
|
|
x_zk["ZK verify. on-chain BN254 Groth16 via SP1, Halo2, RISC Zero, all classical LIVE. PQ STARK verifier (roadmap)"]:::cross
|
|
x_agile["Crypto-agility. schemes addressable and swappable by the calling contract"]:::cross
|
|
end
|
|
|
|
APP -->|builds on| ACC
|
|
ACC -->|builds on| EXE
|
|
EXE -->|builds on| CON
|
|
|
|
XC -.spans.-> APP
|
|
XC -.spans.-> ACC
|
|
XC -.spans.-> EXE
|
|
XC -.spans.-> CON
|
|
```
|
|
|
|
## Layer-by-layer map
|
|
|
|
### Consensus (LIVE)
|
|
Aere Network runs QBFT (Istanbul BFT family) with a Hyperledger Besu block producer, signing blocks with classical ECDSA over secp256k1. The live validator set is N=7 (f=2, commit quorum 5 of 7), all Foundation-operated, at a 500 ms target block period with sub-second deterministic finality. A second execution client, a patched Nethermind 1.39.0, is LIVE as a client-diversity cross-check: it peers with the Besu validators over devp2p and independently validates and follows the live chain (verification-layer diversity). Nethermind producing live QBFT blocks is roadmap: block production and adversarial recovery are proven on isolated testnets and via offline import (Besu imports Nethermind-sealed blocks byte-for-byte), but it is not yet a live producing validator on mainnet. Consensus is classical today, not post-quantum.
|
|
|
|
### Execution (LIVE base, frontier roadmap)
|
|
The EVM is at Pectra plus Fusaka parity with Ethereum mainnet (Prague/Cancun activated at block 2,075,341; Osaka at block 2,106,597), including EIP-7702, EIP-2537 BLS12-381, EIP-2935 historical block hashes, transient storage, and the RIP-7951 P-256 precompile at 0x100. Five native post-quantum precompiles are LIVE on mainnet since block 9,189,161 (Falcon-512, Falcon-1024, ML-DSA-44, SLH-DSA-128s, SHAKE256 at 0x0AE1 through 0x0AE5), NIST KAT-validated on-chain. Roadmap execution items, all built and tested but not activated on mainnet: two further precompiles (ML-KEM-768 at 0x0AE6 and Falcon HashToPoint at 0x0AE7, KAT-verified on isolated testnet); parallel execution via a Block-STM engine (correctness proven bit-identical to sequential, near-linear execution-phase scaling, but no end-to-end throughput win claimed and not enabled on L1); and a full-EVM zk validity rollup (revm in the SP1 zkVM), which is verified on-chain as a proof-of-approach on small real blocks, not yet a production-throughput rollup.
|
|
|
|
### Accounts (LIVE, some V2 redeploys founder-gated)
|
|
Aere supports the full modern account spectrum: plain EOAs; WebAuthn / P-256 passkey accounts (backed by the native 0x100 precompile); ERC-4337 v0.7 smart accounts (AereEntryPointV2 live); EIP-7702 EOA delegation; a Falcon-512 post-quantum account whose sole owner is a Falcon public key; hybrid ECDSA plus Falcon authorization; and non-custodial t-of-n post-quantum threshold accounts (AereThresholdAccountFactory V2 at `0x69734E4044B1C5943B9256A73De41B101BFA2633`, each committee leg verified by the live PQC precompiles).
|
|
|
|
**Correction of 2026-08-01, because this line and `AERE-POST-QUANTUM-GOVERNANCE.md` in this same publication bundle contradicted each other.** This map said the V2 factory was "live on mainnet"; the governance document said of the same address "not on mainnet, treated here as not deployed". Two public documents in one bundle cannot say opposite things about one address. Measured at head block 11,810,041: the address carries **6,835 bytes** of code, against 6,717 at V1, so this map was closer to the truth and the governance document has been corrected. But neither was fully honest, and the accurate status is narrower than either: **deployed, code present, build identity NOT MEASURED**. The repository artifact is 7,407 bytes and reproduces neither version, so we cannot yet assert from bytecode that the deployed runtime is the duplicate-key-guard build. Do not cite it as the fixed factory until that is reproduced. Honest caveat: several first-generation account contracts had audited defects and were superseded by fixed V2 redeploys that hold zero value; some corrected factories are deployed inert and the live migration of any funds-bearing path is founder-gated.
|
|
|
|
### Applications (mixed LIVE and roadmap)
|
|
- DeFi (LIVE): an isolated-market lending engine (AereLendingMarket, proven end-to-end with real supply/borrow/repay), the sAERE staking-receipt vault, and the immutable AereSink burn-and-buyback router. **On AereSink, one word of that is not currently earned: the buyback.** Measured at head, `AereSink.DEX_ROUTER()` is `0x0000000000000000000000000000000000000001` and `ORACLE()` is the zero address, both immutable, so the 40% buyback bucket cannot execute for a non-AERE token and the documented oracle-derived minimum-output floor is not active. The burn path and the AERE/WAERE flow work as described. Read it as a burn router that is wired, plus a buyback leg that is not. Note that sAERE has a corrected V2 whose migration is founder-gated.
|
|
- Settlement (LIVE): AereSettlementHub, AereStateChannels (24h challenge window), and AERE402 machine-to-machine payments (AereAgentV2 plus AERE402FacilitatorV2). The settlement hub is deployed in a bootstrap state holding no value pending a founder-supervised migration.
|
|
- Bridge and interop: Hyperlane-compatible message bus (AereMessenger) is LIVE, as are the inbound zk Ethereum light client and the outbound zk QBFT-finality light client (both proven live end-to-end, trust-minimized, classical BN254). ERC-7683 intent settlement (SpokePool path) is roadmap: the corrected contracts exist but are deployed inert, so no live intent route is enrolled.
|
|
- Identity and compliance: ZKScreen v3 sanctions screening is LIVE, as is a compliant, sanctions-gated privacy pool (deposit/withdraw circuit proofs are still being generated) and the AereProof proof-anchoring registry. zk-KYC and the over-18 attribute proof are roadmap (proofs generated, pending a Foundation registration signature).
|
|
- AI agents: AgentDID (Falcon-rooted decentralized identity), AIReputation, the slashable agent bond, and the InferNet inference-audit-log commitments (EU AI Act style) are LIVE. A general AI runtime and a zero-knowledge proof-of-inference (zkML) verifier are roadmap.
|
|
|
|
### Cross-cutting: PQC (transversal)
|
|
Post-quantum cryptography is not a layer, it runs through the stack. LIVE: the execution-layer PQC precompiles, the PQC accounts, and application-layer PQC signature verification (for example AerePQCAttestation, proven usable end-to-end on mainnet). Roadmap: post-quantum consensus. A hybrid ECDSA plus Falcon dual-quorum design, an on-chain Falcon registry, and in-place activation without re-genesis are all proven on isolated testnets and formally analyzed as no-worse-than-ECDSA, but they are not activated on mainnet and remain audit-plus-founder gated. Consensus stays classical ECDSA QBFT today.
|
|
|
|
### Cross-cutting: ZK verification (transversal)
|
|
Aere exposes a multi-prover verification surface. The on-chain verifiers that are LIVE today are all classical BN254: the SP1 Groth16 gateway, a Halo2 PLONK-over-BN254 (KZG) verifier, and a RISC Zero Groth16 verifier. These underpin ZKScreen, the privacy pool, the zk light clients, and the zk validity rollup anchors. Because BN254 pairings are Shor-breakable, this surface is not post-quantum. A post-quantum STARK verifier is roadmap. Scope caveat (2026-07-19 finding): the 0x0AE8 verifier skeleton built so far is a BabyBear + FRI STARK verifier, conformance-confirmed against Plonky3 and targeting Aere's OWN circuits; it does NOT yet verify SP1 6.1.0 proofs, because the pinned SP1 6.1.0 is a Hypercube (KoalaBear multilinear) system, a different stack. Replacing the SP1 BN254 Groth16 path is a separate ~22 to 32 person-week retarget (`AERE-STARK-SP1-RECURSION-AIR-PORT-SPEC-SUMMARY.md`), not done or imminent.
|
|
|
|
### Cross-cutting: crypto-agility (transversal)
|
|
Signature and proof schemes are addressable and swappable by the calling contract rather than hard-wired. AereCryptoRegistry (live) maps scheme identifiers to concrete precompiles or verifiers, with additional reserved scheme slots and a governance rotation runbook, so applications can migrate primitives (for example add or rotate a PQC scheme) without redesigning the stack.
|
|
|
|
---
|
|
|
|
Convention recap: plain / green means LIVE on mainnet chain 2800; "(roadmap)" / orange dashed means built and tested but not yet activated on mainnet. Consensus is classical ECDSA QBFT; PQC is signatures, accounts, and precompiles only; on-chain ZK verifiers are classical BN254.
|