aere-network/aere-node
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

D-470 / AIP-22 erratum 2026-10-01: the verifier prints POST-QUANTUM CERTIFIED and says what a certificate proves (its signers sealed the block post-quantum, in some round) and what it does not (that the block was decided); SPEC and the anchor README qualified the same way

Browse Source
This commit is contained in:
Aere Network 2026-10-01 17:09:27 +03:00
parent fe41803c07
commit 1238760940
3 changed files with 25 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
SPEC.md
View File

@ -1,6 +1,6 @@
# Aere Network chain 2800: full protocol specification
Version: 1.2.0, written 2026-08-25, amended 2026-09-02 (section 2.6, D8, G11), 2026-09-05 (sections 2.6 and 3.1: the message-layer arming heights, the v2 hybrid certificate, the anchor interval schedule) and 2026-09-17 (sections 2.6 and 3.1: the four enforcement heights have passed, hybrid keys are live; the "emission only" qualification is dated history), and 2026-09-22 (sections 2.7 and 5.3: AIP-21 verifiable per-block post-quantum finality live on chain 2800; AIP-20 native post-quantum transactions armed for height 19,900,000, patches 0006 and 0007 added to the recipe). Scope: everything a third party needs to implement a client
Version: 1.2.0, written 2026-08-25, amended 2026-09-02 (section 2.6, D8, G11), 2026-09-05 (sections 2.6 and 3.1: the message-layer arming heights, the v2 hybrid certificate, the anchor interval schedule) and 2026-09-17 (sections 2.6 and 3.1: the four enforcement heights have passed, hybrid keys are live; the "emission only" qualification is dated history), and 2026-09-22 (sections 2.7 and 5.3: AIP-21 verifiable per-block post-quantum finality live on chain 2800; AIP-20 native post-quantum transactions armed for height 19,900,000, patches 0006 and 0007 added to the recipe), and 2026-10-01 (sections 2.7 and 3 and the table of formal results: dated notes after the AIP-21 and AIP-22 errata of that date; nothing removed). Scope: everything a third party needs to implement a client
that follows chain 2800 from block 0 to the live head and validates what the network validates,
without reading Aere source code. It specifies the follower (validation) protocol completely; it
describes seal production only where a follower must understand it to validate.
@ -378,6 +378,12 @@ is history now. What remains classical is named in section 3.1.
Normative for a validator-capable build; informative for a pure follower, which answers honestly
that it has nothing to report.
Note added 2026-10-01 (AIP-21 erratum of that date): the seals this record counts carry no consensus
round and are kept by block hash across rounds, so the verdict `post-quantum` shows that at least the
commit quorum of distinct validators sealed the block post-quantum, in some round, not by itself that
the block was decided. The method, its fields and its values are unchanged. Below AIP-22 stage 5 a node
imports a block only with the ECDSA commit quorum of one round.
- Every validator keeps the Falcon-512 seals it hears on QBFT COMMIT messages (section 2.6) in a
retention window of the last 256 heights, keyed by the canonical block hash (not by the QBFT
message digest, which carries the round and differs from the on-chain hash for any block
@ -458,6 +464,10 @@ Falcon key can rewrite at most the tail since the last anchor, so fork depth <=
block 20,746,736 (about 20 seconds at the measured rhythm; <= 128 blocks, about 75 seconds, from block
17,225,968 to block 20,746,736; <= 32 blocks, about 16 seconds, before that); rewriting anything below an anchor changes that anchor's parent hash, forces the
anchor to be reproduced, and reproducing it requires Falcon signatures the adversary does not have.
Added 2026-10-01 (AIP-22 erratum of that date; derived, not exercised): the certificate's seals carry no
round, so if the validators had also sealed, at the height of the last anchor's parent, a block in a
round that did not decide it, those honest seals can certify an anchor over that block, and the
rewrite can reach the anchor's parent, one block deeper than the bound above.
History below H remains protected by ECDSA alone, permanently (source:
`anchor/consensus/common/.../PqAnchorConfig.java`, interval javadoc; `anchor/README.md`).
@ -999,7 +1009,7 @@ document `strategie/VERIFICARE-FORMALA-2026-08-24.md`):
| Liveness post-GST: within f+1 rounds an honest proposer commits | SMT N=4..7 | `qbft_liveness_smt.py` |
| Network partitions: no split-brain in any split; the minority side cannot commit; progress returns on heal | SMT parametric N=9 + unbounded; TLC N=4 EXHAUSTIVE (6 configs, 0 states left in queue) | `partition_safety_smt.py`, `QBFTPartition.tla` |
| PQ anchor certificate acceptance is fail-closed (quorum, root, size, domain, rotation gates each individually load-bearing) | SMT N=9 | `pqfinality_smt.py`, `anchor_blocking_quorum_smt.py` |
| A round change on an anchor height cannot yield two different valid certificates; uniqueness comes from binding to the FINALIZED block, not from K (K=3 alone admits two, shown SAT) | SMT N=9 | `anchor_viewchange_smt.py` |
| A round change on an anchor height cannot yield two different valid certificates; uniqueness comes from binding to the FINALIZED block, not from K (K=3 alone admits two, shown SAT). Note added 2026-10-01: a property of the MODEL only; the shipped rule does not require the certified block to be the decided one, and the AIP-22 erratum of that date shows a valid certificate over a block no round decided | SMT N=9 | `anchor_viewchange_smt.py` |
| Emergency ceiling only lowers K | SMT | `pqanchor_ceiling_monotonicity_smt.py` |
| Registry rotation covers every height exactly once; index binding | SMT | `registry_rotation_coverage_smt.py`, `registry_index_binding_smt.py` |

