From 95435019dd9bbb6f658bade459cb24d284daa0da Mon Sep 17 00:00:00 2001 From: Aere Network Date: Thu, 1 Oct 2026 15:28:19 +0300 Subject: [PATCH] AIP-22 erratum 2026-10-01: the post-quantum commit seal carries no round, so a certificate of seals does not prove that the anchor's parent was decided Measured in the reference client: at N = 10, seven valid Falcon-512 seals over M(p) from rounds 0 and 2 while p' is decided in round 3, and an anchor over p carrying them passes the certificate rules. Withdrawn as written until the commit seal binds the round: the finality definition of section 1, the Rationale's implication that a quorum of seals proves consensus, and the Security Considerations claim for H_fin. Chain 2800 below stage 5 is not affected. The original text stays; the correction is dated in a note at the top and in the Errata. Co-Authored-By: Claude Opus 5.5 --- aips/AIP-22.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/aips/AIP-22.md b/aips/AIP-22.md index fc92dd3..13958fd 100644 --- a/aips/AIP-22.md +++ b/aips/AIP-22.md @@ -6,6 +6,11 @@ > stage 2 (Falcon-512 every 32nd block, SLH-DSA every 128th) from block 20,746,736, both on 2026-09-29, and stage 3 > (post-quantum validator ids in the header and in `qbft_getValidatorsByBlockNumber`) from block 20,836,228, on > 2026-09-30. Stages 4 and 5 (per-block post-quantum finality, the header without ECDSA) are not active on chain 2800. +> +> **Correction added 2026-10-01.** The post-quantum commit seal `M(B)` carries no round, and a certificate of seals over +> `M(parent(A))` does not prove that `parent(A)` was decided, for any number of seals. See the Errata entry of that date; +> it withdraws the finality definition of section 1 as written and three statements that rest on it. Chain 2800 today, +> below stage 5, is not affected: its headers still carry the ECDSA commit quorum of a single round. ## Preamble @@ -302,6 +307,25 @@ Two refinements to the text above, recorded rather than silently applied: the Me - 2026-09-24, section 9: the text said that conformance vectors "are published" with the reference implementation. No AIP-22 vector corpus is published yet; the sentence now says they are to be, and says what has been done instead (both clients checked against each other on chain 28001 at every stage). - 2026-09-25, section 5: the text admitted a header's proposer seal only for the `coinbase`'s `id`. A block prepared in one round and re-proposed unchanged in a later one keeps its builder's `coinbase` and carries the later round's proposer's seal, and every node refused it (stage record of 2026-09-25). Corrected in place in the working text on 2026-09-25; the published text carried the old rule until 2026-09-27 (stage record of that date). +- 2026-10-01, sections 1, 4 and 6, Rationale and Security Considerations: the post-quantum commit seal is made over + `M(B) = keccak256(RLP["AERE-PQ-COMMIT-1", chainId, number(B), hash(B)])`, which has no round. In QBFT an honest validator can + commit a block `p` in one round while a different block `p'` is decided in a later round (the round-change justification + does not need every honest lock to be in its quorum), and seals over `M(p)` made in different rounds cannot be told apart. + Measured on 2026-10-01 in the reference client (test classes `AereRoundFreeCertificateTest`, `AereRoundFreeRestartTest`, + `AereRoundFreeCommitTest`): at N = 10, seven valid Falcon-512 seals over `M(p)` from rounds 0 and 2, `p'` decided in round 3, + and an anchor over `p` carrying those seven seals passes the certificate rules; the same holds up to ten seals with more + round changes (derived, not run). Withdrawn as written, until the commit seal binds the round: (1) the definition of + post-quantum finality in section 1, which takes a certificate of `Q` seals over `M(parent(A))` as proof that `parent(A)` + is final; what such a certificate does prove, when every honest validator runs the clients' decided-head rule, is that + the anchor's grandparent was decided; (2) the Rationale's "below the quorum the certificate proves participation, not + consensus", which implies that at the quorum it proves consensus; (3) in Security Considerations, "after `H_fin`: cannot + cause any node to consider any block final": from `H_fin` the author of a commit is taken from its post-quantum seal and + the round is bound only by the ECDSA commit seal, which the adversary of that section holds. Not affected: chain 2800 below + stage 5 (every header carries the ECDSA commit quorum of one round), the anchor certificate as evidence of participation, + and the message-layer seals, which carry the round. On testnet 28001, where stage 5 is active, the `finalized` tag can name + a block no round decided; not exercised as an attack. The remedy proposed is a commit seal that binds the round, with a + certificate of `Q` seals of one round; it is a coordinated fork and is not scheduled. + ## Post-Acceptance Outcome Record Not accepted; nothing to record.