aere-network/aere-research
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

AIP-22 stage R and stage 4 in force on chain 2800 (2026-10-24, 2026-10-25): dated corrections to the README, pq-stark README and AIP index (votes attributed only through verified post-quantum seals since block 24,300,000; headers still admitted on ECDSA commit seals until stage 5), AIP-1 and CONTRIBUTING editorial rules corrected with their date, AIP-22 dated correction to rule 2 of section 4, AIP-3 interval dated

Browse Source
This commit is contained in:
Aere Network 2026-10-26 06:27:26 +02:00
parent 4c4d57cd2c
commit 0bf80e42fe
6 changed files with 31 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
README.md
View File

@ -14,8 +14,7 @@ Falcon-1024 (`0x0AE2`), ML-DSA-44 (`0x0AE3`), SLH-DSA-128s (`0x0AE4`) and SHAKE2
have been live as precompiles since block 9,189,161. You can call them yourself against have been live as precompiles since block 9,189,161. You can call them yourself against
`https://rpc.aere.network` without asking us for anything. `https://rpc.aere.network` without asking us for anything.
**Consensus on chain 2800 is classical secp256k1 ECDSA QBFT on every block, with a post-quantum **Consensus on chain 2800 is QBFT, with a post-quantum checkpoint every 32 blocks; since block 24,300,000 (AIP-22 stage 4) every validator attributes each consensus vote only through the verified post-quantum seal of its author (headers are still admitted on their ECDSA commit seals until AIP-22 stage 5).** Since block 13,014,000 anchor blocks carry, under the block hash, a
checkpoint every 32 blocks.** Since block 13,014,000 anchor blocks carry, under the block hash, a
certificate of validator post-quantum seals (Falcon-512, with SLH-DSA-SHA2-128s as well since certificate of validator post-quantum seals (Falcon-512, with SLH-DSA-SHA2-128s as well since
2026-09-04, at every 128th block since 2026-09-29; every anchor was 128 blocks apart from block 2026-09-04, at every 128th block since 2026-09-29; every anchor was 128 blocks apart from block
17,225,968 to block 20,746,736). Since block 20,715,632 (2026-09-29) a node rejects an anchor block 17,225,968 to block 20,746,736). Since block 20,715,632 (2026-09-29) a node rejects an anchor block

18
aips/AIP-1.md
View File

@ -235,9 +235,15 @@ correctly formed is not the same person deciding whether the idea wins.*
- Every number carries its provenance: **measured**, **spec**, or **estimate**. - Every number carries its provenance: **measured**, **spec**, or **estimate**.
- Design ceilings (a theoretical maximum throughput) are never presented as - Design ceilings (a theoretical maximum throughput) are never presented as
measured throughput. measured throughput.
- Aere consensus is classical secp256k1 ECDSA QBFT. No AIP claims or implies - Aere consensus is QBFT on chain 2800: anchor blocks carry a post-quantum
post-quantum consensus. Post-quantum applies to signatures, accounts and certificate under their hash since block 13,014,000, and since block
applications only. 24,300,000 (AIP-22 stage 4) a consensus vote counts only with the verified
post-quantum seal of its author (headers still carry ECDSA commit seals until
AIP-22 stage 5). No AIP claims or implies post-quantum consensus without the
limits it states. Post-quantum also applies to signatures, accounts and
applications (this rule corrected on 2026-10-26: until that date it said that
Aere consensus is classical secp256k1 ECDSA QBFT and that post-quantum applies
to signatures, accounts and applications only).
### 10. Where AIPs live ### 10. Where AIPs live
@ -282,8 +288,10 @@ AIP carries the label **"Foundation-ratified (pre-decentralization)"** so that n
reader mistakes editorial ratification for trustless governance. reader mistakes editorial ratification for trustless governance.
The intended migration, each step its own Meta AIP: (1) open the validator set The intended migration, each step its own Meta AIP: (1) open the validator set
beyond the current seven Foundation-operated validators and run a second client beyond the Foundation-operated validators and run a second client as a live
as a live producer; (2) introduce a public review period the Foundation cannot producer (seven validators when this was written; ten since 2026-09-11, the
tenth running the second client, which produces blocks; this clause corrected
on 2026-10-26); (2) introduce a public review period the Foundation cannot
unilaterally shorten; (3) move ratification to stake-weighted or unilaterally shorten; (3) move ratification to stake-weighted or
validator-weighted approval once an independent staker and validator base exists. validator-weighted approval once an independent staker and validator base exists.

