aere-research/aips/AIP-7.md

AIP-7: AerePQC Hard-Fork Activation (Native PQC Precompiles and Extended EIP-2935 Lookback)

Preamble

Field	Value
AIP	7
Title	AerePQC Hard-Fork Activation (Native PQC Precompiles and Extended EIP-2935 Lookback)
Author	AERE Foundation
Type	Standards Track
Category	Core
Status	Final
Created	2026-07-16
Requires	4
Ratification	Foundation-ratified (pre-decentralization)

Abstract

This AIP documents the AerePQC hard fork, a coordinated, client-only activation on mainnet chain 2800 at block 9,189,161 (2026-07-12) that added two Core changes: five native post-quantum verification precompiles at the address band 0x0AE1..0x0AE5 (Falcon-512, Falcon-1024, ML-DSA-44, SLH-DSA-SHA2-128s, and SHAKE256), and the native EIP-2935 8191-block historical-block-hash lookback. It is a retro-filed record of a change already live on chain 2800. It is explicit that this fork changed only the execution layer; AERE consensus is still classical secp256k1 ECDSA QBFT and is not post-quantum.

Motivation

AIP-4 documents AERE's pure-Solidity post-quantum verifier suite. Two of those schemes, Falcon-1024 and ML-DSA-44, cannot record a verification result in a state-changing transaction in pure Solidity, because a recording transaction exceeds the EIP-7825 per-transaction gas cap of 16,777,216 (2^24). Their verification is correct but was reachable only as a read-only eth_call view, which is only as trustworthy as the node answering it and is not consensus anchored. The other schemes that do fit under the cap (notably Falcon-512, at roughly 10.5M gas inside a full userOp) are correct but expensive.

The fix that removes both limits is a native precompile: the dominant cost inside every one of these verifiers is SHAKE / Keccak-f[1600] streaming plus lattice ring arithmetic, and moving that into audited native code, wrapped as an EVM precompile, reduces each verification by more than an order of magnitude. This is the same approach Ethereum uses for other heavy primitives (RIP-7951 for native P-256, EIP-2537 for native BLS12-381). Bundling the native EIP-2935 write path into the same fork gave the network extended trustless block-hash lookback in one scheduled activation instead of two.

The goal was to make Falcon-1024 and ML-DSA-44 record on-chain within the same 16,777,216 per-transaction cap AERE keeps as a functional peer of Ethereum L1, to make the schemes that already fit far cheaper, and to do so as a client-only fork with no re-genesis and no state migration.

Specification

Activation point

The AerePQC hard fork activated on mainnet chain 2800 at block 9,189,161 (2026-07-12). It is configured as a Besu futureEips milestone with activation timestamp futureEipsTime = 1783820272 (2026-07-12 01:37:52 UTC). Activation added precompile behavior and the EIP-2935 write path only. It did NOT change how blocks are proposed, signed, or committed: blocks are still produced and committed by the QBFT validator set signing classical secp256k1 ECDSA committed seals.

Native PQC precompiles

The fork registers five native precompiles that wrap the audited Bouncy Castle 1.83 BCPQC verifiers already present on the client classpath, behind a dedicated classloader-isolation boundary so that Bouncy Castle 1.83 cannot collide with the older Bouncy Castle that Besu bundles. There is zero new hand-rolled cryptography.

Address	Precompile	Standard	Output
0x0000000000000000000000000000000000000AE1	Falcon-512 verify	NIST round-3 Falcon	valid / invalid
0x0000000000000000000000000000000000000AE2	Falcon-1024 verify	NIST round-3 Falcon	valid / invalid
0x0000000000000000000000000000000000000AE3	ML-DSA-44 verify	FIPS 204 (internal interface)	valid / invalid
0x0000000000000000000000000000000000000AE4	SLH-DSA-SHA2-128s verify	FIPS 205 (internal interface)	valid / invalid
0x0000000000000000000000000000000000000AE5	SHAKE256	FIPS 202 XOF	requested output bytes

Each verify precompile is a pure function of its input bytes: it parses a packed, length-prefixed public key, signature, and message; reverts deterministically on malformed structure; and otherwise returns a valid/invalid decision. SHAKE256 returns the requested number of output bytes. Because a precompile result feeds a consensus-critical state transition, every node MUST return byte-identical output for identical input; the verify paths used are deterministic and integer-only (Falcon verification never touches the floating-point signing path).

