diff --git a/CITATIONS-UNRESOLVED.md b/CITATIONS-UNRESOLVED.md index 23f5ee2..2db547b 100644 --- a/CITATIONS-UNRESOLVED.md +++ b/CITATIONS-UNRESOLVED.md @@ -1,7 +1,7 @@ # Citations in this repository that you cannot open This file is generated by the legaturi-repara.cjs script in the Aere working tree and -enforced by legaturi.cjs. It is the complete list, measured on 2026-09-02, of every +enforced by legaturi.cjs. It is the complete list, measured on 2026-09-12, of every path cited in this repository that does not resolve to a published file. A citation is a promise that a claim is checkable. Where the target is not published, @@ -15,15 +15,24 @@ repositories, so they begin with a repository name, for example Unresolvable distinct paths in this repository: **104**. +- `addresses.ts` cited in: aere-research/research/specs/spec-account-abstraction.md, aere-research/research/specs/spec-antimev-mempool.md, aere-research/research/specs/spec-eip2935-lookback.md, aere-research/research/specs/spec-full-evm-validity.md, aere-research/research/specs/spec-recursive-aggregation-scale.md, aere-research/research/specs/spec-zk-stack.md, aere-research/results/PROVEN-RESULTS-2026-07-11.md +- `aerenew/basefee-floor-dryrun/basefee-floor.diff` cited in: aere-research/aips/AIP-10.md, aere-research/aips/AIP-17.md +- `aerenew/consensus-pqc/besu-consensus-pqc-fork-activation.patch` cited in: aere-research/aips/AIP-15.md - `aerenew/contracts/deployments/falcon-512-verifier.json` cited in: aere-research/research/pqc-onchain-verification.md - `aerenew/contracts/deployments/pqc-account.json` cited in: aere-research/research/pqc-onchain-verification.md +- `aerenew/docs/AERE-EIP-COMPATIBILITY-MATRIX.md` cited in: aere-research/aips/AIP-18.md +- `aerenew/docs/AERE-PROTOCOL-SPECIFICATION.md` cited in: aere-research/aips/AIP-17.md, aere-research/aips/AIP-18.md +- `aerenew/docs/AIP-PQ-TX-2026-07-18.md` cited in: aere-research/aips/AIP-19.md +- `aerenew/docs/BASEFEE-FLOOR-FORK-RUNBOOK-2026-07-17.md` cited in: aere-research/aips/AIP-17.md - `aerenew/docs/drafts/PQC-FORK-PAPER-DRAFT.md` cited in: aere-research/research/aip-draft-pqc-precompiles.md +- `aerenew/docs/PQ-STARK-VERIFIER-ACTIVATION-2026-07-18.md` cited in: aere-research/aips/AIP-16.md +- `aerenew/docs/PQ-STARK-VERIFIER-PRECOMPILE-2026-07-18.md` cited in: aere-research/aips/AIP-16.md - `aerenew/docs/TRANZITIA-QBFT-SETTLED-2026-07-20.md` cited in: aere-research/aips/AIP-3.md - `aerenew/formal-tla/QBFT.tla` cited in: aere-research/formal-consensus/RULEAZA-TOT.md - `aerenew/formal-tla/QBFTPartition.tla` cited in: aere-research/formal-consensus/RULEAZA-TOT.md - `aerenew/scripts/deschise/flaguri-verify.cjs` cited in: aere-research/VERIFY-POLICY.md - `aerenew/strategie/EXECUTION-KERNEL-2026-08-15.md` cited in: aere-research/execution-kernel/MACHINE-INTERFACE-CONTRACT.md -- `AIP-N.md` cited in: aere-research/aips/AIP-1.md, aere-research/aips/README.md +- `AIP-N.md` cited in: aere-research/aips/AIP-1.md, aere-research/aips/CONTRIBUTING.md, aere-research/aips/README.md - `air.rs` cited in: aere-research/pq-stark/README.md - `batch-prover-recovered/bin/aere-prover/Cargo.toml` cited in: aere-research/pq-stark/export-inner-stark-vector.md - `besu-pqc-precompiles-mlkem-hashtopoint.patch` cited in: aere-research/PQC-FORK-README.md @@ -32,17 +41,12 @@ Unresolvable distinct paths in this repository: **104**. - `CLAUDE.md` cited in: aere-research/execution-kernel/MACHINE-INTERFACE-CONTRACT.md - `compression.rs` cited in: aere-research/pq-stark/spec-mmcs-babybear.md - `config.rs` cited in: aere-research/pq-stark/spec-fri-babybear.md -- `contracts/contracts/AereCoinbaseSplitter.sol` cited in: aere-research/aips/AIP-2.md -- `contracts/contracts/AereCoinbaseSplitterV2.sol` cited in: aere-research/aips/AIP-2.md -- `contracts/contracts/AereFeeBurnVault.sol` cited in: aere-research/aips/AIP-2.md - `contracts/contracts/AereIdentity.sol` cited in: aere-research/research/specs/spec-identity-compliance.md - `contracts/contracts/anchor/AereHistoryStateRootAnchor.sol` cited in: aere-research/research/specs/spec-eip2935-lookback.md - `contracts/contracts/parallel/AereBlockSTMRegistry.sol` cited in: aere-research/research/specs/spec-parallel-execution.md - `contracts/contracts/parallel/AereEVMValidity.sol` cited in: aere-research/research/specs/spec-full-evm-validity.md - `contracts/contracts/parallel/AereRollupValidity.sol` cited in: aere-research/research/specs/spec-full-evm-validity.md, aere-research/research/specs/spec-parallel-execution.md - `contracts/contracts/raas/AereRaaSFactory.sol` cited in: aere-research/parallel-executor/README.md -- `contracts/contracts/sink/AereSink.sol` cited in: aere-research/aips/AIP-5.md -- `contracts/contracts/staking/sAERE.sol` cited in: aere-research/aips/AIP-5.md - `contracts/contracts/zkverify/AereProofAggregator.sol` cited in: aere-research/research/specs/spec-recursive-aggregation-scale.md - `contracts/deploy/deploy-saere-sink-stack.js` cited in: aere-research/aips/AIP-5.md - `contracts/deployments/block-stm-registry.json` cited in: aere-research/research/specs/spec-parallel-execution.md @@ -58,11 +62,6 @@ Unresolvable distinct paths in this repository: **104**. - `contracts/deployments/zkml-mnist-verifier.json` cited in: aere-research/research/specs/spec-zk-stack.md - `contracts/deployments/zkverify-stack.json` cited in: aere-research/research/specs/spec-zk-stack.md - `contracts/test/block-stm-registry.test.js` cited in: aere-research/research/specs/spec-parallel-execution.md -- `contracts/test/falcon1024_kat0.json` cited in: aere-research/aips/AIP-4.md -- `contracts/test/falcon512_kat0.json` cited in: aere-research/aips/AIP-4.md -- `contracts/test/fixtures/mldsa44-acvp-tg8.json` cited in: aere-research/aips/AIP-4.md -- `contracts/test/fixtures/sphincs-sha2-128s-acvp-tg31.json` cited in: aere-research/aips/AIP-4.md -- `contracts/test/fixtures/xmss-sha2_10_256-kat.json` cited in: aere-research/aips/AIP-4.md - `crypto/merklesignature/committablePublicKeys.go` cited in: aere-research/research/pqc-onchain-verification.md - `data/transactions/logic/langspec_v12.json` cited in: aere-research/research/pqc-onchain-verification.md - `dense-batch-2026-07-11/NOTE.md` cited in: aere-research/research/specs/spec-full-evm-validity.md @@ -103,6 +102,7 @@ Unresolvable distinct paths in this repository: **104**. - `rollup-sequencer/src/blockstm/BlockSTMExecutor.ts` cited in: aere-research/research/specs/spec-parallel-execution.md - `rollup-sequencer/src/blockstm/example.ts` cited in: aere-research/research/specs/spec-parallel-execution.md - `run-kats.sh` cited in: aere-research/PQC-FORK-README.md +- `sdk-js/src/addresses.ts` cited in: aere-research/aips/AIP-1.md, aere-research/aips/AIP-11.md, aere-research/aips/AIP-2.md, aere-research/aips/AIP-4.md, aere-research/aips/AIP-5.md, aere-research/aips/AIP-6.md, aere-research/aips/AIP-7.md, aere-research/aips/AIP-8.md, aere-research/aips/CONTRIBUTING.md, aere-research/aips/README.md, aere-research/aips/aip-template.md, aere-research/research/pqc-onchain-verification.md, aere-research/research/specs/spec-account-abstraction.md, aere-research/research/specs/spec-antimev-mempool.md, aere-research/research/specs/spec-eip2935-lookback.md, aere-research/research/specs/spec-flywheel-economics.md, aere-research/research/specs/spec-full-evm-validity.md, aere-research/research/specs/spec-identity-compliance.md, aere-research/research/specs/spec-parallel-execution.md, aere-research/research/specs/spec-recursive-aggregation-scale.md, aere-research/research/specs/spec-zk-stack.md, aere-research/results/PROVEN-RESULTS-2026-07-11.md - `setup-fork.sh` cited in: aere-research/PQC-FORK-README.md - `shutter-mempool-v2.json` cited in: aere-research/research/specs/spec-antimev-mempool.md - `shutter-mempool-v3.json` cited in: aere-research/research/specs/spec-antimev-mempool.md diff --git a/aips/AIP-10.md b/aips/AIP-10.md new file mode 100644 index 0000000..3490b95 --- /dev/null +++ b/aips/AIP-10.md @@ -0,0 +1,86 @@ +# AIP-10: Execution Client: Forked Besu with Nethermind as the Second Client, not Reth + +## Preamble + +| Field | Value | +| --- | --- | +| AIP | 10 | +| Title | Execution Client: Forked Besu with Nethermind as the Second Client, not Reth | +| Author | Aere Network Foundation | +| Type | Informational | +| Category | (none) | +| Status | Final | +| Created | 2026-07-19 | +| Requires | 7, 9 | +| Supersedes | None | +| Superseded-By | None | +| Ratification | Foundation-ratified (pre-decentralization) | + +## Abstract + +This AIP records the decision to run a fork of Hyperledger Besu as the sole live +mainnet producer and a patched Nethermind as the second, independent client, +rather than adopting Reth. It backfills a decision already live on chain 2800. + +## Motivation + +A production chain needs a producing client and, to retire single-implementation +risk, a second independent client. Aere already ships QBFT (AIP-9), which is +Besu-specific: no off-the-shelf Geth, Reth, Erigon, or stock Nethermind produces +QBFT-compatible blocks. + +## Specification + +- **Producer:** a fork of Hyperledger Besu v26.4.0 (Java, base commit + `d2032017`, JDK 21 toolchain), the sole live mainnet producer. The fork carries + the native post-quantum precompiles and the EIP-2935 write path (live from + block 9,189,161, AIP-7) and the 1-Gwei base-fee floor (live from block + 10,141,734, AIP-17). +- **Second client:** a patched Nethermind 1.39.0 (.NET), which validates the live + chain and runs the five live PQC precompiles byte-for-byte identically (27 of + 27 NIST KAT vectors, **measured**). + +## Rationale + +Besu already carries QBFT and already carries the codebase into which the PQC +precompile fork and base-fee changes were integrated. Nethermind was chosen as +the second client specifically for implementation diversity: a different codebase +in a different language (.NET versus Java), so a consensus-relevant bug in one is +unlikely to exist in the other. On an isolated test network the patched +Nethermind produces byte-identical QBFT blocks that stock Besu accepts through +full BFT validation, with a one-byte-tampered seal rejected. + +**Alternatives rejected.** Reth (Rust) as the base client: it has no notion of +QBFT, so it would require building QBFT production into a client that lacks it +before producing a single block; and the September 2025 Reth halt is the +reference case for why depending on one producing implementation is a systemic +risk. A second Besu instance instead of Nethermind: that is not client diversity, +since it shares every bug with the first. + +## Backwards Compatibility + +None. This records the existing topology. + +## Security Considerations + +Cross-client production is proven on an isolated testnet (offline import and, +later, live devp2p between test nodes), and a listen-only Nethermind follower has +run against the live network. **Nethermind is not yet a live gossiping producer +on chain 2800.** Besu remains the sole live producer, so single-implementation +risk is mitigated as a cross-check and fail-safe, not eliminated. Making +Nethermind a live producer is a founder-supervised change, because a producer bug +on a live chain can halt or fork it. + +## Reference Implementation and On-Chain Deployment + +Chain ID 2800; live producer Besu only. Client fork sources and the Nethermind +patch live in the consensus and client work trees; the base-fee floor diff is at +`aerenew/basefee-floor-dryrun/basefee-floor.diff`. + +## Errata + +None. + +## Copyright + +Released to the public domain (CC0). No rights reserved. diff --git a/aips/AIP-11.md b/aips/AIP-11.md new file mode 100644 index 0000000..4cacbcf --- /dev/null +++ b/aips/AIP-11.md @@ -0,0 +1,86 @@ +# AIP-11: Interoperability: Hyperlane-Compatible Messaging plus zk Light Clients, not IBC + +## Preamble + +| Field | Value | +| --- | --- | +| AIP | 11 | +| Title | Interoperability: Hyperlane-Compatible Messaging plus zk Light Clients, not IBC | +| Author | Aere Network Foundation | +| Type | Informational | +| Category | (none) | +| Status | Final | +| Created | 2026-07-19 | +| Requires | None | +| Supersedes | None | +| Superseded-By | None | +| Ratification | Foundation-ratified (pre-decentralization) | + +## Abstract + +This AIP records the decision to build cross-chain interoperability as an +EVM-native, Hyperlane-compatible messaging layer plus zero-knowledge light +clients, rather than adopting IBC natively. It backfills a decision already made +and partly deployed. + +## Motivation + +Aere's value proposition is that it is an ordinary EVM chain. Cross-chain interop +must serve permissionless, EVM-familiar builders while also offering +trust-minimized verification of a counterparty's finality, and those two goals +pull in different directions. + +## Specification + +- An EVM-native, Hyperlane-compatible messaging layer: a Mailbox-compatible + `AereMessenger` and an interchain gas paymaster `AereIGP`. +- An ERC-7683 intent layer and an Across-v3-compatible spoke pool. +- A zero-knowledge interop path: on-chain zk light clients verifying a + counterparty's consensus finality from inside a contract (inbound Ethereum + sync-committee finality, outbound Aere QBFT finality) via SP1 Groth16 proofs. + +## Rationale + +IBC's design philosophy, verifying the counterparty's consensus rather than +trusting a bridge committee, is the right one, and Aere adopts the philosophy +directly. Aere splits the problem: for permissionless, developer-familiar interop +it uses the Hyperlane-compatible interfaces the EVM tooling ecosystem already +speaks; for the trust-minimization that is IBC's real contribution it built the +zk light clients, which capture "verify the counterparty's consensus, do not +trust a relayer" without leaving the EVM world. + +**Alternatives rejected.** IBC as a protocol: it is built around Tendermint-style +light clients and a non-EVM connection, channel, and packet model. Adopting it +natively would import a substantial non-EVM stack and its tooling into a chain +whose entire premise is that it is an ordinary EVM. + +## Backwards Compatibility + +None. + +## Security Considerations + +The Hyperlane-compatible endpoints are interface-faithful and deployed, but a +live decentralized relayer and interchain-security-module network is **not** yet +stood up: the current bridge path runs through a single Foundation signer with a +relayer pending. Until that changes, the messaging layer's trust assumption is +the Foundation, not a validator set. + +The zk light clients are trust-minimized, not trustless, and **not quantum-safe**: +their committed seals are classical secp256k1 and the proof wrap is Groth16 over +BN254, which is Shor-breakable. A post-quantum-sound replacement is recorded in +AIP-16 and is not live. + +## Reference Implementation and On-Chain Deployment + +Deployed messaging and intent interfaces are listed in `sdk-js/src/addresses.ts`. +The zk light-client and verifier-gateway work is under `aere-contracts` and +the zk work trees. + +## Errata + +None. + +## Copyright + +Released to the public domain (CC0). No rights reserved. diff --git a/aips/AIP-12.md b/aips/AIP-12.md new file mode 100644 index 0000000..9f497b7 --- /dev/null +++ b/aips/AIP-12.md @@ -0,0 +1,88 @@ +# AIP-12: The Virtual Machine: Extend the EVM, not a New VM + +## Preamble + +| Field | Value | +| --- | --- | +| AIP | 12 | +| Title | The Virtual Machine: Extend the EVM, not a New VM | +| Author | Aere Network Foundation | +| Type | Informational | +| Category | (none) | +| Status | Final | +| Created | 2026-07-19 | +| Requires | None | +| Supersedes | None | +| Superseded-By | None | +| Ratification | Foundation-ratified (pre-decentralization) | + +## Abstract + +This AIP records the decision to keep the EVM unchanged and to add Aere's +differentiating capability as precompiles and client-fork rules at reserved +addresses, rather than designing a new virtual machine. It backfills a decision +already live on chain 2800. + +## Motivation + +Aere differentiates on post-quantum verification, parallel execution, and +extended block-hash lookback. It must add these without taxing the developer +surface it depends on for adoption. + +## Specification + +Solidity, EVM bytecode, JSON-RPC, and the developer tooling are unchanged. +Differentiation is added as: + +- precompiles at otherwise-empty reserved addresses (the `0x0AE1`..`0x0AE5` band, + live from block 9,189,161, AIP-7), and +- client-fork rules activated in the same manner Ethereum activates its own hard + forks. + +No new instruction set, no new language, no nonstandard account model, and no +nonstandard RPC. + +## Rationale + +A mature VM has years of implementation hardening, a known cost model, and an +operational history; a new VM starts that clock at zero, maximizing both +technical and adoption risk. The EVM is the single largest smart-contract +developer surface in existence, and every deviation (a nonstandard opcode, +account model, or RPC) is a tax on every developer and every tool. Aere's thesis +is settlement, not a novel programming model, so the design keeps the tested +execution environment intact and adds differentiation only at the EVM's standard +extension points. Nothing about Aere's account, passkey, or post-quantum surface +depends on a nonstandard EVM. + +**Alternatives rejected.** Designing a new, purpose-built VM (a new bytecode, +language, or non-EVM environment) optimized around Aere's differentiators. + +## Backwards Compatibility + +Full EVM compatibility is the point of the decision. Precompiles at previously +empty addresses are additive: before activation those addresses were empty +accounts, so a call to one returned empty rather than reverting. AIP-7 covers the +activation-boundary consequences. + +## Security Considerations + +Some ambitions (base-layer parallel execution, an EVM-in-a-zkVM) must be reached +inside the existing model rather than designed in from scratch. Those remain +roadmap and are labeled as such wherever they appear. Adding capability at +reserved addresses means the address band must be treated as consensus-critical: +activating a precompile at an address that historical transactions already called +would change their re-execution result, which is why AIP-16 forward-dates its +milestone rather than folding into a crossed one. + +## Reference Implementation and On-Chain Deployment + +Chain ID 2800. Live precompiles and their activation block are specified in +AIP-7. + +## Errata + +None. + +## Copyright + +Released to the public domain (CC0). No rights reserved. diff --git a/aips/AIP-13.md b/aips/AIP-13.md new file mode 100644 index 0000000..6d40b0c --- /dev/null +++ b/aips/AIP-13.md @@ -0,0 +1,90 @@ +# AIP-13: Post-Quantum Signatures: Falcon and ML-DSA Together, not a Single Lattice Family + +## Preamble + +| Field | Value | +| --- | --- | +| AIP | 13 | +| Title | Post-Quantum Signatures: Falcon and ML-DSA Together, not a Single Lattice Family | +| Author | Aere Network Foundation | +| Type | Informational | +| Category | (none) | +| Status | Final | +| Created | 2026-07-19 | +| Requires | 4, 7 | +| Supersedes | None | +| Superseded-By | None | +| Ratification | Foundation-ratified (pre-decentralization) | + +## Abstract + +This AIP records the decision to support multiple post-quantum signature schemes +across two distinct lattice families (Falcon and ML-DSA) plus hash-based schemes, +rather than standardizing on one. It backfills a decision already live on chain +2800. The normative mechanism is in AIP-4 (contract suite) and AIP-7 (precompile +activation); this record captures the decision framing. + +## Motivation + +Aere verifies post-quantum signatures on-chain at both the contract layer (AIP-4) +and, since block 9,189,161, the native precompile layer (AIP-7). A choice of +scheme family is a bet on a mathematical assumption, and betting on one is a +single point of cryptographic failure. + +## Specification + +Supported families: + +- **Falcon** (Falcon-512, Falcon-1024): NTRU lattices. +- **ML-DSA** (Dilithium2 / ML-DSA-44): module lattices with + Fiat-Shamir-with-aborts. +- **Hash-based**: SLH-DSA, XMSS, WOTS+. + +Live mainnet precompiles occupy `0x0AE1`..`0x0AE5`: Falcon-512 `0x0AE1`, +Falcon-1024 `0x0AE2`, ML-DSA-44 `0x0AE3`, SLH-DSA-SHA2-128s `0x0AE4`, SHAKE256 +`0x0AE5` (**measured**, live from block 9,189,161). `0x0AE6` (ML-KEM-768) and +`0x0AE7` (Falcon HashToPoint) are **testnet-only and not live on chain 2800**. + +## Rationale + +Cryptographic-risk diversification. Supporting both lattice families means a +cryptanalytic break or a standardization flaw in one does not, by itself, remove +Aere's ability to verify post-quantum signatures: accounts and settlement +authorization can migrate to the surviving family. This mirrors the hybrid +`AereHybridAuth` account, which requires both a classical ECDSA and a Falcon-512 +signature, so that neither a broken curve nor a broken lattice alone suffices to +forge. + +**Alternatives rejected.** Standardizing on a single lattice scheme (ML-DSA alone +as the NIST primary, or Falcon alone for its compact signatures). The cost of +supporting several schemes is more verifier surface to implement, validate, and +eventually audit; that cost is accepted deliberately rather than betting the +network's post-quantum future on a single assumption. + +## Backwards Compatibility + +None. Additive. + +## Security Considerations + +**Scope boundary (binding).** This is post-quantum at the signature, account and +application layer only. Consensus remains classical: validators sign secp256k1 +QBFT. The zk verification path is also classical (BN254 Groth16, Shor-breakable). +**Aere never claims post-quantum consensus.** + +The verifiers and precompiles carry an internal self-audit only. An external +audit is pending before they should secure material value. Their assurance today +rests on bit-for-bit agreement with official NIST KAT and ACVP vectors and on +cross-checks against independent reimplementations. + +## Reference Implementation and On-Chain Deployment + +Contract suite: AIP-4. Precompile activation and addresses: AIP-7. Chain ID 2800. + +## Errata + +None. + +## Copyright + +Released to the public domain (CC0). No rights reserved. diff --git a/aips/AIP-14.md b/aips/AIP-14.md new file mode 100644 index 0000000..06cae1e --- /dev/null +++ b/aips/AIP-14.md @@ -0,0 +1,82 @@ +# AIP-14: Account Abstraction: ERC-4337 with EIP-7702 Bridge, not Native AA + +## Preamble + +| Field | Value | +| --- | --- | +| AIP | 14 | +| Title | Account Abstraction: ERC-4337 with EIP-7702 Bridge, not Native AA | +| Author | Aere Network Foundation | +| Type | Informational | +| Category | (none) | +| Status | Final | +| Created | 2026-07-19 | +| Requires | 6 | +| Supersedes | None | +| Superseded-By | None | +| Ratification | Foundation-ratified (pre-decentralization) | + +## Abstract + +This AIP records the decision to deliver programmable accounts through ERC-4337 +smart accounts with EIP-7702 as the migration bridge, rather than protocol-level +native account abstraction. It backfills a decision already live on chain 2800. +The normative stack is in AIP-6; this record captures the decision framing. + +## Motivation + +Aere wants programmable accounts (recovery, passkey ownership, post-quantum +ownership, gas sponsorship) without breaking EVM and externally-owned-account +compatibility. + +## Specification + +ERC-4337 (v0.7) smart accounts as the account-abstraction path, with EIP-7702 +(live under the Pectra ruleset) as the migration bridge that lets existing +externally-owned accounts delegate to smart-account code. EIP-3074 is **not** +implemented. + +## Rationale + +ERC-4337 needs no consensus change, is an established standard with an existing +bundler and tooling ecosystem, and delivers programmable accounts (including the +Falcon-owned post-quantum smart account `AerePQCAccountFactory`) without touching +the protocol, preserving exact EVM and Ethereum compatibility. EIP-7702 is the +chosen bridge precisely because it upgrades existing externally-owned accounts in +place without forcing a disruptive "everything is a contract" change. + +**Alternatives rejected.** Native, protocol-level account abstraction up to an +"all accounts are smart accounts by default" end state: it changes what an +account fundamentally is, breaking existing tooling, contracts, and user keys. +EIP-3074, an earlier proposal for empowering externally-owned accounts: it was +superseded upstream by EIP-7702, which is the mechanism Aere carries. + +## Backwards Compatibility + +Existing externally-owned accounts keep working unchanged. Migration via EIP-7702 +is opt-in per account. + +## Security Considerations + +The EntryPoints are Aere's own ERC-4337-compatible implementations: compatible in +shape and interface but **not byte-identical to Ethereum's canonical audited +singleton**. Integrators should treat them as Aere-specific and should not assume +the upstream audit applies to them. These contracts have not had an external +audit. + +Gasless onboarding is subsidized (Foundation-funded, rate-limited), not free. A +paymaster that runs out of funds stops sponsoring; onboarding degrades rather +than fails silently. + +## Reference Implementation and On-Chain Deployment + +The normative stack (accounts, factories, paymasters, EntryPoints) with addresses +is in AIP-6. Chain ID 2800. + +## Errata + +None. + +## Copyright + +Released to the public domain (CC0). No rights reserved. diff --git a/aips/AIP-15.md b/aips/AIP-15.md new file mode 100644 index 0000000..6ff77c3 --- /dev/null +++ b/aips/AIP-15.md @@ -0,0 +1,114 @@ +# AIP-15: In-Place Hybrid PQC Consensus Activation via On-Chain Anchor Contract, not Re-Genesis + +## Preamble + +| Field | Value | +| --- | --- | +| AIP | 15 | +| Title | In-Place Hybrid PQC Consensus Activation via On-Chain Anchor Contract, not Re-Genesis | +| Author | Aere Network Foundation | +| Type | Standards Track | +| Category | Core | +| Status | Draft (isolated-testnet R&D; not live on chain 2800) | +| Created | 2026-07-19 | +| Requires | 9 | +| Supersedes | None | +| Superseded-By | None | +| Ratification | Not ratified; external-audit gated and founder gated | + +## Abstract + +This AIP specifies a way to bind a Falcon-512 validator manifest to on-chain +state **after** genesis, via a minimal immutable anchor contract, so that hybrid +post-quantum consensus could be activated on a live chain without a re-genesis. +It is **Draft**. Nothing in it is live on chain 2800, whose consensus remains +classical secp256k1 ECDSA QBFT. + +## Motivation + +Aere's hybrid consensus research proved, on isolated test networks, a gossiped, +blocking Falcon-512 quorum certificate running alongside the ECDSA +committed-seal quorum, empirically at N = 4 (2 s) and N = 7 (0.5 s). Its Falcon +registry, however, was bound to chain identity at genesis, by folding +`keccak256(manifest)` into the genesis state root. Chain 2800 launched long +before any Falcon manifest existed, so blocking activation was previously +recorded as "requires a re-genesis". That is a non-starter for a live chain: +re-genesis destroys history and chain identity. + +## Specification + +Bind the Falcon manifest to on-chain state post-genesis: + +1. Deploy a minimal, immutable, ownerless **anchor contract** by one ordinary + transaction at an activation height. Its runtime code is a single `STOP` byte, + so it is never callable and has no admin. +2. The contract commits `keccak256(manifest)` to storage slot 0. +3. On every block import, the validation rule resolves the manifest from the + **parent block's world state** at the anchor address, and activates the + pending registry only if the observed hash matches. Any mismatch fails closed. +4. The deploy address is deterministic, `keccak256(rlp[deployer, nonce])[12:]`, so + validators can be pre-configured before deployment. +5. Activation is idempotent and retried each block, so deploy-then-configure and + configure-then-deploy both converge. + +The re-genesis requirement is removed. + +## Rationale + +The late anchor folds `keccak256(manifest)` into every block hash from the +deployment block onward, so two nodes that agree on the chain past that block +necessarily agree on the anchored hash. That is the same integrity guarantee the +genesis ceremony gave, minus the re-genesis. + +**Alternatives rejected.** Re-genesis carrying a Falcon anchor in the genesis +alloc: destroys history and chain identity. A shared per-node manifest file with +no on-chain root: a node with a tampered manifest could join silently, whereas the +on-chain anchor makes it fail closed. + +## Backwards Compatibility + +Pre-activation blocks remain valid and are unaffected. The design is +non-retroactive by construction: the anchor address is an empty account before +its deploy block. + +## Security Considerations + +**Evidence and honest scope.** Proven end-to-end on an **isolated N = 4 at 0.5 s +testnet** (chain ID 440855) whose genesis is byte-shape-identical to a classical +ECDSA-only chain: classical start, deploy anchor at block 16, activate from the +contract at block 17, flip to blocking at fork block 150, with 0 forks, 0.5 s +cadence maintained, pre-activation blocks still valid, a post-activation +sub-quorum block rejected (the chain halts), and recovery in place with no +re-genesis. All **measured** on that testnet. + +**Nothing in this AIP is live on chain 2800.** This was written 2026-07-19, when +the chain ran N = 7 and carried no Falcon material in any header. Measured +2026-09-12: the set is N = 10, and since block 13,014,000 anchor headers carry a +post-quantum certificate under the block hash. That anchor is a periodic +checkpoint, not the per-block blocking quorum specified here, and the design +below has never been armed on chain 2800. + +The hybrid can only shrink the committable set, so it is never worse than the +ECDSA-only chain; ECDSA committed seals remain the decisive safety and liveness +seal. The corresponding risk is liveness: in this design, which is not live, a +blocking Falcon quorum that cannot be met would halt block production. At N = 7, +the set size when this was written, the blocking configuration has a zero +two-fault margin, which is why a larger set is recommended before any live flip. + +**Remaining gates to a live flip.** No longer a gate: re-genesis. Still required: +an external audit of the Falcon consensus patch (quorum, gossip, assembly, +late-anchor Java) and of BouncyCastle Falcon-512 on the consensus path; +finalizing the full target validator set with an address-bound manifest +re-anchored for the full set; a live isolated soak of the combined activation at +the full set size (N = 10, measured 2026-09-12); and an explicit founder GO. +**No agent activates blocking consensus on chain 2800.** + +## Reference Implementation and On-Chain Deployment + +Not deployed. Reference patch: +`aerenew/consensus-pqc/besu-consensus-pqc-fork-activation.patch`, with evidence +under `aerenew/consensus-pqc/inplace-activation-evidence/`. + +## Copyright + +Released to the public domain (CC0). No rights reserved. diff --git a/aips/AIP-16.md b/aips/AIP-16.md new file mode 100644 index 0000000..f037c10 --- /dev/null +++ b/aips/AIP-16.md @@ -0,0 +1,110 @@ +# AIP-16: PQ STARK-Verify Precompile (0x0AE8) + +## Preamble + +| Field | Value | +| --- | --- | +| AIP | 16 | +| Title | PQ STARK-Verify Precompile (0x0AE8) | +| Author | Aere Network Foundation | +| Type | Standards Track | +| Category | Core | +| Status | Draft (reference skeleton; verifies nothing; not live on any Aere network) | +| Created | 2026-07-19 | +| Requires | 7, 12 | +| Supersedes | None | +| Superseded-By | None | +| Ratification | Not ratified; prerequisite gated, external-audit gated, founder gated | + +## Abstract + +This AIP reserves precompile address `0x0AE8` for a post-quantum-sound +STARK-verify precompile that would verify a hash-based STARK on-chain, removing a +BN254 pairing check from Aere's zk paths. It is **Draft**. As of this date the +artifact is a reference skeleton that verifies nothing, and `0x0AE8` is not +activated on any Aere network. + +## Motivation + +Aere's zk interop and validity paths currently wrap proofs as Groth16 over BN254, +which is classical and Shor-breakable. A post-quantum-sound proof system (a +FRI-based STARK, hash commitments only, no pairing) would remove that assumption. +A native precompile is the natural home for STARK verification, matching the same +reasoning used for the post-quantum signature precompiles in AIP-7. + +## Specification + +Reserve precompile address `0x0AE8`. It is specified to activate under a new, +**forward-dated** milestone (PQ-3), never folded into an already-crossed +milestone, so that pre-activation history is byte-identical on old and new +binaries and the upgrade itself carries no fork risk. + +**Scope correction (2026-07-19 research finding).** An earlier draft described +this as verifying "an SP1 inner-STARK (FRI over a Poseidon2 commitment)". That is +corrected here: the verifier skeleton built so far is a BabyBear + FRI STARK +verifier, conformance-confirmed against Plonky3 `0.4.3-succinct`, which targets +Aere's own Plonky3 circuits and **not** SP1 6.1.0. The pinned SP1 6.1.0 is a +Hypercube release (KoalaBear multilinear: BaseFold plus sumcheck-zerocheck plus +LogUp-GKR), so FRI does not apply to it and this skeleton does not verify SP1 +6.1.0 proofs. Retargeting `0x0AE8` to the SP1 Hypercube stack is a separate +effort **estimated** at 22 to 32 person-weeks. See +`AERE-STARK-SP1-RECURSION-AIR-PORT-SPEC-SUMMARY.md`. + +## Rationale + +A forward-dated, non-retroactive milestone plus a rolling binary upgrade (the same +zero-liveness-risk posture proven for the base-fee floor in AIP-17 and the +in-place activation in AIP-15) means the address stays an empty account, and every +consumer adapter fails closed, until the announced activation time. A migrated +consumer can keep both the new `0x0AE8` path and the existing BN254 gateway during +a defense-in-depth window before dropping the classical path. + +**Alternatives rejected.** Folding `0x0AE8` into the already-crossed +`futureEipsTime` milestone (block 9,189,161): every historical block that called +the currently-empty address would re-execute with different return data on the +upgraded binary, which is a state divergence and a consensus split. Also +rejected: presenting the current artifact as a working verifier, because it is +not one. + +## Backwards Compatibility + +None, by construction: the address is an empty account until a forward-dated +activation, so no historical execution changes. + +## Security Considerations + +**This is the load-bearing honesty statement of this record.** `0x0AE8` is not +activated on any Aere network. As of this date it is a reference skeleton that +fail-closes, returning EMPTY for every input. **It is not a working verifier and +must not be presented as one.** Mainnet 2800 has exactly five PQC precompiles, +`0x0AE1` to `0x0AE5`, live from block 9,189,161. The sibling ML-KEM-768 (`0x0AE6`) +and Falcon HashToPoint (`0x0AE7`) precompiles are testnet-only. +`AerePQStarkVerifier.sol` is a fail-closed adapter that denies every proof, safe +by construction. Consensus is untouched by all of this and remains classical +ECDSA QBFT. + +**Prerequisites before activation can even begin.** The crypto core must be +ported from maintained references (Plonky3 FRI/Poseidon2/uni-stark, SP1 stark) or +a pinned native wrap must be built and reproducible; a real SP1 v6.1.0 +inner-STARK vector corpus must exist, with the precompile accepting every valid +vector and rejecting every tampered or wrong-public-values vector, including +cross-agreement with the live BN254 gateway; a soundcalc receipt for the exact +pinned `FriConfig` must be recorded (no 128-bit claim without the receipt); and a +benchmark must confirm a real verify fits under the EIP-7825 2^24 per-transaction +gas cap. + +**Gates beyond the prerequisites.** A specialist external STARK/FRI audit of the +consensus-critical crypto, a conformance gate green on the frozen artifact, an +isolated N = 7 soak across a simulated milestone crossing, and an explicit founder +GO. Until all hold, `0x0AE8` stays a skeleton. + +## Reference Implementation and On-Chain Deployment + +Not deployed. Design: +`aerenew/docs/PQ-STARK-VERIFIER-PRECOMPILE-2026-07-18.md`. Gated activation plan: +`aerenew/docs/PQ-STARK-VERIFIER-ACTIVATION-2026-07-18.md`. Fail-closed adapter: +`aere-contracts/contracts/zkverify/AerePQStarkVerifier.sol`. + +## Copyright + +Released to the public domain (CC0). No rights reserved. diff --git a/aips/AIP-17.md b/aips/AIP-17.md new file mode 100644 index 0000000..9595390 --- /dev/null +++ b/aips/AIP-17.md @@ -0,0 +1,161 @@ +# AIP-17: One-Gwei EIP-1559 Base-Fee Floor + +## Preamble + +| Field | Value | +| --- | --- | +| AIP | 17 | +| Title | One-Gwei EIP-1559 Base-Fee Floor | +| Author | Aere Network Foundation | +| Type | Standards Track | +| Category | Core | +| Status | Final | +| Created | 2026-07-20 | +| Requires | 10 | +| Supersedes | None | +| Superseded-By | None | +| Ratification | Foundation-ratified (pre-decentralization) | + +## Abstract + +This AIP documents the client-flag-gated fork that clamps the EIP-1559 base fee +on chain 2800 to a minimum of 1 Gwei from block **10,141,734**. Before that block +the real minimum bottomed out at 7 wei. It is a retro-filed record of a change +already live on chain 2800: it backfills history and did not go through Draft, +Review or Last Call. + +## Motivation + +Aere's public RPC and its documentation reported a 1 Gwei base fee while the +chain's actual base fee had decayed to 7 wei. That gap was being closed by a +presentation-layer shim rather than by the chain, which meant a user who queried +the chain directly and a user who read our documentation got different answers, +and only one of them was true. + +There were two honest ways to close it: change the documentation to say 7 wei, or +change the chain so that 1 Gwei is the real value. The second was chosen because +a base fee of 7 wei is not a meaningful price signal, and because a floor is a +value the chain can actually enforce and any observer can verify from block data. +The shim was then retired, which was the point of the exercise: the number +reported is now the number the chain produces. + +## Specification + +For every block `B`: + +``` +baseFee(B) = max( baseFee_1559(parent), 1000000000 ) if number(B) >= 10141734 +baseFee(B) = baseFee_1559(parent) otherwise +``` + +where `baseFee_1559` is the unmodified parent-derived EIP-1559 base fee and +`1000000000` wei = 1 Gwei. + +- The clamp is applied at the three exits of + `computeBaseFee(blockNumber, parentBaseFee, parentGasUsed, targetGasUsed)`, + identically on the produce path and the validate path, so a floored block both + produces and self-validates the floored value. +- The two driving values are Besu client **system properties**: + `AERE_BASEFEE_FLOOR_FORK_BLOCK = 10141734` and + `AERE_BASEFEE_FLOOR_VALUE = 1000000000`, exposed as + `aere.basefee.floor.forkBlock`. +- The defaults are **dormant** (`forkBlock = Long.MAX_VALUE`), so an unflagged + build never applies the floor and is byte-identical to stock in behavior. +- The change is deliberately **not** an EIP-2124 fork-id input and is not + registered as a scheduled fork. + +**Measured activation boundary** (re-confirmed by direct measurement 2026-07-19): +block 10,141,733 has `baseFeePerGas = 7` wei; block 10,141,734 has +`baseFeePerGas = 0x3b9aca00 = 1,000,000,000` wei; the value holds at 1 Gwei at +every later block sampled through head, and `eth_feeHistory` at head reports +`0x3b9aca00`. + +## Rationale + +**Why a client flag rather than a chain-config fork.** Base-fee validation is +absent from the QBFT header ruleset, so a node with a different floor flag does +not reject a peer's blocks: two clients with different flags share one fork id +and peer normally. That property is what made the rollout carry no liveness risk, +because validators could be upgraded one at a time and a lagging node could not +halt or split the chain. The flag being dormant by default is what keeps every +historical block below 10,141,734 valid with its original sub-Gwei base fee. + +**Why 1 Gwei.** It is the value the documentation already claimed, so the fork +made the documentation true rather than choosing a new number and creating a +second discrepancy. + +**Alternatives rejected.** Keeping the presentation-layer shim: it makes the RPC +lie, and a hash-verifiable chain that needs a shim to look right has a +credibility problem worse than a low base fee. Enshrining the floor as a +consensus fork rule with a fork id: unnecessary given that base fee is not +header-validated here, and it would have introduced a genuine split risk in +exchange for nothing. + +## Backwards Compatibility + +Historical blocks are unaffected and still validate with their original base +fees. Integrators that hard-coded a sub-Gwei minimum gas price will underprice +transactions from block 10,141,734 onward and should read the base fee from the +chain. No contract interface changed. + +## Security Considerations + +This modification cannot halt or fork QBFT, because base-fee validation is not +part of the QBFT header ruleset (which is also why a non-upgraded node syncs +straight past the floor block with no rejection). The corresponding weakness is +the same fact stated from the other side: because the floor is not +consensus-enforced, a validator running without the flag would produce blocks +with a sub-Gwei base fee and no one would reject them. Consistency depends on +operational rollout to all validators, not on consensus. All seven validators are +Foundation-operated (AIP-9), so today that is an operational guarantee under one +operator. + +**Open question, honestly flagged.** Where the EIP-1559 base fee ultimately goes +on chain 2800 is **not fully resolved**. Measurement on block 10,487,561 (one +transaction, `gasUsed` 22,474, `effectiveGasPrice` = `baseFeePerGas` = 1 Gwei, so +zero priority tip) showed a coinbase balance delta of **exactly 0 wei**, which +rules out the base fee being credited to the coinbase, since crediting would have +moved 22,474,000,000,000 wei. Because the tip was zero, that measurement cannot by +itself separate "protocol-burned" from "routed elsewhere". Completing the +distinction needs a block containing a transaction with a nonzero priority tip and +unpruned state. + +**This floor is not a burn.** Aere's burn is a separate cut of the validator +coinbase reward (AIP-2). A base-fee floor sets a minimum price; it does not remove +supply. These two must not be conflated in any Aere document. + +## Reference Implementation and On-Chain Deployment + +- Diff: `aerenew/basefee-floor-dryrun/basefee-floor.diff` +- Runbook: `aerenew/docs/BASEFEE-FLOOR-FORK-RUNBOOK-2026-07-17.md` +- Specification detail: `aerenew/docs/AERE-PROTOCOL-SPECIFICATION.md` Section 5.1 +- Chain ID 2800, activation block 10,141,734. No contract address: this is a + client change. + +Verify it yourself: fetch `baseFeePerGas` for blocks 10,141,733 and 10,141,734 +from `https://rpc.aere.network` and from the second public endpoint +`https://rpc2.aere.network`. Both return 7 wei and 1,000,000,000 wei +respectively, and the fork-block hash is identical across both endpoints. + +## Errata + +**Erratum 1 (2026-09-12).** The Security Considerations say "All seven validators +are Foundation-operated (AIP-9)" without a date, so read on its own it is a claim +about today. That was a measurement of 2026-07-19. Measured 2026-09-12: the set +is ten, still all Foundation-operated, so the conclusion of that sentence stands +and only its count moved. See the erratum on AIP-9. The original text is left +exactly as published, per AIP-1 section 5. + +## Post-Acceptance Outcome Record + +**2026-07-20.** Activation was clean and is **measured**: base fee 7 wei at block +10,141,733 became 1 Gwei at 10,141,734 and has stayed 1 Gwei; the fork-block hash +was identical across the public RPC and the second RPC, so there was no split; +N = 7 held with no halt. The presentation-layer shim was retired, and both public +endpoints now serve an honest, hash-verifiable 1 Gwei. Rollback remains available +by clearing the flag, which would return the chain to unmodified EIP-1559 +behavior from the next block. + +## Copyright + +Released to the public domain (CC0). No rights reserved. diff --git a/aips/AIP-18.md b/aips/AIP-18.md new file mode 100644 index 0000000..17ea7fb --- /dev/null +++ b/aips/AIP-18.md @@ -0,0 +1,147 @@ +# AIP-18: EIP-2935 on Chain 2800: Deviation from the Written Activation Schedule + +## Preamble + +| Field | Value | +| --- | --- | +| AIP | 18 | +| Title | EIP-2935 on Chain 2800: Deviation from the Written Activation Schedule | +| Author | Aere Network Foundation | +| Type | Standards Track | +| Category | Core | +| Status | Final | +| Created | 2026-07-20 | +| Requires | 7 | +| Supersedes | None | +| Superseded-By | None | +| Ratification | Foundation-ratified (pre-decentralization) | + +## Abstract + +Chain 2800 lists EIP-2935 under its Pectra ruleset, but the history-storage +system contract was not populated and the write path did not run until the +AerePQC fork at block **9,189,161**. Any client or integrator that assumed +"Pectra is active, therefore EIP-2935 serves history" was wrong for every block +between the Pectra ruleset taking effect and block 9,189,161. This AIP records +that deviation explicitly so it is discoverable, and states exactly what is true +before and after that block. It is a retro-filed record and backfills history. + +## Motivation + +A deviation from a written standard that is not written down is a trap. It does +not cause a problem on the day it is created; it causes one months later, when +somebody reads the standard, checks that the fork is active, and writes code +against a guarantee the chain was not providing. + +The deviation was found and confirmed by direct measurement while building the +EIP compatibility matrix, not by reading our own configuration, which is exactly +the failure mode this record exists to prevent for the next person. + +## Specification + +EIP-2935 as written specifies a history-storage system contract at +`0x0000F90827F1C53a10cb7A02335B175320002935`, a ring buffer serving the last +`HISTORY_SERVE_WINDOW = 8191` block hashes, written by a consensus system call at +the start of each block, activated at the fork that adopts it. + +On chain 2800: + +- **Address:** `0x0000F90827F1C53a10cb7A02335B175320002935` (canonical, unchanged). +- **Window:** 8191 blocks (`0x1fff`), unchanged from the written EIP. +- **Runtime:** 83 bytes, byte-for-byte the canonical EIP-2935 runtime + (**measured**). Disassembly confirms the two jump targets: the `JUMPDEST` at + `0x42` (revert path) and the `JUMPDEST` at `0x46` (the `SSTORE` path taken when + `caller == SYSTEM_ADDRESS`). +- **Deviation:** the contract was **not populated at the Pectra ruleset**. It was + populated, and the consensus write path began running, at the AerePQC milestone + block **9,189,161** (Besu `futureEipsTime = 1783820272`), the same fork + documented in AIP-7. + +Therefore, normatively: + +- For `number < 9,189,161`: a call to the history address returns empty, because + the address was an empty account. EIP-2935 MUST NOT be relied on. +- For `number >= 9,189,161`: the contract serves the window + `[number - 8191, number - 1]`. A call passes the 32-byte block number as + calldata; a query outside the served window reverts. + +At the 500 ms target block period, 8191 blocks is roughly **68 minutes** of +trustless lookback, against roughly 128 seconds for the 256-block `BLOCKHASH` +window. + +## Rationale + +The deviation was not a design choice made in advance; it is the honest +description of what happened. Pectra parity was configured before the EIP-2935 +write path existed in the Aere Besu fork, so the ruleset listed an EIP whose +system contract nothing was writing to. When the write path shipped, it was +bundled into the AerePQC fork rather than given its own activation, because the +fork was already scheduled and a second coordinated activation would have added +rollout risk for no benefit (the same bundling rationale as AIP-7). + +**Alternatives rejected.** Silently correcting the compatibility documentation to +say EIP-2935 was live from Pectra: false. Backfilling the ring buffer at +activation: impossible without rewriting state, and the fail-empty behavior of an +unpopulated contract is the safe outcome anyway. + +## Backwards Compatibility + +This is the whole subject of the AIP. Concretely: a contract deployed before +block 9,189,161 that called the history address received empty return data, and +if it treated empty as "hash zero" it computed a wrong answer rather than +reverting. Any such contract should be re-checked. From block 9,189,161 the same +call returns real history, so a contract whose behavior depended on the empty +return changes behavior at that block. + +Note the asymmetry that makes this safe at the consensus layer: the transition is +from an empty account to a populated one, so no historical block re-executes +differently on an upgraded binary. + +## Security Considerations + +The window is 8191 blocks and queries outside it revert. A consumer that assumes +a longer lookback fails closed, which is correct, but a consumer that assumes any +lookback before block 9,189,161 silently receives nothing, which is not. That +asymmetry is the reason this record exists. + +The trustless-lookback guarantee is only as strong as the chain itself: on chain +2800 that is a seven-validator, single-operator QBFT chain (AIP-9). EIP-2935 +removes a trust assumption on an oracle; it does not remove the trust assumption +on the validator set. + +## Reference Implementation and On-Chain Deployment + +Chain ID 2800, activation block 9,189,161, contract +`0x0000F90827F1C53a10cb7A02335B175320002935`, runtime 83 bytes. + +Verify it yourself against `https://rpc.aere.network`: + +1. `eth_getCode` at the history address returns the canonical 83-byte runtime. +2. `eth_call` the address with the 32-byte block number of `head - 100` returns + that block's hash, byte-identical to `eth_getBlockByNumber`. This is the + stronger check: the ring buffer is not merely populated, it is serving correct + history. + +Related: AIP-7 (the fork that activated it), +`aerenew/docs/AERE-EIP-COMPATIBILITY-MATRIX.md` (deviation 7), +`aerenew/docs/AERE-PROTOCOL-SPECIFICATION.md`. + +## Errata + +None. + +## Post-Acceptance Outcome Record + +**2026-07-20.** Both verification paths above were run against the live chain and +both pass (**measured**). The functional check, returning the correct hash for +`head - 100`, is recorded as the canonical proof rather than the bytecode check, +because matching bytes prove deployment while a correct answer proves operation. + +An adjacent claim remains open and is flagged rather than assumed: whether the +EIP-6110 deposit system contract is populated on mainnet 2800 has **not** been +checked directly. Given that EIP-2935's contract was listed as active while +unpopulated, that claim must be measured, not inferred from the ruleset. + +## Copyright + +Released to the public domain (CC0). No rights reserved. diff --git a/aips/AIP-19.md b/aips/AIP-19.md new file mode 100644 index 0000000..d56bbc5 --- /dev/null +++ b/aips/AIP-19.md @@ -0,0 +1,125 @@ +# AIP-19: AIP Process Hardening: Numbering, Status Transitions, Supersession, and Post-Acceptance Immutability + +## Preamble + +| Field | Value | +| --- | --- | +| AIP | 19 | +| Title | AIP Process Hardening: Numbering, Status Transitions, Supersession, and Post-Acceptance Immutability | +| Author | Aere Network Foundation | +| Type | Meta | +| Category | (none) | +| Status | Review | +| Created | 2026-07-20 | +| Last Call opens | on ratifier acknowledgement | +| Requires | 1 | +| Supersedes | None (amends AIP-1, which is Living) | +| Superseded-By | None | +| Ratification | **Not yet ratified.** Ratifier is the founder. | + +## Abstract + +This AIP records the 2026-07-20 hardening of the Aere Improvement Proposal +process: permanent non-reusable numbering, an explicit table of permitted status +transitions, paired `Supersedes` / `Superseded-By` headers, a mandatory template, +and a rule that a Final AIP is never silently edited (errata and outcome records +are appended instead). Each mechanism is adopted from an existing standards body +rather than invented. The amendments are written into AIP-1, which is Living. +This AIP is the record of why, and is itself in **Review**, not Final. + +## Motivation + +Before this change, Aere had a document describing a process rather than a +process. The evidence for that statement, gathered 2026-07-20: + +1. **Nothing had moved through the lifecycle.** All eight AIPs that existed + entered directly at Final, Living, or Draft. Not one had ever occupied Review + or Last Call. Seven of them were written on two days (2026-07-11 and + 2026-07-16). A lifecycle no document has traversed is a diagram, not a + process. +2. **The index referenced files that did not exist.** AIP-9 through AIP-16 were + published in a numbered index while existing only as sections inside a single + prose document, `AERE-AIP-PROCESS-AND-INDEX.md`. A number that does not + resolve to a document is not a record. +3. **AIP-8 was outside the index**, living at + `aerenew/docs/AIP-PQ-TX-2026-07-18.md` under a non-conforming filename. +4. **Two mechanisms that the process depends on did not exist at all:** + supersession headers and a rule against editing accepted documents. Without + the first, a reader landing on an old AIP has no way to find the current one. + Without the second, a citation to an AIP is a citation to whatever the file + happens to contain today. +5. **Real decisions had no number.** The 1 Gwei base-fee floor at block + 10,141,734, live since 2026-07-17, appeared in four documents and no AIP. The + EIP-2935 activation deviation was recorded only in a compatibility matrix. + +The underlying finding is the one that motivated putting effort here at all: +formal specifications tend to die (Polkadot's was marked unmaintained on +2 October 2024; the Ethereum Yellow Paper stops at Shanghai, April 2023; Bitcoin +never produced one), while numbered proposal processes survive. A process is only +worth that bet if it has the mechanisms that made the surviving ones survive. + +## Specification + +The normative text is AIP-1 revision 2, sections 2 through 6. Summary of what was +added, with the precedent each mechanism is taken from: + +| Mechanism | Precedent | Failure it prevents | +| --- | --- | --- | +| Numbers assigned at Draft entry, never reused, retained through Withdrawn | IETF RFC 2026; PEP 1; EIP-1 | A citation resolving to a different document than the one cited | +| Explicit table of permitted status transitions, including that Final has no outbound transition | PEP 1's state diagram; EIP-1's status set | Status becoming an adjective applied by judgment rather than a state with rules | +| Paired `Supersedes` / `Superseded-By` headers | IETF `Obsoletes` / `Obsoleted by` (RFC 2026, RFC 7322); PEP 1 `Replaces` / `Superseded-By` | A reader landing on outdated text with no path to the current text | +| Mandatory template with no removable sections | EIP-1 required sections; RFC 3552 mandating Security Considerations | An omission being invisible, since "None" is challengeable and an absent section is not | +| Post-acceptance immutability, with errata and outcome records appended and dated | RFC Editor immutability plus separate errata; Nygard Architecture Decision Records | Silent revision of accepted decisions, which makes the whole archive uncitable | + +Alongside the process change, this AIP records the housekeeping that made the +index true: AIP-8 moved into `aere-research/aips/`; AIP-9 through AIP-16 materialized as +individual files; AIP-17 (base-fee floor) and AIP-18 (EIP-2935 deviation) filed as +new retro-filed records; and `CONTRIBUTING.md` added as the outsider path. + +## Rationale + +Everything here is borrowed. Aere has one operator, no external contributors, and +a young archive, so it has not yet encountered the failures these mechanisms +prevent. That is precisely the argument for adopting them now: the cost of adding +a `Superseded-By` header to a nineteen-document archive is trivial, and the cost +of adding it to a two-hundred-document archive that has been edited in place for +three years is that you cannot, because the history needed to do it correctly is +gone. + +**Alternatives rejected.** Designing an Aere-specific process: it would be a +solution to problems we have not had, while missing the ones already known. +Deferring until external contributors exist: the mechanisms are cheap now and +expensive later, and the archive being built today is the one that would need +retrofitting. + +## Backwards Compatibility + +AIP-2 through AIP-16 remain valid and are not rewritten. Missing `Superseded-By` +headers on older AIPs read correctly as "not superseded". Sections 2 through 6 of +AIP-1 bind every AIP filed from 2026-07-20 onward and are applied to earlier AIPs +on their next touch. Post-Acceptance Outcome Records appended to AIP-2, AIP-3 and +AIP-7 on 2026-07-20 are additions under the new rule and change no existing +sentence in those documents. + +## Security Considerations + +This AIP does not change the fundamental governance weakness: a single party can +still both author and ratify. Immutability and sourcing rules limit the damage +that state can do (a false claim becomes dated, attributed, and hard to erase +quietly) but they do not remove it. Only independent ratifiers do that. + +There is a specific new risk worth naming: an immutability rule that is not +enforced by tooling is enforced by discipline, and discipline is not a control. A +repository-level check that a Final AIP's normative sections have not changed +between commits would make the rule real. That check does not exist yet and is +listed here as an open item rather than claimed as shipped. + +## Reference Implementation and On-Chain Deployment + +None. This is a process document. Artifacts: `aere-research/aips/AIP-1.md` (revision 2), +`aere-research/aips/aip-template.md`, `aere-research/aips/README.md`, +`aere-research/aips/CONTRIBUTING.md`. + +## Copyright + +Released to the public domain (CC0). No rights reserved. diff --git a/aips/AIP-2.md b/aips/AIP-2.md index d3acf0a..aebd1b2 100644 --- a/aips/AIP-2.md +++ b/aips/AIP-2.md @@ -48,7 +48,7 @@ third-party explorer or analyst against the whitepaper. anyone, which forwards its native balance to `address(0)` (QBFT Besu permits a send to the zero address, after which the value is unreachable). Counters `totalBurnedAERE` and `totalSentToZero` make the burn queryable in O(1). - Source: `contracts/contracts/AereFeeBurnVault.sol`. + Source: `aere-contracts/contracts/AereFeeBurnVault.sol`. - **AereCoinbaseSplitter** at `0xb4b0eCe9011613A5b84248a9B42a0f309E6F01Ec`. The routing contract. A validator or its forwarder daemon calls @@ -57,11 +57,11 @@ third-party explorer or analyst against the whitepaper. burnBps / 10000`, forwards `burnAmount` to AereFeeBurnVault via its `burn()` entrypoint, and returns the remainder to the validator address. It maintains lifetime counters `totalBurned` and `totalDistributed` and per-caller - attributions. Source: `contracts/contracts/AereCoinbaseSplitter.sol`. + attributions. Source: `aere-contracts/contracts/AereCoinbaseSplitter.sol`. - **AereCoinbaseSplitterV2** at `0x8C1A48eFA57b66fEE743A00E3899c29ad3Fd27b4`. The current canonical splitter. Source: - `contracts/contracts/AereCoinbaseSplitterV2.sol`. + `aere-contracts/contracts/AereCoinbaseSplitterV2.sol`. ### Parameters @@ -116,9 +116,9 @@ reentrancy-guarded, and the burn vault has no withdraw path or admin. The ## Reference Implementation and On-Chain Deployment -- `contracts/contracts/AereCoinbaseSplitter.sol` -> `0xb4b0eCe9011613A5b84248a9B42a0f309E6F01Ec` -- `contracts/contracts/AereCoinbaseSplitterV2.sol` -> `0x8C1A48eFA57b66fEE743A00E3899c29ad3Fd27b4` -- `contracts/contracts/AereFeeBurnVault.sol` -> `0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6` +- `aere-contracts/contracts/AereCoinbaseSplitter.sol` -> `0xb4b0eCe9011613A5b84248a9B42a0f309E6F01Ec` +- `aere-contracts/contracts/AereCoinbaseSplitterV2.sol` -> `0x8C1A48eFA57b66fEE743A00E3899c29ad3Fd27b4` +- `aere-contracts/contracts/AereFeeBurnVault.sol` -> `0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6` - Related extra-burn bucket: AereSink `0x69581B86A48161b067Ff4E01544780625B231676` (AIP-5) All addresses copied verbatim from `sdk-js/src/addresses.ts`. Live cumulative diff --git a/aips/AIP-4.md b/aips/AIP-4.md index 256f027..48f5c5d 100644 --- a/aips/AIP-4.md +++ b/aips/AIP-4.md @@ -14,6 +14,8 @@ | Status | Final | | Created | 2026-07-11 | | Requires | None | +| Supersedes | None | +| Superseded-By | None | | Ratification | Foundation-ratified (pre-decentralization) | ## Abstract @@ -65,12 +67,12 @@ pure Solidity are `view`-only until a native precompile exists (see below). Validation vectors used, as repo fixtures: -- Falcon-512: `contracts/test/falcon512_kat0.json` (official NIST KAT). -- Falcon-1024: `contracts/test/falcon1024_kat0.json` (official round-3 KAT). -- XMSS: `contracts/test/fixtures/xmss-sha2_10_256-kat.json` (xmss-reference vectors). -- ML-DSA-44: `contracts/test/fixtures/mldsa44-acvp-tg8.json` (NIST ACVP +- Falcon-512: `aere-contracts/test/falcon512_kat0.json` (official NIST KAT). +- Falcon-1024: `aere-contracts/test/falcon1024_kat0.json` (official round-3 KAT). +- XMSS: `aere-contracts/test/fixtures/xmss-sha2_10_256-kat.json` (xmss-reference vectors). +- ML-DSA-44: `aere-contracts/test/fixtures/mldsa44-acvp-tg8.json` (NIST ACVP ML-DSA-sigVer, 15/15 cases reproduce NIST's expected results). -- SPHINCS+/SLH-DSA: `contracts/test/fixtures/sphincs-sha2-128s-acvp-tg31.json` +- SPHINCS+/SLH-DSA: `aere-contracts/test/fixtures/sphincs-sha2-128s-acvp-tg31.json` (NIST ACVP SLH-DSA-sigVer, 14/14 cases reproduce NIST's expected results). ### Account-layer primitives (live on chain 2800) @@ -102,6 +104,7 @@ in its stack than AERE does, inside its own state proofs. That prior art, with sources and dates, is set out in `aere-research/research/pqc-onchain-verification.md`, Section 8. + ## Rationale Pure-Solidity verifiers were built first because they run on the live chain today @@ -188,7 +191,7 @@ Further honest caveats: ## Reference Implementation and On-Chain Deployment -Verifier sources are under `contracts/contracts/` (glob for the PQC, Falcon, +Verifier sources are under `aere-contracts/contracts/` (glob for the PQC, Falcon, XMSS, ML-DSA, and SPHINCS verifiers). All addresses in the tables above are copied verbatim from `sdk-js/src/addresses.ts`. Each verifier is live and answerable via `eth_call` on `https://rpc.aere.network` (chain ID 2800): official vectors return @@ -199,4 +202,3 @@ under the EIP-7825 cap. ## Copyright Released to the public domain (CC0). No rights reserved. - diff --git a/aips/AIP-5.md b/aips/AIP-5.md index c24e1fd..e735d9c 100644 --- a/aips/AIP-5.md +++ b/aips/AIP-5.md @@ -12,6 +12,8 @@ | Status | Final | | Created | 2026-07-11 | | Requires | 2 | +| Supersedes | None | +| Superseded-By | None | | Ratification | Foundation-ratified (pre-decentralization) | ## Abstract @@ -40,7 +42,7 @@ point of trust or a point of failure. ### AereSink (immutable three-bucket router) Address `0x69581B86A48161b067Ff4E01544780625B231676`. Source -`contracts/contracts/sink/AereSink.sol`. +`aere-contracts/contracts/sink/AereSink.sol`. Fee-source contracts call `flush(token, amount)` after approving the sink. The sink splits the amount into three buckets by immutable basis points that MUST sum @@ -67,7 +69,7 @@ router means redeploying and rewiring fee sources, not mutating this contract. ### sAERE (ERC-4626 receipt token) Address `0xA2125bE9C6fd4196D9F94757Df18B3a2A5e650b0`. Source -`contracts/contracts/staking/sAERE.sol`. +`aere-contracts/contracts/staking/sAERE.sol`. sAERE is a standard ERC-4626 vault: deposit WAERE, receive sAERE shares. The WAERE-per-sAERE rate rises as the staker-yield bucket arrives. Two hardening @@ -131,8 +133,8 @@ not change existing contracts. Fee sources opt in by calling `flush`. ## Reference Implementation and On-Chain Deployment -- `contracts/contracts/sink/AereSink.sol` -> `0x69581B86A48161b067Ff4E01544780625B231676` -- `contracts/contracts/staking/sAERE.sol` -> `0xA2125bE9C6fd4196D9F94757Df18B3a2A5e650b0` +- `aere-contracts/contracts/sink/AereSink.sol` -> `0x69581B86A48161b067Ff4E01544780625B231676` +- `aere-contracts/contracts/staking/sAERE.sol` -> `0xA2125bE9C6fd4196D9F94757Df18B3a2A5e650b0` - Burn destination: AereFeeBurnVault `0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6` (AIP-2) - Base token: WAERE `0x7e84d7d66d5da4cfE46Da67CDEeB05B323e1f5e8` - Deploy script: `contracts/deploy/deploy-saere-sink-stack.js` (splits 1500/4000/4500) @@ -144,4 +146,3 @@ is readable on-chain via `AereSink.BURN_BPS()`, `BUYBACK_BPS()`, and ## Copyright Released to the public domain (CC0). No rights reserved. - diff --git a/aips/AIP-6.md b/aips/AIP-6.md index 0ef851e..ac1d93d 100644 --- a/aips/AIP-6.md +++ b/aips/AIP-6.md @@ -12,6 +12,8 @@ | Status | Final | | Created | 2026-07-11 | | Requires | None | +| Supersedes | None | +| Superseded-By | None | | Ratification | Foundation-ratified (pre-decentralization) | ## Abstract @@ -132,9 +134,9 @@ a paymaster. ## Reference Implementation and On-Chain Deployment -Sources under `contracts/contracts/passkey/` (accounts, factories, MultiOwnable, -EntryPointV2, WebAuthn, P256Probe) and `contracts/contracts/` plus -`contracts/contracts/paymaster/` (the paymasters and EntryPoint). Addresses: +Sources under `aere-contracts/contracts/passkey/` (accounts, factories, MultiOwnable, +EntryPointV2, WebAuthn, P256Probe) and `aere-contracts/contracts/` plus +`aere-contracts/contracts/paymaster/` (the paymasters and EntryPoint). Addresses: - AereEntryPoint `0x19773ba45287A64B05d0BCBD59D1371BF51Bd5D2` - AereEntryPointV2 `0x8D6f40598d552fF0Cb358b6012cF4227B86aF770` @@ -152,4 +154,3 @@ activation (unix 1780220351, block 2,106,597). ## Copyright Released to the public domain (CC0). No rights reserved. - diff --git a/aips/AIP-8.md b/aips/AIP-8.md new file mode 100644 index 0000000..6199524 --- /dev/null +++ b/aips/AIP-8.md @@ -0,0 +1,390 @@ +# AIP-8: Post-Quantum-Authorized Transaction Envelope (EIP-2718 Type 0x2A) + +> **Note added 2026-08-19.** Statements in this document that consensus on chain 2800 is (or remains) classical secp256k1 ECDSA QBFT were written before the post-quantum header anchor went live, and remain true for block-by-block finality. Since block 13,014,000 anchor blocks (every 32nd block, on every one since block 13,889,296) also carry, under the block hash, a certificate of validator Falcon-512 seals, and since 2026-08-14 a node rejects an anchor block with fewer than three valid seals (f+1 of nine; eight or nine are carried in practice). That is a post-quantum checkpoint about every 16 seconds, not a per-block quorum: the claim published on 2026-08-15 that from block 14,050,000 no block finalizes without a post-quantum quorum was wrong (the per-block rule armed at that height is retired in the shipped code in favour of the anchor rules) and was withdrawn on 2026-08-19. Details: https://aere.network/quantum.html and the aere-node repository, anchor/README.md. + +## Preamble + +| Field | Value | +| --- | --- | +| AIP | 8 | +| Title | Post-Quantum-Authorized Transaction Envelope (EIP-2718 Type 0x2A) | +| Author | Aere Network Foundation | +| Type | Standards Track | +| Category | Core | +| Status | Draft | +| Created | 2026-07-18 | +| Requires | 7 | +| Supersedes | None | +| Superseded-By | None | +| Ratification | Not ratified; Draft. Ratifier is the founder (pre-decentralization). | + +## Abstract + +This AIP specifies a new EIP-2718 typed transaction, `TransactionType = 0x2A`, whose +**sender authorization is a NIST post-quantum signature** (Falcon-512 or ML-DSA-44) +rather than a secp256k1 ECDSA signature. The transaction carries a scheme selector, a +raw PQC public key, and a PQC signature; the sender address is derived from the public +key, and the transaction is valid only if the signature verifies against the exact same +native precompiles that are already live on AERE mainnet chain 2800 (Falcon-512 `0x0AE1`, +ML-DSA-44 `0x0AE3`, activated at block 9,189,161 per AIP-7). It makes ordinary value and +contract-call transactions authorizable by a quantum-resistant key with no smart-account +indirection. This is a **base-layer execution change requiring a coordinated Besu hard +fork**; it is NOT yet live. It is explicit that this does not change how AERE blocks are +proposed, signed, or committed: consensus remains classical secp256k1 ECDSA QBFT and is +not post-quantum. A deploy-today reference path that needs no fork +(`AerePQCTxAccount.sol`, an ERC-4337 account) accompanies this AIP. + +## Motivation + +AERE has live, mainnet-proven post-quantum signature verification at the precompile layer +(AIP-7) and usable post-quantum authorization at the account layer (AerePQCAccount, +AereThresholdAccount, AerePQCSocialRecoveryModule). What is still missing is the most +basic object of all: an ordinary externally-originated transaction whose right to spend an +account is a post-quantum signature. + +Today every transaction on chain 2800, including one that calls a post-quantum contract, +is itself authorized by a secp256k1 ECDSA signature. The account's ability to move its +native balance rests on ECDSA. A cryptographically-relevant quantum computer running +Shor's algorithm breaks secp256k1: it recovers the private key from the public key, and on +any account that has ever sent a transaction the public key is already on-chain. Account- +layer PQC (a 4337 smart account) closes this for smart-contract wallets, but it cannot +protect a plain externally-owned account (EOA), and it adds a bundler/EntryPoint and a +deployment step. A base-layer post-quantum transaction type closes the gap for the EOA +itself: the account is a hash of a PQC public key, and only a PQC signature can spend it. + +The goal is a transaction type that (1) reuses the audited, mainnet-live precompile verify +paths verbatim (no new cryptography), (2) is a pure function of the transaction bytes for +validation (like ECDSA sender recovery, so mempool validation reads no state), (3) fits far +under the Fusaka EIP-7825 per-transaction gas cap, and (4) is a strictly additive, +client-only hard fork with no re-genesis, exactly like AIP-7. + +## Specification + +The keywords MUST, SHOULD, and MAY are to be interpreted as in RFC 2119. + +### Transaction type byte + +The transaction type is `0x2A`. + +EIP-2718 constrains a valid `TransactionType` to the range `[0x00, 0x7f]`: a first byte +`>= 0xc0` is ambiguous with the RLP list header of a legacy transaction and is excluded, +and EIP-2718 recommends implementers stay within `0x00`..`0x7f`. Within that range the +Ethereum L1 assignments are `0x01` (EIP-2930), `0x02` (EIP-1559), `0x03` (EIP-4844), and +`0x04` (EIP-7702); AERE recognizes all four. `0x2A` is chosen because it is unassigned by +any Ethereum L1 EIP and sits well below the `0x64`..`0x7f` band that existing L2s have +informally colonized (Arbitrum `0x64`..`0x6c`, zkSync Era `0x71`+, Optimism deposit +`0x7e`, Celo `0x7b`..`0x7d`), which minimizes the chance that an imported third-party tool +misparses an AERE PQ transaction as some other chain's type. `0x2A` is reserved henceforth +in the AERE chain specification for this purpose. If Ethereum L1 later assigns `0x2A`, AERE +will re-evaluate to preserve equivalence, as AIP-7 commits to for the precompile band. + +### Signature-scheme selector + +A one-byte `pq_scheme` selects the NIST scheme and the precompile that validates it. The +values match AIP-7 and AerePQCAttestation: + +| `pq_scheme` | Scheme | Precompile | Public-key length | Signature envelope | +| --- | --- | --- | --- | --- | +| `0x01` | Falcon-512 | `0x0AE1` | 897 bytes (header `0x09`) | `nonce(40) || esig` (esig starts `0x29`) | +| `0x03` | ML-DSA-44 | `0x0AE3` | 1312 bytes | `sig`, exactly 2420 bytes | + +`pq_scheme` `0x02` (Falcon-1024, `0x0AE2`, 1793-byte pk) and `0x04` (SLH-DSA-128s, `0x0AE4`, +32-byte pk, 7856-byte sig) MAY be enabled by the same rules; they are omitted from the +mandatory set because Falcon-512 (NIST level 1, smallest signature) and ML-DSA-44 (FIPS 204, +fixed-size, conservative) span the practical trade-off between signature size and margin. +Any other value MUST be rejected as an invalid transaction. + +### RLP wire format + +A type-`0x2A` transaction is the concatenation of the type byte and the RLP encoding of a +12-element list: + +``` +0x2A || rlp([ + chain_id, # scalar; MUST equal 2800 for AERE mainnet + nonce, # scalar; the PQC-derived sender's account nonce + max_priority_fee_per_gas, # scalar (EIP-1559 semantics) + max_fee_per_gas, # scalar (EIP-1559 semantics) + gas_limit, # scalar + to, # 20-byte address, or empty (0x) for contract creation + value, # scalar + data, # byte string + access_list, # EIP-2930 [[address, [storageKey, ...]], ...] + pq_scheme, # single byte, 0x01 or 0x03 (see selector table) + pq_public_key, # raw NIST public key for pq_scheme + pq_signature # signature envelope for pq_scheme (see selector table) +]) +``` + +The fee, gas, `to`, `value`, `data`, and `access_list` fields are identical in meaning to +EIP-1559 (type `0x02`) with an EIP-2930 access list, so existing execution and fee-market +logic is unchanged. The three trailing fields replace the ECDSA `(y_parity, r, s)` triple. + +The transaction hash is `keccak256(0x2A || rlp([...all 12 fields...]))`, as for any typed +transaction. + +### Sender derivation + +The sender is derived from the PQC public key and the scheme, not from signature recovery: + +``` +sender = keccak256(pq_scheme || pq_public_key)[12:32] # last 20 bytes +``` + +Binding the address to `pq_scheme` as well as the key means the same raw key bytes under a +different scheme selector yield a different account, so there is no cross-scheme aliasing. A +user migrates to post-quantum custody by moving assets to their `sender` address; from then +on only a valid PQC signature can spend it. Unlike ECDSA, the public key is transmitted in +full on every transaction (the verify precompiles are stateless), which is safe: Falcon and +ML-DSA remain secure with the public key exposed. This is the point of the design, not a +weakness. + +### Signing message and verification + +`pq_signature` MUST be a valid signature, under `pq_public_key` and `pq_scheme`, over the +32-byte digest: + +``` +sig_hash = keccak256(0x2A || rlp([ + chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, + to, value, data, access_list, pq_scheme, pq_public_key +])) # the 12-field list WITHOUT pq_signature +``` + +Validation MUST assemble the precompile input for `pq_scheme` exactly as +AerePQCAttestation / AerePQCKeyRegistry do, with `sig_hash` as the signed message, and +accept the transaction only if the corresponding precompile returns the 32-byte +"valid" word `0x…01`: + +- Falcon-512: `input = pk(897) || sm`, where `sm = sigLen(2, big-endian) || nonce(40) || + sig_hash(32) || esig` and `sigLen == esig.length`; call `0x0AE1`. +- ML-DSA-44: `input = pk(1312) || sig(2420) || sig_hash(32)`; call `0x0AE3`. + +The client MUST use the same Bouncy Castle 1.83 verify path the precompile wraps, so +that transaction validation and an in-EVM `STATICCALL` to the precompile agree bit-for-bit +on every `(pq_public_key, sig_hash, pq_signature)` triple. A transaction whose signature +does not verify has no valid sender and is invalid: it MUST be rejected from the mempool and +MUST NOT be included in a block, exactly as an ECDSA transaction with an unrecoverable +signature is. + +### Nonce and replay handling + +- **Cross-chain replay** is prevented by `chain_id` inside both the transaction and + `sig_hash`: a signature for chain 2800 does not verify for any other chain id. +- **Intra-chain replay and ordering** are enforced by `nonce`, the account nonce of the + PQC-derived `sender`, tracked in world state and incremented on inclusion, identical to an + ECDSA account. A given `(sender, nonce)` can be mined at most once. +- **Cross-protocol replay** (reusing a PQ tx signature as an AerePQCAttestation, + AerePQCKeyRegistry, or ERC-4337 authorization, or vice-versa) is prevented because those + surfaces sign structurally different messages: attestation/registry/account challenges are + `keccak256(abi.encode(DOMAIN, ...))` or `abi.encodePacked(domain, hash)` byte strings that + can never equal the `0x2A || rlp(...)` preimage of `sig_hash`. The leading type byte `0x2A` + in the signed preimage is the domain tag for this transaction type, mirroring how EIP-1559 + signs `keccak256(0x02 || rlp(...))`. + +### Gas accounting + +Intrinsic gas for a type-`0x2A` transaction is: + +``` +intrinsic = 21000 + + calldata_gas(entire type-0x2A payload, including pq_public_key + pq_signature) + + access_list_gas # EIP-2930: 2400 per address, 1900 per storage key + + PQ_VERIFY_GAS[pq_scheme] # fork constant, MUST equal the live precompile verify gas +``` + +`PQ_VERIFY_GAS` MUST equal the marginal verify-op gas the corresponding precompile charges, +which AIP-7 measured on the pre-activation scratch fork (chain 28099) and carried to +mainnet: + +| Scheme | `PQ_VERIFY_GAS` (measured, AIP-7) | +| --- | --- | +| Falcon-512 (`0x0AE1`) | 40,000 | +| ML-DSA-44 (`0x0AE3`) | 55,000 | +| Falcon-1024 (`0x0AE2`) | 75,000 | +| SLH-DSA-128s (`0x0AE4`) | 350,000 | + +The dominant *additional* cost versus an EIP-1559 transaction is the calldata for the public +key and signature. Approximate PQ-material sizes and the resulting calldata component (to be +measured on the scratch fork; calldata is priced at EIP-2028 rates, subject to the EIP-7623 +floor): + +| Scheme | pk bytes | sig-envelope bytes | PQ material | approx. calldata gas | +| --- | --- | --- | --- | --- | +| Falcon-512 | 897 | ~707 (40 + 1 + ~666) | ~1,605 B | ~24,000 (to be measured) | +| ML-DSA-44 | 1,312 | 2,420 | ~3,732 B | ~56,000 (to be measured) | + +A complete Falcon-512 PQ transaction therefore lands near `21,000 + ~24,000 + 40,000 ≈ +85,000` gas of intrinsic cost before execution, consistent with AIP-7's measured +end-to-end Falcon-512 verify-and-record transaction of 86,336 gas; a ML-DSA-44 PQ +transaction lands near `21,000 + ~56,000 + 55,000 ≈ 132,000`. Both are a tiny fraction of +the EIP-7825 per-transaction cap of 16,777,216 (2^24), leaving the full block-execution +budget for the call itself. + +`PQ_VERIFY_GAS` is folded into intrinsic gas so the sender pays for the verification work +that validators perform. Because signature validity is a precondition of transaction +validity, a transaction with an invalid signature is never included and thus is never +charged on-chain, exactly as with a bad ECDSA signature; it simply cannot be mined. + +### Base-layer activation sketch (Besu fork) + +The change is a strictly additive execution-layer fork of the AERE Besu build (base +`hyperledger/besu:26.4.0`, the same tree that carries the AIP-7 precompiles). No re-genesis, +no state migration. The implementation touches, at minimum: + +1. **TransactionType.** Add `PQ_AUTHORIZED((byte) 0x2A)` to + `org.hyperledger.besu.datatypes.TransactionType`. +2. **Codec.** Add a `PQAuthorizedTransactionDecoder` / `PQAuthorizedTransactionEncoder` + implementing the 12-field RLP layout above and register them in the `TransactionDecoder` / + `TransactionEncoder` dispatch. Extend the `Transaction` model to carry `pqScheme`, + `pqPublicKey`, and `pqSignature`, and override sender computation for this type to + `keccak256(pqScheme || pqPublicKey)[12:]`, defined only when the PQC signature verifies. +3. **PQ signature verifier.** A `PQAuthorizedSignatureVerifier` that calls the exact same + Bouncy Castle 1.83 BCPQC verify path (`AereFalconSupport.verify`, ML-DSA `verifyInternal`) + the `0x0AE1` / `0x0AE3` precompiles wrap. Zero new cryptography; reuse the precompile + adapters through the same classloader-isolation boundary AIP-7 established. +4. **Validation.** In `MainnetTransactionValidator` (via `TransactionValidatorFactory`), for + type `0x2A`: reconstruct `sig_hash`, verify the PQC signature (reject with an INVALID + reason on failure), derive the sender, and validate nonce, balance, and intrinsic gas as + usual. +5. **Gas.** Extend the `GasCalculator` with `pqAuthorizationIntrinsicGasCost(scheme, payload)` + returning the calldata component plus `PQ_VERIFY_GAS[scheme]`, wired into + `transactionIntrinsicGasCost`. +6. **Mempool and wire.** Teach `TransactionPool` and the eth/68 `Transactions` / + `PooledTransactions` codecs to carry the larger typed body; expose the type in the JSON-RPC + transaction serialization (`eth_getTransactionByHash`, receipts). +7. **Fork gating.** Add an `AerePQTx` milestone to `ProtocolScheduleBuilder` / the chain spec, + activated at a future block or timestamp distinct from the AIP-7 precompile activation. + Before activation, a `0x2A` first byte is an unknown type and is rejected; after + activation it is valid. Because chain 2800 runs seven QBFT validators under one operator on + one client, activation is a flag-day client upgrade across the validator set, exactly as in + AIP-7. A non-upgraded validator would reject the type and fork off, so the upgrade is + mandatory at the fork block. +8. **Differential testing.** Gate ship on a test that, for the NIST KAT vectors in + `pqc-fork/kat` and randomized cases, asserts the transaction-validation verify agrees + bit-for-bit with a `STATICCALL` to the matching precompile over the same + `(pk, sig_hash, sig)`, plus round-trip encode/decode and a full mine-and-receipt path on an + isolated testnet. + +Consensus is untouched: QBFT proposal, the committed-seal ECDSA signatures, and block +structure are unchanged; type `0x2A` is simply another transaction a block may contain, with +its own receipt type. + +## Rationale + +**Full public key in every transaction, not a registry keyId.** An alternative shrinks +calldata by replacing `pq_public_key` with a `keyId` into AerePQCKeyRegistry +(`0x1eCa…3691`). It is rejected for the base type because it makes transaction validation +depend on world state (a registry lookup), which breaks the property that a transaction's +validity is a pure function of its own bytes, the same property ECDSA sender recovery has, +and which mempool validation relies on. The stateless full-key form keeps validation pure +and matches how the live precompiles already work. A registry-indexed companion type could be +specified later once the state-dependency implications for the mempool are worked through. + +**Sender = hash of (scheme, key), reusing the 20-byte address space.** This keeps the PQ +account indistinguishable from any other address to every downstream contract, tool, and +explorer: balances, `CALL`, `msg.sender`, and logs all behave normally. The only thing that +changes is who may originate a transaction from that address. + +**Type `0x2A` over a higher value.** Staying in the low half of the valid range and away +from the L2-colonized `0x64`..`0x7f` band reduces cross-ecosystem tool confusion, at no cost. + +**A base-layer type at all, given 4337 exists.** ERC-4337 already gives post-quantum +authorization for smart-contract wallets and is the recommended path today (see the reference +implementation). But a 4337 account cannot protect a plain EOA, requires a deployed contract +and a bundler, and pays EVM-execution overhead for validation. The base type is the only way +to make an *ordinary* account post-quantum, and it prices verification at the native +precompile cost rather than in-EVM. The trade-off is that it requires a hard fork and touches +the entire transaction-decoding surface of the ecosystem, which is exactly why it is filed as +a Draft with a shipping 4337 alternative rather than activated immediately. + +## Backwards Compatibility + +Additive. Existing legacy, `0x01`, `0x02`, `0x03`, and `0x04` transactions are unaffected. +Before the `AerePQTx` fork block, a `0x2A` transaction is an unknown type and is rejected by +all nodes; after it, all nodes accept it. There is no change to existing accounts, contracts, +receipts of other types, or the genesis state root. + +Ecosystem tooling that decodes raw transactions (wallets, explorers, indexers, the RPC +transaction serializer, hardware-wallet firmware, signing libraries) MUST learn type `0x2A` +to build, sign, display, or index these transactions. Tools that only handle types they +recognize will treat a `0x2A` transaction as opaque or unsupported rather than misdecode it, +because the type byte is self-describing. This ecosystem surface is the principal cost of the +change and the reason the ERC-4337 path is preferred for immediate use. + +Because AERE runs all validators under one operator and one client, activation is a +mandatory flag-day client upgrade across the validator set at the fork block, as in AIP-7. A +validator that had not upgraded would reject the type and fork. + +## Security Considerations + +**This change does not make AERE consensus post-quantum.** Validators continue to sign +classical secp256k1 QBFT committed seals; blocks are proposed and committed exactly as today. +Type `0x2A` makes an individual transaction's *sender authorization* post-quantum. It does +not make block production, finality, or the validator set post-quantum, and any claim to that +effect on the basis of this AIP would be false and must not be made. + +**A valid signature is not authorization beyond spend rights.** A "valid" precompile decision +establishes only that `pq_signature` is a valid signature by `pq_public_key` over `sig_hash`. +Freshness and ordering come from `nonce`; scope comes from the tx fields themselves. There is +no key rotation or recovery at this layer: losing the PQC private key loses the account, the +same as losing an ECDSA key. Users who need rotation or social recovery should hold assets in +an ERC-7579 account guarded by AerePQCSocialRecoveryModule instead of, or in addition to, a +PQ EOA. + +**Single operator, one client (no client-diversity safety net).** Chain 2800's seven QBFT +validators are one operator on one execution client. A consensus bug in the PQ-transaction +validation path (for example a decoder edge case, or a divergence between the tx-validation +verify and the precompile verify) would not be caught by a second live client, because there +is none. This raises the bar for external audit and for the mandatory bit-for-bit +differential testing in the activation sketch. + +**Determinism.** Transaction validation, like a precompile, must be deterministic and read no +node-local state or block context beyond the transaction and the account nonce/balance. +Falcon verification MUST use the integer-only verify path (never the floating-point signing +path). Malformed structure MUST be rejected deterministically as an invalid transaction, not +faulted. + +**Public-key exposure is intended.** The public key is on-chain from the account's first +transaction. This is safe for Falcon and ML-DSA and is the mechanism by which the account is +quantum-resistant; it is called out only to preempt the ECDSA-era intuition that an unspent +address "hides" its key. + +**Not live; external audit pending.** This is a Draft specification and a reference- +implementation sketch. Nothing here is deployed on chain 2800. The precompiles it reuses +carry an internal self-audit only (AIP-7). This transaction type MUST NOT secure material +value until it is implemented, differentially tested against the live precompiles, and +covered by an external security audit. + +## Reference Implementation and On-Chain Deployment + +**Not yet live.** The base-layer fork above is a specification and a Besu implementation +sketch, not a deployed change. + +**Deploy-today reference path (no fork required).** The same user-visible guarantee, "a +transaction is authorized by a post-quantum signature and nothing else", is delivered today, +with no base-layer change, by an ERC-4337 v0.7 smart account whose sole owner is a NIST PQC +key and whose `validateUserOp` verifies via the live precompiles: + +- Contract: `aere-contracts/contracts/pqc/AerePQCTxAccount.sol` (this repository). +- Tests: `aere-contracts/test/AerePQCTxAccount.test.js` (MockPQCPrecompile across all four schemes + plus a genuine Falcon-512 path through the NIST-KAT-proven AereFalcon512Verifier). +- **Verified 2026-07-18:** compiled and tested under the canonical Hardhat toolchain, + `npx hardhat compile` then `npx hardhat test test/AerePQCTxAccount.test.js`. The contract + compiles clean and all 20 tests pass: the mock verifier across all four schemes, the + domain-separation and single-use replay checks, and two genuine Falcon-512 paths through the + NIST-KAT-proven verifier. This bullet records an actual machine run; it should be read as a + verified result, not an untested present-tense assertion. +- It calls the live precompiles (`0x0AE1`..`0x0AE4`) directly with the identical wire + encoding proven on mainnet by AerePQCAttestation + (`0x465d9E3b476BF98Aa1393079e240Db5D2a9bEA6A`) and AerePQCKeyRegistry + (`0x1eCa3c5ADcBD0b22636D8672b00faC6D89363691`), and targets AereEntryPointV2 + (`0x8D6f40598d552fF0Cb358b6012cF4227B86aF770`). Addresses are copied verbatim from + `sdk-js/src/addresses.ts`. + +The precompile band, its activation block (9,189,161), and the wire encoding are verifiable +on `https://rpc.aere.network` (chain id 2800) as documented in AIP-7. + +## Copyright + +Released to the public domain (CC0). No rights reserved. diff --git a/aips/AIP-9.md b/aips/AIP-9.md new file mode 100644 index 0000000..86048fc --- /dev/null +++ b/aips/AIP-9.md @@ -0,0 +1,102 @@ +# AIP-9: Consensus Mechanism: QBFT, not HotStuff + +## Preamble + +| Field | Value | +| --- | --- | +| AIP | 9 | +| Title | Consensus Mechanism: QBFT, not HotStuff | +| Author | Aere Network Foundation | +| Type | Informational | +| Category | (none) | +| Status | Final | +| Created | 2026-07-19 | +| Requires | 3 | +| Supersedes | None | +| Superseded-By | None | +| Ratification | Foundation-ratified (pre-decentralization) | + +## Abstract + +This AIP records the decision to run QBFT as Aere's consensus protocol rather +than HotStuff or a pipelined HotStuff variant. It backfills a decision that is +already live on chain 2800. It is a decision record: it explains why a shipped +choice was made and mandates nothing new. + +## Motivation + +Aere is a settlement layer whose core promise is deterministic, single-slot +finality at a sub-second cadence, running a small permissioned validator set: +seven validators today, with a roadmap target in the 9 to 21 range. The consensus +choice determines whether that promise is deliverable at all, and it was taken +without being written down anywhere citable. + +## Specification + +Aere runs QBFT, the Byzantine-fault-tolerant IBFT-family protocol as implemented +in Hyperledger Besu, producing deterministic single-block finality. + +- Validator count N = 7 (**measured**, all Foundation-operated). +- Fault tolerance f = 2, commit quorum 2f + 1 = 5-of-7 (**spec**). +- Target block period 500 ms (**spec**, see AIP-3); measured mean interval + 516.4 ms. +- Validator seals are classical secp256k1 ECDSA. **Consensus is not + post-quantum** and no part of this record implies otherwise. + +## Rationale + +At Aere's validator-set size, QBFT's O(N^2) message complexity is negligible in +absolute terms: a 5-of-7 quorum verify costs on the order of a few milliseconds +per block, a small fraction of the 500 ms slot. Against that non-cost, QBFT gives +three concrete advantages. It provides deterministic instant single-block +finality, which is the exact settlement guarantee the network sells. It is mature +and already integrated in Besu, so there is no new-protocol implementation risk. +And Aere's post-quantum consensus research, second-client work, and zk finality +proofs are all built against QBFT, so changing it would invalidate that work. + +**Alternatives rejected.** HotStuff and its pipelined variants, whose linear +per-round communication complexity is engineered to scale BFT to hundreds of +validators. That scaling regime is one Aere does not operate in and does not plan +to enter under this design, so HotStuff's headline benefit is unavailable, while +adopting it would add the risk and integration cost of a protocol less +battle-tested in the chosen client. + +## Backwards Compatibility + +None. This records the existing protocol. + +## Security Considerations + +At N = 7 the fault tolerance against node outages is real, but **all seven +validators are Foundation-operated**, so the effective Nakamoto coefficient is 1. +Decentralization, not the consensus mechanism, is the binding trust assumption on +this chain. A reader should not read "Byzantine fault tolerant" as "trustless". + +Consensus seals are secp256k1 ECDSA and are therefore classically breakable by a +cryptographically relevant quantum computer. Work on a hybrid post-quantum +consensus path is recorded in AIP-15 and is **not live**. + +## Reference Implementation and On-Chain Deployment + +Chain ID 2800. Configuration lives in the Besu QBFT genesis and chain config; the +block period transition is documented in AIP-3. There is no contract address for +a consensus choice. + +## Errata + +**Erratum 1 (2026-09-12).** Every validator count in this document is a +measurement of 2026-07-19, the day it was written, and none of them carries that +date in its own sentence, so a sentence quoted on its own reads as a claim about +today. Read them as dated: "seven validators today" in the Motivation, +"Validator count N = 7 (**measured**)" and "commit quorum 2f + 1 = 5-of-7" in the +Specification, and "At N = 7 ... all seven validators are Foundation-operated" in +the Security Considerations were all true on 2026-07-19. Measured 2026-09-12 on +the live chain: N = 10, f = 3, commit quorum 7-of-10, and one of the ten runs a +different client implementation. The decision this AIP records, QBFT rather than +HotStuff, is unaffected, and so is the Nakamoto argument in the Security +Considerations: the set grew, the operator count did not. The original text is +left exactly as published, per AIP-1 section 5. + +## Copyright + +Released to the public domain (CC0). No rights reserved. diff --git a/aips/CONTRIBUTING.md b/aips/CONTRIBUTING.md new file mode 100644 index 0000000..a4cf984 --- /dev/null +++ b/aips/CONTRIBUTING.md @@ -0,0 +1,130 @@ +# Proposing a change to Aere Network + +This document is for someone who is not part of the Aere Foundation and wants to +change how Aere Network works. It tells you what to do, what happens next, and +who decides. The last of those three is the one most projects are vague about, so +it is answered first. + +## Who decides + +**The founder decides.** Today, ratification of an AIP is one person's decision, +exercised through the Aere Foundation account +`0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3`. That account is a single key. It is +not a multisig, it is not a timelock, and there is no on-chain vote that binds it. + +There is a governance stack deployed on chain 2800 (a Governor, a Timelock, and a +governance token). **It controls nothing.** No production contract on chain 2800 +is owned by a timelock, and the governance contracts hold no authority over the +protocol. They exist as deployed, inert infrastructure for a future in which they +do. Do not read their existence as a claim that Aere has on-chain governance. + +The network runs seven QBFT validators, all operated by the Foundation, on one +live client, with no external security audit. The effective Nakamoto coefficient +is 1. + +This is worth stating plainly rather than implying a governance that does not +exist. If you are deciding whether to invest engineering effort in an Aere +proposal, that paragraph is the fact you need, and finding it out later would be +worse for you and for us. + +**What this means in practice for you:** + +- A good technical argument can win. There is no stake threshold, no token + requirement, no membership, and no fee. Your proposal is judged on whether it + is correct and worth doing. +- There is no appeal. If the founder declines your proposal, that is the end of + it inside this process. Aere's proposals are CC0, so forking the record and + implementing your version elsewhere is always available to you, and nobody here + will treat that as hostile. +- A rejection will be written down. If your AIP is rejected, it keeps its number, + moves to Withdrawn, and stays in the repository with the reason recorded. We do + not delete proposals we disagreed with. + +## What we will not do + +Two commitments, so you know what you are relying on: + +1. **We will not renumber or reuse your number.** Once your proposal is assigned + AIP-N it is AIP-N permanently, including if it is withdrawn (AIP-1 section 2). +2. **We will not silently edit your proposal after it is accepted.** A Final AIP + is frozen. Corrections are appended as dated errata that leave the original + text visible (AIP-1 section 5). + +## How to propose + +### Step 0: check it belongs in an AIP + +**In scope:** a protocol or consensus change (block time, fee routing, +precompiles); a new contract standard or interface others integrate against; a +token or account standard convention; a process or governance change. + +**Out of scope:** bug-fix redeploys that preserve an existing interface, routine +parameter tuning inside an already-ratified bound, and pure documentation. A +security vulnerability is **not** an AIP: do not publish it. Report it privately +first. + +If you are unsure, propose it anyway. The editor will tell you. + +### Step 1: write it + +Copy `aip-template.md`. Fill in every section. Do not delete a header; write +"None" if a section does not apply, because "Security Considerations: None" is a +claim a reviewer can challenge and a missing section is not. + +The rules that get proposals bounced fastest: + +- **Cite addresses verbatim** from `sdk-js/src/addresses.ts`. Do not retype them. +- **Label every number** as **measured** (reproducible from the chain or a repo + fixture), **spec** (a configured or standardized value), or **estimate**. +- **Write "to be measured"** rather than guessing. A guessed gas figure is worse + than an absent one, because the reader cannot tell it is a guess. +- **Do not claim post-quantum consensus.** Aere consensus is classical secp256k1 + ECDSA QBFT. Aere's post-quantum work is at the signature, account and + application layers. A proposal that blurs this will be sent back. + +### Step 2: submit it + +Open a pull request against `aere-research/aips/` adding `AIP-N.md`, where N is the +next free integer, plus a row in `README.md`. If you cannot open a pull request, +send the document by any route that reaches the Foundation; the format matters, +the transport does not. + +### Step 3: what happens next + +| Stage | What happens | Who | Typical time | +| --- | --- | --- | --- | +| Well-formedness check | The editor checks the template is complete, the number is right, and every cited address, hash and number is real. This is not a merit review. | Editor (the Foundation today) | days | +| **Draft** | Your number is assigned. You own the document and can keep changing it. | You | as long as you want | +| **Review** | You declare it ready for scrutiny. Open questions are tracked inside the document itself, not in a side channel. | You, plus anyone who comments | open-ended | +| **Last Call** | A final review window, 14 days by default, with the end date written into the document. | Editor | 14 days | +| **Final** | Ratified. Frozen under AIP-1 section 5. | Founder | one decision | + +You can stop at any point by withdrawing. The editor moves a proposal to Stagnant +after six months of inactivity in Draft or Review; anyone, including you later, +can revive it. + +### Step 4: honestly, about "review" + +Aere has **no external technical community commenting on AIPs yet**. This is not +a modesty statement, it is the current state: decentralization is thin and +external usage is thin. If you file a proposal today, the review you get is from +the Foundation, and it may be the only review you get. + +We record that rather than inventing the alternative. There are no fabricated +comment threads in this repository, no invented "the community debated", and no +imagined participants. When real external comment arrives it will be recorded as +it happened. Until then, do not expect a crowd, and do not mistake an empty +comment section for consensus. + +## Reporting a vulnerability instead + +If you found a security bug, this is the wrong document. Do not file an AIP, do +not open a public pull request, and do not include the vulnerability in any +public issue. Report it privately to the Foundation first. Publishing a live +vulnerability against a chain with a single operator and no external audit +endangers users who have no way to react. + +## Copyright + +Everything you submit here is CC0, released to the public domain. If that is not +acceptable to you, do not submit it.