2
aips/AIP-22.md
View File

@ -186,6 +186,8 @@ From `H_fin` (a height at or above `H_id`), on every node that validates or read
5. **Weak subjectivity, named.** A node that syncs from genesis with no other knowledge can be served, by an eclipsing peer, a fork that ends before the first enforced anchor (block 13,034,000, where the certificate schedule first required a seal); such a fork can never carry a later certificate and so can never reach the height of the honest chain, but an eclipsed node does not know that height. A syncing node therefore SHOULD be given a recent anchor (height and hash) out of band, from the published registry epoch or from the operator, and MUST refuse to consider a chain canonical that does not reach it with valid certificates. This is the same requirement every finality-gadget chain has, and it is the honest replacement for the statement "history below H is protected by ECDSA only": with the checkpoint, a rewrite at any height, including below 13,014,000, would have to reproduce every certificate above it, and the strongest of those requires Q post-quantum keys. 5. **Weak subjectivity, named.** A node that syncs from genesis with no other knowledge can be served, by an eclipsing peer, a fork that ends before the first enforced anchor (block 13,034,000, where the certificate schedule first required a seal); such a fork can never carry a later certificate and so can never reach the height of the honest chain, but an eclipsed node does not know that height. A syncing node therefore SHOULD be given a recent anchor (height and hash) out of band, from the published registry epoch or from the operator, and MUST refuse to consider a chain canonical that does not reach it with valid certificates. This is the same requirement every finality-gadget chain has, and it is the honest replacement for the statement "history below H is protected by ECDSA only": with the checkpoint, a rewrite at any height, including below 13,014,000, would have to reproduce every certificate above it, and the strongest of those requires Q post-quantum keys.
6. **Fallback and crypto-agility.** The schemes required at an anchor are named by the scheme-interval schedule, by height; the keys are bound by the registry epoch, by height; the on-chain scheme registry (`CryptoRegistry`, AIP-4 and AIP-7) names what verifiers exist. Retiring a scheme, adding one (ML-DSA-65 keys would be a founder ceremony: new keys), or changing an interval is a schedule step at a future height on every node that judges headers, the procedure the fleet has executed for the base-fee floor, the seal threshold, the hybrid, the interval and the four message layers. Because the hybrid rule is a conjunction, a scheme that is *broken* does not weaken the certificate (the adversary still needs the other); a scheme whose *implementation* stops producing seals halts anchors, and the answer is a uniform schedule step or the existing uniform emergency options, never a single node's setting. 6. **Fallback and crypto-agility.** The schemes required at an anchor are named by the scheme-interval schedule, by height; the keys are bound by the registry epoch, by height; the on-chain scheme registry (`CryptoRegistry`, AIP-4 and AIP-7) names what verifiers exist. Retiring a scheme, adding one (ML-DSA-65 keys would be a founder ceremony: new keys), or changing an interval is a schedule step at a future height on every node that judges headers, the procedure the fleet has executed for the base-fee floor, the seal threshold, the hybrid, the interval and the four message layers. Because the hybrid rule is a conjunction, a scheme that is *broken* does not weaken the certificate (the adversary still needs the other); a scheme whose *implementation* stops producing seals halts anchors, and the answer is a uniform schedule step or the existing uniform emergency options, never a single node's setting.
**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.
### 5. ECDSA out of the header ### 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 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, 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 or is examined in any consensus message; the last classical use is the RLPx transport.

12
aips/CONTRIBUTING.md
View File

