aere-research/aips/AIP-21.md

# AIP-21: Verifiable Post-Quantum Finality per Block (Side Store, Proof RPC, Anchor as Permanent Record)

> **Note added 2026-09-30.** Where this document says that only every 128th block carries a certificate, it describes
> chain 2800 from block 17,225,968 to block 20,746,736 (2026-09-05 to 2026-09-29). Since block 20,746,736 (AIP-22
> stage 2) a Falcon-512 certificate is carried every 32nd block and SLH-DSA seals every 128th, with at least seven of
> ten seals per scheme since block 20,715,632 (AIP-22 stage 1).
>
> **Correction added 2026-10-01.** The commit seal this record counts carries no round, and the store keeps seals by block
> hash across rounds. A record that reaches `post-quantum` shows that at least the commit quorum of distinct validators
> sealed the block post-quantum, in some round; it does not by itself prove that the block was decided. See the Errata entry
> of that date, which follows the AIP-22 erratum of the same day. Chain 2800 today, below AIP-22 stage 5, is not affected:
> a node imports a block only with the ECDSA commit quorum of a single round.

## Preamble

| Field | Value |
| --- | --- |
| AIP | 21 |
| Title | Verifiable Post-Quantum Finality per Block (Side Store, Proof RPC, Anchor as Permanent Record) |
| Author | Aere Network Foundation |
| Type | Standards Track |
| Category | Interface (non-consensus) |
| Status | Draft (first half implemented in the Besu-derived client on 2026-09-18, not yet on any network at the Created date; both halves in both clients on testnet 28001 the same day; on chain 2800 on all ten validators since 2026-09-22, see the dated records at the end) |
| Created | 2026-09-18 |
| Requires | AIP-15 (post-quantum anchor certificates), the per-Commit post-quantum seal enforced on chain 2800 since 2026-09-05 |
| Supersedes | None |
| Superseded-By | None |
| Ratification | Not ratified; testnet-gated (chain 28001 first), second-client-gated (both clients answer the same record for the same block), no activation height needed on chain 2800 because nothing here changes block validity |

## Abstract

Every block of an Aere QBFT chain is committed with a Falcon-512 seal on each Commit message, and
every validator already holds, for recent blocks, the seals it heard. Those seals never reach the
header: only every 128th block carries a certificate, over its parent, so the immediate post-quantum
finality of a block has been true and not observable. This AIP makes it observable without growing the
header: a bounded side store of heard seals per block hash, a JSON-RPC method `aere_getPqFinality`
that returns the seals of a block re-verified now against the anchored registry over the exact message
the validators signed, with the verdict "verified distinct signers ≥ the chain's commit quorum",
and the anchor certificate as the permanent record once the window has passed.

## Motivation

A user, an exchange or a bridge that asks "is this block final under post-quantum assumptions right
now?" could until now only be answered "yes, trust us" or "wait for the next anchor". The seals that
prove it exist on every validator and are thrown away after a few hundred blocks. Keeping them a
little longer and answering a query costs kilobytes, and turns a claim into a measurement that a
third party can repeat: fetch the record, verify each Falcon-512 seal against the published registry
epoch, count distinct signers, compare with the quorum. It also makes "immediate post-quantum
finality" a gate we can run against our own nodes, on the block of ten seconds ago, instead of a
sentence on a website.

## Specification

### The record

For a block `B` at height `h` with on-chain hash `H` (round forced to zero), a node answers:

```
blockNumber          h
blockHash            H
validators           n, the size of the validator set that validated B
quorum               the chain's commit quorum for n (Besu: ceil(2n/3))
sealForm             "anchor" when the signed message is M = commitMessage(chainId, h, H) (AIP-15,
                     the form in force on every live network today), "commit-digest" below it
signedMessage        M in hex, or null when it cannot be rebuilt from the header
falconSeals          [{scheme:"falcon-512", index, verified, signature}] as heard, index-sorted
falconSealsHeard     count
falconSealsVerified  distinct validator indexes whose seal verifies NOW against the registry epoch
                     bound at height h (verifyAtHistoric)
verifiedIndexes      that set
hybridSeals          [{scheme, index, verified:null, signature}] heard extras (SLH-DSA on anchor
                     parents); listed, not verified by this method: the anchor certificate is theirs
finality             "post-quantum" | "partial" | "none" | "unavailable" | "unverifiable-form"
retentionBlocks      the node's window
note                 one sentence that says what the verdict rests on
```

