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:
parent
b75b3981b3
commit
6514604819
@ -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
|
||||
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
|
||||
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.
|
||||
|
||||
## Fixes
|
||||
|
||||
@ -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
|
||||
|
||||
**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:
|
||||
|
||||
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.
|
||||
|
||||
"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
|
||||
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
|
||||
|
||||
@ -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
|
||||
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
|
||||
verifier.
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user