diff --git a/aips/AIP-13.md b/aips/AIP-13.md index 6d40b0c..7152fd3 100644 --- a/aips/AIP-13.md +++ b/aips/AIP-13.md @@ -1,5 +1,7 @@ # AIP-13: Post-Quantum Signatures: Falcon and ML-DSA Together, not a Single Lattice Family +> **Note added 2026-10-27 (consensus).** Where this document says that consensus remains classical (validators sign secp256k1 QBFT), read it as the 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 commit still carries the ECDSA commit seal of its validator as an additional check; headers are still admitted on their ECDSA commit seals until AIP-22 stage 5, and Aere does not claim post-quantum consensus. The decision this document records, two lattice families plus hash-based schemes, is unchanged. + ## Preamble | Field | Value | diff --git a/aips/AIP-22.md b/aips/AIP-22.md index cbf7600..aeb1109 100644 --- a/aips/AIP-22.md +++ b/aips/AIP-22.md @@ -173,6 +173,8 @@ Loading is strict, as today: `count` present, indices exactly `0..count-1`, ever | genesis of a new chain | validators are ECDSA addresses | validators are `id`s and `pqRegistryHash` names a v3 registry with `bindHeight 0`; the genesis set is then post-quantum from block 0 and the `ecdsa` field is never needed | | history | | a from-genesis node judges sets below `H_id` by addresses and above it by `id`s, with the registry history list (never pruned, SPEC 3.2) providing every epoch | +**Note added 2026-10-27 (to the row "message authorship" of the table above).** From `H_fin` (block 24,300,000 on chain 2800) rule 3 of section 4 governs this row: the envelope is not examined for authorship, so the clause "its recovered address MUST equal `row.ecdsa.addr` while that field exists in the head registry" no longer applies, although every row of the head registry of chain 2800 (epoch v3 bound at 20,836,228) still carries `ecdsa.addr` (read 2026-10-27 from `pq/manifests/registry-v3-20836228.json`). The row is kept as it was written. + #### 3.4 Peer forwarding The Besu-derived client forwards Istanbul messages only to peers whose RLPx node-key address is in the validator set (measured 2026-09-02 on testnet 28001: a validator whose node key differed from its validator key received no consensus messages). With `id`s in the set, that predicate has no ECDSA address to match. From `H_id` a client MUST forward to every peer that (a) has negotiated the Istanbul capability and (b) either presents a node-key address listed as `transport.secp256k1Address` in a row of the head registry whose `id` is in the set, or, when no row lists a transport address, is any connected peer with the capability. Node identity on RLPx remains secp256k1 ECDSA; this AIP does not change the transport (Security Considerations). @@ -196,6 +198,8 @@ From `H_hdr` (at or above `H_fin`), `extraData` gains element 6, `proposerSeal = **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. +**Note added 2026-10-27 (to the correction above).** The correction says that one consensus message still carries ECDSA. Every consensus message still carries the ECDSA envelope of the upstream wire format, and both clients judge its form, though not its author: the Besu-derived client requires a low s (`SignedData`), and the Nethermind-derived client refuses a message whose envelope does not recover (`BesuQbftWire.Recover`). The D-454 quotas also classify a message by the key that signed its envelope. What the correction says of the commit seal is unchanged. The correction is kept as it was written. + ### 6. Equivocation evidence and consequences without stake **Evidence object.** `PqEquivocation = [type, height, round, payloadA, sealA, payloadB, sealB, registryProof]` where `type` is one of the four message domains, the two payloads are the upstream RLP payloads of two messages of that type at the same height and round with different digests (for round-change, different `prepared digest` at the same target round), the seals are the two Falcon-512 seals of the same index over the respective pre-images of SPEC 2.6, and `registryProof` is the v3 Merkle path of that index's row in the epoch bound at `height`. The object is valid iff both seals verify under the row's Falcon key, the index is the same, and the digests differ. A second form, `PqConflictingAnchors = [anchorHeaderA, anchorHeaderB, registryProofs]`, two anchor headers at the same height with different parent hashes and each with a valid certificate of at least Q seals: by the quorum-intersection bound proved for all N in `formal-consensus/qbft_safety_smt.py` (L1: `2Q - N >= f + 1`), the two certificates share at least f + 1 = 4 indexes at N = 10, each of which double-signed. This is accountable safety: a finality violation names its authors by their post-quantum seals, and it needs `K = Q` (section 2), which is one more reason for that step. @@ -258,6 +262,7 @@ Every activation height here is a coordinated fork: the same binary and the same - **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. + **Erratum added 2026-10-27.** Two parts of this sentence do not hold as written. (1) Neither client's consensus layer bounds the messages of one peer: what bounds them today is deduplication on bytes, the total event queue of the Besu-derived client (1,000), the future-message buffer (per author and in total), the frame size and the RLP limits, and none of these bounds the refused messages of one peer; whether the devp2p layer below bounds a peer's istanbul messages is not measured. (2) A refusal does not cost one verification: a proposal may nest up to 512 messages in each of its two justification lists and the Besu-derived client verifies all of them while decoding, so a forged proposal can cost about 1,025 Falcon-512 verifications; the Nethermind-derived client verifies a carrier twice (relay and handler); a forged commit costs ECDSA recovery only. The cost per message type on the validator machines is not measured. The sentence is kept as it was written. ## Reference Implementation and On-Chain Deployment @@ -407,6 +412,8 @@ Two refinements to the text above, recorded rather than silently applied: the Me whose height is not set there). Chain 2800 is not affected: no evidence contract is deployed there and its commit seal is still COMMIT-1 (the round-bound height is not set). +- 2026-10-27, section 3.3, section 5 and Security Considerations: three dated notes. The row "message authorship" of table 3.3 required the envelope's recovered address to equal `row.ecdsa.addr` while that field exists; from `H_fin` the envelope is not examined for authorship. The correction of 2026-10-25 to section 5 named the commit seal as the one classical element of consensus messages; every message still carries the ECDSA envelope, whose form both clients judge and by whose signer the D-454 quotas classify. "Denial of service by seals" said that the per-peer limits of the clients apply and that a refusal costs 0.068 ms; neither client's consensus layer bounds one peer, and a forged proposal can cost about 1,025 Falcon-512 verifications. Found by an adversarial review of the draft that removes ECDSA from consensus messages. + ## Post-Acceptance Outcome Record Not accepted; nothing to record. diff --git a/aips/AIP-7.md b/aips/AIP-7.md index 366fde5..271e5b0 100644 --- a/aips/AIP-7.md +++ b/aips/AIP-7.md @@ -1,5 +1,7 @@ # AIP-7: AerePQC Hard-Fork Activation (Native PQC Precompiles and Extended EIP-2935 Lookback) +> **Note added 2026-10-27 (consensus).** Where this document says that AERE consensus is classical secp256k1 ECDSA QBFT and not post-quantum, read it as the 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 commit still carries the ECDSA commit seal of its validator as an additional check; headers are still admitted on their ECDSA commit seals until AIP-22 stage 5, and Aere does not claim post-quantum consensus. What this document records, a fork that changed the execution layer only, remains true. + ## Preamble | Field | Value | diff --git a/execution-kernel/MACHINE-INTERFACE-CONTRACT.md b/execution-kernel/MACHINE-INTERFACE-CONTRACT.md index 569d265..b5e57ec 100644 --- a/execution-kernel/MACHINE-INTERFACE-CONTRACT.md +++ b/execution-kernel/MACHINE-INTERFACE-CONTRACT.md @@ -1,7 +1,9 @@ # MachineInterface (MI) contract, Execution Kernel treapta 1 -Chain 2800 (AERE). Written 2026-08-15, the day the post-quantum consensus milestone went -live at block 14,050,000. This is the seam for interface **I3** in +Chain 2800 (AERE). Written 2026-08-15 (Corrected 2026-10-27: this line said it was written the day +the post-quantum consensus milestone went live at block 14,050,000; that claim was withdrawn on +2026-08-19, nothing changed at that height, see https://aere.network/docs/network/forks.html). +This is the seam for interface **I3** in `aerenew/strategie/EXECUTION-KERNEL-2026-08-15.md`. This document is a **contract**, not an implementation. Treapta 1 adds no new infrastructure. @@ -145,7 +147,8 @@ both directions (section 7). Two MI results for the same input are equal when, a Determinism is a claim about these commitments, not about internal representation. Two clients may lay out their trie nodes differently in memory, name their threads differently, and store `extraData` differently for the same block (QBFT lets each node assemble the final header -locally, and the block hash does not cover the seals; see `CLAUDE.md`). None of that is an MI +locally, and the block hash does not cover the seals; see aere-node `SPEC.md`, section 2.3; corrected +2026-10-27: this pointed to a file that is not public). None of that is an MI input or output. Only the commitments above are. **Determinism is measured across implementations, not asserted from one.** A single client diff --git a/formal-consensus/RULEAZA-TOT.md b/formal-consensus/RULEAZA-TOT.md index ed48614..b823aa5 100644 --- a/formal-consensus/RULEAZA-TOT.md +++ b/formal-consensus/RULEAZA-TOT.md @@ -75,11 +75,14 @@ on the delivery of messages between groups) and checks it exhaustively at N=4. S ### The run (much faster under Linux, or WSL on Windows, than natively on Windows) Write a script, copy it, run it without inline quotes. Every run uses `-deadlock`, because the protocol TERMINATES -normally (everyone has decided) and termination is not a defect: +normally (everyone has decided) and termination is not a defect. The models are in the development tree only: the TLA+ +results below cannot be rerun from the public repositories today (corrected 2026-10-27: the script asked for the root of +your clone, where `formal-tla/` does not exist): ```bash # copy the directory outside any mounted Windows drive (a faster run) -AERE_REPO=/path/to/the/clone # the root of your clone; the formal-tla/ directory sits directly under it +AERE_REPO=/path/to/the/development/tree # formal-tla/ is not in the public aere-research repository, so this run + # cannot be reproduced from a public clone today mkdir -p /root/ftla cp -f "$AERE_REPO"/formal-tla/*.tla /root/ftla/ cp -f "$AERE_REPO"/formal-tla/*.cfg /root/ftla/