`finality` is `post-quantum` iff `falconSealsVerified >= quorum > 0`; `partial` when at least one
seal verifies but fewer than the quorum; `none` when seals were heard and none verifies; `unavailable`
when no seal was heard (a reader node, or a block outside the window); `unverifiable-form` below the
anchor form. A method that cannot verify says so; it never counts an unverified seal.

### The side store

The existing per-node seal cache (keyed on the on-chain block hash, populated from Commit messages)
gains a configurable retention window, system property `aere.pq.finality.window` (blocks). The
consensus default stays the previous value (256); the value is per node and never a consensus value:
two nodes with different windows import the same chain. Memory cost is about 7 kB per block for ten
seals.

### The window on disk (second half, 2026-09-18)

The window survives a restart. Each client appends what it heard for a height to a journal when the NEXT
height begins, and reads the journal back at startup. Both clients write the SAME format, pinned by a byte
vector present literal for literal in both proof suites: one directory, segment files of 64 heights
(`w-<height / 64>.rlp`), each a sequence of frames `length(4, big endian) || payload || crc32(payload)(4, big
endian)`, the payload being the RLP list `["AERE-PQ-SEALWINDOW-1", chainId, blockNumber, blockHash,
[[index, signature], ...]]`. Frames are only appended; segments wholly below the window are deleted, so the
footprint is bounded by the window (a few megabytes at the default) whatever the age of the node. Writes are
best effort and unsynced: a disk fault costs the answer for those blocks after a restart, never the node.

Nothing read from the journal is believed. A seal is self-verifying: at startup every seal is verified again
against the registry epoch bound at its height, over the commit message rebuilt from the block hash, and what
does not verify is dropped. The Besu-derived client also drops, before looking at a signature, any frame whose
hash is not the canonical hash its own chain holds at that height; the Nethermind-derived client keeps the
hash beside each seal and applies the same canonical filter at query time. A forged journal obtains the empty
window an absent journal already gives. A torn tail (the node died mid-append) or a damaged frame costs that
frame and what follows it in the same segment, nothing else.

Switches, per node, never consensus values: Besu-derived client, system property `aere.pq.finality.persist`
(`false` turns the journal off; default on wherever the head-seal store is on), directory
`<data>/aere-pq-seal-window`; Nethermind-derived client, environment variable `AERE_PQ_FINALITY_DIR` (unset
= off). What is NOT persisted: the hybrid extras (SLH-DSA seals on anchor parents); after a restart they are
listed only for blocks heard since, and the anchor certificate remains their permanent record.

### The method

`aere_getPqFinality([blockParameter])`, `blockParameter` a number, `latest` or `pending`; default
`latest`. Registered in the QBFT API group. Returns the record above, or `null` for an unknown block.

### Who can answer

Seals travel on Commit messages between validators, so only validators hear them. A public reader
node answers `unavailable` honestly. A network that wants the record public exposes a read-only door
that accepts only this method and asks a validator: on testnet 28001 that door is
`https://testnet-rpc.aere.network/finality`, a proxy that tries the four Besu validators in turn and
refuses every other method.

### The permanent record

Once the block leaves every node's window, its post-quantum finality is recorded by the next anchor
certificate (AIP-15), which is verifiable forever with the published verifier. The two are the same
claim at two ages: the seals prove it in the second, the certificate proves it for the life of the
chain.

## Rationale

Growing the header with a post-quantum seal per validator per block was measured at 247 GB to 2.9 TB
per node per year on 2026-09-17 and rejected; anchors every 128 blocks cost about 32 GB per year. A
side store that keeps what validators already hold, for a bounded window, costs kilobytes and changes
nothing about validity, so it needs no coordination, no fork and no signature to deploy.

## Backwards Compatibility

None affected. Nodes with and without the method import the same chain.

## Security Considerations

The record is only as strong as its verification: a seal is counted only if it verifies now against
the registry epoch bound at that height, over the message rebuilt from the header this node holds. A
node lying about the record can be caught by any second node or by the anchor certificate. The record
exposes no secret: seals are already broadcast to every validator.

## Reference Implementation

