111 lines
5.2 KiB
Markdown
111 lines
5.2 KiB
Markdown
# 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.
|