diff --git a/aips/AIP-1.md b/aips/AIP-1.md index 0b391ee..0efea64 100644 --- a/aips/AIP-1.md +++ b/aips/AIP-1.md @@ -238,9 +238,7 @@ correctly formed is not the same person deciding whether the idea wins.* - Aere consensus is QBFT on chain 2800: anchor blocks carry a post-quantum certificate under their hash since block 13,014,000, and since block 24,300,000 (AIP-22 stage 4) a consensus vote counts only with the verified - post-quantum seal of its author (headers still carry ECDSA commit seals until - AIP-22 stage 5). No AIP claims or implies post-quantum consensus without the - limits it states. Post-quantum also applies to signatures, accounts and + post-quantum seal of its author (since block 25,080,000, AIP-22 stage 5, headers no longer carry ECDSA commit seals and are admitted on the Falcon-512 seal of their proposer alone; a commit still carries the ECDSA commit seal of its validator as an additional check); that arrangement has 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. No AIP claims or implies post-quantum consensus without naming them. Post-quantum also applies to signatures, accounts and applications (this rule corrected on 2026-10-26: until that date it said that Aere consensus is classical secp256k1 ECDSA QBFT and that post-quantum applies to signatures, accounts and applications only). diff --git a/aips/AIP-13.md b/aips/AIP-13.md index 7e7535c..05693c0 100644 --- a/aips/AIP-13.md +++ b/aips/AIP-13.md @@ -87,7 +87,7 @@ Contract suite: AIP-4. Precompile activation and addresses: AIP-7. Chain ID 2800 ## Errata -None. +**Erratum 1 (2026-10-30).** The Security Considerations describe consensus as classical, with validators signing secp256k1 QBFT, and say that Aere never claims post-quantum consensus. For when the first held, see the notes of 2026-10-27 and 2026-10-28 at the top of this document, which date it; that validators sign secp256k1 in QBFT stays true, since every commit carries the ECDSA commit seal of its validator as an additional check. Since block 25,080,000 (AIP-22 stage 5) headers no longer carry ECDSA commit seals, each carrying the Falcon-512 seal of its proposer instead, 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 Aere calls 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. The statement that Aere never claims post-quantum consensus, and what the note of 2026-10-27 says about the headers, describe chain 2800 below block 25,080,000. The decision this AIP records, two lattice families plus hash-based schemes, is unchanged. The original text is left exactly as published, per AIP-1 section 5. ## Copyright diff --git a/aips/AIP-15.md b/aips/AIP-15.md index 5936409..134b9c6 100644 --- a/aips/AIP-15.md +++ b/aips/AIP-15.md @@ -1,5 +1,7 @@ # AIP-15: In-Place Hybrid PQC Consensus Activation via On-Chain Anchor Contract, not Re-Genesis +> **Note added 2026-10-30 (consensus).** Since block 25,080,000 (AIP-22 stage 5) headers no longer carry ECDSA commit seals: each carries the Falcon-512 seal of its proposer instead, and a commit still carries the ECDSA commit seal of its validator as an additional check. Where the note of 2026-09-24 below describes the headers, it describes chain 2800 below that block. + > **Note added 2026-09-24 (consensus).** Where this document says that consensus is classical secp256k1 ECDSA and not post-quantum, read it as the per-block finality statement it was until block 24,300,000 (AIP-22 stage 4, 2026-10-25). Since that block every validator attributes a consensus vote only through its verified post-quantum seal, and a block is post-quantum final once the next anchor, at most 32 blocks later, carries the certificate that covers it; headers still carry classical ECDSA commit seals until AIP-22 stage 5 (this sentence corrected on 2026-10-25). It no longer describes all of consensus on chain 2800: since 2026-08-14 every anchor block must carry a certificate of validator post-quantum seals under its hash (Falcon-512, with SLH-DSA as well since 2026-09-04), and since 2026-09-05 (block 17,250,000) the nine AERE-client validators (nine of the ten) refuse a commit message without a valid Falcon-512 seal of its author, and since 2026-09-08 (block 17,700,000) any QBFT consensus message without one, while the tenth, the second client, enforced that seal only on commit messages until block 24,300,000 and attributes every consensus message only through it since (this clause corrected on 2026-10-12, 2026-10-25 and 2026-10-28; until 2026-10-28 it dated the refusal of every message type to 2026-09-05, the date of the commit layer alone). (Note applied to this document on 2026-10-28.) ## Preamble diff --git a/aips/AIP-16.md b/aips/AIP-16.md index b91c366..f3bfb63 100644 --- a/aips/AIP-16.md +++ b/aips/AIP-16.md @@ -1,5 +1,7 @@ # AIP-16: PQ STARK-Verify Precompile (0x0AE8) +> **Note added 2026-10-30 (consensus).** Since block 25,080,000 (AIP-22 stage 5) headers no longer carry ECDSA commit seals: each carries the Falcon-512 seal of its proposer instead, and a commit still carries the ECDSA commit seal of its validator as an additional check. Where the note of 2026-09-24 below describes the headers, it describes chain 2800 below that block. + > **Note added 2026-09-24 (consensus).** Where this document says that consensus is classical secp256k1 ECDSA and not post-quantum, read it as the per-block finality statement it was until block 24,300,000 (AIP-22 stage 4, 2026-10-25). Since that block every validator attributes a consensus vote only through its verified post-quantum seal, and a block is post-quantum final once the next anchor, at most 32 blocks later, carries the certificate that covers it; headers still carry classical ECDSA commit seals until AIP-22 stage 5 (this sentence corrected on 2026-10-25). It no longer describes all of consensus on chain 2800: since 2026-08-14 every anchor block must carry a certificate of validator post-quantum seals under its hash (Falcon-512, with SLH-DSA as well since 2026-09-04), and since 2026-09-05 (block 17,250,000) the nine AERE-client validators (nine of the ten) refuse a commit message without a valid Falcon-512 seal of its author, and since 2026-09-08 (block 17,700,000) any QBFT consensus message without one, while the tenth, the second client, enforced that seal only on commit messages until block 24,300,000 and attributes every consensus message only through it since (this clause corrected on 2026-10-12, 2026-10-25 and 2026-10-28; until 2026-10-28 it dated the refusal of every message type to 2026-09-05, the date of the commit layer alone). (Note applied to this document on 2026-10-28.) ## Preamble diff --git a/aips/AIP-22.md b/aips/AIP-22.md index cbb43fe..089d234 100644 --- a/aips/AIP-22.md +++ b/aips/AIP-22.md @@ -29,6 +29,8 @@ > **Note added 2026-10-25.** Stage 4 is active on chain 2800 since block 24,300,000: from it every validator, on both clients, takes the author of a consensus message from its verified post-quantum seal, and the second client's proposal, prepare and round-change layers, named in the notes above as taking effect at stage 4, are in force. Rule 4 of section 4 (the provisional tail and its rollback) is not part of the stage-4 binaries on chain 2800: neither client implements it at this date, a block is final on import as before, and its post-quantum proof is the anchor that covers it; the bound of rule 1 holds because every anchor height must carry a valid certificate. Headers keep their ECDSA commit seals until stage 5. +> **Note added 2026-10-30.** Stage 5 is active on chain 2800 since block 25,080,000: from it every header, anchors included, is admitted only with an empty ECDSA committed-seals element and a valid Falcon-512 proposer seal in element 6 (section 5), so no header carries an ECDSA signature. Below it every header carried the ECDSA commit quorum, which both clients required on import exactly as upstream does: rule 2 of section 4 was not implemented separately. Since stage 4 a vote counts only with its author's verified post-quantum seal, and a commit still carries the validator's ECDSA commit seal as an additional check (the correction of 2026-10-25 under section 5), so the classical uses that remain are that commit seal, the ECDSA envelope that every consensus message still carries on the wire (no longer naming its author) and the RLPx transport between nodes; the ten validators are run by one operator, and no third party has audited the stages. 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). Where the notes above, Motivation item 1 and the "Today" of the per-height bullet in Security Considerations say that headers carry ECDSA commit seals, they describe chain 2800 below that block. Item (4) of the Abstract describes the design; on chain 2800 the ECDSA commit seal of a commit remains a validity criterion, as rule 3 of section 4 and the correction of 2026-10-25 under section 5 say. + ## Preamble | Field | Value | @@ -58,7 +60,7 @@ What remains classical is exactly what a node that is NOT online, one that syncs 1. Between two anchors, the header of a block carries only ECDSA commit seals. A syncing node checks those and nothing post-quantum for up to 127 blocks (about 72 seconds at the measured block period). Its post-quantum assurance for those blocks arrives only with the next anchor, and the anchor's certificate is bound to the parent hash, so the assurance is real but delayed, and it is not stated as a rule anywhere. 2. The certificate threshold is six of ten (schedule step `14961456:6`), which is f + 3 at N = 10 and below the QBFT quorum of seven (recorded in the repository's findings register on 2026-09-11). A hostile reader is right to say: the certificate proves that six validators signed, it does not prove that consensus was reached. 3. Validator identity is an ECDSA address: the validator list in `extraData`, the proposer rotation, the `coinbase`, the vote recipient, the registry's `claim`, and the peer-forwarding predicate of the Besu-derived client (it forwards Istanbul messages only to peers whose node-key address is in the set, measured 2026-09-02) all name secp256k1 keys. The Falcon registry binds an index to that address; the address itself is classical. -4. The ECDSA signature of every consensus message and the ECDSA commit seals in every header are still validity criteria. The live security is therefore "ECDSA AND Falcon" for an online node, which is stronger than either alone, and "ECDSA, then Falcon at the next anchor" for a syncing one. (Corrected 2026-10-09: on the second client "ECDSA AND Falcon" holds for commits; it counts proposal, prepare and round-change messages by their ECDSA author until stage 4, whose height is not yet set on chain 2800. See Errata.) +4. The ECDSA signature of every consensus message named its author until stage 4 below (its form is still judged by both clients, though not its author: the note of 2026-10-27 under section 5), and the ECDSA commit seals in every header were a validity criterion until stage 5; until then the live security was "ECDSA AND Falcon" for an online node, which is stronger than either alone, and "ECDSA, then Falcon at the next anchor" for a syncing one. (On chain 2800 the ECDSA signature of a consensus message stopped naming its author at stage 4 below, block 24,300,000, from which a vote counts only with its author's verified post-quantum seal; a commit still needs both its ECDSA commit seal and that post-quantum seal, so for commits the live security is still "ECDSA AND post-quantum". The ECDSA commit quorum in the header stayed a validity criterion, applied by both clients exactly as before, until stage 5, block 25,080,000, 2026-10-30, from which no header carries an ECDSA signature; rule 2 of section 4 was not implemented separately.) (Corrected 2026-10-09: on the second client "ECDSA AND Falcon" holds for commits; it counts proposal, prepare and round-change messages by their ECDSA author until stage 4, whose height is not yet set on chain 2800. See Errata.) The Foundation's stated goal, restated on 2026-09-22, is a consensus whose safety and finality do not depend on ECDSA at all. This AIP is the path from the measured state above to that goal, with the cost of each step in bytes, disk, bandwidth and latency, and with the founder decisions it needs named. @@ -194,7 +196,7 @@ From `H_fin` (a height at or above `H_id`), on every node that validates or read ### 5. ECDSA out of the header -From `H_hdr` (at or above `H_fin`), `extraData` gains element 6, `proposerSeal = [index, signature]`, a Falcon-512 seal by the proposer over the message the proposal already signs, `keccak256(RLP["AERE-PQ-PROPOSAL-1", chainId, height, round, proposalDigest])`, where `proposalDigest` is the QBFT proposal digest recomputable from the stored header (the round is element 3 of the stored `extraData`; the digest is the `EXCLUDE_COMMIT_SEALS` encoding hash, SPEC 2.3). Element 6 is outside both hashes (like the commit seals and the certificate) and subject to the strict codec; when it is present, element 5 is present too, an empty list where the header carries no certificate, so position alone says which element is which (a six-element header whose element 5 is an empty list is not canonical and is refused). From `H_hdr` every header, anchors included, is admitted iff its ECDSA committed seals element is empty and the proposer seal verifies, over the round in element 3, for the `coinbase` `id` at that height or, when that round is above zero, for the `id` of the proposer of that round (the proposer rotation computed from the parent's `coinbase` and the header's validator list); the round in element 3 is at most 1024 (no honest round gets near it, the round timer doubling each round), and, the parent being known, the `coinbase` is the proposer of some round from 0 to the round in element 3, that is, the block's builder; an anchor is judged by the anchor rule as well. The second case is the block prepared in one round and re-proposed unchanged in a later one: QBFT keeps the locked block, so its `coinbase` stays its builder's, and the accepted proposal, whose seal every node writes, is the later round's proposer's. (Corrected 2026-09-25: the text until then named the `coinbase` only, both clients implemented it so, and on testnet 28001 block 3,314,873, prepared at round 0 under load, was re-proposed at rounds 1 to 4 and refused by every node each time, 128 s, until round 5 was its builder's turn again; at N = 10 that wait is ten rounds, and with the builder down after the prepare it does not end.) Cost: +663 B and -455 B (7 x 65) per block at N = 10, net +208 B, that is **+11.6 GB per node per year** (208 x 55,854,159 / 10^9). After `H_hdr` no ECDSA signature appears in any header or is examined in any consensus message; the last classical use is the RLPx transport. +From `H_hdr` (at or above `H_fin`), `extraData` gains element 6, `proposerSeal = [index, signature]`, a Falcon-512 seal by the proposer over the message the proposal already signs, `keccak256(RLP["AERE-PQ-PROPOSAL-1", chainId, height, round, proposalDigest])`, where `proposalDigest` is the QBFT proposal digest recomputable from the stored header (the round is element 3 of the stored `extraData`; the digest is the `EXCLUDE_COMMIT_SEALS` encoding hash, SPEC 2.3). Element 6 is outside both hashes (like the commit seals and the certificate) and subject to the strict codec; when it is present, element 5 is present too, an empty list where the header carries no certificate, so position alone says which element is which (a six-element header whose element 5 is an empty list is not canonical and is refused). From `H_hdr` every header, anchors included, is admitted iff its ECDSA committed seals element is empty and the proposer seal verifies, over the round in element 3, for the `coinbase` `id` at that height or, when that round is above zero, for the `id` of the proposer of that round (the proposer rotation computed from the parent's `coinbase` and the header's validator list); the round in element 3 is at most 1024 (no honest round gets near it, the round timer doubling each round), and, the parent being known, the `coinbase` is the proposer of some round from 0 to the round in element 3, that is, the block's builder; an anchor is judged by the anchor rule as well. The second case is the block prepared in one round and re-proposed unchanged in a later one: QBFT keeps the locked block, so its `coinbase` stays its builder's, and the accepted proposal, whose seal every node writes, is the later round's proposer's. (Corrected 2026-09-25: the text until then named the `coinbase` only, both clients implemented it so, and on testnet 28001 block 3,314,873, prepared at round 0 under load, was re-proposed at rounds 1 to 4 and refused by every node each time, 128 s, until round 5 was its builder's turn again; at N = 10 that wait is ten rounds, and with the builder down after the prepare it does not end.) Cost: +663 B and -455 B (7 x 65) per block at N = 10, net +208 B, that is **+11.6 GB per node per year** (208 x 55,854,159 / 10^9). After `H_hdr` no ECDSA signature appears in any header, and none decides who authored a consensus vote (that holds from `H_fin`); ECDSA remains on the envelope of every consensus message, whose form both clients still judge (note of 2026-10-27 under this section), and in the commit seal that a commit message still carries as an additional check, until stage E (section 10) replaces it; the RLPx transport stays classical. (Sentence corrected on 2026-10-31: until that day it also excluded ECDSA from the consensus messages, which is the work of stage E, not of this stage.) **Correction added 2026-10-25 (to the last sentence of the paragraph above).** After `H_hdr` no header carries an ECDSA signature, but one consensus message still does: a commit carries the validator's ECDSA commit seal, and both clients refuse a commit whose commit seal does not recover to its author, at every height, `H_hdr` included (the Besu-derived client in `AereVoteCounts.java`, the Nethermind-derived client in `AereVoteCounts.cs`), as rule 3 of section 4 says ("a commit's author is its index's `id` only when that `id` is the commit seal signer's"). A vote counts only with its author's verified post-quantum seal, and a commit still carries the validator's ECDSA commit seal as an additional check: forging a vote needs the post-quantum key, and the ECDSA key alone does not make a vote count. The classical uses after `H_hdr` are therefore that commit seal, as an additional check, and the RLPx transport. The sentence above is kept as it was written. diff --git a/aips/AIP-4.md b/aips/AIP-4.md index 48f5c5d..28ce96a 100644 --- a/aips/AIP-4.md +++ b/aips/AIP-4.md @@ -199,6 +199,10 @@ true, tampered inputs return false. The recording transactions cited (XMSS, SPHINCS+, the Falcon-512 account userOp, and the hybrid auth) are on-chain and under the EIP-7825 cap. +## Errata + +**Erratum 1 (2026-10-30).** The Motivation and the Security Considerations say that validators sign classical QBFT and that AERE consensus is not post-quantum; the note of 2026-08-19 at the top of this document dates those statements for anchor blocks, and they describe chain 2800 on the date of this document. Validators still sign their commits with secp256k1: every commit carries the ECDSA commit seal of its validator as an additional check. Since block 25,080,000 (AIP-22 stage 5) headers no longer carry ECDSA commit seals, each carrying the Falcon-512 seal of its proposer instead, 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 Aere calls 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. What this AIP records, post-quantum verifiers at the application and account layer, is unchanged, and they do not address consensus. The original text is left exactly as published, per AIP-1 section 5. + ## Copyright Released to the public domain (CC0). No rights reserved. diff --git a/aips/AIP-7.md b/aips/AIP-7.md index c540234..5ca5384 100644 --- a/aips/AIP-7.md +++ b/aips/AIP-7.md @@ -248,6 +248,8 @@ is byte-for-byte agreement with the NIST KAT and ACVP vectors in both directions recorded in `AERE-NIST-VALIDATION-STATUS.md` section 3.4. Nothing normative in this AIP changed: the precompiles, addresses, encodings and gas constants are untouched. +**Erratum 2 (2026-10-30).** The Abstract describes AERE consensus as classical secp256k1 ECDSA QBFT and not post-quantum, and the Specification describes blocks as committed by validators signing classical secp256k1 ECDSA committed seals. For when that description held, see the notes of 2026-10-27 and 2026-10-28 at the top of this document, which date it (the second dates the post-quantum layers added to consensus before block 24,300,000). Since block 25,080,000 (AIP-22 stage 5) headers no longer carry ECDSA commit seals, each carrying the Falcon-512 seal of its proposer instead, 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 Aere calls 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. What the note of 2026-10-27 says about the headers, and that Aere does not claim post-quantum consensus, describes chain 2800 below block 25,080,000. What this AIP records, a fork that changed the execution layer only, remains true. The original text is left exactly as published, per AIP-1 section 5. + The clarification below remains an outcome record rather than an erratum, because this AIP specified five precompiles and five is what is live. The record exists to close off a misreading that arose elsewhere, not to correct this text. diff --git a/aips/AIP-8.md b/aips/AIP-8.md index d921787..6108a31 100644 --- a/aips/AIP-8.md +++ b/aips/AIP-8.md @@ -1,5 +1,7 @@ # AIP-8: Post-Quantum-Authorized Transaction Envelope (EIP-2718 Type 0x2A) +> **Note added 2026-10-30 (consensus).** Since block 25,080,000 (AIP-22 stage 5) headers no longer carry ECDSA commit seals: each carries the Falcon-512 seal of its proposer instead, and a commit still carries the ECDSA commit seal of its validator as an additional check. Where the note of 2026-09-24 below describes the headers, it describes chain 2800 below that block. + > **Note added 2026-09-24 (consensus).** Where this document says that consensus is classical secp256k1 ECDSA and not post-quantum, read it as the per-block finality statement it was until block 24,300,000 (AIP-22 stage 4, 2026-10-25). Since that block every validator attributes a consensus vote only through its verified post-quantum seal, and a block is post-quantum final once the next anchor, at most 32 blocks later, carries the certificate that covers it; headers still carry classical ECDSA commit seals until AIP-22 stage 5 (this sentence corrected on 2026-10-25). It no longer describes all of consensus on chain 2800: since 2026-08-14 every anchor block must carry a certificate of validator post-quantum seals under its hash (Falcon-512, with SLH-DSA as well since 2026-09-04), and since 2026-09-05 (block 17,250,000) the nine AERE-client validators (nine of the ten) refuse a commit message without a valid Falcon-512 seal of its author, and since 2026-09-08 (block 17,700,000) any QBFT consensus message without one, while the tenth, the second client, enforced that seal only on commit messages until block 24,300,000 and attributes every consensus message only through it since (this clause corrected on 2026-10-12, 2026-10-25 and 2026-10-28; until 2026-10-28 it dated the refusal of every message type to 2026-09-05, the date of the commit layer alone). (Note applied to this document on 2026-09-27.) > **Note added 2026-08-19.** Statements in this document that consensus on chain 2800 is (or remains) classical secp256k1 ECDSA QBFT were written before the post-quantum header anchor went live, and remain true for block-by-block finality. Since block 13,014,000 anchor blocks (every 32nd block, on every one since block 13,889,296) also carry, under the block hash, a certificate of validator Falcon-512 seals, and since 2026-08-14 a node rejects an anchor block with fewer than three valid seals (f+1 of nine; eight or nine are carried in practice). That is a post-quantum checkpoint about every 16 seconds, not a per-block quorum: the claim published on 2026-08-15 that from block 14,050,000 no block finalizes without a post-quantum quorum was wrong (the per-block rule armed at that height is retired in the shipped code in favour of the anchor rules) and was withdrawn on 2026-08-19. Details: https://aere.network/quantum.html and the aere-node repository, anchor/README.md. diff --git a/aips/AIP-9.md b/aips/AIP-9.md index 86048fc..f4e671c 100644 --- a/aips/AIP-9.md +++ b/aips/AIP-9.md @@ -97,6 +97,8 @@ HotStuff, is unaffected, and so is the Nakamoto argument in the Security Considerations: the set grew, the operator count did not. The original text is left exactly as published, per AIP-1 section 5. +**Erratum 2 (2026-10-30).** The Specification and the Rationale describe the finality that QBFT gives here as deterministic and reached in a single block. Read that as the finality of the validators, the nodes that take part in consensus: from block 25,080,000 (AIP-22 stage 5) a node outside consensus treats a block as final once the next anchor covers it, which is the finalized block, at most one anchor interval (32 blocks, about 20 seconds) behind the head. The Specification also describes the validator seals as classical secp256k1 ECDSA and states that consensus is not post-quantum, and the Security Considerations describe the consensus seals the same way; that was true on the date of this document, and post-quantum layers were added to consensus after it, each dated in AIP-22 (the hybrid design of AIP-15 that the Security Considerations name is not live). Since block 25,080,000 headers no longer carry ECDSA commit seals, each carrying the Falcon-512 seal of its proposer instead, 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 Aere calls 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. The decision this AIP records, QBFT rather than HotStuff, is unaffected. The original text is left exactly as published, per AIP-1 section 5. + ## Copyright Released to the public domain (CC0). No rights reserved. diff --git a/aips/CONTRIBUTING.md b/aips/CONTRIBUTING.md index 1e9e36b..c83442e 100644 --- a/aips/CONTRIBUTING.md +++ b/aips/CONTRIBUTING.md @@ -81,10 +81,7 @@ The rules that get proposals bounced fastest: - **Do not claim post-quantum consensus without its limits.** On chain 2800 anchor blocks carry a post-quantum certificate under their hash since block 13,014,000, and since block 24,300,000 (AIP-22 stage 4) a consensus vote - counts only with the verified post-quantum seal of its author (headers still - carry ECDSA commit seals until AIP-22 stage 5); the transport between nodes is - still secp256k1. Aere's post-quantum work is also at the signature, account - and application layers. A proposal that blurs this will be sent back (this + counts only with the verified post-quantum seal of its author (since block 25,080,000, AIP-22 stage 5, headers no longer carry ECDSA commit seals and are admitted on the Falcon-512 seal of their proposer alone; a commit still carries the ECDSA commit seal of its validator as an additional check); that arrangement has 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. Aere's post-quantum work is also at the signature, account and application layers. A proposal that names fewer of these limits, or blurs them, will be sent back (this rule corrected on 2026-10-26: until that date it said that Aere consensus is classical secp256k1 ECDSA QBFT). diff --git a/aips/README.md b/aips/README.md index d90f322..ef85a17 100644 --- a/aips/README.md +++ b/aips/README.md @@ -46,7 +46,7 @@ document is current. | [19](./AIP-19.md) | AIP Process Hardening | Meta | **Review, not ratified** | | | [20](./AIP-20.md) | Native Post-Quantum Transactions (Type 0x50, ML-DSA Authorization) | Standards Track / Core | **Draft, not ratified; implemented in both clients and proven conformant on shared vectors (2026-09-17); live on testnet 28001 from block 2,212,000 (first type-0x50 transaction at 2,212,032, both clients); on chain 2800 the implementation runs on every node since 2026-09-22 and is armed, uniformly, for block 19,900,000 (per-node property, not a genesis change); no type-0x50 transaction on chain 2800 before that height** | | | [21](./AIP-21.md) | Verifiable Post-Quantum Finality per Block (Side Store, Proof RPC, Anchor as Permanent Record) | Standards Track / Interface (non-consensus) | **Draft, not ratified; first half (retention window + `aere_getPqFinality`) implemented in the Besu-derived client with 7 tests and deployed on testnet 28001 (5 nodes, public door `testnet-rpc.aere.network/finality`) on 2026-09-18; Nethermind port the same day (10 tests) and deployed on the testnet Nethermind validator with its own public door; two-client conformance proven live (`aip21-conformitate/DOVEDESTE.sh`, CONFORM on block 2,250,809); second half (the window on disk, same journal format in both clients) deployed on all six testnet nodes the same day: the window survives a restart in both (1,284 and 1,255 seals re-verified, 0 failed), and a round-1 block is `post-quantum` in both on the same hash (CONFORM 08:49Z, block 2,285,481 and round-1 block 2,285,333); on chain 2800 since 2026-09-22 on all ten validators and both clients (`aere_getPqFinality` answers `post-quantum` with 10 of 10 seals re-verified; dated record at the end of AIP-21)** | | -| [22](./AIP-22.md) | Post-Quantum-Only Finality (Chained Quorum Certificates, PQ Validator Identity, ECDSA Demoted to Compatibility) | Standards Track / Core | **Draft, not ratified; a design only on 2026-09-23; stages 1 to 6 then proven on testnet 28001 in both clients (from 2026-09-23, stage 5 in its corrected form since 2026-09-26 and stage 6 in its repaired form since 2026-10-16; stage records in the AIP); conformance corpus of all nine kinds published 2026-09-27 (`aip22-conformance/`); on chain 2800 stages 1 to 3 active from blocks 20,715,632, 20,746,736 and 20,836,228 (2026-09-29 and 2026-09-30), stage R active since block 24,148,752 (2026-10-24), stage 4 active since block 24,300,000 (2026-10-25), stage 5 not armed (its activation height is the founder's)** | | +| [22](./AIP-22.md) | Post-Quantum-Only Finality (Chained Quorum Certificates, PQ Validator Identity, ECDSA Demoted to Compatibility) | Standards Track / Core | **Draft, not ratified; a design only on 2026-09-23; stages 1 to 6 then proven on testnet 28001 in both clients (from 2026-09-23, stage 5 in its corrected form since 2026-09-26 and stage 6 in its repaired form since 2026-10-16; stage records in the AIP); conformance corpus of all nine kinds published 2026-09-27 (`aip22-conformance/`); on chain 2800 stages 1 to 3 active from blocks 20,715,632, 20,746,736 and 20,836,228 (2026-09-29 and 2026-09-30), stage R active since block 24,148,752 (2026-10-24), stage 4 active since block 24,300,000 (2026-10-25), stage 5 active since block 25,080,000 (2026-10-30)** | | | [23](./AIP-23.md) | AERE Proof Protocol (Portable Verifiable-Statement Envelope with Optional Post-Quantum On-Chain Finality) | Standards Track / Interface | **Draft, not ratified (2026-09-26); reference verifier and conformance vectors published 2026-09-27; finality proven end to end on testnet 28001** | | Numbers are permanent and are never reused, including for withdrawn proposals @@ -72,16 +72,15 @@ at least seven valid seals per scheme of the ten validators, as many as the quor (AIP-22 stages 1 to 3, 2026-09-29 and 2026-09-30), and the per-message Falcon-512 enforcement: every validator refuses a commit without a seal, and the nine validators that run the primary, Besu-derived client refuse every QBFT message without one (heights 17,250,000 to 17,700,000, September 2026); the second, Nethermind-derived -client enforces commits since 18,131,633 and the other three message types since block 24,300,000 (AIP-22 stage 4, 2026-10-25). (Corrected 2026-10-09: until that date this line named the enforcement on every QBFT +client enforces commits since 18,131,633 and the other three message types since block 24,300,000 (AIP-22 stage 4, 2026-10-25). Since block 24,148,752 (AIP-22 stage R, 2026-10-24) every post-quantum commit seal is bound to its consensus round and every anchor certificate is v3, carrying that round; since block 25,080,000 (AIP-22 stage 5, 2026-10-30) headers no longer carry ECDSA commit seals, and each carries the Falcon-512 seal of its proposer. (Corrected 2026-10-09: until that date this line named the enforcement on every QBFT message without the second client's exception.) AIP-21's record is live on chain 2800 since 2026-09-22; AIP-20 is deployed and armed for 19,900,000. **Not live:** AIP-8 (needs a hard fork), AIP-15 as written (its testnet R&D form; what is live is the dated list above), AIP-16 (a skeleton that verifies nothing), -AIP-19 (a process change under review), AIP-22 from stage 5 (its stages 1 to 4 and stage R are live, above, stage R since block 24,148,752, 2026-10-24, and stage 4 since block 24,300,000, 2026-10-25; stage 5 runs on the public testnet 28001, and its height is not yet set on chain 2800; rule 4 of section 4, the provisional tail, is implemented in neither client). +AIP-19 (a process change under review), rule 4 of section 4 and stage 6 of AIP-22 (the provisional tail and its rollback, implemented in neither client, and the equivocation evidence of section 6, proven on the public testnet 28001 only; stages 1 to 5 and stage R are live, above, stage R since block 24,148,752, 2026-10-24, stage 4 since block 24,300,000, 2026-10-25, and stage 5 since block 25,080,000, 2026-10-30). -**Not claimed:** consensus whose safety does not depend on ECDSA. Aere consensus is -QBFT in which classical secp256k1 ECDSA is still a validity criterion on every block header (its commit seals), with the post-quantum layers above added to it (hybrid, never "post-quantum only"), and since block 24,300,000 (stage 4) a consensus message counts only through its verified post-quantum seal; AIP-22 is the design for removing that dependence: its stages 1 to 4 and stage R are live (above); rule 4 of section 4 and stages 5 and 6 are not. (Corrected 2026-10-09: until that date these two paragraphs said that AIP-22 +**Not claimed:** a post-quantum transport. Since block 25,080,000 (AIP-22 stage 5) headers on chain 2800 no longer carry ECDSA commit seals, and since block 24,300,000 (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; the transport between nodes (RLPx) is still authenticated by secp256k1, the ten validators are run by one operator, and no third party has audited it yet. Stages 1 to 5 and stage R of AIP-22 are live on chain 2800 (above); stage 6 and rule 4 of section 4 are not. (Corrected 2026-10-09: until that date these two paragraphs said that AIP-22 is design only and that nothing in it is implemented; its stages 1 to 3 have been live on chain 2800 since 2026-09-29 and 2026-09-30.) The precompiles `0x0AE6` and `0x0AE7` are testnet-only.