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

AIP-20: clarification dated 2026-10-05 under the quantum threat model: the post-quantum seal is already required beside the classical signature on consensus messages; what is not active is the seal as the validity criterion (AIP-22 stage 4)

Browse Source 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Aere Network 2026-10-05 17:11:14 +03:00
parent 4739d4206b
commit 51c17f08de
1 changed files with 6 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
aips/AIP-20.md
View File

@ -232,6 +232,12 @@ early is safe.
carry post-quantum certificates (AIP-22 stages 1 to 3), and per-commit post-quantum enforcement carry post-quantum certificates (AIP-22 stages 1 to 3), and per-commit post-quantum enforcement
(AIP-22 stage 4) is not active as of that date. Node-to-node transport (RLPx) remains classical; it (AIP-22 stage 4) is not active as of that date. Node-to-node transport (RLPx) remains classical; it
authenticates peers, not funds, and is out of scope here. authenticates peers, not funds, and is out of scope here.
Clarified 2026-10-05: "not enforced" above means that the post-quantum seal is not yet the validity
criterion of a consensus message. The seal is already required beside the classical signature: the
validators that run the primary client count a commit only with a valid Falcon-512 seal of its author
since block 17,250,000, and all four QBFT message types since block 17,700,000; the second client
requires the seal on commits and applies the rule to the other three types from AIP-22 stage 4. The
decision recorded in each header remains the classical commit quorum.
- **Key reuse and the empty context.** The signature covers the 32-byte `signing_hash` with the - **Key reuse and the empty context.** The signature covers the 32-byte `signing_hash` with the
empty FIPS 204 context. A key that authorizes a type-`0x50` account MUST NOT be used by a signer empty FIPS 204 context. A key that authorizes a type-`0x50` account MUST NOT be used by a signer
that signs caller-supplied 32-byte values with the empty context (a generic "sign this hash" that signs caller-supplied 32-byte values with the empty context (a generic "sign this hash"