4a0b48588c
Aere Network public source. Everything here can be checked against the live chain (chain id 2800, https://rpc.aere.network). Scope note, stated up front rather than buried: consensus on chain 2800 is classical secp256k1 ECDSA QBFT. The post-quantum work in this repository is at the signature, precompile, account and transport layers. Nothing here makes the consensus post-quantum, and no document in it should be read as claiming so.
193 lines
12 KiB
Markdown
193 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.
|
|
|
|
## 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 audited
|
|
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>
|