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

AIP-22 stage R and stage 4 in force on chain 2800: SPEC amended 2026-10-26 (stage R since 24,148,752, stage 4 since 24,300,000; below H_hdr a header is still admitted on the ECDSA commit seals of one round), README and anchor/README dated

Browse Source
This commit is contained in:
Aere Network 2026-10-26 06:27:51 +02:00
parent 6c13bb314d
commit 7ba8334ecf
3 changed files with 16 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
README.md
View File

@ -24,9 +24,7 @@ seals at first (f+1 of nine), six of nine, as many as the 2f+1 quorum, from bloc
validators on 2026-09-05) the anchor fell on every 128th block instead of every 32nd, with both
schemes at every anchor; since block 20,746,736 (AIP-22 stage 2) Falcon-512 is required at every
32nd block again and SLH-DSA-SHA2-128s at every 128th. Since block 20,836,228 (AIP-22 stage 3) the
header and `qbft_getValidatorsByBlockNumber` name the validators by post-quantum ids. Classical
secp256k1 ECDSA QBFT still finalizes every block, and node identity and transport (RLPx) remain
classical; the QBFT
header and `qbft_getValidatorsByBlockNumber` name the validators by post-quantum ids. QBFT finalizes every block, whose votes every validator attributes, since block 24,300,000 (AIP-22 stage 4), only through their verified post-quantum seals (headers are still admitted on their ECDSA commit seals until AIP-22 stage 5), and node identity and transport (RLPx) remain classical; the QBFT
messages themselves carry post-quantum seals of their authors on the live fleet (emission since
blocks 16,620,000 to 16,690,000), with refusal of unsealed messages armed for blocks 17,250,000 to
17,700,000 (set 2026-09-05; see `anchor/README.md`, the arming table). Correction 2026-08-19: the

9
SPEC.md
View File

