diff --git a/aips/AIP-17.md b/aips/AIP-17.md index 9595390..ae6d2b6 100644 --- a/aips/AIP-17.md +++ b/aips/AIP-17.md @@ -106,9 +106,7 @@ straight past the floor block with no rejection). The corresponding weakness is the same fact stated from the other side: because the floor is not consensus-enforced, a validator running without the flag would produce blocks with a sub-Gwei base fee and no one would reject them. Consistency depends on -operational rollout to all validators, not on consensus. All seven validators are -Foundation-operated (AIP-9), so today that is an operational guarantee under one -operator. +operational rollout to all validators, not on consensus. All validators (seven at the Created date, ten since 2026-09-11) are Foundation-operated (AIP-9), so today that is an operational guarantee under one operator. **Open question, honestly flagged.** Where the EIP-1559 base fee ultimately goes on chain 2800 is **not fully resolved**. Measurement on block 10,487,561 (one diff --git a/aips/AIP-2.md b/aips/AIP-2.md index aebd1b2..3ec9904 100644 --- a/aips/AIP-2.md +++ b/aips/AIP-2.md @@ -103,8 +103,7 @@ semantics, gas accounting, or the EVM ruleset. The honest limitation of this design is that the burn is **cooperative, not protocol-enforced**. Nothing at the consensus layer compels a validator to route its coinbase through the splitter. A validator that keeps its full coinbase simply -does not burn. Today the network runs seven validators under a single operator -(the Foundation), so in practice the burn depends on Foundation-operated +does not burn. At the time of writing the network ran seven validators under a single operator (the Foundation; ten since 2026-09-11, still one operator), so in practice the burn depends on Foundation-operated infrastructure calling the splitter, not on a trustless rule. As the validator set decentralizes, making the burn a credible network-wide property will require either social/economic commitment from validators or a future Core AIP that moves diff --git a/aips/AIP-3.md b/aips/AIP-3.md index b6d4c05..fa7efba 100644 --- a/aips/AIP-3.md +++ b/aips/AIP-3.md @@ -126,8 +126,7 @@ block height, for wall-clock math. ## Security Considerations -Reducing the block period narrows the timing margin for each consensus round. With -the current seven validators under a single operator this is low-risk because +Reducing the block period narrows the timing margin for each consensus round. With the seven validators of the time (ten since 2026-09-11) under a single operator this is low-risk because network latency between the nodes is small and predictable, and QBFT finalizes within the round among a small set. The honest caveats: diff --git a/aips/AIP-7.md b/aips/AIP-7.md index 6abb249..366fde5 100644 --- a/aips/AIP-7.md +++ b/aips/AIP-7.md @@ -40,7 +40,7 @@ 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, +arithmetic, and moving that into 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 @@ -170,11 +170,7 @@ fork would be false and must not be made. Isolated-testnet work on a Falcon quor 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 +**Single operator, one client (at the Created date).** Chain 2800 ran seven QBFT validators (f=2, quorum 5-of-7), all Foundation-operated, on a single execution client (Hyperledger Besu); since 2026-09-11 it runs ten (f=3, quorum 7-of-10), still all Foundation-operated, one of them on a second, Nethermind-derived client that executes the same precompiles. At that date the validators were one operator and one client, so a consensus bug in a precompile could not be caught by client diversity, because there was no second live client; since 2026-09-11 a disagreement between the two implementations would show up as the second client diverging from the others. 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