aere-docs/AERE-SHADOW-PRODUCER.md

Aere Shadow Block Producer

Technical specification. Chain 2800 (Aere Network mainnet).

Grounding and consistency: this document describes a live compliance monitor that generalizes the offline determinism proofs already in the repository. It is consistent by construction with aerenew/parallel-executor/README.md (the Block-STM correctness guarantee), aerenew/parallel/combined-fork-binary/VALIDATION_REPORT.md (the forked-Besu commit path, 253 real blocks re-imported with zero state-root mismatch), and aerenew/docs/AERE-CROSS-CLIENT-DETERMINISM.md (two independent clients computing byte-identical block hashes and state roots). Where those documents and this one describe the same status, they say the same thing. If they ever diverge, the cross-client determinism doc and the engineering security spec are authoritative and this document is wrong.

The runnable component lives in aerenew/shadow-producer/ (shadow-producer.mjs, blockstm-adapter.mjs, and its logs/).

---

1. Why a shadow producer, and the honest scope

1.1 The gap between an offline proof and a live guarantee

Aere already has strong offline evidence that parallel execution is safe. The Block-STM executor is proven bit-identical to sequential execution over 6000 randomized comparisons (aerenew/parallel-executor/), the forked-Besu commit path re-imported 253 real exported blocks with zero state-root mismatch (aerenew/parallel/), and two independent clients compute byte-identical block hashes and state roots (aerenew/docs/AERE-CROSS-CLIENT-DETERMINISM.md). Each of those is an offline, bounded, after-the-fact proof.

What none of them is, on its own, is a continuously armed live check that watches the canonical chain as it advances and asserts, block by block, that an independent re-derivation still agrees. The cross-client determinism doc names exactly this gap in its section 4: the cross-check "is not yet wired into production monitoring as an automated, alerting fail-safe". The shadow producer is the component that closes it.

1.2 What it is, in one sentence

A read-only process that re-derives each canonical chain-2800 block independently and raises a divergence alarm the moment its re-derivation disagrees with what the live sequential Besu producer committed.

It is a monitor. It runs alongside the chain, never in front of it.

1.3 What this does NOT claim (read this, it is load-bearing)

• It does NOT claim parallel execution is live on Aere L1. It is not. The canonical chain is produced SEQUENTIALLY by the forked Hyperledger Besu producer. Nothing in this component changes how the L1 executes blocks.
• It does NOT produce the canonical chain. The shadow producer seals no block, casts no consensus vote, and gossips nothing. It issues only read-only eth_* and qbft_* calls. It cannot affect consensus, by construction, because it writes nothing that consensus reads.
• It does NOT change the consensus model. Consensus stays classical secp256k1 ECDSA QBFT. It is not post-quantum. This monitor does not touch that surface.
• It does NOT, by itself, authorize enabling parallel execution on L1. That decision stays founder gated and audit gated. This component is the evidence-gathering step that would inform such a decision, not the decision.

The value delivered is real and bounded: an independent, live, continuously runnable re-derivation of the canonical chain whose disagreement with the producer is detectable rather than silent.

---

2. Architecture

The pipeline is four stages: fetch canonical, re-derive independently, diff, alarm.

   live chain 2800 (sequential Besu producer, ECDSA QBFT)
            |
            |  read-only eth_getBlockByNumber / eth_getStorageAt / qbft_getValidatorsByBlockNumber
            v
   +-------------------- shadow producer (monitor) --------------------+
   |                                                                   |
   |  Phase A  recompute QBFT block hash from header fields            |
   |           recover committed seals -> quorum (set as-of-block)     |
   |                                                                   |
   |  Phase B  re-derive the empty-block state delta                   |
   |           history[(n-1) % 8191] == blockhash(n-1)  (EIP-2935)     |
   |                                                                   |
   |  Phase C  replay transactions through the Block-STM parallel      |
   |           executor -> full world-state root  [MEASURE]            |
   |                                                                   |
   +----------------------------- diff --------------------------------+
            |
            |  any mismatch
            v
      DIVERGENCE ALARM  (halt-and-investigate signal; never forks the chain)

2.1 Phase A: structural re-derivation of the block hash [FRESH]

For each monitored block the shadow producer fetches the canonical header, then recomputes the QBFT on-chain block hash from the header fields using the same EXCLUDE_COMMIT_SEALS_AND_ROUND_NUMBER extraData re-encoding that the Besu fork uses (BftBlockHashing), and asserts the recomputed hash equals the RPC-reported blockHash. It then recovers each 65-byte committed seal to a distinct validator address and requires the recovered-signer count to meet the QBFT quorum ceil(2N/3) for the validator set VALID AT THAT BLOCK.

