aere-docs/AERE-PQ-FINALITY-CERTIFICATE.md

# Aere Network Post-Quantum Finality Certificate

Status: on-chain certificate verifier and attestation-key registry BUILT and TESTED against a
mock SP1 gateway. The off-chain XMSS / leanSig aggregation zkVM circuit is NOT implemented,
[MEASURE], and is novel research-frontier work.

Scope: ADDITIVE post-quantum finality attestation. This changes nothing about Aere Network
consensus, which stays classical ECDSA QBFT. Validators keep signing ECDSA committed seals for
consensus and ALSO sign a hash-based attestation over each finalized block. The certificate
proves the second, additive quorum. It does not replace, gate, or flip consensus, it needs no
re-genesis, and PQ finality is not live. Aere consensus is not post-quantum, and nothing here
claims it is.

Contracts:
- `contracts/contracts/pqfinality/AerePQAttestationKeyRegistry.sol`
- `contracts/contracts/pqfinality/AereFinalityCertificateVerifier.sol`
- Test: `contracts/test/AerePQFinalityCertificate.test.js` (12 passing)

---

## 1. What a Post-Quantum Finality Certificate is

A Post-Quantum Finality Certificate is ONE succinct proof that a quorum of Aere Network
validators attested to a finalized block using their HASH-BASED (post-quantum) attestation keys.
Anyone, a light client, a bridge, an L2, or an AI agent, can verify with a SINGLE on-chain
`verifyProof` call, at a cost independent of the validator count N, that an Aere block reached
post-quantum finality, WITHOUT trusting the classical ECDSA seals and WITHOUT any change to the
base QBFT consensus.

The certificate is what a relying party checks when it wants a finality signal that survives a
quantum adversary. The classical path (the ECDSA committed-seal quorum, proven by
`AereZkQbftLightClient`) is trust-minimized but NOT quantum-safe: the seals are secp256k1 ECDSA,
and the Groth16 wrap is over BN254, both Shor-breakable. The certificate is the additive,
quantum-durable finality signal layered on top of the same live blocks.

---

## 2. Architecture: validators dual-sign, a zkVM aggregates, one on-chain verify

### 2.1 Validators dual-sign every finalized block

Each Aere validator holds two independent keys:

- an ECDSA (secp256k1) CONSENSUS key, used exactly as today to sign the QBFT committed seal that
  finalizes a block. This is unchanged. Consensus is untouched.
- a HASH-BASED ATTESTATION key (Winternitz-XMSS / leanSig style), registered in
  `AerePQAttestationKeyRegistry`, used ONLY to sign an additive post-quantum attestation over each
  finalized block.

The attestation message is domain-bound so it cannot be replayed to another chain or purpose:
`msg = keccak256(abi.encode(attestationDomain, blockHash, blockHeight))`, where
`attestationDomain = keccak256(DOMAIN_PREFIX, chainId, registry)`. Because the ECDSA seal and the
hash-based attestation are separate signatures over separate keys, a quantum adversary that can
forge ECDSA still cannot forge the hash-based leg.

Hash-based signatures (XMSS, WOTS+, leanSig, SLH-DSA) are ONE-TIME or FEW-TIME: a given key can
sign only a bounded number of messages before its security degrades. The registry therefore treats
attestation keys as ROTATING: each validator advances a monotonic `keyEpoch` as it registers a
successor key, and the append-only history retains every key ever used.

### 2.2 The off-chain zkVM aggregates the quorum into one proof ([MEASURE])

An off-chain aggregator collects the validators' hash-based attestations for a finalized block and
runs an aggregation guest program inside a zkVM (the SP1 zkVM in the reference design) with:

- PRIVATE witness: the enrolled validators' attestation public keys, and the hash-based signatures
  over the domain-bound block message.
- The circuit MUST, inside the zkVM:
  1. recompute the `validatorSetRoot` from the witnessed keys and their epochs (and abort if it
     does not match the committed root),
  2. verify each counted attestation as a valid hash-based signature against a DISTINCT committed
     key over `msg`,
  3. never double-count a validator,
  4. count the DISTINCT valid attestations and require the count to reach `ceil(2N/3)`,
  5. output the public values below.
- PUBLIC output (the fixed 192-byte layout the on-chain verifier decodes):
  `abi.encode(bytes32 blockHash, uint256 blockHeight, bytes32 validatorSetRoot,
              uint256 validatorSetSize, uint256 quorumCount, bytes32 attestationDomain)`.

The proof is succinct: its size and its on-chain verification cost are fixed by the SP1 verifier,
independent of N and of how many attestations the circuit checked internally.

