119 lines
7.0 KiB
Markdown
119 lines
7.0 KiB
Markdown
# AIP-15: In-Place Hybrid PQC Consensus Activation via On-Chain Anchor Contract, not Re-Genesis
|
|
|
|
> **Note added 2026-10-30 (consensus).** Since block 25,080,000 (AIP-22 stage 5) headers no longer carry ECDSA commit seals: each carries the Falcon-512 seal of its proposer instead, and a commit still carries the ECDSA commit seal of its validator as an additional check. Where the note of 2026-09-24 below describes the headers, it describes chain 2800 below that block.
|
|
|
|
> **Note added 2026-09-24 (consensus).** Where this document says that consensus is classical secp256k1 ECDSA and not post-quantum, read it as the per-block finality 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 block is post-quantum final once the next anchor, at most 32 blocks later, carries the certificate that covers it; headers still carry classical ECDSA commit seals until AIP-22 stage 5 (this sentence corrected on 2026-10-25). It no longer describes all of consensus on chain 2800: since 2026-08-14 every anchor block must carry a certificate of validator post-quantum seals under its hash (Falcon-512, with SLH-DSA as well since 2026-09-04), and since 2026-09-05 (block 17,250,000) the nine AERE-client validators (nine of the ten) refuse a commit message without a valid Falcon-512 seal of its author, and since 2026-09-08 (block 17,700,000) any QBFT consensus message without one, while the tenth, the second client, enforced that seal only on commit messages until block 24,300,000 and attributes every consensus message only through it since (this clause corrected on 2026-10-12, 2026-10-25 and 2026-10-28; until 2026-10-28 it dated the refusal of every message type to 2026-09-05, the date of the commit layer alone). (Note applied to this document on 2026-10-28.)
|
|
|
|
## Preamble
|
|
|
|
| Field | Value |
|
|
| --- | --- |
|
|
| AIP | 15 |
|
|
| Title | In-Place Hybrid PQC Consensus Activation via On-Chain Anchor Contract, not Re-Genesis |
|
|
| Author | Aere Network Foundation |
|
|
| Type | Standards Track |
|
|
| Category | Core |
|
|
| Status | Draft (isolated-testnet R&D; not live on chain 2800) |
|
|
| Created | 2026-07-19 |
|
|
| Requires | 9 |
|
|
| Supersedes | None |
|
|
| Superseded-By | None |
|
|
| Ratification | Not ratified; external-audit gated and founder gated |
|
|
|
|
## Abstract
|
|
|
|
This AIP specifies a way to bind a Falcon-512 validator manifest to on-chain
|
|
state **after** genesis, via a minimal immutable anchor contract, so that hybrid
|
|
post-quantum consensus could be activated on a live chain without a re-genesis.
|
|
It is **Draft**. Nothing in it is live on chain 2800, whose consensus remains
|
|
classical secp256k1 ECDSA QBFT.
|
|
|
|
## Motivation
|
|
|
|
Aere's hybrid consensus research proved, on isolated test networks, a gossiped,
|
|
blocking Falcon-512 quorum certificate running alongside the ECDSA
|
|
committed-seal quorum, empirically at N = 4 (2 s) and N = 7 (0.5 s). Its Falcon
|
|
registry, however, was bound to chain identity at genesis, by folding
|
|
`keccak256(manifest)` into the genesis state root. Chain 2800 launched long
|
|
before any Falcon manifest existed, so blocking activation was previously
|
|
recorded as "requires a re-genesis". That is a non-starter for a live chain:
|
|
re-genesis destroys history and chain identity.
|
|
|
|
## Specification
|
|
|
|
Bind the Falcon manifest to on-chain state post-genesis:
|
|
|
|
1. Deploy a minimal, immutable, ownerless **anchor contract** by one ordinary
|
|
transaction at an activation height. Its runtime code is a single `STOP` byte,
|
|
so it is never callable and has no admin.
|
|
2. The contract commits `keccak256(manifest)` to storage slot 0.
|
|
3. On every block import, the validation rule resolves the manifest from the
|
|
**parent block's world state** at the anchor address, and activates the
|
|
pending registry only if the observed hash matches. Any mismatch fails closed.
|
|
4. The deploy address is deterministic, `keccak256(rlp[deployer, nonce])[12:]`, so
|
|
validators can be pre-configured before deployment.
|
|
5. Activation is idempotent and retried each block, so deploy-then-configure and
|
|
configure-then-deploy both converge.
|
|
|
|
The re-genesis requirement is removed.
|
|
|
|
## Rationale
|
|
|
|
The late anchor folds `keccak256(manifest)` into every block hash from the
|
|
deployment block onward, so two nodes that agree on the chain past that block
|
|
necessarily agree on the anchored hash. That is the same integrity guarantee the
|
|
genesis ceremony gave, minus the re-genesis.
|
|
|
|
**Alternatives rejected.** Re-genesis carrying a Falcon anchor in the genesis
|
|
alloc: destroys history and chain identity. A shared per-node manifest file with
|
|
no on-chain root: a node with a tampered manifest could join silently, whereas the
|
|
on-chain anchor makes it fail closed.
|
|
|
|
## Backwards Compatibility
|
|
|
|
Pre-activation blocks remain valid and are unaffected. The design is
|
|
non-retroactive by construction: the anchor address is an empty account before
|
|
its deploy block.
|
|
|
|
## Security Considerations
|
|
|
|
**Evidence and honest scope.** Proven end-to-end on an **isolated N = 4 at 0.5 s
|
|
testnet** (chain ID 440855) whose genesis is byte-shape-identical to a classical
|
|
ECDSA-only chain: classical start, deploy anchor at block 16, activate from the
|
|
contract at block 17, flip to blocking at fork block 150, with 0 forks, 0.5 s
|
|
cadence maintained, pre-activation blocks still valid, a post-activation
|
|
sub-quorum block rejected (the chain halts), and recovery in place with no
|
|
re-genesis. All **measured** on that testnet.
|
|
|
|
**Nothing in this AIP is live on chain 2800.** This was written 2026-07-19, when
|
|
the chain ran N = 7 and carried no Falcon material in any header. Measured
|
|
2026-09-12: the set is N = 10, and since block 13,014,000 anchor headers carry a
|
|
post-quantum certificate under the block hash. That anchor is a periodic
|
|
checkpoint, not the per-block blocking quorum specified here, and the design
|
|
below has never been armed on chain 2800.
|
|
|
|
The hybrid can only shrink the committable set, so it is never worse than the
|
|
ECDSA-only chain; ECDSA committed seals remain the decisive safety and liveness
|
|
seal. The corresponding risk is liveness: in this design, which is not live, a
|
|
blocking Falcon quorum that cannot be met would halt block production. At N = 7,
|
|
the set size when this was written, the blocking configuration has a zero
|
|
two-fault margin, which is why a larger set is recommended before any live flip.
|
|
|
|
**Remaining gates to a live flip.** No longer a gate: re-genesis. Still required:
|
|
an external audit of the Falcon consensus patch (quorum, gossip, assembly,
|
|
late-anchor Java) and of BouncyCastle Falcon-512 on the consensus path;
|
|
finalizing the full target validator set with an address-bound manifest
|
|
re-anchored for the full set; a live isolated soak of the combined activation at
|
|
the full set size (N = 10, measured 2026-09-12); and an explicit founder GO.
|
|
**No agent activates blocking consensus on chain 2800.**
|
|
|
|
## Reference Implementation and On-Chain Deployment
|
|
|
|
Not deployed. Reference patch:
|
|
`aerenew/consensus-pqc/besu-consensus-pqc-fork-activation.patch`, with evidence
|
|
under `aerenew/consensus-pqc/inplace-activation-evidence/`.
|
|
|
|
## Copyright
|
|
|
|
Released to the public domain (CC0). No rights reserved.
|