Dated correction 2026-11-04 to the vote attribution since block 24,300,000 (one path of the second client until 2026-10-31 12:27Z; AIP-22 rule 3, correction of 2026-11-01): SECURITY.md, anchor/README.md, validator/README.md

This commit is contained in:
Aere Network 2026-11-04 05:32:57 +02:00
parent b75b3981b3
commit 6514604819
3 changed files with 4 additions and 4 deletions

View File

@ -38,7 +38,7 @@ pointer is <https://aere.network/.well-known/security.txt>.
every 32nd block (every 128th from block 17,225,968 to block 20,746,736) carries a post-quantum every 32nd block (every 128th from block 17,225,968 to block 20,746,736) carries a post-quantum
certificate under the block hash (Falcon-512, and from block 17,047,600 also SLH-DSA-SHA2-128s, at certificate under the block hash (Falcon-512, and from block 17,047,600 also SLH-DSA-SHA2-128s, at
every 128th block since block 20,746,736), requiring at least seven valid seals of each scheme every 128th block since block 20,746,736), requiring at least seven valid seals of each scheme
since block 20,715,632, as many as the quorum of the ten validators (six from block 14,961,456, six of nine validators then); below block 24,148,752 the seals proved those validators signed the block, not that it was decided (AIP-22 erratum, 2026-10-01), and from that block a certificate that carries the quorum of one round proves the decision. Blocks between anchors carry no certificate of their own and are decided by QBFT (this sentence corrected on 2026-10-28: it said that blocks between anchors rest on ECDSA): since block 24,300,000 (AIP-22 stage 4) every vote counts only with the verified post-quantum seal of its author, and a commit still carries the ECDSA commit seal of its validator as an additional check; their headers were admitted on their ECDSA commit seals until block 25,080,000 (AIP-22 stage 5), and from it a node that does not take part in consensus admits a header between anchors on the Falcon-512 seal of its proposer alone, so the post-quantum key of one validator can serve such a node a branch up to the block before the next anchor (below block 25,080,000 that took the ECDSA keys of a quorum), and the next anchor ends it for a node that requires the seals of a quorum in its certificate (the published follower, with its seal ceiling at 1, is not such a node: for it one leaked or misused post-quantum key of a validator makes the rewrite depth unbounded, section 6.4 of the aere-node SPEC). We correct since block 20,715,632, as many as the quorum of the ten validators (six from block 14,961,456, six of nine validators then); below block 24,148,752 the seals proved those validators signed the block, not that it was decided (AIP-22 erratum, 2026-10-01), and from that block a certificate that carries the quorum of one round proves the decision. Blocks between anchors carry no certificate of their own and are decided by QBFT (this sentence corrected on 2026-10-28: it said that blocks between anchors rest on ECDSA): since block 24,300,000 (AIP-22 stage 4) every vote counts only with the verified post-quantum seal of its author (corrected 2026-11-04: from block 24,300,000 until 2026-10-31 12:27Z one path of the second client took the author of a proposal that named a height below 24,300,000 from its ECDSA envelope, as the correction of 2026-11-01 to rule 3 of AIP-22 says), and a commit still carries the ECDSA commit seal of its validator as an additional check; their headers were admitted on their ECDSA commit seals until block 25,080,000 (AIP-22 stage 5), and from it a node that does not take part in consensus admits a header between anchors on the Falcon-512 seal of its proposer alone, so the post-quantum key of one validator can serve such a node a branch up to the block before the next anchor (below block 25,080,000 that took the ECDSA keys of a quorum), and the next anchor ends it for a node that requires the seals of a quorum in its certificate (the published follower, with its seal ceiling at 1, is not such a node: for it one leaked or misused post-quantum key of a validator makes the rewrite depth unbounded, section 6.4 of the aere-node SPEC). We correct
over-claims publicly when we find them, and we have done so before. over-claims publicly when we find them, and we have done so before.
## Fixes ## Fixes

View File