THIS CIRCUIT IS NOT IMPLEMENTED IN THIS REPOSITORY. It is real, novel cryptographic engineering
and is the [MEASURE] research component. See Section 6.

### 2.3 The on-chain half verifies one proof (BUILT and TESTED)

`AerePQAttestationKeyRegistry`:
- The owner (Aere Foundation, later the Timelock) enrolls the validator addresses that count toward
  the quorum, mirroring how QBFT consensus enrollment is curated off-chain via the Foundation
  Ledger and QBFT extraData. Enrollment fixes each validator's position in the root ordering.
- Each validator registers its OWN hash-based attestation key (the owner cannot forge a validator's
  PQ key). Rotation is the same call again: it appends a new record, marks the predecessor
  superseded, and advances the key-epoch. Append-only, fail-closed, no silent rewrite.
- `validatorSetRoot()` is a deterministic commitment to the current set and their current keys:
  `leaf_i = keccak256(abi.encode(validator_i, keyEpoch_i, keyHash_i))`, and
  `root = keccak256(abi.encode(leaf_0, ..., leaf_{N-1}))` in enrollment order. Any rotation bumps an
  epoch and changes a key hash, so the root changes, and a certificate proven against the old root
  stops matching automatically. A Merkle tree is a drop-in alternative if inclusion proofs are
  wanted; a flat commitment suffices because the circuit witnesses the whole set.

`AereFinalityCertificateVerifier`:
- `verifyCertificate(publicValues, proof)` binds the proof's public values to the LIVE registry
  (current root and size), enforces the quorum threshold, and makes a SINGLE `verifyProof` call to
  the deployed SP1 gateway. It is fail-closed: it rejects unless ALL hold:
  - the registry validator set is non-empty,
  - `publicValues.validatorSetRoot == registry.validatorSetRoot()` (a rotation invalidates old
    certificates),
  - `publicValues.validatorSetSize == registry.validatorCount()`,
  - `publicValues.attestationDomain == attestationDomain` (blocks cross-chain / cross-purpose
    replay),
  - `publicValues.quorumCount >= ceil(2N/3)`,
  - `publicValues.blockHash != 0`,
  - the SP1 proof verifies against the pinned circuit vkey (`verifyProof` REVERTS on an invalid
    proof).
- `assertFinalizes(claimedBlockHash, claimedHeight, publicValues, proof)` additionally requires the
  proof to finalize EXACTLY the claimed block, so a certificate for a different block cannot be
  substituted. This is the call a bridge uses when releasing funds for a specific block.
- `recordCertificate(publicValues, proof)` verifies (strict) and records the certificate keyed by
  block hash. `isFinalPQ(blockHash)` then returns true, which is the gate a consumer contract
  checks. Recording is permissionless: any prover can submit a valid certificate.

The circuit is pinned. `PROGRAM_VKEY` is fixed at construction, so no caller can substitute a
different circuit. The deployed SP1 verifier gateway on Aere Network mainnet (chain 2800) is the
canonical Succinct gateway at `0x9ca479C8c52C0EbB4599319a36a5a017BCC70628`, the same gateway the
parallel-execution validity contracts and the zk light clients already call.

---

## 3. Why it is additive: no consensus flip, no re-genesis

The certificate reads the chain; it does not change how the chain is produced.

- No consensus change. Block production and finalization remain Besu QBFT over classical ECDSA
  committed seals. The certificate is computed from an ADDITIONAL signature validators produce off
  the hot path. If the aggregator is down, or no certificate is ever produced, consensus is
  unaffected: blocks still finalize on ECDSA exactly as today. The certificate is "permissionless
  but not automatic", the same property the zk light clients already have.
- No re-genesis. The attestation keys live in an ordinary contract, and the certificate is verified
  by an ordinary contract. Adding this feature is a contract deployment plus validators registering
  keys. It touches no genesis state and no client fork rule. This is a strictly weaker requirement
  than the blocking hybrid consensus path (which the in-place activation work showed can itself now
  be armed WITHOUT a re-genesis via a contract-anchored fork activation; the certificate needs even
  less, because it never gates a block).
- Separation of concerns. The blocking hybrid ECDSA-plus-Falcon consensus path (formally proven
  no-worse-than-ECDSA in `aerenew/formal-consensus/falcon_hybrid_dualquorum_smt.py`, with in-place
  activation proven in the PQ-INPLACE-ACTIVATION work) makes CONSENSUS itself refuse a block
  without a post-quantum quorum. The certificate is the READ side: it lets external parties verify
  a post-quantum finality quorum without waiting for, or depending on, the consensus flip. The two
  compose: a chain running the blocking hybrid can ALSO emit certificates, and a chain not yet
  running it can emit certificates today as an attestation-only signal.

