aere-network/aere-docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
173c40ed61
aere-docs/AERE-PQ-FINALITY-CERTIFICATE-SUMMARY.md

5.1 KiB
Raw Blame History

Spec 4: Aere Network Post-Quantum Finality Certificate

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 (block 17,250,000) the nine AERE-client validators (nine of the ten) refuse a commit message without a valid Falcon-512 seal of its author, and since 2026-09-08 (block 17,700,000) any QBFT consensus message without one, 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, 2026-10-25 and 2026-10-28; until 2026-10-28 it dated the refusal of every message type to 2026-09-05, the date of the commit layer alone). (Note applied to this document on 2026-10-28.)

Built the flagship ADDITIVE post-quantum finality feature: one succinct proof that a quorum of Aere validators attested to a finalized block with HASH-BASED (post-quantum) keys, verifiable on-chain in ONE call, WITHOUT changing QBFT consensus and WITHOUT a re-genesis.

Deliverables (all new, no deployed contract modified)

  1. aere-contracts/contracts/pqfinality/AerePQAttestationKeyRegistry.sol

    • Per-validator hash-based attestation public key (XMSS / WOTS+ / leanSig / SLH-DSA / XMSS^MT), SEPARATE from the ECDSA consensus key. This is the PQ finality key.
    • Maps validator -> current key + monotonic keyEpoch. One-time/few-time keys rotate: registering again appends a new record, marks predecessor superseded, bumps epoch. Append-only history, fail-closed, no silent rewrite.
    • Governed membership (Ownable enrollValidator = the N=7 set + root ordering), self-custodied keys (validator registers its OWN key; owner cannot forge it).
    • Deterministic validatorSetRoot() = keccak over (validator, keyEpoch, keyHash) leaves in enrollment order. Any rotation changes the root.

  2. aere-contracts/contracts/pqfinality/AereFinalityCertificateVerifier.sol

    • Verifies ONE SP1 proof via the live gateway (0x9ca479C8...70628), pinned PROGRAM_VKEY.
    • Public values (192 bytes): blockHash, blockHeight, validatorSetRoot, validatorSetSize, quorumCount, attestationDomain.
    • Fail-closed: binds root+size to the LIVE registry, binds attestationDomain (chainId+registry), requires quorumCount >= ceil(2N/3) = 5 of 7, rejects zero block, then one verifyProof (reverts on bad proof). Cost independent of N.
    • isFinalPQ(blockHash) consumer gate + recordCertificate + assertFinalizes(claimedBlock) for bridges confirming a specific block.

  3. aere-contracts/test/AerePQFinalityCertificate.test.js - 12 passing (MockSp1Verifier). Covers all required cases: 7-validator set registers (threshold 5); valid quorum-5 cert records + isFinalPQ true; below-quorum rejects; wrong root rejects; wrong block/height/zero-block rejects; invalid proof fail-closed; key rotation changes root and old-root cert no longer matches; empty set fails closed; append-only + owner-gated enroll + self-register.

  4. aerenew/docs/AERE-PQ-FINALITY-CERTIFICATE.md - architecture (dual-sign ECDSA+hash-based, off-chain zkVM aggregates into one STARK/SP1 proof, on-chain one verify), why additive (no flip, no re-genesis), quantum-safety argument (hash-based sigs + hash-based FRI STARK are Shor- resistant vs classical ECDSA seals + BN254 Groth16), consumer use cases (light client/bridge/ L2/AI agent), live-first framing (ships ahead of Ethereum Lean Consensus ~2027 because N small), honest [MEASURE] status.

REAL test result

npx hardhat test test/AerePQFinalityCertificate.test.js from aerenew/contracts: 12 passing (2s), 0 failing. Contracts compile under solc 0.8.23 (repo config).

Honesty flags

  • [MEASURE] / NOT implemented: the off-chain XMSS/leanSig aggregation zkVM guest circuit (verify N hash-based sigs against the root inside the zkVM, emit public values). Novel research. leanSig or XMSS-in-zkVM is the target; ML-DSA-in-zkVM is a lattice alternative (loses the hash-only argument).
  • On-chain verifier + registry are REAL and tested against a MOCK SP1 gateway. NOT proven end-to-end. Do NOT claim PQ finality is live.
  • [VERIFY]/design-only: the Shor-resistant end-to-end claim holds for a NATIVE hash-based STARK proof; a Groth16 wrap would reintroduce a BN254 leg. Stated in the doc.
  • Scope boundary kept: base QBFT consensus is STILL classical ECDSA. This is additive attestation ON TOP; it never flips or gates consensus and is not live.