AIP-15: In-Place Hybrid PQC Consensus Activation via On-Chain Anchor Contract, not Re-Genesis

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:

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.
The contract commits keccak256(manifest) to storage slot 0.
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.
The deploy address is deterministic, keccak256(rlp[deployer, nonce])[12:], so validators can be pre-configured before deployment.
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/.

5.3 KiB Raw Permalink Blame History