The full input encodings, per-scheme parameters, revert-versus-0x00 semantics, and gas model are specified in research/aip-draft-pqc-precompiles.md. Gas figures below are the values measured on the pre-activation scratch fork (chain 28099) and carried to mainnet.

Scheme	Marginal verify-op gas	Full verify-and-record tx gasUsed	Share of 16,777,216 cap
SHAKE256	60 + 12/word	21,470	0.13%
Falcon-512	40,000	86,336	0.51%
Falcon-1024	75,000	145,496	0.87%
ML-DSA-44	55,000	351,050	2.09%
SLH-DSA-SHA2-128s	350,000	558,276	3.33%

These figures move Falcon-1024 (about 21.7M gas in pure Solidity) and ML-DSA-44 (about 52.9M gas) from view-only to record-on-chain, and drop Falcon-512 from about 10.49M gas to 86,336.

Native EIP-2935 (extended block-hash lookback)

The fork also activates the native EIP-2935 history-storage system contract at the canonical address 0x0000F90827F1C53a10cb7A02335B175320002935, a ring buffer of the last 8191 block hashes. At the start of every block, the parent block hash is written into slot (number - 1) % 8191 by a consensus system call, before any user transaction runs. There is no keeper, relayer, or Foundation key involved; the write is a condition of block validity. Contracts read a hash by STATICCALL with the 32-byte block number; a query outside the served window [number - 8191, number - 1] reverts. At AERE's 0.5-second block time, 8191 blocks is roughly 68 minutes of trustless lookback, against the roughly 128 seconds the 256-block BLOCKHASH opcode gives. The system contract's runtime bytecode is byte-identical to Ethereum's Pectra deployment and was deployed post-genesis via the canonical keyless "Nick's-method" transaction, so the block-0 state root is unchanged.

Rationale

Native precompiles rather than more Solidity optimization: the pure-Solidity verifiers are already heavily optimized (hand-written Keccak-f assembly) and the remaining cost is intrinsic. Only native code removes it, which is the same reasoning that justified RIP-7951 and EIP-2537 on Ethereum.

Wrapping a maintained, audited native library (Bouncy Castle) rather than hand-rolling the verify keeps the security boundary at a reviewed implementation plus a thin parsing adapter. The classloader-isolation boundary exists because Besu bundles an older Bouncy Castle, and a naive classpath addition risks silently binding the wrong implementation.

A single coordinated hard fork with no re-genesis was chosen over a chain restart so the network kept its entire history, state, and validator keys, consistent with the same discipline applied in AIP-3. Bundling EIP-2935 into the same activation gave the network extended lookback and post-quantum verification in one scheduled event. Keeping the same 16,777,216 per-transaction gas cap as Ethereum L1, rather than raising a local gas limit, is deliberate: it is why the native precompile, not an unbounded gas budget, is the correct fix.

The precompiles were placed at the 0x0AE1..0x0AE5 band already used on the scratch fork, above the Ethereum standard precompiles, the EIP-2537 BLS12-381 range, and the RIP-7951 P-256 precompile at 0x100, so upstream precompile allocations do not collide. If upstream Ethereum later allocates into this band, AERE will re-evaluate to preserve equivalence.

Backwards Compatibility

None that breaks existing contracts. Before activation the five band addresses were empty accounts and the EIP-2935 system address had no code; a call to any of them behaved as a call to an empty address. After block 9,189,161 they behave as precompiles and as the consensus-written history ring buffer. The pure-Solidity verifiers documented in AIP-4 remain deployed and unchanged; contracts MAY migrate to the precompiles for lower gas but are not required to. Integrators SHOULD gate precompile use on chain height (past the activation block), not on probing.

Because AERE runs all validators under one operator and one client today, activation was a flag-day upgrade of the client build across the validator set at the fork block. A node that had not upgraded would compute different results for calls into the band and fork off, so the upgrade was mandatory for all validators and archive/RPC nodes at the fork block.

Security Considerations

