diff --git a/README.md b/README.md index 6cdf42a..81a74f1 100644 --- a/README.md +++ b/README.md @@ -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 diff --git a/SPEC.md b/SPEC.md index c5fcdaf..3badfb1 100644 --- a/SPEC.md +++ b/SPEC.md @@ -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: diff --git a/anchor/README.md b/anchor/README.md index 691cd7f..a58a6d4 100644 --- a/anchor/README.md +++ b/anchor/README.md @@ -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.