Besu-derived client, `consensus-pqc/arbore-complet-2026-08-01/petice-aip21/`: the method
`AereGetPqFinality` (consensus/qbft), its test `AereGetPqFinalityTest` (7 cases, each with its negative
pair: a signer short of quorum, nothing verifying, nothing heard, a form that cannot be rebuilt, an
unknown block), the retention window in `PqSealCache`, three anchored edits (`aip21-aplica.py`). The
Nethermind port, the testnet deployment and the public door are recorded here, dated, as they land.

**Testnet 28001 deployment, 2026-09-18 02:35Z.** The five Besu nodes of the public testnet (four validators and the
reader) run the AIP-21 distribution `besu-aip21-26.4.0-aere.1-d203201-wt5fda18a0`, switched one at a time with a
130 s cooling window between restarts (`testnet-public/84-comuta-toate-f2.sh` over `83-binar-nod-f2.sh`, each node
back at the tip before the next). Public door: `https://testnet-rpc.aere.network/finality` (`finalitate-proxy.mjs`,
unit `aere-testnet-finalitate`; accepts only `aere_getPqFinality` and `eth_blockNumber`, asks the four validators in
turn and names which one answered). First public record: block 2,244,964, quorum 4, 5 of 5 seals verified,
`post-quantum`; after the full switch, block 2,246,017, quorum 4, 5 of 5, `post-quantum`. Aere Cloud relays it as
`GET /v1/pq/finality/{block}?network=testnet`.

**Nethermind port, written 2026-09-18** (`nethermind-pqc/nethermind-intree/`): `Nethermind.AerePqc/Consensus/Finality/AerePqFinality.cs`
(the query; the same record, the same five verdicts and notes as the Besu method), `patches/AereRpcModule.cs`
(JSON-RPC module `Aere`, `aere_getPqFinality`, enabled per endpoint like every module), `patches/aip21-finalitate-nm.py`
(anchored, idempotent: retention window `AERE_PQ_FINALITY_WINDOW`, default 256, in place of the previous fixed 8
heights; each heard seal remembers the digest of the proposal it was heard for, because this engine keys its store
on the height, so a seal of a losing proposal at the same height is never listed for the block that won; snapshots
under the engine lock for the RPC thread), `patches/AereAip21PqFinalityProofTests.cs` (10 cases, each with its
negative pair; 10 of 10 green, negative control: with verification planted to 'always true' 5 of 10 go red).

**Nethermind testnet deployment, 2026-09-18 03:18Z.** The Nethermind validator of testnet 28001 runs
build `client2-aip21-2026-09-18` (built on its host from the same overlay, 185 assemblies, nothing lost against the
previous live binary), switched by `testnet-public/88-aip21-nm-binar-nou.sh` with the `Aere` module enabled in its
JSON-RPC configuration. Functional proof on the node: `latest` (block 2,250,690) `post-quantum`, 5 of 5 seals verified,
quorum 4, `retentionBlocks` 256; `latest-64` (2,250,626) `post-quantum`; an unknown block returns `null`, a block from
before the restart returns `unavailable`, an unknown method of the module returns -32601. Public door:
`https://client2.aere.network/testnet/finality` (`89-finalitate-usa-client2.sh`, unit `aere-testnet-finalitate-nm`,
`answeredBy: nethermind@8651`; nginx location in `deploy/client2/nginx-client2-rpc.conf`).

**Two-client conformance, 2026-09-18 03:21Z** (`aips/aip21-conformitate/DOVEDESTE.sh`, repeatable, writes `ULTIMA.txt`):
block 2,250,809 asked to both doors: hash `0xab55016e3b3b5397abd6bfd8e86299f7105e95af8c9675979d4240ffe9293451` on both,
`post-quantum` on both, quorum 4, verified indexes [0,1,2,3,4] on both; negative controls: the hash of block N-1 from
Nethermind differs from the hash of N from Besu (the comparison can fail), a block outside the Nethermind window is
`unavailable` there (no invented agreement), both doors refuse every other method. Aere Cloud:
`GET /v1/pq/finality/{block}?network=testnet&client=besu|nethermind|both`; with `both` the response carries the two
records, `agreement` and `postQuantumConfirmedByBoth`. Record: `aips/aip21-conformitate/TESTNET-28001-2026-09-18.md`.