This fork does not make AERE consensus post-quantum. Validators continue to sign classical secp256k1 QBFT committed seals. The precompiles are an application and account layer capability. Any claim of post-quantum consensus on the basis of this fork would be false and must not be made. Isolated-testnet work on a Falcon quorum certificate and a second execution client is separate R&D and is not live on chain 2800.

Single operator, one client. Chain 2800 runs seven QBFT validators (f=2, quorum 5-of-7), all Foundation-operated, on a single execution client (Hyperledger Besu). Even at f=2, the validators are one operator and one client, so a consensus bug in a precompile is not caught by client diversity, because there is no second live client. This raises, not lowers, the bar for an external audit and for extensive differential testing.

Determinism and gas agreement. Every node must compute the identical accept/reject and the identical gas charge. The verify paths are deterministic and integer-only, and the adapter reads no chain state or block context. Gas is priced from native microbenchmarks so a precompile call cannot consume disproportionate wall-clock time for its gas; malformed input reverts and consumes all supplied gas, so it cannot be used as a cheap probe.

A valid signature is not authorization. A valid decision from a verify precompile establishes only that the signature is valid for the given public key and message. It does not establish freshness, ordering, replay protection, or key ownership; consuming contracts (for example AerePQCAttestation) add their own nonce and domain separation. For hash-based schemes with one-time-per-leaf state (XMSS, WOTS+), a valid verification does not prove the signer has not reused a leaf.

External audit pending. The fork, the five precompiles, and the consuming contracts carry an internal self-audit only. They have not undergone an external security audit. Their assurance today rests on bit-for-bit agreement with the official NIST KAT and ACVP vectors, cross-checks against independent reimplementations (including a second execution client that runs the precompiles byte-identically on an isolated testnet), and an on-chain end-to-end attestation. They should not secure material value until an external audit lands.

Reference Implementation and On-Chain Deployment

This is a client and chain-configuration change, so the precompile band and the EIP-2935 system contract have no per-scheme deployment artifact of their own; the authoritative artifact is the AERE Besu fork (base hyperledger/besu:26.4.0, gold binary SHA-256 7c5c0743088e9fa765d54c745814601b3c7a27a892e396156f88092b34c80772) and the chain history from block 9,189,161 onward.

On-chain evidence:

• AerePQCAttestation at 0x465d9E3b476BF98Aa1393079e240Db5D2a9bEA6A (verbatim from sdk-js/src/addresses.ts) is a permissionless, no-custody attestation registry that verifies through the live precompiles. A real Falcon-1024 signature (Bouncy Castle 1.83) was verified through the 0x0AE2 precompile and recorded on mainnet: attestation tx 0xb659…9ec1, block 9,200,542, gasUsed 692,206, status 1. A transaction success alone proves the live precompile returned valid, because the contract reverts PQCVerificationFailed otherwise.
• AereCryptoRegistry at 0xaE6fC596bb3eCcbf5c5D02D67B0Ef065b3Afbaa5, a crypto-agility registry over the five live precompiles.
• AerePQCKeyRegistry at 0x1eCa3c5ADcBD0b22636D8672b00faC6D89363691 (proof-of-possession; precompileFor(1) == 0x0ae1 confirmed on-chain), and AereThresholdPQCRegistry at 0x9a6096F6FB3a7E54cF70DE12Cb3903Ae79D1C213 (t-of-n post-quantum authorization via the precompiles).
• EIP-2935 history contract at 0x0000F90827F1C53a10cb7A02335B175320002935, deployed via the canonical keyless transaction 0x67139a552b0d3fffc30c0fa7d0c20d42144138c8fe07fc5691f09c1cce632e15 (mined at block 9,182,379, status 1); eth_getCode returns the canonical Pectra runtime, which encodes the 8191-block (0x1fff) ring buffer.

All addresses above are copied verbatim from sdk-js/src/addresses.ts. The live precompile band, its activation block, and the EIP-2935 window are verifiable on https://rpc.aere.network (chain ID 2800): the current head is well past block 9,189,161, eth_getCode at the EIP-2935 address returns the 8191-block runtime, and the recorded Falcon-1024 attestation is retrievable at block 9,200,542. The design and gas model are specified in research/aip-draft-pqc-precompiles.md; the pure-Solidity verifier suite that the precompiles accelerate is documented in AIP-4.

Copyright

Released to the public domain (CC0). No rights reserved.