aere-docs/AERE-QUANTUM-MIGRATION-SUMMARY.md
2026-10-31 14:46:52 +02:00

67 lines
5.7 KiB
Markdown

# Spec #14: Account migration + network key rotation (quantum layer 11)
> **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.)
Built the LAST account-layer quantum-resistance piece: a real, no-custody,
tested contract for moving assets off a classical ECDSA EOA onto a post-quantum
account, plus a design doc covering both that and network key rotation (gated).
## Deliverables
1. Contract: `aere-contracts/contracts/pqc/AereAccountMigrator.sol` (solc 0.8.23,
OZ SafeERC20 + ReentrancyGuard). New file; deployed contracts untouched.
- `migrate(destination, tokens[], amounts[], moveNative)`: atomic sweep of ERC-20
balances + optional native AERE from caller (old EOA) to a destination PQC
account, one tx, authorized by caller's ECDSA key.
- `migrateToPqcAccount(factory, falconPubKey, salt, expectedDestination, ...)`:
DERIVES the destination from the Falcon-512 key via the live
AerePQCAccountFactory.predictAddress, so the sweep is cryptographically bound
to the PQC account that Falcon key controls. Optional expectedDestination guard.
- `predictPqcAccount(...)` view for frontends.
- Authorization documented BOTH ways: pre-approval (default) OR EIP-7702
delegation (Aere supports 7702 per the EIP matrix; single-tx approve+migrate).
- No custody (caller is `from`, destination is `to`, one hop; native forwarded
in full same-call). No owner/admin/upgrade/withdraw/rescue/sweep. Only recipient
is the caller-specified destination.
- Fail-closed + atomic: zero destination reverts; length/zero-token/zero-amount
checks; strict native (StrayNative / ZeroNative / NothingToMigrate); any failed
transfer reverts the WHOLE tx (SafeERC20). Emits Migrated(old, new, tokens,
amounts, nativeAmount).
2. Test: `aere-contracts/test/account-migrator.test.js`. RAN it:
`npx hardhat test test/account-migrator.test.js` -> **9 passing** (2026-07-19).
Destination in strong-path tests is a REAL AerePQCAccount deployed via the REAL
AerePQCAccountFactory (Falcon verify mocked; CREATE2 + asset moves fully real).
Covers: one-tx ERC-20 migration (both entrypoints), native forward, zero-dest
revert, atomicity (first token NOT moved on a failed second leg), only-destination
(third party gets nothing), no-admin-drain (ABI has no owner/withdraw/rescue/
sweep; force-sent tokens unrecoverable), fail-closed native + malformed sets.
3. Doc: `aerenew/docs/AERE-QUANTUM-MIGRATION.md`. Dual:
- Part A (real): harvest-now-decrypt-later rationale, the live PQC destinations
(AerePQCAccount / AerePQCAccountFactory / AereHybridAuth / verifier / key
registry), the contract, user flow, and the real 9/9 test result. References
the pqc-migration-toolkit as the companion scanner/derivation/simulator.
- Part B (design only, gated): Foundation operator key rotation = operational
role transfer to a PQC/threshold account, founder-gated, NOT coupled to
consensus. Validator signing key rotation = coupled to the gated consensus-PQC
activation (seals are classical ECDSA QBFT today), founder + external-audit +
N>=9 + soak gated. Explicit: none of this makes consensus post-quantum by itself.
## Honesty flags carried in the doc
- `[VERIFY]`: live addresses (factory 0xd5315Ea7...CE58, sample account
0xa42a5e7F...4326f, verifier 0x4E8e9682...D8fFC, key registry 0x1eCa3c5A...3691);
AereHybridAuth is repo source, no mainnet address; which threshold account is the
intended operator destination.
- `[MEASURE]`: full operator role-rotation cost across the live role set;
consensus-PQC flip fork-freedom / halt-recover behavior at N>=9 soak.
## Scope boundary kept
Account migration hardens ACCOUNT authorization only. It does NOT make consensus
post-quantum. Validator-key rotation is coupled to the separate gated consensus-PQC
item, not a today-action. No new token; no real user/Foundation funds moved (this is
the mechanism, not an executed migration). No em-dashes in prose; brand "Aere
Network"/"Aere", ticker AERE.