db/state: prune TemporalMemBatch overlay entries past unwindToTxNum

[mh0lt]

Summary

Fix a post-unwind stale-read in the in-memory domain overlay that causes gas-used mismatches on post-Fusaka mainnet catch-up.

TemporalMemBatch stores per-key overlay writes as []dataWithTxNum, each entry stamped with its write txNum. getLatest returns dataWithTxNums[len-1] — the most recently appended entry — without comparing it against sd.unwindToTxNum. Unwind() only recorded unwindToTxNum + an unwindChangeset; it never touched sd.domains / sd.storage. Since unwindChangeset is consulted only when the overlay misses, any key still present in the overlay kept returning a pre-unwind write made inside the unwound txNum range.

Observed symptom

Post-Fusaka mainnet catch-up, after a forkchoice-driven unwind. The first re-executed block reads a storage slot that was first-written inside the unwound range. The overlay returns the post-target write, flipping the SSTORE cost from SET (20000) to RESET (2900) — exactly a 17100-gas shortfall per affected slot.

• Block 24,898,955: diff=-34200 (2 slots × 17100)
• Block 24,899,403: diff=-73829 (compound — several slots affected)

Live trace instrumentation (not shipped) captured 3,082 SD_STALE_READ events between an unwind at txNum=3454259398 and the resulting mismatch at block 24,899,403.

Fix

On Unwind, walk sd.domains and sd.storage and drop any dataWithTxNum whose txNum > unwindToTxNum. If a key's slice empties out, delete the key so the unwindChangeset fallback (or the underlying tx) supplies the pre-unwind answer. Runs under sd.latestStateLock so the transition is atomic to concurrent reads. Storage-btree mutations are staged after Scan to respect btree iterator rules.

Regression test

TestSharedDomain_UnwindDoesNotRestoreOverlayForNewKey in db/state/execctx/domain_shared_test.go:

• writes a first-time storage value at txNum=100
• calls Unwind(50)
• asserts the overlay no longer returns the post-target write

Test fails on pre-fix code with the exact error that mirrors the mainnet symptom; passes with this change.

Test plan

• go test -short ./db/state/... — all pass
• make lint — 0 issues
• make erigon — builds clean
• Manual sync verification: post-Fusaka mainnet with chaindata/ wiped and snapshots/ retained (same repro that produced block-24,899,403 mismatch) — sync progresses past the catch-up / first-forkchoice-unwind window without a gas mismatch.

Known adjacent issues, out of scope

DB-layer siblings of this bug exist separately and are not addressed here:

1. db/state/domain.go:1317 — on-disk unwind currently conflates nil ("different step, skip") and []byte{} ("key was absent, write tombstone") via if len(value) > 0, so first-time writes in the unwound range leave no restoring tombstone.
2. db/state/domain.go:1665 — getLatestFromDb discards deletion markers at a step within file range, so the caller falls through to getLatestFromFiles, which has no concept of deletions and returns stale pre-deletion data.

Both were previously addressed by #20483 and reverted by #20509 while regressions were investigated. They need their own narrower fixes with dedicated regression guards and should be staged as separate PRs so they're independently revertible.

🤖 Generated with Claude Code

[sudeepdino008]

getLatestFromFiles, which has no concept of deletions and returns stale pre-deletion data.

files do have notion of deleted keys vs missing keys