From bd35b7f42c2cce218e6560a42dffa67a60de7b1b Mon Sep 17 00:00:00 2001 From: Aere Network Date: Sun, 27 Sep 2026 09:53:53 +0300 Subject: [PATCH] Cross-client determinism + engineering security spec: the second client is the tenth validator of chain 2800 since 2026-09-11 (dated corrections 2026-09-27) --- AERE-CROSS-CLIENT-DETERMINISM.md | 24 +++++++++++++++--------- AERE-ENGINEERING-SECURITY-SPEC.md | 4 ++-- 2 files changed, 17 insertions(+), 11 deletions(-) diff --git a/AERE-CROSS-CLIENT-DETERMINISM.md b/AERE-CROSS-CLIENT-DETERMINISM.md index 009d040..804e95c 100644 --- a/AERE-CROSS-CLIENT-DETERMINISM.md +++ b/AERE-CROSS-CLIENT-DETERMINISM.md @@ -37,8 +37,11 @@ second-client program exists to retire, and it is the reason `AERE-ENGINEERING-S section 4.2 records "a single producing client is a demonstrated systemic risk" as the design driver. -Aere's live mainnet today runs one production client: a fork of Hyperledger Besu v26.4.0 -(base commit d2032017, JDK 21), the sole producer for all seven QBFT validators. A second, +Aere's live mainnet ran one production client, a fork of Hyperledger Besu v26.4.0 +(base commit d2032017, JDK 21), as the sole producer for all of its QBFT validators until +2026-09-11; since then the Nethermind client described here is the tenth validator and produces +blocks alongside nine Besu validators (correction 2026-09-27; what follows describes the +follower phase and the determinism evidence, which still holds). A second, independent implementation that computes the same state from the same inputs turns "trust the one client" into "two independent implementations agree", which is a materially different and stronger assurance. @@ -59,9 +62,10 @@ This document proves one specific property: This document does **not** claim any of the following, and the reader should not infer them: -- It does **not** claim Nethermind is a live producing validator on mainnet. It is not. - Nethermind runs as a non-validating follower and as a cross-check; it takes zero part in - live consensus. Besu remains the sole live producer. +- It did **not**, when written, claim Nethermind was a live producing validator on mainnet; + at that time Nethermind ran as a non-validating follower and cross-check, took zero part in + live consensus, and Besu was the sole live producer. Since 2026-09-11 Nethermind is the tenth + validator of chain 2800 and produces blocks (correction 2026-09-27). - It does **not** claim client-diverse consensus or a "two-client mainnet". Making Nethermind a live sealer is a separate, founder-gated, high-risk change documented in `DECENTRALIZATION-2ND-CLIENT-RUNBOOK.md` Phase B, not started and not authorized here. @@ -325,10 +329,12 @@ monitoring as an automated, alerting fail-safe that watches Besu and Nethermind and raises an alarm on the first byte of divergence. Today the comparison is run and spot-checked; it is not a continuously-armed live gate. -**NOT yet a live producing validator.** Nethermind is a non-validating follower and a -cross-check. It takes zero part in live consensus. Besu is the sole live producer on chain -2800. A Nethermind disagreement flags a discrepancy against the producer; it does not arbitrate -consensus, because Nethermind casts no vote and seals no block on mainnet. +**A live producing validator since 2026-09-11 (correction 2026-09-27).** When this document was +written Nethermind was a non-validating follower and a cross-check, took no part in live +consensus, and Besu was the sole live producer on chain 2800. Since 2026-09-11 Nethermind is the +tenth validator: it votes, proposes and seals blocks on mainnet, so a disagreement is no longer +only a flag against the producer, it is a vote inside consensus; the chain's liveness still +depends on the nine Besu validators. **Behavior on a detected divergence.** This is a fail-safe, not an automatic consensus action. A detected divergence is a signal to halt and investigate before the divergent block is diff --git a/AERE-ENGINEERING-SECURITY-SPEC.md b/AERE-ENGINEERING-SECURITY-SPEC.md index 937a0ad..11ad7ef 100644 --- a/AERE-ENGINEERING-SECURITY-SPEC.md +++ b/AERE-ENGINEERING-SECURITY-SPEC.md @@ -172,7 +172,7 @@ This section records, for each load-bearing architecture decision, what was chos **Why not Reth.** Two reasons, one structural and one empirical. Structurally, Besu already ships QBFT, and QBFT block production is Besu-specific: no off-the-shelf Geth, Reth, Erigon, or stock Nethermind produces QBFT-compatible blocks. Choosing Reth would have meant building QBFT production into a client that has no notion of it, before we could produce a single block. Besu also already carried the codebase into which our PQC precompile fork and base-fee changes were integrated. Empirically, a single producing client is a demonstrated systemic risk: the September 2025 Reth halt is the reference case for why a chain that depends on one producing implementation can stop when that implementation hits a bug. That event is precisely the risk the second-client program exists to retire. -**Why Nethermind as the second client (not a second Besu).** A second Besu instance is not client diversity; it shares every bug with the first. Nethermind was chosen specifically for implementation diversity: it is a different codebase in a different language (.NET versus Besu's Java), so a consensus-relevant bug in one is unlikely to exist in the other. The patched Nethermind validates the live chain, runs the five PQC precompiles byte-for-byte identically (27 of 27 NIST KAT vectors), and, on an isolated test network, produces byte-identical QBFT blocks that stock Besu accepts through full BFT validation (with a one-byte-tampered seal rejected). The honest boundary: this cross-client production is proven on an isolated testnet (offline import and, in later work, live devp2p between test nodes), and a listen-only Nethermind follower has been run against the live network; it is not yet a live gossiping producer on chain 2800. Making it one is a founder-supervised change, because a producer bug on a live chain can halt or fork it. Besu remains the sole live producer today; the second client is a client-diversity cross-check and fail-safe, not a second live validator yet. +**Why Nethermind as the second client (not a second Besu).** A second Besu instance is not client diversity; it shares every bug with the first. Nethermind was chosen specifically for implementation diversity: it is a different codebase in a different language (.NET versus Besu's Java), so a consensus-relevant bug in one is unlikely to exist in the other. The patched Nethermind validates the live chain, runs the five PQC precompiles byte-for-byte identically (27 of 27 NIST KAT vectors), and, on an isolated test network, produces byte-identical QBFT blocks that stock Besu accepts through full BFT validation (with a one-byte-tampered seal rejected). The honest boundary: this cross-client production is proven on an isolated testnet (offline import and, in later work, live devp2p between test nodes), and a listen-only Nethermind follower has been run against the live network; it became a live producer on chain 2800 on 2026-09-11, when it was admitted as the tenth validator (correction 2026-09-27); until then Besu was the sole live producer and the second client was a cross-check and fail-safe. Nine of ten validators still run Besu, so the fault-tolerance benefit of two clients is not yet real. ### 4.3 Interoperability: Hyperlane-compatible, not IBC, plus a zk-interop path @@ -279,7 +279,7 @@ A safety-first summary that holds across every mode tested: **in all adversarial **Behavior.** The second client exists precisely to catch this. The patched Nethermind independently re-derives state: it has re-validated the full chain to genesis with zero invalid seals and re-executed real chain-2800 blocks to byte-for-byte identical block hashes and state roots (spot-checked across many heights, and, as a live listen-only follower, matched the live RPC's hash and state root at every checked height in range). Because there is exactly one definition of correct state and two independent implementations computing it, a consensus-relevant divergence between Besu and Nethermind (a differing state root, a differing block hash, a differing seal decision) is detectable by comparing the two: it does not silently pass. -**Halt / fork / continue.** This is a fail-safe (a cross-check), not an automatic consensus action. A detected divergence is a signal to halt and investigate before the divergent block is trusted, not something that itself forks or halts the live chain. Besu is the sole live producer today, so a Nethermind disagreement flags a discrepancy against the producer; it does not currently arbitrate consensus. +**Halt / fork / continue.** This is a fail-safe (a cross-check), not an automatic consensus action. A detected divergence is a signal to halt and investigate before the divergent block is trusted, not something that itself forks or halts the live chain. Until 2026-09-11 Besu was the sole live producer, so a Nethermind disagreement only flagged a discrepancy against the producer; since then Nethermind is the tenth validator and its vote counts inside consensus (correction 2026-09-27), while nine Besu validators still carry liveness. **Status.** PROVEN as a validation cross-check (full-chain re-validation, byte-identical state-root re-execution, and identical PQC precompile outputs). It is not yet a live, automated, alerting divergence gate wired into production monitoring, and Nethermind is not yet a live producing validator. Framed honestly: the second client demonstrably would detect a state divergence, and this is real client-diversity assurance; turning that into an automated live fail-safe gate is the remaining operational work.