# Execution Kernel, Stage 4: parallel execution under the MachineInterface

Stage 4 lets Block-STM optimistic parallel execution enter the kernel, but through the
MachineInterface seam of Stage 1, never beside it. The value is not the speedup, which is
capacity and not throughput while blocks are empty. The value is a single guarantee, stated as a
contract and proven with a negative control:

> **Parallel execution produces the byte-identical state root that serial execution produces,
> for the same block and the same pre-state, or the kernel refuses it.**

## Why this is the one that can hurt

The feared failure mode of parallel execution is a SILENT state divergence: two transactions
touch the same storage slot, the optimistic scheduler commits them in an order the serial
executor would not, and the resulting root differs by one slot in one block, a year from now,
under load. No unit test of the happy path finds it. Only an equality check between the two
executors, run as an oracle, finds it, and only if that check has itself been shown to catch a
planted collision.

## The contract

- **MI purity is a precondition (Stage 1).** Parallel execution is only sound if MI reads go
  exclusively through StateView and writes are invisible until commit. The StateView purity rule
  and its planted-impurity negative control from Stage 1 protect exactly this. Stage 4 does not
  re-derive that; it depends on it.
- **One vkey covers the whole state transition (borrowed from draft C).** There is no per-machine
  proof stitching. Whether a block was executed serially or in parallel, the state transition it
  proves is the same STF, under one PROGRAM_VKEY. Parallelism is an execution strategy, not a
  different machine, so it does not fork the proof.
- **Storage-key anti-aliasing, named now (borrowed from draft C).** The multi-version memory keys
  state by (address, slot). Any collapse of two distinct logical locations onto one key is a
  correctness bug, not a performance detail, and is named in the contract while it costs nothing,
  not when it bites.
- **One visible consensus change per activation (house rule from the panel).** Turning the
  AERE Block-STM engine on for mainnet, if it ever changes an observable, is one coordinated
  activation with a runbook, exactly the discipline proven at block 14,050,000.
- **The live engine, stated plainly (measured):** upstream Besu ships
  `DEFAULT_PARALLEL_TX_PROCESSING = true`, the fleet's start script does not disable it, and
  `AERE_BLOCKSTM` is unset on all nine validators. So the fleet already runs Besu's own
  parallel-capable block processor; on today's empty blocks it executes nothing in parallel, so
  no contention path is exercised in production. Setting `AERE_BLOCKSTM=1` would REPLACE that
  engine with ours, which is exactly why the determinism oracle and a real-block proof (which
  does not exist yet, and this document says so instead of implying it) must come first.

## The proof (Stage 4 gate)

The reference executor `aere-research/parallel-executor` already carries both paths
(`execute_block_sequential` as the oracle, `execute_block_parallel` as Block-STM) and a
from-scratch keccak256 state root. The Stage 4 gate is its A/B mode run as a determinism oracle:

1. **Positive:** for SYNTHETIC batches with designed contention (not real chain-2800 blocks,
   which are empty today), serial and parallel produce the
   IDENTICAL state root, across repetitions and thread counts. Same root, or the gate is red.
2. **Negative control (mandatory):** plant a divergence, a parallel path that drops one write, or
   a key-aliasing bug, and require the A/B gate to go red. A determinism oracle that has never
   disagreed is applause, not measurement.

## What the oracle's model does and does not cover

The reference executor models accounts, storage writes and a keccak state root. It does NOT
model gas accounting, receipts, or the full EVM; those live in the real engines and are covered
by the cross-client checks, not by this oracle. And the oracle runs on synthetic batches: the
proof that parallel execution reproduces REAL chain-2800 blocks does not exist yet and is held
open as a CRITIC finding in the registry (D-184) rather than implied here.

## What Stage 4 does NOT claim

- It does not claim a throughput number. 8-10x is proven CAPACITY on synthetic contended
  workloads; chain 2800 blocks are empty, so realized throughput today is not the point and no
  TPS figure is published.
- It does not put parallel execution on mainnet in this stage. It proves the equality that would
  make doing so safe, so the switch becomes a measured decision rather than a hope.
- It does not verify the SP1 proof (that is the audit layer of Stages 2 and 6); it verifies the
  execution the proof would attest.

## Status

Contract written 2026-08-15. The determinism oracle runs from the existing Rust executor; its
run and its negative control are recorded in `stage4-determinism-run.md` beside this file once the
toolchain build completes. Until that run is recorded, Stage 4 is specified and NOT yet proven,
and this sentence says so rather than implying otherwise.

---

## Stage 5 note (window narrowing): specified, blocked on a live prover

Stage 5 narrows the proof window as the cost curve from Stage 2 allows. Measured 2026-08-15:
the claim-chain detector's lag is dominated by the safety margin behind the tip (about 8 blocks),
not by proving cost, because there is no SP1 prover producing timed proofs on this machine, and
running MODE=prove is never done on aere-infra. So the cost curve that Stage 5 would narrow
against does not exist yet to be measured. Stage 5 is specified and honestly NOT measurable until
a prover produces windowed proofs with recorded wall-time. Stating this rather than publishing a
lag number that measures the ruler and not the proving cost, which is the D-150 mistake.