85495f3830
Block-STM enters the kernel through the MachineInterface seam, not beside it. The one guarantee, stated as a contract and proven: parallel execution produces the byte-identical state root that serial execution produces, or the kernel refuses it. The feared failure mode is a silent state divergence under contention, and that is exactly what the negative control plants. Run 2026-08-15 (WSL, Rust release build of parallel-executor): - positive: harness reports 0 mismatches, parallel Block-STM == sequential on all profiles, seeds, and thread counts 4/8/16. - negative control: disable the validation phase (the mechanism that catches a stale read and forces re-execution) and the harness reports MISMATCH on every contended profile. So the oracle is load-bearing, not applause. No throughput number is claimed; 8-10x is proven capacity while chain 2800 blocks are empty. Parallel execution is not put on mainnet in this stage; the equality that would make that safe is proven, so the switch becomes a measured decision. One coordinated activation if it ever changes an observable, the discipline proven at block 14,050,000.
2.6 KiB
Stage 4 determinism oracle: the run and its negative control, 2026-08-15
The Stage 4 gate is the reference executor's serial-vs-parallel harness, run as a determinism
oracle. Both runs below were executed on this machine (WSL, Rust release build of
aere-research/parallel-executor), not asserted from documentation.
Positive run: parallel Block-STM == sequential
cargo build --release
./target/release/aere-block-stm harness
mismatches : 0
RESULT: PASS -- parallel Block-STM == sequential on ALL cases
Across the harness profiles (mixed-moderate and others), seeds, and thread counts (4, 8, 16), the state root produced by optimistic parallel Block-STM is byte-identical to the state root the sequential oracle produces for the same block and pre-state. Zero mismatches.
Negative control: disable validation, and the oracle goes red
Block-STM's validation phase is what catches a transaction that read a now-stale value and forces it to re-execute. It is exactly the mechanism that prevents a silent divergence. The control disables it (the validation match arm forced to report "matches" always) and rebuilds:
src/parallel.rs:198 _ => false -> _ => true /* PLANT: validation disabled */
./target/release/aere-block-stm harness
MISMATCH profile=mixed-moderate seed=0 threads=4: parallel != sequential
MISMATCH profile=mixed-moderate seed=0 threads=8: parallel != sequential
MISMATCH profile=mixed-moderate seed=0 threads=16: parallel != sequential
MISMATCH profile=mixed-moderate seed=1 threads=4: parallel != sequential
...
With validation removed, parallel execution commits a divergent state on contended traffic and the harness catches it on every profile. The source was restored immediately after.
What this proves, and what it does not
PROVES: the determinism oracle is load-bearing. A green from it means parallel and serial agree, because the same oracle demonstrably goes red the moment the safety mechanism that guarantees agreement is removed. This is the D-150 discipline applied to parallel execution: the failure mode of concern (silent state divergence under contention) is exactly the one the negative control plants and the oracle catches.
DOES NOT PROVE: a throughput number (none is claimed; blocks on 2800 are empty, so 8-10x is proven capacity, not realized debit), and does not put parallel execution on mainnet. It proves the equality that makes turning it on a measured decision rather than a hope. Turning it on, if it ever changes an observable, is one coordinated activation, the discipline proven at block 14,050,000.