---

## 4. The quantum-safety argument

The certificate is Shor-resistant end to end, which is precisely what the classical finality path
is not.

- The attestation legs are HASH-BASED signatures. XMSS, WOTS+, leanSig, and SLH-DSA derive their
  security from the collision and preimage resistance of a hash function ALONE. There is no lattice
  and no discrete-log assumption. Grover's algorithm gives at most a square-root speedup against a
  hash, which is answered by doubling the output size; there is no known quantum attack that breaks
  a well-parameterized hash-based signature. This is the most conservative post-quantum assumption
  available, weaker than the lattice assumptions behind Falcon or ML-DSA.
- The aggregation proof is a HASH-BASED STARK. Its soundness rests on hashing, not on pairings, so the
  proof itself is Shor-resistant. (Scope note, 2026-07-19 finding: the underlying zkVM proof systems
  are hash-based, but the pinned SP1 6.1.0 is a Hypercube / BaseFold multilinear system, not a
  FRI-based STARK; the hash-based hence Shor-resistant reasoning is unchanged, only the "FRI" label is
  corrected. The on-chain BabyBear + FRI verifier skeleton at 0x0AE8 verifies Aere's OWN Plonky3
  aggregation STARK, not an SP1 6.1.0 proof.) This is the
  crucial difference from a Groth16 SNARK over BN254: BN254 pairings are Shor-breakable
  (Assumption A-9 in the engineering security spec is explicit that the BN254 verifiers stand only
  until a hash-based STARK verifier replaces them). A certificate whose proof is a native STARK does
  not carry a classical cryptographic leg.

Contrast with the classical path. `AereZkQbftLightClient` proves the ECDSA committed-seal quorum;
the seals are secp256k1 (Shor-breakable) and the on-chain proof is Groth16 over BN254 (Shor-
breakable). Under a cryptographically-relevant quantum adversary, that path offers no guarantee.
The certificate is designed so that neither the attestation nor the proof has that weakness.

HONESTY on this claim. The quantum-safety property is a property of the DESIGN and of the
[MEASURE] circuit ONCE IT IS REAL. The on-chain contract alone does not establish it: today the
contract is verified against a mock gateway, and if the certificate were wrapped to Groth16 (an
SP1 option) instead of proven as a native STARK, it would reintroduce a BN254 leg and lose the
end-to-end property. The Shor-resistant claim holds only for a native hash-based STARK proof over a
correctly implemented hash-based aggregation circuit. The direct hash-based STARK verifier on Aere
(the `AerePQStarkVerifier` line of work) is the on-chain counterpart that keeps even the proof
verification quantum-safe.

---

## 5. Consumer use cases

The certificate is a finality oracle a relying party gates on. In every case the consumer calls
`isFinalPQ(blockHash)` (or `assertFinalizes` for a specific block) and acts only on a recorded,
proof-backed post-quantum quorum.

- LIGHT CLIENT. A trust-minimized client of Aere finality that wants a quantum-durable signal
  advances its view only on certificates, so its finality assumption reduces to "a quorum of Aere
  validators held their hash-based keys", with no dependence on ECDSA or BN254 staying unbroken.
- BRIDGE. A bridge out of Aere releases funds for block X only after `assertFinalizes(X, ...)`
  succeeds, so a future quantum adversary that forges the ECDSA seals still cannot forge a finality
  certificate and cannot trick the bridge into releasing against a non-final block.
- L2 / ROLLUP. An L2 that settles to Aere, or reads Aere as a data or finality layer, gates its
  own state transitions on the post-quantum certificate, inheriting Aere finality without inheriting
  its classical cryptographic assumptions.
- AI AGENT. An autonomous agent that acts on Aere state (an x402 / AERE402 settlement agent, a
  treasury bot) checks `isFinalPQ` before treating a payment or state change as settled, so its
  actions rest on a quantum-safe finality signal rather than on a classical seal it cannot itself
  audit.

The on-chain verification cost is independent of the validator count N: the verifier does no
per-validator work, it compares six words of public values against the registry and makes one
`verifyProof` call. A larger validator set does not raise the consumer's gas.

---

## 6. Honest status and the research frontier

BUILT and TESTED (this repository):
- `AerePQAttestationKeyRegistry.sol`: governed validator enrollment, self-custodied per-validator
  hash-based attestation keys, append-only key history with monotonic key-epochs and rotation, a
  deterministic `validatorSetRoot`, and fail-closed views.