The per-block validator set matters and is a real correctness point. The chain-2800 validator set grew over its history (N=3 in the early range, N=7 today), so a seal quorum check that used the current set on a historical block would be wrong. The monitor queries qbft_getValidatorsByBlockNumber at each block's height and checks seals against that set with that block's quorum.

This phase proves the fetch plus consensus-hashing path is byte-correct. It runs live and read-only with no client build. It reuses the exact byte layouts from aerenew/conformance/lib.mjs, so it is consistent with the executable conformance suite by construction.

2.2 Phase B: empty-block state-delta re-derivation [FRESH]

Organic chain-2800 blocks are near-empty. For a post-EIP-2935 empty block the ONLY state transition is a single system SSTORE into the EIP-2935 history ring: the parent block hash is written to slot (n-1) % 8191 of the history contract 0x0000F90827F1C53a10cb7A02335B175320002935. The shadow producer re-derives that one delta from first principles (the parent hash, the ring index) and asserts it matches the value the history contract actually stores. This is a real, if partial, re-derivation of the block's committed state delta, and it runs live and read-only.

It is verifiable only inside the recent window: the ring holds the last 8191 hashes at latest, and the public RPC is not archival, so historical slots are legitimately out of window and are reported as skipped, not as divergences. Pre-EIP-2935 empty blocks (before block 9,189,161) have a constant state root and are skipped as pre-fork. This behavior was measured directly (empty pre-fork blocks 1000..1005 share one state root; each post-fork empty block advances the state root by exactly the one ring write), and the monitor encodes that measured fact.

2.3 Phase C: full parallel re-execution [MEASURE]

The complete check is: take the parent world state as of block n-1, replay block n's transactions through the Block-STM parallel executor, recompute the full Merkle-Patricia world-state root, and diff it against the canonical stateRoot in the header. This is the strong check, because a matching state root means every transaction, reward, and fee rule was applied identically.

It is honestly marked [MEASURE], because it needs infrastructure the read-only monitor does not carry: a full-state (archive) node holding the parent world state, and a client-grade parallel EVM. blockstm-adapter.mjs produces an inspectable re-execution PLAN for each block (transaction set, parent state root needed, canonical state root to match, and the exact command a full-state harness would run) without pretending the heavy step has happened.

There are two backends, and the adapter is explicit about which is which:

• The standalone Rust Block-STM (aerenew/parallel-executor/) proves the CONCURRENCY CONTROL is serializable, but its state model is balances plus key/value slots with a fixed transaction-kind set and a flat keccak root, not the full EVM with an MPT. It is the right tool to prove the scheduler is correct and the wrong tool to reproduce an L1 state root. The adapter deliberately does not map arbitrary EVM calldata onto that toy model, because that translation would be unfaithful.
• The forked-Besu Block-STM commit path (aerenew/parallel/) is the client-grade backend: the real Besu EVM plus the parallel executor and commit. It already re-imported 253 real exported blocks with zero state-root mismatch. A faithful Phase C reproduction of a live block's state root runs on that path, on a scratch full-state node, and NEVER on the live producer or the infra box.

---

3. Why it is a zero-risk on-ramp to L1 parallel execution

The shadow producer is the safest possible way to accumulate real, live evidence about parallel execution, for one structural reason: it runs alongside the chain and never produces it.

• It writes nothing on-chain. It seals no block and casts no vote. Consensus never reads anything the monitor produces, so a bug in the monitor, up to and including a wrong re-derivation, cannot change the canonical chain, cannot fork it, and cannot halt it. The worst a monitor bug can do is raise a false alarm, which is a human-investigated signal, not a consensus action.
• It is read-only against the RPC. It issues only eth_* and qbft_* reads. It holds no validator key and touches no producer path.
• Its failure posture is halt-and-investigate, not fork. A detected divergence is a signal to stop trusting the divergent block until a human has looked, exactly the posture the cross-client determinism doc records for the chain itself (zero forks observed in all fault testing; the chain halts and later recovers rather than forking).

The on-ramp is therefore: run the monitor live and read-only for as long as wanted, gathering a continuous record that an independent parallel re-derivation agrees with the sequential producer block by block, at zero risk to the live chain. Only after that evidence exists, and only behind the founder and audit gates, could enabling parallel execution on the actual producer ever be proposed. The monitor is the evidence; it is not the flip, and running it does not bring the flip any closer than the founder and the auditors decide it does.

---

4. Relationship to the existing evidence

The shadow producer does not reinvent any determinism proof. It is the live consumer and generalization of three existing artifacts.

