AIP-16: PQ STARK-Verify Precompile (0x0AE8)

Note added 2026-09-24 (consensus). Where this document says that consensus is classical secp256k1 ECDSA and not post-quantum, read it as the per-block finality statement it was until block 24,300,000 (AIP-22 stage 4, 2026-10-25). Since that block every validator attributes a consensus vote only through its verified post-quantum seal, and a block is post-quantum final once the next anchor, at most 32 blocks later, carries the certificate that covers it; headers still carry classical ECDSA commit seals until AIP-22 stage 5 (this sentence corrected on 2026-10-25). It no longer describes all of consensus on chain 2800: since 2026-08-14 every anchor block must carry a certificate of validator post-quantum seals under its hash (Falcon-512, with SLH-DSA as well since 2026-09-04), and since 2026-09-05 (block 17,250,000) the nine AERE-client validators (nine of the ten) refuse a commit message without a valid Falcon-512 seal of its author, and since 2026-09-08 (block 17,700,000) any QBFT consensus message without one, while the tenth, the second client, enforced that seal only on commit messages until block 24,300,000 and attributes every consensus message only through it since (this clause corrected on 2026-10-12, 2026-10-25 and 2026-10-28; until 2026-10-28 it dated the refusal of every message type to 2026-09-05, the date of the commit layer alone). (Note applied to this document on 2026-10-28.)

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.

6.6 KiB Raw Blame History