4
anchor/README.md
View File

@ -70,7 +70,9 @@ anchor itself; and a message without a valid seal is REFUSED from blocks 17,250,
heights were set on all nine validators on 2026-09-05 and take effect as the chain reaches them;
until each height passes, that message type is still accepted without a seal. What a quantum
adversary cannot do at any height is rewrite history past the last anchor without also forging
Falcon-512 and SLH-DSA-SHA2-128s signatures. None of this has been audited by a third party.
Falcon-512 and SLH-DSA-SHA2-128s signatures (added 2026-10-01, AIP-22 erratum of that date: except at
the height of the last anchor's parent, if the validators had also sealed there a block in a round
that did not decide it; derived, not exercised). None of this has been audited by a third party.
The threat it addresses is not "harvest now, decrypt later". A signature is public; there is nothing
to harvest. The threat is **retroactive rewriting**: validator keys recovered later can be used to

14
tools/verify-anchor.mjs
View File

@ -430,9 +430,13 @@ let ok = 0, bad = 0, sealsTotal = 0, sealsValid = 0;
// nemeritat: se numara separat si iese cu alt cod.
let unmeasured = 0;
// 2026-09-26: the most recent anchor whose certificate VERIFIED here (anchors are walked newest first). Its PARENT is the
// post-quantum finality point of the chain (AIP-15/22: the certificate signs the parent's commit message); printed in the
// summary so a stranger gets the answer to "which block is final" from this tool, not from our word. Nodes do not serve the
// finalized/safe tags on this chain yet (measured 2026-09-26: eth_getBlockByNumber("finalized") answers "Unknown block").
// block the certificate's seals signed (AIP-15/22: the certificate signs the parent's commit message); printed in the summary
// so a stranger reads from this tool, not from our word, which block the newest verified certificate covers. Nodes did not serve
// the finalized/safe tags on this chain then (measured 2026-09-26: eth_getBlockByNumber("finalized") answered "Unknown block").
// 2026-10-01 (AIP-22 erratum of that date): this comment and the summary line called that parent the chain's "post-quantum
// finality point" and printed it on a FINALIZED line. The commit seal carries no round, so a certificate shows that its
// signers sealed that block post-quantum, in some round, not that the block was decided; the line now says what was verified.
// The ANCHOR_REPORT keys below are unchanged (the AIP-23 verifier reads them).
let newestOk = null;
let newestParentHash = null; // the hash of block newestOk - 1 the verified seals signed (M(parent)), for ANCHOR_REPORT
// ce scheme au fost CHIAR verificate: rezumatul final nu are voie sa numeasca o schema pe care nu a vazut-o
@ -702,7 +706,9 @@ console.log(all
// 2026-10-01: the tail of this line said, on every chain, that a header between anchors carries only its proposer's seal. That is true only
// where AIP-22 stage 5 is active (testnet 28001 from block 3,131,000); on chain 2800 headers between anchors still carry the validators'
// classical ECDSA commit seals, and this tool printed the stage-5 sentence there on every run. It now says what it measured above.
if (newestOk !== null) console.log('FINALIZED (post-quantum): block ' + (newestOk - 1) + ', the parent of anchor ' + newestOk + ', the most recent anchor whose certificate verified here. Nothing between anchors is post-quantum final; '
if (newestOk !== null) console.log('POST-QUANTUM CERTIFIED: block ' + (newestOk - 1) + ', the parent of anchor ' + newestOk + ', the most recent anchor whose certificate verified here:'
+ ' the validators whose seals it carries sealed that block post-quantum. The seals carry no consensus round, so this does not by itself prove'
+ ' that the block was decided (AIP-22 erratum, 2026-10-01). Between anchors no block carries a post-quantum certificate; '
+ (propChecked === 0
? 'a header between anchors carries the validators\' classical ECDSA commit seals (AIP-22 stage 5 is not active at these heights on this chain).'
: 'a header between anchors carries only its proposer\'s seal.'));