**Correction, 2026-09-18 08:17Z (Nethermind-derived client, found on testnet, fixed the same morning).** The first form of
the port remembered each heard seal under the QBFT *message* digest. That digest keeps the round; the on-chain hash zeroes
it. They coincide in round 0 and differ for any block finalised in a round above zero, which every validator restart
produces; the Falcon commit seal signs the on-chain hash. So for those blocks the client answered `unavailable` while
holding five valid seals, and the window restore dropped them. Measured on block 2,282,930 (round 1): Besu-derived
`post-quantum`, Nethermind-derived `unavailable`; `DOVEDESTE.sh` reported NECONFORM. Fixed by remembering seals under the
on-chain hash (`CurrentOnchainHash()`), pinned by a proof (round 0 equal, round 1 different, the query under each key), and
the conformance proof now looks for the newest round-above-zero block and demands agreement on it. Implementers: the key
under which anything about a BLOCK is kept is the on-chain hash, never the message digest.

**Second half on testnet 28001, 2026-09-18 08:24Z to 08:49Z (both clients).** Besu-derived client: distribution
`besu-aip21b-26.4.0-aere.1-d203201-wt3f12ef0d` (33 proofs on the distribution tree, 9 of them the window persistence suite,
with a negative control that blinds the historic verification and turns the restore proof red) rolled onto the five nodes
one at a time with the host-clock cooling; a second restart of node 0 then restored `1284 verified seal(s) over 257
block(s)` from 257 frames, `0 not canonical`, `0 FAILED`, and block 2,284,257, heard before that restart, answered
`post-quantum` after it. Nethermind-derived client: build `client2-aip21c` (17 proofs, 6 of them the journal suite with the
shared byte vector; negative control on both the query and the journal verification), `AERE_PQ_FINALITY_DIR` set in the
unit's environment; after its second restart `1255 verified seal(s) over 251 block(s)` restored from 265 frames and block
2,285,317 (heard before it) stayed `post-quantum`, `0 FAILED`, while a block outside the window stayed `unavailable`.

**The round-above-zero case, measured live (08:48Z).** Block 2,285,333 was finalised in round 1. Both doors answer
`post-quantum` on the same hash (`0xcfecf9d0...8d2c3b`): the Besu-derived validator with signers `[0,1,2,3]`, the
Nethermind-derived validator with `[0,1,2,3,4]`, its own seal included (a validator finalises on quorum, so it may not
have heard the last Commit; the two counts legitimately differ, the verdict and the hash do not). The full
Nethermind-side record, signatures included, is kept in `aips/aip21-conformitate/runda1-bloc-2285333-nethermind.json`.
The same question on the first form of the port gave `unavailable` (the 08:17Z correction below). `DOVEDESTE.sh`:
CONFORM at 08:49:38Z, round-1 block included.

**Rebuild, 2026-09-18 11:54Z.** The Nethermind-derived testnet validator now runs build `client2-aip21d`: the same AIP-21
code, rebuilt after the host build script was found to copy only one of the five files of the consensus subprotocol from
the repository (the difference was one diagnostic line's log level; nothing functional). Switched with the same script and
proofs: window restored after the second restart (`1255 verified seal(s) over 251 block(s)`, 0 failed), round-1 block
2,305,309 `post-quantum` in both clients on the same hash, `DOVEDESTE.sh` CONFORM at 11:57Z.

**A probe that manufactures its own rare case measures its action, not the code (08:42Z).** The switch script first
looked for the round-above-zero block that ITS OWN restart of the validator produces, demanded `post-quantum` there, and
rolled a good binary back: the round had changed precisely because that validator was down, so it could not have heard
the seals of that block, and `unavailable` was the correct answer. A round-above-zero block says something about a client
only if the client answers for it, or if the OTHER client's record lists its seal index among the verified signers (then
it took part and must hold the record). Three cases, in the switch script and in `DOVEDESTE.sh`: answers `post-quantum`
on the same hash = measured; does not, but its index is in the other record = failure; does not, and its index is absent
= it was down, nothing measured.

**Interoperability note (measured 2026-09-18 03:16Z).** Send `blockParameter` as a hex string (`"0x2256b9"`), `latest`
or `pending`. The Besu-derived client also accepts a bare JSON number; the Nethermind-derived client rejects it with
`-32602 Invalid params` (`unknown block parameter type`). The public doors pass parameters through unchanged.

