From c5cef2821f319830ac12289917aa6b628a812431 Mon Sep 17 00:00:00 2001 From: Aere Network Date: Thu, 24 Sep 2026 01:17:07 +0300 Subject: [PATCH] AIP-22: section 5 made exact (the certificate slot is present when the proposer seal is; the rule judges every header from H_hdr); stage 5 rehearsed, armed and proven on testnet 28001 --- aips/AIP-22.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/aips/AIP-22.md b/aips/AIP-22.md index 8eefde2..f526f42 100644 --- a/aips/AIP-22.md +++ b/aips/AIP-22.md @@ -159,7 +159,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 the hash (like the commit seals and the certificate), present only when non-empty, and subject to the strict codec. From `H_hdr` a header is admitted between anchors iff the proposer seal verifies for the `coinbase` `id` at that height, and the ECDSA committed seals element MUST be empty. 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 for the `coinbase` `id` at that height, over the round in element 3; an anchor is judged by the anchor rule as well. 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. ### 6. Equivocation evidence and consequences without stake @@ -253,6 +253,10 @@ Activation heights on chain 2800 are the founder's (AIP-19 acceptance per stage) **2026-09-23 19:40Z, stage 4 proven on testnet 28001 (H_fin = 3,117,000).** Over [H_fin - 1, H_fin + 500]: H_fin armed in the environment of all six nodes (five of five Besu-derived, one of one Nethermind-derived; positive control on the same read, the H_k property, five of five and one of one); both clients held identical hashes for all 502 blocks; all five ids proposed (101, 100, 100, 100, 100 blocks), so every validator's proposals and votes, the Nethermind-derived validator's included, have an author in the other client; the rhythm was 0.568 s per block before and 0.566 after (ratio 0.996); at the crossing itself the 60 blocks after H_fin took 33 s against 35 s for the 59 before. NEGATIVE CONTROL OF THE METHOD: the same measures on the known-bad window [3,080,010, 3,080,510] (the second defect at H_id, four proposers) come out red (four proposers, ratio 2.741), and the proof refuses to speak (NOT MEASURED) unless H_fin is armed on all six nodes, which it would otherwise have reported as proven on a window without the stage. Not measured, and stated: a forged message on the network (no testnet node can inject one; its refusal is proven by the probes and negative controls in both clients and by the shared vectors). +**2026-09-23 20:31-21:17Z, stage 5 (ECDSA out of the header) rehearsed on a chain of our own from genesis, a defect of the second client found by the rehearsal, and the stage armed on testnet 28001 for H_hdr = 3,131,000.** Built in both clients to section 5 as now worded: element 6 `[index, signature]`, the certificate slot present as an empty list when element 6 is and no certificate is, both outside both hashes; the proposer seal is the seal of the proposal message, so every node writes the same header; the header rule replaces the committed-seals rule from H_hdr; `AERE-PQC-HDR-01` refuses H_hdr below H_fin and `AERE-PQC-HDR-02` refuses to seal without the proposal's seal. Probes: in the Besu-derived client the codec, both hashes, admission and each refusal by its reason (three modules 1,143 tests, 0 failures; negative controls planted at run time "ECDSA seals not refused", "every proposer seal verifies", "any index for any coinbase", each red); in the Nethermind-derived client the same cases with probe Falcon-512 keys (39 tests). Rehearsal on chain 28099 (one validator, a Besu-derived and a Nethermind-derived reader, the fleet's full configuration on small heights, H_fin = 600, H_hdr = 700): the Besu-derived nodes crossed H_hdr with 601 of 601 headers in the new form, and the Nethermind-derived reader REFUSED block 700 with an empty reason. Its import verdict (`IsValid`) still required a quorum of ECDSA seals while the refusal reason followed the new rule, and its probes asserted only the reason. On testnet 28001 its validator would have refused at H_hdr the blocks of every other validator and its own. Repaired so that the reason and the verdict come from one value; the probes now assert the verdict the import path returns, and a new negative control that puts the old verdict back turns them red. Second pass, the repaired binary: the Nethermind-derived reader synced from genesis across H_hdr, 2,064 headers in the new form, 65 anchors (17 hybrid), identical hashes on all three nodes. Negative control on the network: a reader started WITHOUT H_hdr does not follow the chain. The Besu-derived one stops exactly at 699 with the old rule's reason ("Insufficient committers to seal block"); the Nethermind-derived one judges headers in batches and stops at the end of the previous batch (511), refusing only headers at or above 700. The public verifier was updated and published before the testnet height (aere-node ab90cc5 and the site): its default mode counted extraData elements to find certificates and would have failed on every stage-5 header. Armed on 28001: the Nethermind-derived validator on a binary built on its host that loses no module of the live one (21:08Z, five peers, kept pace for 90 s), then the five Besu-derived nodes on a distribution that loses no class of the live one (one added), one at a time with cooling, each logging "H_hdr armed at 3131000" and importing an anchor before the next (21:17Z). Not measured by the rehearsal (one validator), and stated: a forged header sent by an adversary (its refusal is proven by the planted controls in both clients) and headers of a set whose validators run both clients, which the testnet proof measures. + +**2026-09-23 22:05Z, stage 5 proven on testnet 28001 (H_hdr = 3,131,000).** At the crossing (21:48Z) the five proposers kept their turns on both sides (12 x 5 before, 13, 12, 12, 12, 12 after), 35 s for the 59 blocks before and 33 s for the 60 after, extraData from 416 to 812 bytes, zero refusals in either client. The rare case was provoked from outside: one Besu-derived validator restarted after H_hdr, and two blocks were finalized at round 1 (3,131,097 and 3,131,101), with the same hash in both clients. Over [H_hdr - 1, H_hdr + 500]: H_hdr armed in the environment of all six nodes (positive control on the same read, H_fin, six of six); both clients held identical hashes for all 502 blocks; read from the bytes, all 501 headers from H_hdr have an empty ECDSA seal element, seven elements, a proposer seal `[index, Falcon-512 signature]`, an empty certificate slot between anchors and a certificate at each of the 16 anchors, and the five coinbases map one-to-one onto five indexes (positive control of the decoder: the 64 headers below H_hdr carry at least four ECDSA seals and no element 6); the extraData of all 501 blocks is byte-identical between the two clients, so each writes the same canonical encoding (control of the method: 8 of the 40 blocks below H_hdr differ between clients, as locally gathered ECDSA seals legitimately do); all five ids proposed (101, 101, 100, 100, 99), the rhythm was 0.567 s per block before and 0.594 after, ratio 1.048 with the provoked restart inside the window; the published verifier in its default mode verified 15 of 15 anchors after H_hdr, while its previous form fails on the same chain ("the two most recent anchors are 1 apart"). NEGATIVE CONTROL OF THE METHOD: the proposer and rhythm measures on the known-bad window [3,080,010, 3,080,510] come out red (four proposers, ratio 2.741). A first run of the proof reported a failure of step 4 that belonged to the proof, not to the chain: it copied the verifier without `registry-v3.mjs`, which the verifier loads on a chain with v3 epochs; the harness now copies every module published beside the tool. Not measured, and stated: a forged header sent on the network (no testnet node can inject one; its refusal is proven by the planted controls in both clients). + **2026-09-23, stage 3 foundation: the registry v3 forms, pinned.** Section 3.2 names a "canonical serialization"; the bytes are now fixed, identically, in the Besu-derived client (`PqRegistryV3`), the Nethermind-derived client (`PqRegistryV3`) and a third, independent JavaScript implementation, and pinned by 19 shared conformance vectors (two valid epochs, the second rotating one validator's keys under its id; seventeen refusals, each differing from a valid manifest in one field with the signatures re-made over that field, one per refusal code `AERE-PQC-REG3-01` to `-16`): ```