AIP-21/22: dated errata notes of 2026-10-07 (fixture seals, tail counting, checkpoint bound); nothing removed
This commit is contained in:
parent
2fe5a51bbd
commit
39ec3c684a
@ -279,6 +279,22 @@ local, so the record is read on the validator, or through Aere Cloud when that r
|
||||
block; and the agreement of the two clients on the same record. The remedy is the one the AIP-22 erratum proposes: a commit
|
||||
seal that binds the round, with a quorum of one round; it is a coordinated fork and is not scheduled.
|
||||
|
||||
- 2026-10-07, Errata entry of 2026-10-01 (the measurement it cites): in the fixture of `AereRoundFreeCertificateTest` validators
|
||||
0 to 8 are honest and X = 9 is a Byzantine validator that holds its own post-quantum key; the "seven valid Falcon-512 seals
|
||||
over `M(p)` from rounds 0 and 2" are the six honest seals of validators 0, 1, 2 (round 0) and 4, 5, 6 (round 2) plus X's own,
|
||||
and the anchor over `p` is judged in the regime of AIP-22 stage 5 (the header without the ECDSA commit quorum), which chain
|
||||
2800 has not activated. That seven honest validators can seal an undecided sibling with more round changes is derived from
|
||||
the QBFT rules, not run (AIP-22, Errata, 2026-10-01 and 2026-10-07). The two test classes named above, and
|
||||
`AereRoundFreeRestartTest` beside them, are in the reference client's working tree and not in the published patch set
|
||||
(`aere-node/patches/`, 0001 to 0008, checked 2026-10-07): they depend on the decided-head rule that reads a certificate as
|
||||
evidence of the anchor's grandparent (AIP-22, Errata, 2026-10-01), which is in code, deployed on no network and not published;
|
||||
they are to be published together with it. What the exception costs in rewrite depth against an adversary with every
|
||||
classical key and no post-quantum key is derived and machine-checked in
|
||||
`aere-research/research/rewrite-bound-round-free-seal-2026-10-07.md` and
|
||||
`aere-research/formal-consensus/anchor_rewrite_bound_roundfree_smt.py` (33 blocks since block 20,746,736 instead of 32; 13
|
||||
proofs, 8 negative controls). Nothing in the entry above is withdrawn by this one: the record of `aere_getPqFinality` means
|
||||
what that entry says it means.
|
||||
|
||||
## Post-Acceptance Outcome Record
|
||||
|
||||
Not accepted; nothing to record.
|
||||
|
||||
@ -223,11 +223,13 @@ Every activation height here is a coordinated fork: the same binary and the same
|
||||
|
||||
- **Threat model.** An adversary who holds every classical validator key and no post-quantum key (the posterior-corruption, long-range rewrite; peer-reviewed treatment of the threat: Azouvi, Danezis, Nikolaenko, "Winkle", IACR 2019/1440, AFT 2020; the quantum framing and this defence are Aere's own). "Harvest now, decrypt later" does not apply to signatures and is not what this AIP defends against.
|
||||
- **What this AIP achieves against that adversary, per height.** Today: cannot finalize a block online (message seals); can serve a syncing node a tail of up to 127 blocks that the next anchor invalidates. After `H_K` and `H_I`: the same, with the tail bounded at 31 blocks and every covering certificate a quorum. After `H_id`: cannot name a validator, vote, or propose in any set, even for a syncing node. After `H_fin`: cannot cause any node to consider any block final. After `H_hdr`: cannot produce a header that any node admits at all.
|
||||
- **Note added 2026-10-07 (how the tail is counted).** The bullet above counts the blocks above an anchor: "up to 127 blocks" for the 128-block interval in force when it was written, "31 blocks" for the 32-block interval; Motivation (1) ("up to 127 blocks") and the negative control of section 4 rule 4 ("a classical-only fork of up to 31 blocks") count the same way. `SPEC.md` 3.1 and the threat-model page ("at most 32 blocks") count the anchor block too: 32 and 128 for the same sets of blocks; the derivation below counts the anchor block because it is replaceable (its certificate is about its parent). With the exception of the Errata entry of 2026-10-01 (honest validators sealed an undecided sibling of the latest anchor's parent, at least as many of them as the node's effective threshold `K_eff`, since this adversary holds no post-quantum key), one block more can be replaced: 33 since block 20,746,736 and 129 in the dated 128-interval window (blocks 17,225,968 to 20,746,736, 2026-09-05 to 2026-09-29); the latest anchor's grandparent and everything below it are kept in every case. The derivation and its machine-checked model are `aere-research/research/rewrite-bound-round-free-seal-2026-10-07.md` and `aere-research/formal-consensus/anchor_rewrite_bound_roundfree_smt.py` (13 proofs with 8 negative controls; `--plant-bounds`, which lowers every claimed bound by one, fails exactly the ten bound proofs). The bound is stated for a node that holds the honest chain to its head, or a reference anchor (a recent anchor's height and hash): in both cases only the tail above the latest anchor's parent (grandparent, with the exception) is rewritable, and with a reference everything through it is kept whatever the length of the alternative; without one, a node syncing from genesis can be served a history that stops before an anchor, at any height, and cannot tell that the honest chain is longer (rule 5 of section 4 and the "Weak subjectivity" bullet below, read with this limit).
|
||||
- **What it does not achieve.** Node-to-node transport (RLPx) is authenticated by secp256k1; an adversary with node keys can impersonate a peer, not a validator. A post-quantum handshake (ML-KEM) is a separate AIP. Nothing here is audited by a third party; AIP-15's external-audit gate applies before `H_fin` on chain 2800. The set is ten validators operated by one party; this AIP changes what a key can do, not who holds the keys.
|
||||
- **Hybrid conjunction.** A certificate is valid only with the quorum of every required scheme; forging it needs both a lattice break (Falcon-512) and a hash-function break (SLH-DSA-SHA2-128s) at dual-assumption anchors, and a lattice break alone at the intermediate Falcon anchors. The single-assumption window is at most 32 blocks by design, and the founder can shorten it at the cost in the table.
|
||||
- **Liveness tax at K = Q.** With f validators down, an anchor needs every remaining seal to reach its proposer in time; a proposer without them skips by round change. The measured pre-AIP rate is 12 of 12 anchors at round 0; the post-AIP rate is a testnet gate. The threshold guard's warning text is the operator's acknowledgment of this trade.
|
||||
- **Rollback of a provisional tail.** New behaviour for a QBFT client, bounded at 32 blocks, exercised on the testnet with a negative control before any mainnet height. A bug here is a liveness bug on readers, never a safety bug: nothing becomes final without a certificate.
|
||||
- **Weak subjectivity.** Section 4, rule 5. A node without a checkpoint can be eclipsed onto a fork that ends before 13,034,000; with one, it cannot be made to accept a rewrite at any height.
|
||||
- **Correction added 2026-10-07 (to the bullet above).** "At any height" reads "at any height at or below the checkpoint", and so does "a rewrite at any height, including below 13,014,000" in rule 5 of section 4: a chain that diverges at or below the checkpoint is refused whatever its length (property P3b and witness C1b of the model named in the note above); above the checkpoint the bound of that note applies, with or without a checkpoint: at most 32 blocks (the latest anchor and the 31 after it; 33, the anchor's parent too, with the exception of the Errata entry of 2026-10-01). The checkpoint fixes where the rewritable tail can begin; it does not shorten it.
|
||||
- **Identity derivation.** Including the type byte and the algorithm identifier in the `id` pre-image (as AIP-20 does) closes "same bytes, different scheme" confusions; the `id` is not a proof of anything, the registry row is.
|
||||
- **Registry writer.** A registry epoch is produced by the Foundation and pinned on chain by a transaction from a Foundation key; a rogue epoch cannot bind a key to an existing `id` without that id's previous keys signing the rotation, and cannot add a row whose key does not prove possession. It can still add a new `id` with new keys, which is the power to add a validator, and that is the governance weakness the AIP-19 process names, unchanged here.
|
||||
- **Denial of service by seals.** Without the ECDSA authorship check, any connected peer can send messages that fail the Falcon check; each costs 0.068 ms to refuse and the per-peer limits of the client apply. This is the same surface the message layers already have since 17,700,000.
|
||||
@ -326,6 +328,22 @@ Two refinements to the text above, recorded rather than silently applied: the Me
|
||||
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.
|
||||
|
||||
- 2026-10-07, Errata entry of 2026-10-01 (the measurement it cites) and Security Considerations (the count of the tail; dated note
|
||||
there): (1) in the fixture of `AereRoundFreeCertificateTest` validators 0 to 8 are honest and X = 9 is a Byzantine validator
|
||||
that holds its own post-quantum key; the "seven valid Falcon-512 seals over `M(p)` from rounds 0 and 2" are the six honest
|
||||
seals of validators 0, 1, 2 (round 0) and 4, 5, 6 (round 2) plus X's own, and the anchor over `p` is judged in the regime of
|
||||
stage 5 (`H_hdr`, the header without the ECDSA commit quorum), which chain 2800 has not activated. That seven honest validators
|
||||
can seal an undecided sibling is, like the "up to ten seals" above, derived from the QBFT rules and not run. (2) The three test
|
||||
classes named above are in the reference client's working tree and not in the published patch set (`aere-node/patches/`, 0001
|
||||
to 0008, checked 2026-10-07): they depend on the decided-head rule that reads a certificate as evidence of the anchor's
|
||||
grandparent (the entry above), which is in code, deployed on no network and not published; they are to be published together
|
||||
with it. (3) What the exception costs against the adversary of Security Considerations is derived and machine-checked in
|
||||
`aere-research/research/rewrite-bound-round-free-seal-2026-10-07.md` and
|
||||
`aere-research/formal-consensus/anchor_rewrite_bound_roundfree_smt.py`: a rewrite of at most 33 blocks since block 20,746,736
|
||||
(the undecided sibling at the latest anchor's parent, the anchor, 31 blocks after it) and 129 in the dated 128-interval window,
|
||||
against 32 and 128 without the exception; the latest anchor's grandparent and everything below it are kept (13 proofs, 8
|
||||
negative controls, `--plant-bounds` fails exactly the ten bound proofs). Nothing in the entry above is withdrawn by this one.
|
||||
|
||||
## Post-Acceptance Outcome Record
|
||||
|
||||
Not accepted; nothing to record.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user