@ -32,6 +32,15 @@ Amended 2026-10-22 (the heights of AIP-22 stage R and stage 4 on chain 2800: `H_
The notes of 2026-10-14 that say `H_r` is not set on chain 2800 "at this date" describe that date;
nothing removed).
Amended 2026-10-26 (AIP-22 stage R is in force on chain 2800 since block 24,148,752
(`aere.pq.commitRoundBlock`, `H_r`), reached on 2026-10-24, and stage 4 since block 24,300,000
(`aere.pq.finalityBlock`, `H_fin`), reached on 2026-10-25. From `H_r` the anchor certificate is v3 and names
the round its seals were given in; from `H_fin` both clients attribute every consensus message only through
its verified post-quantum seal, and the second client's proposal, prepare and round-change layers are in
force; below `H_hdr` a header is still admitted on the ECDSA commit seals of one round (AIP-22, correction of
2026-10-26 to rule 2 of section 4). The notes of 2026-10-14 that call `H_r` not set or inert, and of
2026-09-17 and 2026-10-09 that say `H_fin` is not set on chain 2800, describe their date; nothing removed).
## 0. Conventions, and how every statement here is grounded
Every normative statement in this document carries one of three markers:

17
anchor/README.md
View File

@ -10,8 +10,7 @@ demonstrable from these files is marked as not demonstrable from these files.
## Scope boundary, stated first and not in a footnote
**Consensus on Aere Network chain 2800 is classical secp256k1 ECDSA QBFT with a post-quantum
checkpoint enforced every 32 blocks (every 128 from block 17,225,968 to block 20,746,736).** This code is what adds the checkpoint, in two steps that
**Consensus on Aere Network chain 2800 is QBFT with a post-quantum checkpoint enforced every 32 blocks (every 128 from block 17,225,968 to block 20,746,736); since block 24,300,000 (AIP-22 stage 4) every validator attributes each consensus vote only through the verified post-quantum seal of its author (headers are still admitted on their ECDSA commit seals until AIP-22 stage 5).** This code is what adds the checkpoint, in two steps that
should not be confused:
1. **The binding.** From block 13,014,000 the block hash of every anchored header (every 32nd
@ -27,8 +26,7 @@ should not be confused:
The schedule is `aere.pq.anchorMinSeals=13014000:0,13034000:3,14961456:6,17102384:0,17102416:6,20715632:7`,
uniform on all ten validators; the
startup guard refuses any threshold above N - f = 7, the highest count reachable with the fault
budget down. Blocks between anchors carry no Falcon seals and are finalized by ECDSA alone, so
the post-quantum guarantee is a checkpoint about every 20 seconds (32 blocks since block 20,746,736;
budget down. Blocks between anchors carry no certificate of their own (headers are still admitted on their ECDSA commit seals until AIP-22 stage 5), and since block 24,300,000 (AIP-22 stage 4) every validator attributes their votes only through verified post-quantum seals, so the post-quantum certificate is a checkpoint about every 20 seconds (32 blocks since block 20,746,736;
128 blocks, about 75 seconds, from block 17,225,968 to block 20,746,736; 32 blocks, about 16 seconds,
before that), not a per-block quorum.
3. **The hybrid certificate.** Since block 17,047,600 (2026-09-04) the certificate is the v2, scheme-tagged
@ -60,8 +58,7 @@ per-block quorum rule would have rejected. The earlier statement in this reposit
14,050,000 every block required a 2f+1 Falcon quorum to finalize is withdrawn.
"Hybrid" is the honest word in two senses and no more: the checkpoint sense above and, since
2026-09-04, the two-scheme certificate. "Post-quantum consensus" without qualification still
overstates: per-block finality and validator identity are classical elliptic-curve cryptography. The
2026-09-04, the two-scheme certificate. "Post-quantum consensus" without qualification still overstates: since block 24,300,000 (AIP-22 stage 4) every validator attributes a consensus vote only through its verified post-quantum seal (headers are still admitted on their ECDSA commit seals until AIP-22 stage 5), and the transport between nodes is still authenticated by secp256k1 (this sentence corrected on 2026-10-26: until that date it also called per-block finality and validator identity classical, and validator identity has been post-quantum since block 20,836,228, AIP-22 stage 3). The
four QBFT message types carry a post-quantum seal of their author on chain 2800 since blocks
16,620,000 (PROPOSAL), 16,660,000 (ROUND-CHANGE) and 16,690,000 (PREPARE), COMMIT seals since the
anchor itself; and a message without a valid seal is REFUSED by the Besu-derived validators from
@ -78,7 +75,7 @@ Falcon-512 and SLH-DSA-SHA2-128s signatures (added 2026-10-01, AIP-22 erratum of
last anchor's parent while headers carry ECDSA seals, before stage 5 of AIP-22, since an anchor can be
certified, with honest validators' seals, over the undecided sibling of the decided block; measured
in a test fixture with the production rules, not exercised on any network; SPEC.md, interval
section). None of this has been audited by a third party.
section) (Note added 2026-10-26: from block 24,148,752, AIP-22 stage R, a certificate whose quorum is of one round closes the exception for a validator; a follower that accepts a certificate below that quorum, such as the published follower with its ceiling at 1, keeps it; SPEC.md, interval section.). 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
@ -221,7 +218,7 @@ proposal without a valid Falcon seal from its own proposer does not open a round
its own domain over (chainId, height, round, digest), so an honest proposal seal cannot be replayed
as a vote nor a vote seal as a proposal - both directions are tested. The ROUND-CHANGE message
carries its own seal since 2026-08-31 (its embedded justifications are coupled to PREPARE
enforcement). What remains classical on chain 2800: node-level devp2p authentication. The validators are named in
enforcement). What remains classical on chain 2800: node-level devp2p authentication, the ECDSA commit seals that every header still carries until AIP-22 stage 5, and the ECDSA commit seal that a commit carries besides its post-quantum seal. The validators are named in
consensus by the post-quantum ids of AIP-22 since block 20,836,228 (stage 3, 2026-09-30); that code is in this directory.
(Corrected 2026-10-22: until that date this sentence also listed validator identity as classical and said that the
post-quantum identity was unarmed on chain 2800 and ran only on testnet 28001.)
@ -330,9 +327,7 @@ was a deliberate decision with a liveness cost, taken for block 20,715,632 (AIP-
then the certificate at an anchor height is again backed by as many validators as the block itself.
Two things follow, and both should be said rather than left to be discovered. The word "quorum"
applies **only at anchor heights** - every 32nd block (every 128th from block 17,225,968 to block 20,746,736); the blocks between them carry no Falcon
seals at all and are finalized by ECDSA alone, so "a post-quantum quorum on every block" would be
false. And the higher threshold costs liveness margin: at K=7 of ten, four late validators are
applies **only at anchor heights** - every 32nd block (every 128th from block 17,225,968 to block 20,746,736); the blocks between them carry no certificate of their own (headers are still admitted on their ECDSA commit seals until AIP-22 stage 5), so "a post-quantum quorum certificate on every block" would be false. And the higher threshold costs liveness margin: at K=7 of ten, four late validators are
enough to stall an anchor block, where K=3 tolerated seven. That trade was made deliberately, and it
is the reason the threshold is a configured schedule rather than a constant.