@ -78,9 +78,15 @@ The rules that get proposals bounced fastest:
fixture), **spec** (a configured or standardized value), or **estimate**. fixture), **spec** (a configured or standardized value), or **estimate**.
- **Write "to be measured"** rather than guessing. A guessed gas figure is worse - **Write "to be measured"** rather than guessing. A guessed gas figure is worse
than an absent one, because the reader cannot tell it is a guess. than an absent one, because the reader cannot tell it is a guess.
- **Do not claim post-quantum consensus.** Aere consensus is classical secp256k1 - **Do not claim post-quantum consensus without its limits.** On chain 2800
ECDSA QBFT. Aere's post-quantum work is at the signature, account and anchor blocks carry a post-quantum certificate under their hash since block
application layers. A proposal that blurs this will be sent back. 13,014,000, and since block 24,300,000 (AIP-22 stage 4) a consensus vote
counts only with the verified post-quantum seal of its author (headers still
carry ECDSA commit seals until AIP-22 stage 5); the transport between nodes is
still secp256k1. Aere's post-quantum work is also at the signature, account
and application layers. A proposal that blurs this will be sent back (this
rule corrected on 2026-10-26: until that date it said that Aere consensus is
classical secp256k1 ECDSA QBFT).
### Step 2: submit it ### Step 2: submit it

9
aips/README.md
View File

