aere-network/aere-docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
dd1410c266
aere-docs/AERE-EIP-COMPATIBILITY-MATRIX.md
Aere Network dd1410c266 The unpublished line of work joins the sanitized public line 
The published line and the local line of this repository had no common
ancestor: the public one carried the hygiene pass (no host names, no internal
paths), the local one carried a month of corrections that never shipped. This
commit ports the local work onto the public line, keeping the public hygiene
wording wherever the two touched the same sentence, and keeping the public
version of AERE-CROSS-CLIENT-DETERMINISM.md entirely.

Carried: LICENSE/LICENSING corrections, VERIFY-POLICY.md,
CITATIONS-UNRESOLVED.md remeasured 2026-08-11, the 'audited' adjective removed
from next to Bouncy Castle, citation paths rewritten to published form, AIP-8,
the QA consolidation report, the second EIP validation pass, fork-height
corrections, the AereSink / threshold-factory correction, the forge test
floor, and the architecture-map updates.
2026-08-15 13:54:42 +03:00

216 lines
42 KiB
Markdown
Raw Blame History

# Aere Network: Ethereum EIP Compatibility Matrix
**Chain:** Aere Network mainnet, chain ID 2800 (`0xaf0`). Execution client: Hyperledger Besu 26.4.0 with QBFT consensus (classical secp256k1 ECDSA, N=7 validators, f=2), approximately 0.5 second blocks. This document is a developer reference: it states, EIP by EIP, where Aere's EVM matches Ethereum mainnet and where it deliberately differs.
Aere tracks Ethereum's hard forks so that its EVM surface matches mainnet at the same addresses and opcodes: London and Shanghai apply from genesis, Cancun and Prague (Pectra) activated together at block 2,075,341, and Osaka (Fusaka) at block 2,106,597. A small set of deviations is intentional and disclosed here, because Aere is a QBFT chain with no separate beacon (consensus) layer and no blob data availability market. Anything not matching Ethereum is a design decision, not an oversight, and each is called out in the matrix and again in the deviations recap at the end.
## How to read this
- **Status** is one of: **Supported** (matches Ethereum), **Partial** (present but materially limited on Aere), **Not implemented** (absent), **No-op** (present in the ruleset but neutralized, returns a defined zero/empty value under QBFT).
- Every row is intended to be literally true. Cells that could not be verified against the repository's genesis or fork configuration carry an explicit **[VERIFY: ...]** note. A `[VERIFY]` note is a permanent, deliberate disclosure that the named fact is **NOT MEASURED**. It is published as it stands, it does not block publication, and it is closed only by a measurement, never by deletion. The full rule is `VERIFY-POLICY.md` at the root of this repository.
- A figure taken from a spec or a config file is a **price**. A figure produced by querying the running chain is a **measurement**. Rows marked *(measured 2026-07-19)* were produced by read-only JSON-RPC against `https://rpc.aere.network`, and the method is stated in "How the measured gas figures were produced" at the end of this document. Nothing in this file was written by sending a transaction.
### Second validation pass, 2026-07-19 (independent re-measurement)
This document was re-validated end to end against the running chain by an independent pass whose brief was to assume nothing in it was true. Every activation height was re-derived by binary search rather than read from this file; every price claim was re-measured with a freshly built and freshly calibrated probe; behavioural claims were driven with real `eth_call`s and compared byte for byte.
**Result: the matrix held up.** No gas figure, activation height, status, or economic claim in it was found to be wrong. Three open flags were closed, one was narrowed, and three points of imprecision were corrected:
- **`blobSchedule` attribution (corrected).** The EIP-7691 row said the raised schedule was set "in config". The *values* are right (live `eth_config`: target 6, max 9), but `blobSchedule` is absent from all four genesis files -- the schedule comes from Besu's built-in default for the active fork, not from Aere's genesis.
- **Blob base-fee update fraction (corrected).** The EIP-7516 row cited `fake_exponential(1, 0, 3338477)`. 3,338,477 is the *Cancun* constant; the live chain reports 5,007,716, the *Prague* (EIP-7691) value. The 1 wei conclusion is unaffected.
- **SHAKE256 figure (disambiguated).** "A 160-byte input" was ambiguous between total input and `data` length; the row now states the fitted gas model and the packed encoding instead of a single point.
**It also propagated a correction outward.** `AERE-PROTOCOL-SPECIFICATION.md` was still carrying the superseded Pectra and Osaka heights (2,075,363 and 2,106,606) in nine places, including its normative activation predicates and its Appendix A fork table. Those were wrong by 22 and 9 blocks and have been corrected to the measured 2,075,341 and 2,106,597. The two documents now agree.
### Measurement provenance for the 2026-07-19 pass
The gas figures, the two fork-boundary heights, and the blob base fee in this document were re-derived from the live chain on 2026-07-19 while diagnosing the Nethermind second client (see `aerenew/cross-client-determinism/`). That pass corrected four values that had been carried from specs rather than measured: the Pectra and Osaka activation heights, the P-256 precompile gas, and the blob base fee. Each correction is called out inline.
- "The fork" or "the AerePQC hard fork" refers to Aere's client-only Besu `futureEips` milestone (`futureEipsTime = 1783820272`), which activated at block 9,189,161 (2026-07-12) and bundled the native post-quantum precompiles, the EIP-2935 write path, and EIP-7939. No re-genesis was involved.
### Fork timeline on chain 2800
| Ethereum fork | Aere activation | Notes |
|---|---|---|
| London, Shanghai | Genesis (block 0) | `londonBlock: 0`, `shanghaiTime: 0` in genesis config |
| Cancun + Prague (Pectra) | **Block 2,075,341** *(measured 2026-07-19)* | `cancunTime == pragueTime == 1780189051`; Cancun and Prague share one activation instant on Aere |
| Osaka (Fusaka) | **Block 2,106,597** *(measured 2026-07-19)* | `osakaTime == 1780220351` |
| AerePQC milestone (post-Osaka) | Block 9,189,161 | Besu `futureEipsTime == 1783820272`; PQC precompiles + EIP-2935 write path + EIP-7939 |
**Correction (2026-07-19).** This table previously read 2,075,363 and 2,106,606. Both were wrong. The heights are gated by timestamp, not by block number, so they have to be read off the chain, and when they were, two independent signals agreed:
| Block | Timestamp | `requestsHash` present |
|---|---|---|
| 2,075,340 | 1780189050 | no |
| **2,075,341** | **1780189051** (`pragueTime`) | **yes** (`sha256("")`) |
| 2,106,596 | 1780220350 | yes |
| **2,106,597** | **1780220351** (`osakaTime`) | yes |
Block 2,075,341 is the first block whose timestamp reaches `pragueTime`, and it is also the first block to carry a `requestsHash` at all, which is an independent confirmation of the Pectra boundary. Block 2,106,597 is the first block whose timestamp reaches `osakaTime`. Both agree with the checkpoints the cross-client harness derived by binary search (`aerenew/cross-client-determinism/`). Block heights on this chain are not a stable API: they are an observation about when a timestamp was crossed, and they are recorded here only because they are useful for locating the boundary in an explorer.
**AerePQC height 9,189,161: now re-derived (2026-07-19, second pass).** This was previously flagged as carried from configuration rather than measured. It has since been confirmed by the same timestamp binary search used for the other two boundaries: block 9,189,160 has timestamp 1783820271 and block 9,189,161 has timestamp **1783820272**, exactly `futureEipsTime`, making it the first block at or past the activation instant. Note the scope of that confirmation: it establishes the *height at which the configured timestamp is first crossed*, which is the same standard applied to Pectra and Osaka. It is not a behavioural probe of the precompiles at that height -- the public RPC prunes historical state, so `eth_call` at 9,189,161 still cannot be used to watch the band switch on. The precompiles are separately confirmed live *at head* by direct measurement (see the Aere additions table).
---
## The Matrix
### London and Shanghai era (active from genesis)
| EIP | Name | Status | Difference from Ethereum |
|---|---|---|---|
| 1559 | Fee market (base fee, type-2 txs) | Partial | Fee-market mechanics present, plus a 1 Gwei base-fee floor live since block 10,141,734 (raised the real minimum from 7 wei). **Floor boundary re-confirmed by direct measurement 2026-07-19**: block 10,141,733 has `baseFeePerGas = 7` wei and block 10,141,734 has `baseFeePerGas = 0x3b9aca00 = 1,000,000,000` wei, and it holds at 1 Gwei at every later block sampled through head. `eth_feeHistory` at head likewise reports `baseFeePerGas` of `0x3b9aca00`. Aere adds no consensus base-fee burn narrative: its "burn" is a separate validator-reward cut (see deviations). [VERIFY (narrowed 2026-07-19): base-fee *disposal*. Measurement rules out crediting to the coinbase (zero coinbase delta across a fee-paying block); burned-versus-routed-elsewhere is still open, see open flag 2.] |
| 3198 | BASEFEE opcode | Supported | Returns the current base fee, which is floored at 1 Gwei (see EIP-1559). |
| 3529 | Reduction in refunds | Supported | Matches Ethereum. |
| 3541 | Reject contract code starting with 0xEF | Supported | Matches Ethereum. Reserves the 0xEF lead byte (the EOF prefix). |
| 3651 | Warm COINBASE | Supported | Matches Ethereum. |
| 3855 | PUSH0 instruction | Supported | Matches Ethereum. |
| 3860 | Limit and meter initcode | Supported | Matches Ethereum. |
| 4895 | Beacon chain push withdrawals as operations | No-op | Withdrawal-operation ruleset present, but Aere has no beacon layer to originate withdrawals, so none are produced. |
### Istanbul-era precompiles and pricing (active from genesis)
Aere starts at London, so every earlier fork is folded into genesis and these are all live. They are listed explicitly because they are **priced** rules, not feature flags: a client that carries the opcode but the wrong price produces a different `gasUsed` and forks. That is not hypothetical. Both EIP-1108 and EIP-152 were missing from the Nethermind second client's chainspec on 2026-07-19, which made it charge pre-Istanbul alt_bn128 prices and halt (see `aerenew/cross-client-determinism/LIVE-BESU-VS-NETHERMIND-2026-07-19.md`).
| EIP | Name | Status | Difference from Ethereum |
|---|---|---|---|
| 196 | alt_bn128 add and mul (`0x06`, `0x07`) | Supported | Matches Ethereum. Verified live: `ecAdd` and `ecMul` both return 64 bytes for the standard generator inputs. |
| 197 | alt_bn128 pairing check (`0x08`) | Supported | Matches Ethereum. Verified live for k = 0, 1, 2 and 4 pairs. |
| 1108 | Reduce alt_bn128 precompile gas costs | Supported | Matches Ethereum. **Post-1108 prices confirmed by measurement, not by config.** Measured 2026-07-19 against the live chain: `ecAdd` **150**, `ecMul` **6,000**, `ecPairing` **45,000 + 34,000 per pair**. The pre-1108 schedule (500 / 40,000 / 100,000 + 80,000 per pair) is ruled out by a margin of 34,000 gas on `ecMul` alone and 239,000 gas on a 4-pair `ecPairing`, far outside any measurement noise. This is the pricing an on-chain BN254 Groth16 verifier depends on; a client on the pre-1108 schedule starves such a verification of gas. |
| 152 | Blake2b `F` compression function (`0x09`) | Supported | Matches Ethereum. Present and fail-closed: probed with a malformed (zero-length) input, it consumes all forwarded gas and reports failure, which is the behavior EIP-152 specifies for an input that is not exactly 213 bytes. **Per-round price now measured on a well-formed 213-byte input** *(measured 2026-07-19)*: `rounds = 12` costs exactly **12** gas and `rounds = 100` costs exactly **100** gas, that is, cost == rounds, the EIP-152 schedule. |
| 198 | Big integer modular exponentiation (`0x05`) | Supported | Matches Ethereum at **Osaka** pricing. **Closed by measurement 2026-07-19, and the answer distinguishes the repricing generation.** A minimal 1-byte base/exponent/modulus call (`b=8, e=9, m=10`) costs **500** gas. EIP-2565's floor is 200 and EIP-7883's is 500, so the measurement rules out EIP-2565-only pricing and confirms **EIP-7883 (Osaka) modexp repricing is live** on chain 2800. This was open flag 5; a client still on the EIP-2565 schedule would undercharge modexp by 300 gas at the floor and diverge. |
### Cancun (block 2,075,341)
| EIP | Name | Status | Difference from Ethereum |
|---|---|---|---|
| 1153 | Transient storage (TLOAD / TSTORE) | Supported | Matches Ethereum. Confirmed live by execution *(measured 2026-07-19)*: a state-override `eth_call` running `TSTORE(0, 0x42); TLOAD(0)` returns `0x..42`. |
| 4844 | Shard blob transactions | Partial | Type-3 blob transactions are present in the EVM and the Cancun blob header fields are carried (`blobGasUsed` and `excessBlobGas` are present and both read `0x0` on live blocks), but Aere runs no blob data-availability market, so no blob is ever included and the blob fee never leaves its floor. See EIP-7516. |
| 4788 | Beacon block root in the EVM | No-op | The beacon-root ring buffer returns 0x0: a QBFT chain has no separate beacon/consensus layer to expose a root from. Live blocks carry `parentBeaconBlockRoot = 0x00..00`. |
| 5656 | MCOPY instruction | Supported | Matches Ethereum. Confirmed live by execution *(measured 2026-07-19)*: a state-override `eth_call` using `MCOPY` to copy a word from offset 0 to offset 32 returns the copied value. |
| 6780 | SELFDESTRUCT only in same transaction | Supported | Matches Ethereum. |
| 7516 | BLOBBASEFEE opcode | Supported (pinned at the floor) | **Corrected 2026-07-19: this previously read "No-op, returns 0". That was wrong.** The opcode is live and returns **1 wei**, the EIP-4844 `MIN_BASE_FEE_PER_BLOB_GAS`, not 0. Live blocks carry `excessBlobGas = 0x0`, and `blob_base_fee = fake_exponential(1, 0, 5007716) = 1`. **Correction (2026-07-19): this previously cited an update fraction of 3,338,477.** That is the *Cancun* `BLOB_BASE_FEE_UPDATE_FRACTION`; the live chain's `eth_config` reports `baseFeeUpdateFraction = 5007716`, the *Prague* (EIP-7691) value. The result is 1 wei either way because `excessBlobGas` is 0 and `fake_exponential(1, 0, k) = 1` for every `k`, so the conclusion was right, but the constant quoted for the active fork was wrong. Confirmed by `eth_feeHistory` on chain 2800, which reports `baseFeePerBlobGas: ["0x1", "0x1"]`. Because Aere runs no blob market, `excessBlobGas` never rises, so the value is permanently pinned at the floor of 1 rather than being absent or zero. See the caveat on probing this opcode in "How the measured gas figures were produced". |
### Prague / Pectra (block 2,075,341)
| EIP | Name | Status | Difference from Ethereum |
|---|---|---|---|
| 2537 | BLS12-381 curve precompiles | Supported | Matches Ethereum. **Prices confirmed by measurement, not by config** *(measured 2026-07-19)*: `BLS12_G1ADD` (`0x0b`) **375**, `BLS12_G2ADD` (`0x0d`) **600**, `BLS12_MAP_FP_TO_G1` (`0x10`) **5,500**, `BLS12_MAP_FP2_TO_G2` (`0x11`) **23,800** -- each exactly the EIP-2537 schedule. All seven BLS addresses `0x0b`..`0x11` are listed in the live `eth_config` precompile set. |
| 2935 | Save historical block hashes in state | Supported | Standard 8191-block history-storage ring buffer at `0x0000F90827F1C53a10cb7A02335B175320002935`, written by consensus. Nominally listed at Pectra but the system contract was not populated on mainnet until the AerePQC fork (block 9,189,161) added the write path; from that block `eth_getCode` returns the canonical runtime and the 8191-block window is live. |
| 6110 | Supply validator deposits on chain | Partial | The deposit-request ruleset is part of the Pectra parity Aere tracks, but Aere has no beacon layer to consume deposits, so a deposit does not create or fund a QBFT validator (the validator set is QBFT-managed). **CLOSED by measurement 2026-08-01** (head block 11,810,041, `https://rpc.aere.network`): `eth_getCode` returns **0 bytes** at the EIP-6110 deposit contract `0x00000961Ef480Eb55e80D19ad83579A64c007002`, at the EIP-7251 consolidation contract `0x0000BBdDc7CE488642fb579F8B00f3a590007251`, and at `0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02`. The live header carries `requestsHash` = `0xe3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855`, which is the SHA-256 of the empty string, and `parentBeaconBlockRoot` = all zeros. So: none of the request system contracts is populated, and the header requests list is empty. That is exactly what "ruleset present, no beacon layer" predicts, and it is now measured rather than flagged. (Contrast EIP-2935 in the row above, which **is** populated, at 83 bytes.) |
| 7002 | Execution-layer triggerable withdrawals/exits | Partial | Withdrawal-request ruleset present, but no beacon layer consumes exits, so it does not affect the QBFT validator set. **CLOSED by measurement 2026-08-01** (head block 11,810,041, `https://rpc.aere.network`): `eth_getCode` returns **0 bytes** at the EIP-6110 deposit contract `0x00000961Ef480Eb55e80D19ad83579A64c007002`, at the EIP-7251 consolidation contract `0x0000BBdDc7CE488642fb579F8B00f3a590007251`, and at `0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02`. The live header carries `requestsHash` = `0xe3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855`, which is the SHA-256 of the empty string, and `parentBeaconBlockRoot` = all zeros. So: none of the request system contracts is populated, and the header requests list is empty. That is exactly what "ruleset present, no beacon layer" predicts, and it is now measured rather than flagged. (Contrast EIP-2935 in the row above, which **is** populated, at 83 bytes.) |
| 7251 | Increase MAX_EFFECTIVE_BALANCE (consolidations) | Partial | Consolidation-request ruleset present, but no beacon layer to act on it under QBFT. **CLOSED by measurement 2026-08-01** (head block 11,810,041, `https://rpc.aere.network`): `eth_getCode` returns **0 bytes** at the EIP-6110 deposit contract `0x00000961Ef480Eb55e80D19ad83579A64c007002`, at the EIP-7251 consolidation contract `0x0000BBdDc7CE488642fb579F8B00f3a590007251`, and at `0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02`. The live header carries `requestsHash` = `0xe3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855`, which is the SHA-256 of the empty string, and `parentBeaconBlockRoot` = all zeros. So: none of the request system contracts is populated, and the header requests list is empty. That is exactly what "ruleset present, no beacon layer" predicts, and it is now measured rather than flagged. (Contrast EIP-2935 in the row above, which **is** populated, at 83 bytes.) |
| 7549 | Move committee index outside signature | Not implemented | Beacon consensus-layer change only, with no execution-layer/EVM surface. It has no applicability under QBFT. |
| 7623 | Increase calldata cost | Supported | Matches Ethereum (calldata floor-cost accounting). |
| 7685 | General purpose execution layer requests | Partial | The requests framework (the umbrella for 6110/7002/7251) exists in the ruleset, but Aere has no beacon layer to consume the requests. **CLOSED by measurement 2026-08-01** (head block 11,810,041, `https://rpc.aere.network`): `eth_getCode` returns **0 bytes** at the EIP-6110 deposit contract `0x00000961Ef480Eb55e80D19ad83579A64c007002`, at the EIP-7251 consolidation contract `0x0000BBdDc7CE488642fb579F8B00f3a590007251`, and at `0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02`. The live header carries `requestsHash` = `0xe3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855`, which is the SHA-256 of the empty string, and `parentBeaconBlockRoot` = all zeros. So: none of the request system contracts is populated, and the header requests list is empty. That is exactly what "ruleset present, no beacon layer" predicts, and it is now measured rather than flagged. (Contrast EIP-2935 in the row above, which **is** populated, at 83 bytes.) |
| 7702 | Set EOA account code (delegation) | Supported | Matches Ethereum. This is the EOA-delegation primitive Aere carries (and the reason EIP-3074 is not needed). **Delegation resolution confirmed live** *(measured 2026-07-19)*: an account whose code is set to the designator (`0xef0100` followed by a 20-byte target address) executes the target's code when called, while the same account given a non-designator `0xEF`-prefixed blob (`0xef9900` followed by the same address) is rejected with `Invalid opcode: 0xef`. So the `0xef0100` prefix is honored as a delegation indicator and no other `0xEF` form is executable, which is exactly the EIP-7702 plus EIP-3541 combination. |
| 7691 | Blob throughput increase | Partial | The active blob schedule is **target 6, max 9, `baseFeeUpdateFraction` 5,007,716** -- the EIP-7691 raised schedule -- confirmed by reading `eth_config` on the live chain *(measured 2026-07-19)*. With no blob data-availability market the increase has no practical effect. **Correction (2026-07-19): this row previously said the schedule was set "in config". That was wrong as to source.** `blobSchedule` is **absent from all four genesis files** (`aere-genesis-current.json`, `aere-genesis-pectra.json`, `aere-genesis-fusaka.json`, `aerenew/genesis.json`); none of them declares one. The schedule the chain actually runs comes from **Besu's built-in default for the active fork**, not from Aere's genesis. The values are correct; the attribution was not. A reimplementer must therefore hardcode the EIP-7691 schedule rather than expect to read it out of Aere's genesis, and a client that defaults to the Cancun schedule (target 3, max 6, fraction 3,338,477) would carry a different blob-fee curve. |
### Fusaka / Osaka (block 2,106,597) and the post-Osaka milestone
| EIP | Name | Status | Difference from Ethereum |
|---|---|---|---|
| 7951 | secp256r1 (P-256) signature verification at `0x100` | Supported | Matches Ethereum's Osaka. Live and verified on chain 2800 *(measured 2026-07-19)*. See the `0x100` row under "Aere additions" for the measured gas and semantics. Activated with the Osaka ruleset at `osakaTime = 1780220351`, block 2,106,597. This is the precompile Aere's passkey/WebAuthn accounts sit on, so it is load-bearing rather than decorative. |
| 7825 | Transaction gas limit cap (2^24 = 16,777,216) | Supported | Matches Ethereum; the per-transaction gas cap is enforced on chain 2800 (real transactions have executed under it). Note this is a per-transaction cap; the live **block** gas limit reads `0x1fffffffffffff` (2^53 - 1). |
| 7939 | Count leading zeros (CLZ) opcode | Supported | Present. On Aere it activated at the post-Osaka AerePQC milestone (block 9,189,161), which the live EIP-2124 fork-id folds in. [VERIFY: activation height for 7939 specifically, confirmed against the live fork schedule.] |
| 7594 | PeerDAS (peer data availability sampling) | Not implemented | No active role under QBFT: Aere runs no blob data-availability market, so there is no data-availability sampling role to perform. |
| 7805 | FOCIL (fork-choice enforced inclusion lists) | Not implemented | No-op under QBFT: there is no fork-choice or proposer-inclusion layer to enforce inclusion lists against. |
| 7692 | EOF (EVM Object Format) mega-set | Not implemented | Not activated under the current ruleset; the 0xEF prefix stays reserved by EIP-3541 (legacy behavior). [VERIFY: confirm the AerePQC `futureEips` protocol spec (futureEipsTime = 1783820272, block 9,189,161) does NOT enable the EOF opcode set or EIP-3540/3670 container validation. Corroboration that EOF is off: the served genesis config and the Nethermind live-sync fork-id mirror both carry no EOF transition, and the engineering spec states EOF is not activated. The one residual risk is that this milestone rides Besu's `futureEips` key, which in stock Besu is EOF's staging ground, so the fork build's spec definition should be inspected to confirm EOF was not pulled in.] |
### Superseded
| EIP | Name | Status | Difference from Ethereum |
|---|---|---|---|
| 3074 | AUTH / AUTHCALL (sponsored EOA actions) | Not implemented | Deliberately absent. It was superseded by EIP-7702, which Aere carries as its EOA-delegation primitive. |
---
## Aere additions beyond Ethereum
These are callable addresses that are not part of the base Ethereum mainnet precompile set. The post-quantum band `0x0AE1`..`0x0AE5` is genuinely Aere-specific and live on mainnet; `0x0AE6`..`0x0AE8` are not on mainnet; the secp256r1 precompile at `0x100` is a shared RIP that Ethereum is standardizing in Osaka (listed here because it sits outside the classic precompile set).
| Address | Name | Status | Notes |
|---|---|---|---|
| `0x0AE1` | Falcon-512 signature verify | Live on mainnet | Activated at block 9,189,161 (AerePQC fork). Thin wrapper over Bouncy Castle 1.83; NIST KAT verified. Gas **40,000**, measured on the live chain 2026-07-19 and matching the committed schedule `Falcon512VerifyGas = 40_000`. |
| `0x0AE2` | Falcon-1024 signature verify | Live on mainnet | Activated at block 9,189,161. NIST KAT verified. Gas **75,000** (measured), matching the committed `FALCON1024_VERIFY_GAS = 75000`. |
| `0x0AE3` | ML-DSA-44 signature verify (FIPS 204) | Live on mainnet | Activated at block 9,189,161. ACVP verified. Gas **55,000** (measured). |
| `0x0AE4` | SLH-DSA-SHA2-128s signature verify (FIPS 205) | Live on mainnet | Activated at block 9,189,161. ACVP verified. Gas **350,000** (measured). |
| `0x0AE5` | SHAKE256 (FIPS 202) | Live on mainnet | Activated at block 9,189,161. Variable cost by input and output length. **Full gas model re-derived on the live chain across 10 input shapes** *(measured 2026-07-19)*, fitting with zero residual: `gas = 60 + 12 * ( ceil(len(data)/32) + ceil(min(outLen, 65536)/32) )`, where the packed input is `outLen` (32-byte big-endian word) followed by `data`. Three properties are load-bearing and all three are measured, not assumed: (1) the two word counts are **rounded up separately, not combined** -- `outLen=33, data=33` costs 108 gas (4 words), where a combined `ceil((33+33)/32)` model predicts 3 words and 96 gas; (2) `outLen` **saturates** at `MAX_OUTLEN = 65536` -- `outLen=100000, data=32` costs 24,648, identical to what 65,536 would cost; (3) the `outLen` framing word is **not** itself charged as data. **Clarification (2026-07-19): this row previously read "a 160-byte input returning 65,536 bytes measured 24,684 gas", which was ambiguous.** 24,684 gas corresponds to **128 bytes of `data`** (a 160-byte *total* input, of which the first 32 bytes are the `outLen` framing word). A call with 160 bytes of actual `data` costs **24,696**. The figure was right under one reading of "input" and wrong under the other, so it is now stated as the model plus the encoding. This independently reconfirms the separate-rounding correction made to `aerenew/eips/eip-draft-shake256-precompile.md`. |
| `0x0AE6` | ML-KEM-768 encapsulation (FIPS 203) | Testnet only | Built and ACVP-verified (25/25) on an isolated QBFT testnet. NOT on mainnet 2800: re-confirmed 2026-07-20 by gas differential, a mainnet `STATICCALL` to `0x0AE6` charges **0 gas** against a codeless control, versus 40,000/75,000/55,000/350,000/24,648 for the live `0x0AE1`..`0x0AE5`. Decisive because `gasRequirement` is a flat 60,000 for every input, so an active `0x0AE6` would bill it even while returning empty. Note the empty return by itself proves nothing: `0x0AE5` is live and also returns empty for a short input. Founder- and audit-gated. |
| `0x0AE7` | Falcon HashToPoint (SHAKE256 sampler) | Testnet only | Built and KAT-verified (12/12) on isolated testnet. NOT on mainnet 2800, re-confirmed by the same measurement. Founder- and audit-gated. |
| `0x0AE8` | BabyBear/FRI STARK verify (skeleton) | Reference skeleton only | Non-working, fail-closed by construction (returns empty for every input). Not deployed on mainnet and explicitly must not be activated until the crypto core is ported. Scope caveat (2026-07-19 finding): the generic components confirmed so far verify BabyBear + FRI STARKs (Aere's OWN Plonky3 circuits), NOT SP1 6.1.0, which is Hypercube (KoalaBear multilinear); retargeting to SP1 6.1.0 is a separate ~22 to 32 person-week effort. See `AERE-STARK-SP1-RECURSION-AIR-PORT-SPEC-SUMMARY.md`. |
| `0x100` | P256Verify / secp256r1 (EIP-7951, formerly RIP-7212) | Live on mainnet | Native P-256 signature verification for passkeys/WebAuthn. Gas **6,900**, measured on the live chain 2026-07-19. **Corrected: this row previously read "about 3,450 gas". That was the original RIP-7212 price, which was doubled to 6,900 when the proposal was standardized into Ethereum's Osaka as EIP-7951.** Active from the Osaka/Fusaka ruleset (`osakaTime = 1780220351`, block 2,106,597). Standards-aligned, not Aere-proprietary. Verified semantics: a valid signature returns a 32-byte `0x..01`; an invalid one returns **empty** (not a zero word, which is how the `0x0AE1`..`0x0AE4` band fails), and the full 6,900 gas is charged either way. Signature malleability is **not** restricted: both the low-s and high-s forms of the same signature verify, matching the spec. Cross-client confirmed: the Nethermind second client returns byte-identical results and charges identical gas. |
All post-quantum precompiles are signature/hash/KEM verifiers on the EVM path. None of them make Aere's consensus post-quantum: mainnet 2800 still seals blocks with classical secp256k1 QBFT.
**Warm/cold note.** The inherited Ethereum precompiles (`0x01`..`0x0A`) and the EIP-7951 verifier at `0x100` are pre-warmed under EIP-2929, so a call to them pays the 100 gas warm-access charge. The Aere-specific band at `0x0AE1`..`0x0AE5` is **not** in the pre-warmed set: a first call in a transaction pays the 2,600 gas cold-account charge on top of the verify price. Measured 2026-07-19. Budget for it when sizing a PQC-verifying transaction.
---
## Deliberate deviations recap
The intentional differences from Ethereum, all a consequence of Aere being a QBFT chain with no beacon layer and no blob market:
1. **Base fee floor plus a validator-reward burn, not a consensus base-fee burn.** Aere applies a 1 Gwei EIP-1559 base-fee floor (live since block 10,141,734). Separately, Aere's "burn" is a cut of the validator coinbase block reward (37.5% under the current configuration, hard-capped at 50%), routed through the `AereCoinbaseSplitterV2` splitter into immutable destinations. This must not be described as a base-fee burn.
**Burn parameters confirmed on chain 2026-07-19** by reading the deployed `AereCoinbaseSplitterV2` at `0x8C1A48eFA57b66fEE743A00E3899c29ad3Fd27b4`: `burnBps() = 3750` (37.5%), `MAX_BURN_BPS() = 5000` (the 50% ceiling), `sinkBps() = 1500`, `MAX_SINK_BPS() = 3000`, `rebateBps() = 4750`. Every figure matches the documented configuration exactly, and `3750 + 1500 + 4750 = 10000` closes.
Two structural facts confirm the separation is real rather than editorial. First, the live block **coinbase is a plain EOA with no code** (`eth_getCode` on the block `miner` returns `0x`), so nothing is deducted from the reward by consensus -- the split happens only when a forwarder sends the reward on to the splitter, which is application-layer wiring above consensus, exactly as described. Second, the base fee is separately confirmed **not credited to that coinbase** (open flag 2), so the two mechanisms do not touch. [MEASURE: `AereCoinbaseSplitterV2.totalBurned()` currently reads **0**, while the older V1 splitter at `0xb4b0eCe9011613A5b84248a9B42a0f309E6F01Ec` reads 137,352,594,046,167,719 wei burned. So V2 is deployed and correctly configured but has not yet received flow; the burn described here is live as a configuration and as a V1 flow, and the V2 path is not yet carrying volume. Confirm the forwarder's current target before describing V2 as the operative path.]
2. **EIP-4844 blobs present, EIP-7516 BLOBBASEFEE pinned at 1 wei.** Blob transactions exist in the EVM, but there is no blob data-availability market, so no blob is ever included, `excessBlobGas` never rises above 0, and the blob base fee sits permanently at the EIP-4844 floor of 1 wei. It is not 0 and the opcode is not neutralized. *(Corrected 2026-07-19; this recap previously said 0.)*
3. **EIP-4788 parent beacon block root returns 0x0.** A QBFT chain has no separate beacon/consensus layer to source a root from.
4. **EIP-3074 not implemented, superseded by EIP-7702.** EIP-7702 is the EOA-delegation primitive Aere carries.
5. **PeerDAS (EIP-7594), FOCIL (EIP-7805), and EOF (EIP-7692) have no active role under QBFT.** PeerDAS has no data-availability role (no blob market), FOCIL has no fork-choice/proposer-inclusion layer to enforce, and EOF is not activated under the current ruleset (0xEF stays reserved by EIP-3541).
6. **Validator-lifecycle requests (EIP-6110/7002/7251/7685) have no beacon consumer.** The requests ruleset is tracked for Pectra parity, but Aere's validator set is QBFT-managed, so deposits/withdrawals/consolidations do not drive it.
7. **EIP-2935 became functionally live at the AerePQC fork (block 9,189,161), not at Pectra.** The Pectra ruleset nominally listed it, but the history-storage contract was not populated on mainnet until the write path shipped in the AerePQC fork.
---
## Closed by measurement on 2026-07-19
These were open [VERIFY] flags. They are now measurements, not prices.
1. **Pectra/Fusaka block heights.** Closed. Measured **2,075,341** and **2,106,597**, by reading block timestamps either side of each activation instant and cross-checking against the first appearance of `requestsHash`. The previously published 2,075,363 and 2,106,606 were wrong and have been corrected throughout this document.
2. **P256Verify gas.** Closed, and the previous figure was wrong. Measured **6,900**, not 3,450. The precompile is live, verifies correctly, fails closed with an empty return, and does not restrict signature malleability.
3. **EIP-1108 alt_bn128 pricing.** Closed. Measured `ecAdd` 150, `ecMul` 6,000, `ecPairing` 45,000 + 34,000 per pair, that is, the post-1108 schedule.
4. **EIP-7516 blob base fee.** Closed, and the previous claim was wrong. It is 1 wei (the EIP-4844 floor), not 0.
## System contract population on mainnet (measured 2026-07-19)
`eth_getCode` at `latest` on chain 2800. This closes most of what was open flag 4.
| Contract | Address | Code on mainnet |
|---|---|---|
| EIP-2935 history storage | `0x0000F90827F1C53a10cb7A02335B175320002935` | **83 bytes** (populated) |
| EIP-7002 withdrawal requests | `0x00000961Ef480Eb55e80D19ad83579A64c007002` | **none** |
| EIP-7251 consolidation requests | `0x0000BBdDc7CE488642fb579F8B00f3a590007251` | **none** |
| EIP-6110 deposit contract | `0x00000000219ab540356cBB839Cbe05303d7705Fa` | **none** |
| EIP-4788 beacon roots ring buffer | `0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02` | **none** |
Live mainnet block headers **do** carry `requestsHash`, and it is always `sha256("") = 0xe3b0c442...b7852b855`, the empty-requests hash. Besu computes that hash without executing the absent predeploys. This exact combination (a `requestsHash` in the header, but no code at the request predeploys) is what halted the Nethermind second client on 2026-07-19; see the cross-client write-up.
Because the EIP-4788 ring buffer has no code, a call to it succeeds with **empty** returndata rather than returning a zero word. Consumers that decode the result as a `bytes32` will see `0x00..00`, which is why the EIP-4788 row above is described as returning `0x0`, but the distinction matters to a contract that checks `returndatasize`.
## Open [VERIFY] flags: facts published as NOT MEASURED
**Second validation pass, 2026-07-19 (independent re-measurement).** All five flags below were re-attacked directly against the live chain. **Three are now closed by measurement, one is narrowed, and one remains genuinely open.** The instrument was re-calibrated from scratch before any of it was trusted (see the method appendix).
1. ~~**EOF off under `futureEips`.**~~ **CLOSED by measurement.** This no longer rests on indirect corroboration. Executing candidate code at head through `eth_call` with a state override: the EOF v1 container magic `0xef0001...` is rejected with `Invalid opcode: 0xef` (so EIP-3540 container validation is not parsing it), and the EOF-only opcodes `RJUMP` (`0xe0`), `CALLF` (`0xe3`) and `EXTCALL` (`0xf8`) are each rejected as `Invalid opcode` (so the EOF opcode set is not enabled). Five independent probes, all fail-closed. **EOF is not activated**, and `0xEF` stays reserved by EIP-3541 legacy behavior. This was the highest-risk open item because the milestone rides Besu's `futureEips` key; it is settled.
2. **EIP-1559 base-fee disposal.** **Narrowed, still open.** Ruled out: the base fee is **not credited to the coinbase**. Measured on block 10,487,561 (1 transaction, `gasUsed` 22,474, `effectiveGasPrice` 1 Gwei, i.e. equal to `baseFeePerGas`, so the priority tip was zero): the coinbase balance delta across that block was **exactly 0 wei**, where crediting the base fee would have moved 22,474,000,000,000 wei. Because the tip was zero, this cannot by itself separate "protocol-burned" from "routed elsewhere" -- both models predict a zero delta. Closing it needs a block with a **nonzero** priority tip and unpruned state. The chain is currently quiet (no logs in the last 5,000 blocks), and the one tipped transaction located, `0xb659...9ec1` at block 9,200,542 (tip 0.1 Gwei), sits below the public RPC's pruning horizon so its balances cannot be read. Either run the check on the archive node or read the client source.
3. ~~**EIP-2935 contract bytes.**~~ **CLOSED by measurement, two ways.** (a) *Byte level*: the 83 bytes at `0x0000F90827F1C53a10cb7A02335B175320002935` are byte-for-byte the canonical EIP-2935 runtime `0x3373...fffe14604657602036036042575f35600143038111604257611fff81430311604257611fff9006545f5260205ff35b5f5ffd5b5f35611fff60014303065500`. Disassembly confirms the two jump targets are the `JUMPDEST` at `0x42` (revert path) and the `JUMPDEST` at `0x46` (the `SSTORE` path taken when `caller == SYSTEM_ADDRESS`), and the length is exactly 83 bytes. (b) *Functional level, which is stronger*: calling the contract with the block number of `head - 100` returns that block's hash, byte-identical to `eth_getBlockByNumber`. The ring buffer is not merely populated, it is serving correct history.
4. **EIP-7939 activation height.** **Partially closed.** The opcode itself is confirmed **live and correct at head** *(measured)*: `PUSH1 0x01; CLZ` returns 255 and `PUSH0; CLZ` returns 256. Only the *boundary* remains unverified -- whether CLZ turned on at the AerePQC milestone (block 9,189,161) or at Osaka (block 2,106,597) -- and that is still not probeable by `eth_call` because the public RPC has pruned state at both heights. Needs the archive node or a source read.
5. ~~**EIP-198 / EIP-2565 / EIP-7883 modexp pricing.**~~ **CLOSED by measurement, and the answer is specific.** A minimal `b=8, e=9, m=10` modexp call costs **500** gas. EIP-2565's floor is 200 and EIP-7883's is 500, so **EIP-7883 (Osaka) modexp repricing is live** and EIP-2565-only pricing is ruled out. The concern that motivated this flag was well founded in kind: a client left on the EIP-2565 schedule undercharges modexp by 300 gas at the floor and would diverge on any modexp-using transaction.
**Newly measured in this pass and previously unstated:** EIP-2537 BLS12-381 prices (`G1ADD` 375, `G2ADD` 600, `MAP_FP_TO_G1` 5,500, `MAP_FP2_TO_G2` 23,800, all exactly the spec schedule); EIP-152 blake2f per-round price (cost == rounds, verified at 12 and 100 rounds); EIP-7702 delegation resolution (the `0xef0100` designator executes the target, non-designator `0xEF` forms are rejected); EIP-1153 and EIP-5656 confirmed by execution rather than by ruleset membership; and the complete `0x0AE5` SHAKE256 gas model fitted across 10 shapes with zero residual.
## How the measured gas figures were produced
Every gas figure marked *(measured)* came from the same read-only technique, and it is worth stating because the obvious techniques do not work here.
**What does not work.** `eth_estimateGas` returns a binary-search result with a small buffer (it reported 66,845 where the true cost is 66,000), and EIP-7623's calldata floor can mask a precompile's price entirely: a 160-byte call to `0x100` costs the same whether or not the precompile exists, because the floor dominates. Neither is precise enough to distinguish a 3,450 gas price from a 6,900 gas one.
**What works.** An `eth_call` with a **state override** that installs a small bytecode probe at a scratch address. The probe reads `GAS`, performs a `STATICCALL` to the target, reads `GAS` again, and returns the difference along with the call's success flag and `RETURNDATASIZE`. Inside the EVM there is no calldata floor, so the difference is the true charged cost plus a fixed harness overhead. That overhead is then calibrated away using two precompiles whose prices are fixed by spec and cannot drift: `ecRecover` at a flat 3,000 and the identity precompile at 15 + 3 per word. Both calibrations agreed on an overhead of 127 gas (100 warm-access plus 27 of probe opcodes), and the identity precompile then read back its spec price of 30 exactly. Residual noise is under 15 gas, from memory expansion inside the measured window, which is far below the margins being distinguished.
**A trap worth recording.** The `BASEFEE` opcode returns **0** inside `eth_call` on this chain, even though the block header and `eth_feeHistory` both report 1 Gwei. Besu simulates calls against a zero base fee. So `eth_call` is not admissible evidence about `BASEFEE` or `BLOBBASEFEE`, and the blob base fee in this document was established from `eth_feeHistory` and the header's `excessBlobGas` instead, not from the opcode. Any future probe of a fee-context opcode needs the same caution.
**Recalibration note (2026-07-19, second pass).** The method reproduces, but the *overhead constant is a property of the probe, not of the chain*, and should not be treated as a checkable figure. The second pass rebuilt the probe independently -- `CALLDATACOPY`, a pre-warming `STATICCALL`, `GAS`, `STATICCALL`, `GAS`, `SWAP1`, `SUB`, `MSTORE`, `RETURN` -- and calibrated to a fixed overhead of **117** gas (100 warm-access plus 17 gas of probe opcodes), not the 127 recorded above, because it uses a slightly shorter opcode sequence between the two `GAS` reads. The calibration itself was exact in a way worth stating as the acceptance bar: against the identity precompile at `15 + 3 * ceil(len/32)` the implied overhead was **117 at every input length tested** (0, 32, 64, 96, 128 and 160 bytes) with no drift, an empty-address control read **exactly 117**, and `ecRecover` read back its flat spec price of **3,000** exactly. Residual noise was zero, not merely small. Anyone rebuilding the probe should calibrate their own constant the same way and only trust the instrument once the control and a spec-fixed price both come back exact -- the number to reproduce is the *measured price* after subtraction, not the overhead.
The probe scripts are throwaway and were not committed. What is reproducible is the method plus the calibration constants above; anyone can rebuild the probe and should get the same numbers against `https://rpc.aere.network`.
Reference in New Issue View Git Blame Copy Permalink