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.
Copyright
Released to the public domain (CC0). No rights reserved.