• Block-STM correctness (aerenew/parallel-executor/). The executor is proven bit-identical to sequential execution. That is the property that makes a parallel re-derivation a valid check at all: if the parallel executor could disagree with sequential on correct inputs, its "divergence" would be meaningless. Because it cannot, a Phase C divergence would point at the chain, not at the checker.
• Forked-Besu commit path (aerenew/parallel/). The 253-block zero-mismatch re-import is the offline precedent for Phase C. The shadow producer generalizes that from "re-import a fixed export and check the roots" to "re-derive live blocks as they arrive and check the roots continuously".
• Cross-client determinism monitor (aerenew/docs/AERE-CROSS-CLIENT-DETERMINISM.md). That work compares two INDEPENDENT CLIENTS (patched Besu and patched Nethermind) and shows they compute the same state. The shadow producer is a complementary axis: it compares one client's SEQUENTIAL production against a PARALLEL re-derivation of the same execution. Cross-client determinism guards against an implementation monoculture; the shadow producer guards against a sequential-versus-parallel execution divergence. Both share the same honest boundary language and the same halt-not-fork failure posture, and both are, today, cross-checks rather than automated always-armed gates.

The two monitors are designed to converge: the endpoint is a single supervised process that reads the chain at head, runs cross-client and sequential-versus-parallel re-derivations, and alarms on the first byte of divergence.

---

5. Honest status

PROVEN, live and read-only (Phase A and Phase B). On the latest run (2026-07-19, chain 2800 at head near 10,364,611), the shadow producer re-derived the canonical block hash of every monitored block, byte-for-byte, across a spread covering the whole chain including the EIP-2935 activation (block 9,189,161) and the base-fee floor fork (block 10,141,734), plus a recent contiguous window at the live edge. It recovered committed seals to quorum against the validator set valid at each block (2 of 3 on early N=3 blocks, 5 of 7 on current N=7 blocks). It re-derived the EIP-2935 empty-block state delta for 17 recent blocks. Divergences: zero. The non-vacuity self-test passes: a genuine block re-derives, and a one-byte tamper of a hashed header field is caught. Raw logs are in aerenew/shadow-producer/logs/.

[MEASURE], the full parallel re-execution (Phase C). Reproducing a live block's full world-state root by replaying its transactions through the forked-Besu parallel executor against real parent state is scaffolded, not run here. It needs a full-state node and the client-grade parallel EVM, on a scratch box, never on the live producer. The adapter emits the plan and the exact command; the offline precedent is the 253-block zero-mismatch re-import in aerenew/parallel/.

NOT a producer, NOT a live automated gate, NOT L1 parallel execution. The shadow producer produces nothing on the canonical chain. It is a monitor that is run and checked; it is not yet wired as a continuously armed, always-alerting production fail-safe, and the L1 producer remains sequential Besu. Enabling parallel execution on L1 stays a separate, founder-gated, audit-gated change, not started and not authorized by this document.

Public-copy rule that travels with this status: the shadow producer is a read-only compliance monitor that independently re-derives canonical chain-2800 blocks. Do not write "parallel execution is live", "parallel L1", or anything implying the monitor produces or seals blocks. Never claim mainnet consensus is post-quantum; it is classical secp256k1 ECDSA QBFT.

---

6. Reproduction

Read-only against the live reference; needs only ethers v6, resolved from the repo's existing installs (no npm install in this directory).

cd aerenew/shadow-producer

# default monitor: spread across the chain + recent window
node shadow-producer.mjs

# a contiguous range, or the last K blocks at the live edge
node shadow-producer.mjs --from 1 --to 2000
node shadow-producer.mjs --recent 32

# emit the Phase C [MEASURE] re-execution plans alongside A and B
node shadow-producer.mjs --recent 4 --reexec

# non-vacuity self-test: genuine re-derives, tamper is caught
node shadow-producer.mjs --selftest

Exit 0 means every checked block re-derived identically. Exit 1 means a divergence alarm fired (or an error). For the [MEASURE] Phase C, follow the printed plan on a full-state scratch node running the forked-Besu parallel executor from aerenew/parallel/; assert the recomputed state root equals the canonical header value, exactly as the 253-block re-import did offline.

---

7. Summary

The shadow block producer turns Aere's offline determinism proofs into a live, read-only monitor that re-derives each canonical chain-2800 block and would raise a divergence alarm on the first mismatch. Today it proves, live, that the block hash and the empty-block state delta re-derive identically to the canonical chain, with a non-vacuous alarm; the full parallel re-execution against real world state is scaffolded and marked [MEASURE], with a 253-block zero-mismatch offline precedent. It is a zero-risk on-ramp precisely because it never produces the canonical chain: it runs alongside, writes nothing consensus reads, and fails to halt-and-investigate rather than to fork. The canonical chain is still produced sequentially by Besu, parallel execution is not enabled on L1, and enabling it stays founder and audit gated. This monitor is the evidence, not the flip.