@ -46,7 +46,7 @@ document is current.
| [19](./AIP-19.md) | AIP Process Hardening | Meta | **Review, not ratified** | | | [19](./AIP-19.md) | AIP Process Hardening | Meta | **Review, not ratified** | |
| [20](./AIP-20.md) | Native Post-Quantum Transactions (Type 0x50, ML-DSA Authorization) | Standards Track / Core | **Draft, not ratified; implemented in both clients and proven conformant on shared vectors (2026-09-17); live on testnet 28001 from block 2,212,000 (first type-0x50 transaction at 2,212,032, both clients); on chain 2800 the implementation runs on every node since 2026-09-22 and is armed, uniformly, for block 19,900,000 (per-node property, not a genesis change); no type-0x50 transaction on chain 2800 before that height** | | | [20](./AIP-20.md) | Native Post-Quantum Transactions (Type 0x50, ML-DSA Authorization) | Standards Track / Core | **Draft, not ratified; implemented in both clients and proven conformant on shared vectors (2026-09-17); live on testnet 28001 from block 2,212,000 (first type-0x50 transaction at 2,212,032, both clients); on chain 2800 the implementation runs on every node since 2026-09-22 and is armed, uniformly, for block 19,900,000 (per-node property, not a genesis change); no type-0x50 transaction on chain 2800 before that height** | |
| [21](./AIP-21.md) | Verifiable Post-Quantum Finality per Block (Side Store, Proof RPC, Anchor as Permanent Record) | Standards Track / Interface (non-consensus) | **Draft, not ratified; first half (retention window + `aere_getPqFinality`) implemented in the Besu-derived client with 7 tests and deployed on testnet 28001 (5 nodes, public door `testnet-rpc.aere.network/finality`) on 2026-09-18; Nethermind port the same day (10 tests) and deployed on the testnet Nethermind validator with its own public door; two-client conformance proven live (`aip21-conformitate/DOVEDESTE.sh`, CONFORM on block 2,250,809); second half (the window on disk, same journal format in both clients) deployed on all six testnet nodes the same day: the window survives a restart in both (1,284 and 1,255 seals re-verified, 0 failed), and a round-1 block is `post-quantum` in both on the same hash (CONFORM 08:49Z, block 2,285,481 and round-1 block 2,285,333); on chain 2800 since 2026-09-22 on all ten validators and both clients (`aere_getPqFinality` answers `post-quantum` with 10 of 10 seals re-verified; dated record at the end of AIP-21)** | | | [21](./AIP-21.md) | Verifiable Post-Quantum Finality per Block (Side Store, Proof RPC, Anchor as Permanent Record) | Standards Track / Interface (non-consensus) | **Draft, not ratified; first half (retention window + `aere_getPqFinality`) implemented in the Besu-derived client with 7 tests and deployed on testnet 28001 (5 nodes, public door `testnet-rpc.aere.network/finality`) on 2026-09-18; Nethermind port the same day (10 tests) and deployed on the testnet Nethermind validator with its own public door; two-client conformance proven live (`aip21-conformitate/DOVEDESTE.sh`, CONFORM on block 2,250,809); second half (the window on disk, same journal format in both clients) deployed on all six testnet nodes the same day: the window survives a restart in both (1,284 and 1,255 seals re-verified, 0 failed), and a round-1 block is `post-quantum` in both on the same hash (CONFORM 08:49Z, block 2,285,481 and round-1 block 2,285,333); on chain 2800 since 2026-09-22 on all ten validators and both clients (`aere_getPqFinality` answers `post-quantum` with 10 of 10 seals re-verified; dated record at the end of AIP-21)** | |
| [22](./AIP-22.md) | Post-Quantum-Only Finality (Chained Quorum Certificates, PQ Validator Identity, ECDSA Demoted to Compatibility) | Standards Track / Core | **Draft, not ratified; a design only on 2026-09-23; stages 1 to 6 then proven on testnet 28001 in both clients (2026-09-23 to 2026-09-25, stage records in the AIP); conformance corpus of all nine kinds published 2026-09-27 (`aip22-conformance/`); on chain 2800 stages 1 to 3 active from blocks 20,715,632, 20,746,736 and 20,836,228 (2026-09-29 and 2026-09-30), stage 4 active since block 24,300,000 (2026-10-25), stage 5 not armed (its activation height is the founder's)** | | | [22](./AIP-22.md) | Post-Quantum-Only Finality (Chained Quorum Certificates, PQ Validator Identity, ECDSA Demoted to Compatibility) | Standards Track / Core | **Draft, not ratified; a design only on 2026-09-23; stages 1 to 6 then proven on testnet 28001 in both clients (2026-09-23 to 2026-09-25, stage records in the AIP); conformance corpus of all nine kinds published 2026-09-27 (`aip22-conformance/`); on chain 2800 stages 1 to 3 active from blocks 20,715,632, 20,746,736 and 20,836,228 (2026-09-29 and 2026-09-30), stage R active since block 24,148,752 (2026-10-24), stage 4 active since block 24,300,000 (2026-10-25), stage 5 not armed (its activation height is the founder's)** | |
| [23](./AIP-23.md) | AERE Proof Protocol (Portable Verifiable-Statement Envelope with Optional Post-Quantum On-Chain Finality) | Standards Track / Interface | **Draft, not ratified (2026-09-26); reference verifier and conformance vectors published 2026-09-27; finality proven end to end on testnet 28001** | | | [23](./AIP-23.md) | AERE Proof Protocol (Portable Verifiable-Statement Envelope with Optional Post-Quantum On-Chain Finality) | Standards Track / Interface | **Draft, not ratified (2026-09-26); reference verifier and conformance vectors published 2026-09-27; finality proven end to end on testnet 28001** | |
Numbers are permanent and are never reused, including for withdrawn proposals Numbers are permanent and are never reused, including for withdrawn proposals
@ -58,7 +58,8 @@ Numbers are permanent and are never reused, including for withdrawn proposals
Read this before citing anything here as a network capability. Read this before citing anything here as a network capability.
**Live:** AIP-2 (burn routing; see its outcome record for the measured amount), **Live:** AIP-2 (burn routing; see its outcome record for the measured amount),
AIP-3 (500 ms target, 516.4 ms measured), AIP-4, AIP-5, AIP-6, AIP-7 AIP-3 (500 ms target, 516.4 ms measured when its outcome record was written; the live
interval is on https://aere.network/capabilities), AIP-4, AIP-5, AIP-6, AIP-7
(precompiles `0x0AE1`..`0x0AE5` from block 9,189,161), AIP-17 (base-fee floor from (precompiles `0x0AE1`..`0x0AE5` from block 9,189,161), AIP-17 (base-fee floor from
block 10,141,734), AIP-18 (EIP-2935 from block 9,189,161). AIP-9 through AIP-14 block 10,141,734), AIP-18 (EIP-2935 from block 9,189,161). AIP-9 through AIP-14
describe the decisions behind the live system. describe the decisions behind the live system.
@ -77,10 +78,10 @@ on chain 2800 since 2026-09-22; AIP-20 is deployed and armed for 19,900,000.
**Not live:** AIP-8 (needs a hard fork), AIP-15 as written (its testnet R&D form; **Not live:** AIP-8 (needs a hard fork), AIP-15 as written (its testnet R&D form;
what is live is the dated list above), AIP-16 (a skeleton that verifies nothing), what is live is the dated list above), AIP-16 (a skeleton that verifies nothing),
AIP-19 (a process change under review), AIP-22 from stage 5 (its stages 1 to 4 are live, above, stage 4 since block 24,300,000, 2026-10-25; stage 5 runs on the public testnet 28001, and its height is not yet set on chain 2800). AIP-19 (a process change under review), AIP-22 from stage 5 (its stages 1 to 4 and stage R are live, above, stage R since block 24,148,752, 2026-10-24, and stage 4 since block 24,300,000, 2026-10-25; stage 5 runs on the public testnet 28001, and its height is not yet set on chain 2800; rule 4 of section 4, the provisional tail, is implemented in neither client).
**Not claimed:** consensus whose safety does not depend on ECDSA. Aere consensus is **Not claimed:** consensus whose safety does not depend on ECDSA. Aere consensus is
QBFT in which classical secp256k1 ECDSA is still a validity criterion on every block header (its commit seals), with the post-quantum layers above added to it (hybrid, never "post-quantum only"), and since block 24,300,000 (stage 4) a consensus message counts only through its verified post-quantum seal; AIP-22 is the design for removing that dependence: its stages 1 to 4 are live (above), and its later stages, from stage 5, are not set on chain 2800. (Corrected 2026-10-09: until that date these two paragraphs said that AIP-22 QBFT in which classical secp256k1 ECDSA is still a validity criterion on every block header (its commit seals), with the post-quantum layers above added to it (hybrid, never "post-quantum only"), and since block 24,300,000 (stage 4) a consensus message counts only through its verified post-quantum seal; AIP-22 is the design for removing that dependence: its stages 1 to 4 and stage R are live (above); rule 4 of section 4 and stages 5 and 6 are not. (Corrected 2026-10-09: until that date these two paragraphs said that AIP-22
is design only and that nothing in it is implemented; its stages 1 to 3 have been is design only and that nothing in it is implemented; its stages 1 to 3 have been
live on chain 2800 since 2026-09-29 and 2026-09-30.) The precompiles `0x0AE6` and live on chain 2800 since 2026-09-29 and 2026-09-30.) The precompiles `0x0AE6` and
`0x0AE7` are testnet-only. `0x0AE7` are testnet-only.

2
pq-stark/README.md
View File

@ -91,7 +91,7 @@ from an SP1 6.1.0 proof chain. Next free precompile address after Falcon-HashToP
the real path), so the top level still returns EMPTY for every real SP1 proof. See sections (a), (b), the real path), so the top level still returns EMPTY for every real SP1 proof. See sections (a), (b),
(c), (d), (e), (f), and 8 below and `../../docs/AERE-STARK-VERIFIER-PORT-SPEC.md`. (c), (d), (e), (f), and 8 below and `../../docs/AERE-STARK-VERIFIER-PORT-SPEC.md`.
- Mainnet chain 2800 has exactly the FIVE PQC precompiles 0x0AE1..0x0AE5. 0x0AE8 is not on any Aere - Mainnet chain 2800 has exactly the FIVE PQC precompiles 0x0AE1..0x0AE5. 0x0AE8 is not on any Aere
network. Consensus stays classical secp256k1 ECDSA QBFT - this is an EVM-layer precompile only. network. Consensus is a separate layer - this is an EVM-layer precompile only.
## Layout ## Layout