fix(stateless): audit of swallowed database errors that fabricate execution results

[Gabriel-Trintinalia]

Origin

This started as an audit, not a bug report. The invariant under test was simply a block execution must never return a wrong result, applied to the stateless witness path.

The audit looked for one specific shape: an error turned into a semantically meaningful default. It found 11 sites — 6 in WitnessDatabase and 5 in the Host accessors — where a "cannot verify" answer became a fabricated one (0, false, EMPTY_TRIE_HASH, or a failed operation) and the block was accepted anyway. Cursor Bugbot's review of the first round surfaced a further instance of the same class, which is what fix 4 below covers.

Sites that looked like instances but were verified not to be are called out as deliberately unchanged, with the reasoning, so the audit's negative results are reviewable too.

Problem

Several places turned a database error into a semantically meaningful default, so an incomplete witness produced a wrong execution result reported as success instead of a rejected block.

The MPT layer already distinguishes the two outcomes precisely: null means proved absent (mpt/main.zig calls this "valid non-inclusion"), whereas error.InvalidProof comes from findNodeInIndex(...) orelse return error.InvalidProof — the node is missing from the witness. So InvalidProof means "cannot verify", never "absent", and defaulting on it fabricates state.

basic() already handled this correctly (InvalidProof → InvalidWitness, with a documented SYSTEM_ADDRESS carve-out). The rest did not. This PR finishes that existing, deliberate design rather than introducing a new policy.

The fixes

1. storage() fabricated zeros. error.InvalidProof => return 0 made an unprovable slot read as zero, and the storage-root lookup's error.InvalidProof => break :blk EMPTY_TRIE_HASH made every slot on an unprovable account read as zero. Demonstrated by a test whose slot genuinely holds 0xabcd.

2. hasNonZeroStorageForAddress() could let an invalid CREATE succeed. catch return false fed the CREATE collision check in setupCreateCore, so an unprovable target allowed a CREATE the reference rejects — consensus-level.

3. A dropped cache entry silently changed the state root. storage_root_cache.put(...) catch {} dropped entries, and storageRootFor() is a bare get(), so a dropped entry is indistinguishable from "never loaded". computeStorageRootBatch reads that as "no pre-state storage" and rebuilds the storage trie from only the touched slots.

4. Five Host accessors swallowed the error anyway — found by Cursor Bugbot's review of this PR (thanks). Fixing storage() was not sufficient on its own: Host.sload swallowed the result with catch return null, and opSload turns null into halt(.invalid_opcode) — a consensus-visible EVM failure — so the transaction failed and the block was still accepted. Same fabricated success, wearing a different mask than the zero it replaced.

Auditing the pattern found five such sites, not the two reported: accountInfo, sload, sstore, selfdestruct, and the loadAccount in recordCreateTargetCore. All now mark ctx_error like their siblings (blockHash, codeInfo, loadAccountWithCode) already did. grep -c "catch return null;" in host.zig is now 0.

setupCreateCore returns a plain CreateSetupResult and cannot report an error, so its sites mark ctx_error — the mechanism already used at seven sites in interpreter/host.zig and checked in stateless/executor/main.zig. Infallible databases (InMemoryDB) are unaffected.

Deliberately unchanged: createAccountCheckpoint's catch in setupCreateCore. The compiler rejected an else prong there, proving its error set is exactly TransferError — all legitimate CREATE outcomes, no database error possible. Documented in place.

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{Reviewed by Cursor Bugbot for commit 01a9a70. Configure here.}

[cursor]

CREATE host tests never actually run

Medium Severity

The new setupCreateCore ctx_error test lives in host.zig, but the interpreter test root only pulls in a few opcode files. addTest collects tests from a module root and from files referenced inside a test { _ = @import(...) } block, so this case never runs — the same silent gap this PR just fixed for journal.zig.

 

^{Reviewed by Cursor Bugbot for commit 01a9a70. Configure here.}