@ -10,7 +10,7 @@ demonstrable from these files is marked as not demonstrable from these files.
## Scope boundary, stated first and not in a footnote ## Scope boundary, stated first and not in a footnote
**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 25,080,000 (AIP-22 stage 5) headers no longer carry ECDSA commit seals and, since block 24,300,000 (AIP-22 stage 4), every vote counts only with the verified post-quantum seal of its author, and a commit still carries the ECDSA commit seal of its validator as an additional check, which we call post-quantum consensus, with three limits: the transport between nodes is still authenticated by secp256k1, the ten validators are run by one operator, and no third party has audited it yet.** 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 25,080,000 (AIP-22 stage 5) headers no longer carry ECDSA commit seals and, since block 24,300,000 (AIP-22 stage 4), every vote counts only with the verified post-quantum seal of its author (corrected 2026-11-04: from block 24,300,000 until 2026-10-31 12:27Z one path of the second client took the author of a proposal that named a height below 24,300,000 from its ECDSA envelope, as the correction of 2026-11-01 to rule 3 of AIP-22 says), and a commit still carries the ECDSA commit seal of its validator as an additional check, which we call post-quantum consensus, with three limits: the transport between nodes is still authenticated by secp256k1, the ten validators are run by one operator, and no third party has audited it yet.** This code is what adds the checkpoint, in two steps that
should not be confused: should not be confused:
1. **The binding.** From block 13,014,000 the block hash of every anchored header (every 32nd 1. **The binding.** From block 13,014,000 the block hash of every anchored header (every 32nd
@ -62,7 +62,7 @@ inert, and the chain itself confirms it: blocks between anchors carried no Falco
14,050,000 every block required a 2f+1 Falcon quorum to finalize is withdrawn. 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 "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" is the word since block 25,080,000 (AIP-22 stage 5), in this sense: headers no longer carry ECDSA commit seals and, since block 24,300,000 (AIP-22 stage 4), every vote counts only with the verified post-quantum seal of its author, and a commit still carries the ECDSA commit seal of its validator as an additional check; its limits are stated with it: the transport between nodes is still authenticated by secp256k1, the ten validators are run by one operator, and no third party has audited it yet (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) (corrected on 2026-10-30, at AIP-22 stage 5: until that day this sentence said that "post-quantum consensus" without qualification overstates). The 2026-09-04, the two-scheme certificate. "Post-quantum consensus" is the word since block 25,080,000 (AIP-22 stage 5), in this sense: headers no longer carry ECDSA commit seals and, since block 24,300,000 (AIP-22 stage 4), every vote counts only with the verified post-quantum seal of its author (corrected 2026-11-04: from block 24,300,000 until 2026-10-31 12:27Z one path of the second client took the author of a proposal that named a height below 24,300,000 from its ECDSA envelope, as the correction of 2026-11-01 to rule 3 of AIP-22 says), and a commit still carries the ECDSA commit seal of its validator as an additional check; its limits are stated with it: the transport between nodes is still authenticated by secp256k1, the ten validators are run by one operator, and no third party has audited it yet (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) (corrected on 2026-10-30, at AIP-22 stage 5: until that day this sentence said that "post-quantum consensus" without qualification overstates). The
four QBFT message types carry a post-quantum seal of their author on chain 2800 since blocks 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 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 anchor itself; and a message without a valid seal is REFUSED by the Besu-derived validators from

View File

@ -537,7 +537,7 @@ admits you, and the same emission and enforcement heights as the fleet, which th
A validator whose seals are refused does not fork and does not accept anything wrong: it loses its A validator whose seals are refused does not fork and does not accept anything wrong: it loses its
turn as proposer, and the chain continues without it as long as a quorum of the others can seal. turn as proposer, and the chain continues without it as long as a quorum of the others can seal.
**What we claim, and what we do not.** Since block 25,080,000 (AIP-22 stage 5) headers no longer carry ECDSA commit seals and, since block 24,300,000 (AIP-22 stage 4), every vote counts only with the verified post-quantum seal of its author, and a commit still carries the ECDSA commit seal of its validator as an additional check, which we call post-quantum consensus. We do not claim a post-quantum transport (the peer-to-peer transport is still authenticated by secp256k1), the ten validators are run by one operator, and no third party has audited it yet. What you can verify yourself, **What we claim, and what we do not.** Since block 25,080,000 (AIP-22 stage 5) headers no longer carry ECDSA commit seals and, since block 24,300,000 (AIP-22 stage 4), every vote counts only with the verified post-quantum seal of its author (corrected 2026-11-04: from block 24,300,000 until 2026-10-31 12:27Z one path of the second client took the author of a proposal that named a height below 24,300,000 from its ECDSA envelope, as the correction of 2026-11-01 to rule 3 of AIP-22 says), and a commit still carries the ECDSA commit seal of its validator as an additional check, which we call post-quantum consensus. We do not claim a post-quantum transport (the peer-to-peer transport is still authenticated by secp256k1), the ten validators are run by one operator, and no third party has audited it yet. What you can verify yourself,
without taking our word for it, is the anchor certificate at every 32nd block, with the public without taking our word for it, is the anchor certificate at every 32nd block, with the public
verifier. verifier.