- `AereFinalityCertificateVerifier.sol`: the public-input binding scheme, the `ceil(2N/3)` quorum
  threshold, fail-closed strict / non-reverting / claimed-block verification, permissionless
  certificate recording, and the `isFinalPQ` consumer gate. The pinned circuit vkey and the
  domain binding are fixed at construction.
- 12 passing Hardhat tests against `MockSp1Verifier`, the same deployed-gateway test double used by
  `AerePQAggregate` and the zk light clients. Its `verifyProof` REVERTS on an invalid proof, so the
  fail-closed path is exercised exactly as against the production gateway. Tests cover: a 7-validator
  set with hash-based keys registers and the quorum threshold is 5; a valid certificate with quorum
  5 records and `isFinalPQ` returns true; a below-quorum certificate rejects; a wrong validator-set
  root, wrong size, and wrong domain reject; a wrong block (and wrong height, and zero block hash)
  rejects; an invalid proof rejects fail-closed; key rotation changes the set root and an
  old-root certificate no longer matches while a fresh one records; and an empty validator set fails
  closed.

NOT implemented, [MEASURE], research frontier:
- The OFF-CHAIN XMSS / leanSig aggregation zkVM guest circuit. Verifying N hash-based signatures
  against the validator-set root inside a zkVM and emitting the public values is real, NOVEL
  cryptographic engineering that is NOT in this repository. The on-chain verifier is proven against
  a mock gateway that asserts the bound public values; a real end-to-end system additionally needs
  the real circuit and a real SP1 proof.
- Which hash-based scheme is the tractable first target is itself a research question. Stateful XMSS
  verification is hash-heavy but has no floating point, which is friendlier to a zkVM than Falcon's
  FFT and Gaussian sampling. leanSig (the hash-based signature line behind Ethereum's Lean Consensus
  direction) is designed for exactly this aggregation setting and is the natural target. An
  ML-DSA-in-zkVM approach (integer arithmetic, FIPS 204) is a lattice alternative that trades the
  most-conservative hash-only assumption for an easier circuit; it is a valid target but is not
  hash-based, so it does not carry the hash-only quantum-safety argument of Section 4.
- The real end-to-end proving cost and latency, and the real-gateway on-chain verify gas, are
  [MEASURE] and depend on the circuit implementation and the proof system (native STARK vs Groth16
  wrap).

LIVE-FIRST framing. Aere Network can ship this ahead of Ethereum's Lean Consensus (targeted around
2027) precisely BECAUSE N is small. With a 7-validator set the aggregation circuit verifies at most
7 hash-based signatures per certificate, a tractable proving workload, whereas Ethereum's hundreds
of thousands of validators make the same aggregation a far larger circuit and a longer research
runway. The small validator set that makes Aere's honest-quorum premise an operator assumption is
the SAME property that makes post-quantum finality aggregation buildable now. This is stated as a
capability of the design, not a claim that the [MEASURE] circuit is finished.

Do NOT claim the certificate works end-to-end, and do NOT imply Aere consensus is post-quantum.
The claim this repository supports: the on-chain certificate verifier and the attestation-key
registry are built, fail-closed, and tested against a mock gateway; the design is additive and
needs no consensus flip and no re-genesis; and the quantum-safety argument holds for the design and
for the [MEASURE] circuit once it is real.

---

## 7. References

- On-chain SP1 gateway pattern: `contracts/contracts/mpc/AerePQAggregateVerifier.sol`,
  `contracts/contracts/interop/AereZkQbftLightClient.sol` (the CLASSICAL ECDSA finality light
  client this certificate is the post-quantum counterpart to).
- Registry pattern: `contracts/contracts/pqc/AerePQCKeyRegistry.sol`,
  `contracts/contracts/validators/AereValidatorManifest.sol`.
- Consensus-side backing: `aerenew/formal-consensus/falcon_hybrid_dualquorum_smt.py`
  (hybrid dual-quorum proven no-worse-than-ECDSA), the PQ-CONSENSUS-STEP2 and
  PQ-INPLACE-ACTIVATION work (blocking hybrid consensus with in-place, no-re-genesis activation).
- Quantum scope boundary: `aerenew/docs/AERE-ENGINEERING-SECURITY-SPEC.md` (signatures and
  accounts can be post-quantum; consensus and the BN254 zk verifiers are classical; the chain as a
  whole is not post-quantum).
- Direct hash-based STARK verifier line: `contracts/contracts/zkverify/AerePQStarkVerifier.sol`.