6cb0140fae
The public history carried kat/__pycache__/mlkem768_reference.cpython-314.pyc, a compiled Python artifact embedding the operator's absolute local path. Text secret scanners do not read compiled binaries, which is exactly how it slipped through, and removing it from the tip would have left it reachable through the old root commits. So this repository is republished from a single clean root. This root also carries, from the previously unpublished line of work: - corrected LICENSE year, LICENSING.md, VERIFY-POLICY.md, and CITATIONS-UNRESOLVED.md remeasured 2026-08-11 (101 paths, README aligned) - O-018: run_consensus_verification.py ran 19 of 29 models and reported PASS; it now runs all 29, and computemarket_smt.py gains resolveByTimeout / reclaimUnsettled cases plus a negative control - O-006: the word 'audited' removed from next to Bouncy Castle, twice, after a concurrent edit resurrected it - O-014: prior art named and dated - Algorand's native falcon_verify shipped about ten months before AERE's precompiles; the primacy claim is withdrawn where it was implied - bench/ scripts parametrized so they actually run for an outsider (the earlier textual sanitization left $STAGING unexpanded inside Python strings) - AIP-2/AIP-3 errata with measured figures, spec remeasurements at 2026-08-01, and the spec-zk-stack retractions (owner is an operational key, not the Foundation; 'maximally sound' withdrawn; aggregator V1 deprecated) The redacted bench-host environment files from the sanitized line are kept exactly as published; the unredacted local variants are not carried.
201 lines
12 KiB
Markdown
201 lines
12 KiB
Markdown
# AIP-4: On-Chain Post-Quantum Signature Verification Suite
|
|
|
|
## Preamble
|
|
|
|
| Field | Value |
|
|
| --- | --- |
|
|
| AIP | 4 |
|
|
| Title | On-Chain Post-Quantum Signature Verification Suite |
|
|
| Author | AERE Foundation |
|
|
| Type | Standards Track |
|
|
| Category | Interface |
|
|
| Status | Final |
|
|
| Created | 2026-07-11 |
|
|
| Requires | None |
|
|
| Ratification | Foundation-ratified (pre-decentralization) |
|
|
|
|
## Abstract
|
|
|
|
This AIP documents AERE's suite of on-chain post-quantum signature verifiers,
|
|
implemented in pure Solidity and validated against official NIST Known-Answer-Test
|
|
(KAT) and ACVP vectors. The suite covers hash-based schemes (WOTS+, XMSS,
|
|
SPHINCS+/SLH-DSA) and lattice schemes (Falcon-512, Falcon-1024, ML-DSA-44), plus
|
|
the account-layer primitives that turn Falcon-512 verification into a usable
|
|
wallet. It is a retro-filed record of contracts already live on chain 2800. It is
|
|
explicit that this is an application and account layer capability today; AERE
|
|
consensus is not post-quantum.
|
|
|
|
## Motivation
|
|
|
|
A cryptographically relevant quantum computer would break the secp256k1 ECDSA
|
|
signatures that secure ordinary EVM accounts. The migration path the ecosystem
|
|
will eventually need is on-chain verification of NIST post-quantum signature
|
|
schemes, so that accounts and applications can require a quantum-resistant
|
|
signature. AERE's goal was to make those verifiers real and correct on a live EVM
|
|
chain, validated bit-for-bit against the official test vectors, rather than
|
|
described in a whitepaper.
|
|
|
|
There is a real scope boundary here that this AIP states plainly, because getting
|
|
it wrong would be a false claim: verifying a post-quantum signature inside a
|
|
contract is an application-layer capability. It does not make the chain's
|
|
consensus post-quantum. Validators on AERE still sign classical QBFT.
|
|
|
|
## Specification
|
|
|
|
### The verifier suite (live on chain 2800)
|
|
|
|
Each verifier is a pure-Solidity contract validated against official vectors.
|
|
Whether a verifier can record a result in a state-changing transaction, versus
|
|
only answer as a `view` via `eth_call`, is decided by the EIP-7825 per-transaction
|
|
gas cap of 16,777,216 (2^24). Schemes whose full verify fits under the cap expose
|
|
a state-changing `verifyAndRecord`; schemes whose full verify exceeds the cap in
|
|
pure Solidity are `view`-only until a native precompile exists (see below).
|
|
|
|
| Scheme | Contract | Address | On-chain mode | Evidence |
|
|
| --- | --- | --- | --- | --- |
|
|
| WOTS+ (hash-based, one-time) | AerePQCVerifier | `0x1cE2949e8cE3f1A77b178aF767a4455c08ec6F82` | records on-chain | hash-based, well under the cap; exact standalone gas to be measured (bounded above by the XMSS figure below, which contains a WOTS+ verify) |
|
|
| XMSS-SHA2_10_256 (RFC 8391, many-time) | AereXmssVerifier | `0x77b14E264D0bb08d304d4e0E527F0fCdFc88B112` | records on-chain | `verifyAndRecord` gasUsed 1,561,963 < 16,777,216 |
|
|
| SLH-DSA-SHA2-128s / SPHINCS+-SHA2-128s-simple (FIPS 205, stateless) | AereSphincsVerifier | `0xAfFc9F8d950969b46b54e77758BbFf7e000c87e6` | records on-chain | `verifyAndRecord` gasUsed 1,812,066 < 16,777,216 |
|
|
| Falcon-512 (NIST level 1 lattice) | AereFalcon512Verifier | `0x4E8e9682329e646784fB3bd01430aA4bA54D8fFC` | records on-chain | verify fits under the cap; demonstrated inside a full ERC-4337 userOp (gasUsed 10,278,313) and hybrid auth (gasUsed 10,299,873), both < 16,777,216 |
|
|
| Falcon-1024 (NIST level 5 lattice) | AereFalcon1024Verifier | `0xF0aFA59BaB2058e4B6e6B424b7f76750F1F66e36` | records on-chain (via precompile) | in this pure-Solidity contract `verifyAndRecord` is about 21.7M gas and EXCEEDS the 16,777,216 cap, so its `verify()` is a pure view; the scheme now records on-chain through the native Falcon-1024 precompile at `0x0AE2`, live on mainnet since block 9,189,161 (AIP-7) |
|
|
| ML-DSA-44 / Dilithium2 (FIPS 204 lattice) | AereMLDSA44Verifier | `0xf1F7A6Acd82D5DAf9AF3166a2F736EE52C5F85AE` | records on-chain (via precompile) | a full verify in this pure-Solidity contract is about 52.9M gas and EXCEEDS the cap, so its `verify()` is a pure view; the scheme now records on-chain through the native ML-DSA-44 precompile at `0x0AE3`, live on mainnet since block 9,189,161 (AIP-7) |
|
|
| Falcon/Dilithium-family lattice core (ring arithmetic, norm), n=64 demo | AereLatticeVerifier | `0x60c06E6A3CC201B46A16650be096C6E45424dfD9` | building block | supports the Falcon verifiers |
|
|
|
|
Validation vectors used, as repo fixtures:
|
|
|
|
- Falcon-512: `contracts/test/falcon512_kat0.json` (official NIST KAT).
|
|
- Falcon-1024: `contracts/test/falcon1024_kat0.json` (official round-3 KAT).
|
|
- XMSS: `contracts/test/fixtures/xmss-sha2_10_256-kat.json` (xmss-reference vectors).
|
|
- ML-DSA-44: `contracts/test/fixtures/mldsa44-acvp-tg8.json` (NIST ACVP
|
|
ML-DSA-sigVer, 15/15 cases reproduce NIST's expected results).
|
|
- SPHINCS+/SLH-DSA: `contracts/test/fixtures/sphincs-sha2-128s-acvp-tg31.json`
|
|
(NIST ACVP SLH-DSA-sigVer, 14/14 cases reproduce NIST's expected results).
|
|
|
|
### Account-layer primitives (live on chain 2800)
|
|
|
|
- **AerePQCAccountFactory** at `0xd5315Ea7caa60d320c4f34b1bEd70dd9cc02CE58`. A
|
|
CREATE2 factory that deploys an ERC-4337 v0.7 smart account whose sole owner is
|
|
a Falcon-512 public key (897 bytes), with no classical ECDSA fallback. Both
|
|
`validateUserOp` and EIP-1271 `isValidSignature` are decided by the live
|
|
AereFalcon512Verifier.
|
|
- **AerePQCAccount_sample** at `0xa42a5e7F72E46BadC11367650Ec34D676194326f`. A
|
|
sample account owned by a real Falcon-512 key, used to prove the EIP-1271 accept
|
|
path (`0x1626ba7e`) and a full userOp through the EntryPoint.
|
|
- **AereHybridAuth** at `0xc20390C9656ECe1AE37603c84E395bC898b3FAA1`. Authorizes
|
|
only if BOTH a secp256k1 ECDSA signature AND a Falcon-512 signature verify over
|
|
the same 32-byte hash. This is the pragmatic migration primitive: classical and
|
|
post-quantum in series, so an account is safe as long as either scheme holds.
|
|
|
|
### Standing of the suite
|
|
|
|
Across hash-based and lattice families, with each verifier validated against the
|
|
official NIST KAT/ACVP vectors and demonstrated on a live EVM chain:
|
|
we are not aware of any other public chain that verifies all of these on-chain.
|
|
|
|
We are not, however, the first public chain to verify a post-quantum signature
|
|
on-chain, and we do not claim to be. Algorand shipped the native Falcon-1024
|
|
`falcon_verify` AVM opcode in a stable release roughly ten months before AERE's
|
|
precompiles activated at block 9,189,161 (2026-07-12), and places Falcon deeper
|
|
in its stack than AERE does, inside its own state proofs. That prior art, with
|
|
sources and dates, is set out in
|
|
`aere-research/research/pqc-onchain-verification.md`, Section 8.
|
|
|
|
## Rationale
|
|
|
|
Pure-Solidity verifiers were built first because they run on the live chain today
|
|
with no client change and are auditable by anyone with an EVM. The design splits
|
|
cleanly along the EIP-7825 gas cap: the hash-based schemes and Falcon-512 fit
|
|
under the cap and can therefore record a verification result on-chain, which is
|
|
what an account or an application actually needs. Falcon-1024 and ML-DSA-44 are
|
|
too expensive to record in pure Solidity, so they are offered as `view` verifiers
|
|
(useful for off-chain-anchored checks and for correctness demonstration) until a
|
|
native precompile makes recording them feasible.
|
|
|
|
Hybrid ECDSA-plus-Falcon authorization (AereHybridAuth) was chosen as the first
|
|
account-facing product because it is the safest migration posture: it never
|
|
weakens the classical guarantee while adding the post-quantum one.
|
|
|
|
### Native precompile (live on mainnet chain 2800 since block 9,189,161)
|
|
|
|
Moving Falcon-1024 and ML-DSA-44 to record-on-chain, and making Falcon-512 and
|
|
SPHINCS+ far cheaper, requires a native precompile for SHAKE256 and for the
|
|
Falcon, ML-DSA, and SPHINCS verify routines. That work was implemented and
|
|
KAT-validated on an isolated Besu 26.4.0 scratch fork (source tag 26.4.0, commit
|
|
`d2032017`, chain 28099), which adds five native precompiles wrapping the
|
|
Bouncy Castle 1.83 BCPQC verifiers already on the client classpath (Falcon-512,
|
|
Falcon-1024, ML-DSA-44, SLH-DSA-SHA2-128s, SHAKE256), plus a native EIP-2935
|
|
8191-block lookback, with zero new dependencies and zero hand-rolled cryptography.
|
|
All NIST KAT and ACVP vectors pass in both directions, positive and negative
|
|
(15/15 ML-DSA-44 cases, 14/14 SLH-DSA cases). Measured full verify-and-record
|
|
gas on that fork: Falcon-512 86,336; Falcon-1024 145,496 (0.87% of the
|
|
16,777,216 cap); ML-DSA-44 351,050 (2.09%); SLH-DSA-SHA2-128s 558,276; SHAKE256
|
|
21,470. This moves Falcon-1024 (about 21.7M gas in pure Solidity) and ML-DSA-44
|
|
(about 52.9M gas) from view-only to record-on-chain with wide margin.
|
|
|
|
That fork is now LIVE on mainnet chain 2800, activated at block 9,189,161
|
|
(2026-07-12) as the AerePQC hard fork: a coordinated, client-only, flag-day
|
|
activation with no re-genesis and no state migration, which adds the five native
|
|
precompiles at the address band `0x0AE1`..`0x0AE5` (Falcon-512, Falcon-1024,
|
|
ML-DSA-44, SLH-DSA-SHA2-128s, SHAKE256) and the native EIP-2935 8191-block
|
|
lookback. The pure-Solidity AereFalcon1024Verifier and AereMLDSA44Verifier
|
|
contracts remain view-only, but the Falcon-1024 and ML-DSA-44 schemes now record
|
|
on-chain through the precompiles at `0x0AE2` and `0x0AE3`, demonstrated
|
|
end-to-end by a real Falcon-1024 attestation recorded through AerePQCAttestation
|
|
(`0x465d9E3b476BF98Aa1393079e240Db5D2a9bEA6A`, attestation tx `0xb659…9ec1`,
|
|
block 9,200,542, status 1). The activation is filed as its own Core AIP, AIP-7;
|
|
the mechanism is specified in `research/aip-draft-pqc-precompiles.md`. The
|
|
precompiles carry an internal self-audit only; an external audit is still pending
|
|
before they should secure material value.
|
|
|
|
## Backwards Compatibility
|
|
|
|
None. The verifiers and account primitives are additive contracts. They do not
|
|
change the EVM ruleset, existing accounts, or consensus. Ordinary secp256k1
|
|
accounts continue to work unchanged.
|
|
|
|
## Security Considerations
|
|
|
|
The single most important honesty point: **this is an application and account
|
|
layer capability, not post-quantum consensus.** AERE validators still sign
|
|
classical QBFT, so a quantum adversary that could forge validator signatures is
|
|
not addressed by these contracts. Do not read this AIP as a claim that AERE
|
|
consensus is post-quantum. It is not.
|
|
|
|
Further honest caveats:
|
|
|
|
- **Pure-Solidity view versus precompile record.** The pure-Solidity
|
|
AereFalcon1024Verifier and AereMLDSA44Verifier cannot record a result on-chain
|
|
because a recording transaction exceeds the 16,777,216 gas cap; their `verify()`
|
|
over `eth_call` is only as trustworthy as the node answering it. Since the
|
|
AerePQC hard fork (block 9,189,161, AIP-7), the Falcon-1024 and ML-DSA-44
|
|
schemes do record on-chain through the native precompiles at `0x0AE2` and
|
|
`0x0AE3`, which are consensus-anchored. Falcon-512, WOTS+, XMSS, and SPHINCS+
|
|
also record on-chain.
|
|
- **XMSS statefulness.** AereXmssVerifier verifies a signature but does not
|
|
enforce the signer's one-time-per-leaf state. Callers that rely on XMSS's
|
|
many-time security must track leaf usage off-chain. WOTS+ is one-time by
|
|
construction and must not be reused across messages.
|
|
- **Cost.** Falcon-512 verification is heavy (roughly 10.3M gas inside a full
|
|
userOp). It fits under the cap but is expensive; the native precompile is the
|
|
path to making it cheap.
|
|
- **Unaudited.** These verifiers have not had an external security audit. Their
|
|
assurance today rests on bit-for-bit agreement with the official NIST KAT/ACVP
|
|
vectors and on cross-checks against independent reference implementations, which
|
|
is strong evidence of correctness on the tested vectors but is not a substitute
|
|
for an audit.
|
|
|
|
## Reference Implementation and On-Chain Deployment
|
|
|
|
Verifier sources are under `contracts/contracts/` (glob for the PQC, Falcon,
|
|
XMSS, ML-DSA, and SPHINCS verifiers). All addresses in the tables above are copied
|
|
verbatim from `sdk-js/src/addresses.ts`. Each verifier is live and answerable via
|
|
`eth_call` on `https://rpc.aere.network` (chain ID 2800): official vectors return
|
|
true, tampered inputs return false. The recording transactions cited (XMSS,
|
|
SPHINCS+, the Falcon-512 account userOp, and the hybrid auth) are on-chain and
|
|
under the EIP-7825 cap.
|
|
|
|
## Copyright
|
|
|
|
Released to the public domain (CC0). No rights reserved.
|
|
</content>
|