**Chain 2800 deployment, 2026-09-22 20:42Z to 21:45Z (both clients).** Under the founder's general mandate of
2026-09-22 (given in chat; the AIP-19 signed acceptance is still to be produced, so the ratification row above stays as
it is), the distribution `26.4.0-aere.1-d203201-wt3f12ef0d` was proven to be the live mainnet binary (`wtde7ea1c5`,
series d358) plus exactly AIP-20 and AIP-21: class by class in both directions (49,481 classes live, 49,492 new, 0 lost,
11 new, 46 with a different CRC of which 20 differ in code, all inside the patch footprint, and 21 identical in code,
line tables only). It was rolled onto the nine Besu-derived validators one at a time with the host-clock cooling (five
minutes and an anchor between restarts; every node returned `LATE-ANCHOR ACTIVATED`, kept pace, kept every property and
gained exactly `-Daere.pqtx.forkBlock=19900000`), then onto the two public readers and the (stopped) archive unit, and
the Nethermind-derived validator (the tenth) moved to a build made on its own host (`client2-aip2021-2026-09-22`,
nothing lost against the live binary, drop-in `zz-binar`, `AERE_PQ_FINALITY_DIR`, `AERE_PQTX_FORK_BLOCK=19900000`).
Measured at 21:45Z with `deploy/validators/aip2021-2026-09-22/dovedeste-aip2021-2800.sh`: every validator answers
`aere_getPqFinality` with `post-quantum`, 10 of 10 Falcon seals verified, quorum 7, `retentionBlocks` 256; the two
readers answer `unavailable` (they hear no seals, which is the honest answer); the Nethermind-derived validator agrees
with a Besu-derived one on the same block (same hash, same quorum, both `post-quantum`); all ten validators keep proposing
in rotation (20 of the last 200 blocks each). There is no public finality door on chain 2800 yet: the validators' RPCs are
local, so the record is read on the validator, or through Aere Cloud when that route is added.

## Errata

- 2026-10-01, Abstract, Motivation, "The record" (the verdict `post-quantum`) and "The permanent record": the record counts
  Falcon-512 seals over `M(B) = keccak256(RLP["AERE-PQ-COMMIT-1", chainId, number(B), hash(B)])`, kept by the block's on-chain
  hash; neither the seal nor the key carries the round. In QBFT an honest validator can commit a block in one round while a
  different block is decided in a later round, and seals over `M(B)` made in different rounds cannot be told apart (AIP-22,
  Errata, 2026-10-01). Measured on 2026-10-01 in the reference client: seven valid Falcon-512 seals over `M(p)` from rounds 0
  and 2 on a block `p` that no round decided (test class `AereRoundFreeCertificateTest`), and a quorum of one round assembled
  from the post-quantum seals of rounds 0 and 2 in the decision collector, which counts the same seals, under the adversary of
  AIP-22 who forges ECDSA (`AereRoundFreeCommitTest`, case RF2-Q1). For `aere_getPqFinality` itself this is derived from the
  code (the same seal store, kept by hash), not run against the method. Withdrawn as written, until the commit seal binds the
  round: (1) "the immediate post-quantum finality of a block has been true" (Abstract) and the reading of the record as the
  answer to "is this block final under post-quantum assumptions" (Motivation); (2) the verdict `post-quantum` as finality: the
  field and its values stay (clients read them) and mean that at least the commit quorum of distinct validators' seals over
  `M(B)` verify now, which is evidence of participation, not of the decision; (3) "The permanent record": the anchor
  certificate is the permanent record of the same participation, and the AIP-22 erratum says what it proves. Not affected:
  chain 2800 below AIP-22 stage 5, where a node imports a block only with the ECDSA commit quorum of one round, so the block of
  a record is final there against an adversary who cannot forge ECDSA; the record as evidence of which validators sealed the
  block; and the agreement of the two clients on the same record. The remedy is the one the AIP-22 erratum proposes: a commit
  seal that binds the round, with a quorum of one round; it is a coordinated fork and is not scheduled.

## Post-Acceptance Outcome Record

Not accepted; nothing to record.

## Copyright

Copyright and related rights waived via CC0.