AIP-22: dated correction to rule 3 of section 4 (one path of the second client until 2026-10-31 12:27Z), Errata entry 2026-11-01

aips/AIP-22.md

@@ -194,6 +194,8 @@ From `H_fin` (a height at or above `H_id`), on every node that validates or read
 
 **Correction added 2026-10-26 (to rule 2 above).** On chain 2800 since block 24,300,000 both clients still apply the upstream rule to every header below `H_hdr`: it must carry at least Q ECDSA committed seals of one round of the parent's set, and a header that does not is refused (the Besu-derived client through `PqHeaderSealRule`, which below `H_hdr` is the upstream `BftCommitSealsValidationRule`; the Nethermind-derived client in `QbftHeaderValidator`). This is the admission filter that the second sentence of rule 2 allows until section 5, and its failure is a refusal, so in effect it is still a validity criterion: the first sentence of rule 2 ("is no longer applied to headers at or above `H_fin`") does not describe the stage-4 binaries. Because rule 4 is not implemented either (note of 2026-10-25 at the top of this document), a header admitted on those seals is final on import, as before; its post-quantum proof is the anchor that covers it. What `H_fin` changed is rule 3: the author of every consensus message is taken only from its verified post-quantum seal, on both clients and all four message types. Rule 2 above is kept as it was written.
 
+**Correction added 2026-11-01 (to rule 3 above).** Until 2026-10-31 12:27Z the second client on chain 2800 derived the author of a proposal at the height named in its payload and then routed and voted on the block by the block's own number, without requiring the two to be equal. For a payload height below `H_fin` that author is the ECDSA envelope signer, so on that path rule 3 did not hold in the second client. The primary client was not exposed: it drops a message by its payload height before relaying it and requires the block number to equal that height. A commit on a false block was not possible on either client, because prepares are counted by the payload height and carry post-quantum seals; the reachable effect was a lost or silenced vote of the second client's validator. Exploitation was not measured. Since 2026-10-31 12:27Z the second client running on chain 2800 refuses at decoding, before authorship and before relay, any proposal whose block number differs from its payload height, and the same for the prepared block of a round-change; it also bounds a round-change's target round to [1, 1000] and its prepared round to [0, target), as the primary client does.
+
 ### 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, 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.)
@@ -422,6 +424,8 @@ Two refinements to the text above, recorded rather than silently applied: the Me
 
 - 2026-11-01, the notes of 2026-10-27 and 2026-10-28 under section 5 and the Errata entries of those dates: the identifier of an internal register entry, by which they named the per-author message quotas, is replaced by that name; nothing else in those sentences changed.
 
+- 2026-11-01, section 4, rule 3: on chain 2800 the rule did not hold on one path of the second client until 2026-10-31 12:27Z (a proposal's author taken at its payload height while the block was handled at its own number, with no check that they are equal); a dated correction under section 4 says what, why the primary client was not exposed, and what the second client refuses since then.
+
 ## Post-Acceptance Outcome Record
 
 Not accepted; nothing to record.