aere-research/aips/AIP-16.md

5.2 KiB

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.

Released to the public domain (CC0). No rights reserved.