113 lines
6.3 KiB
Markdown
113 lines
6.3 KiB
Markdown
# 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 the nine AERE-client validators (nine of the ten) refuse any QBFT consensus message without a valid Falcon-512 seal of its author, 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 and 2026-10-25). (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`.
|
|
|
|
## Copyright
|
|
|
|
Released to the public domain (CC0). No rights reserved.
|