Frozen files encode deletions as absence, so the file returns the pre-deletion value — the exact resurrection the deletion was meant to prevent

files do encode empty byte as marker for deletion. this is different from absence

Fix #1 relies on the nil vs []byte{} distinction in DomainEntryDiff.Value:

• nil → skip Put (different-step skip, legacy V0)
• []byte{} → Put empty tombstone
• non-empty → Put the actual value

Both empty cases have len() == 0, so the new if value != nil guard is the only place in this path where the distinction is load-bearing. Nothing upstream enforces it — DomainDiff.DomainUpdate at db/kv/helpers.go:288 even rewrites nil → []byte{} in the creation path, and a casual refactor that collapses empty slices to nil (a common style lint) would silently regress this.

TestDomain_UnwindRestoresDeletionMarker currently covers the []byte{} case. Worth adding a sibling subtest that explicitly uses Value: nil and asserts no entry is written at unwindStep:

diffs := []kv.DomainEntryDiff{{Key: string(k) + string(stepBytes), Value: nil}}
require.NoError(dt.unwind(ctx, tx, step, txNumUnwindTo, currentFilesEndStep, diffs))
// Expect: no (k, unwindStep, ...) entry — nil means "different step, skip"

That pins the asymmetry into the test suite so a future refactor can't silently flip the semantics back.

Force-pushed a narrowed version of this PR to address the recurring kurtosis/assertoor_glamsterdam CI failure.

Summary of the narrowing:

• Kept: the unwind() write-side fix that restores empty tombstones for first-time writes (fix Pull from go-ethereum up to 26aea73 (7 Feb 2019) #1 in the original).
• Dropped: the getLatestFromDb empty-value authority bypass (the if len(v) == 0 { return ...true } at line ~1665 of domain.go).

Why:

The glamsterdam suite is the one kurtosis configuration that runs with --experimental.bal plus the storagerefundtx + setcodetx spammers — a workload that generates a continuous deluge of empty-value tombstones in the storage domain. With the empty-authority bypass active, many more reads return (ok=true, v=[]byte{}) where they previously returned (ok=false, v=nil); some downstream consumer in the BAL / post-Amsterdam codepath is not robust to this semantic flip and the test hangs (runtime jumped from ~12 min on PR #20624/#20625 to 1h07m / 1h38m on two consecutive runs of this PR's previous version).

The unwind fix alone is sufficient for the originally-reported bug (stale reads after unwind on post-Fusaka mainnet), because the tombstone is written at max(step, currentFilesEndStep) — already beyond the file range, so the existing step-age guard accepts it without any read-path change.

TestDomain_UnwindRestoresDeletionMarker still fails on pre-fix code and passes with this narrower fix, so the regression guard is preserved.

Out of scope, tracked for follow-up:

• The read-side empty-authority bypass (needs separate narrowing to avoid the Glamsterdam regression)
• The LargeValues interrupted-prune cross-check from the original db/state: fix stale slot resurrection after unwind and deletion #20483 (the suspected original revert trigger, still deferred)

CI will re-run on the force-push — expecting glamsterdam to return to ~12min passing.

Confirmed — the narrowing works.

Local reproduction (kurtosis 1.18.1, ethereum-package 6.1.0, same glamsterdam.io config as CI):

[18:01:12] block=44 (Δ=44) stability=success proposal=success
GLAMSTERDAM_PASS

Total wall time from enclave RUNNING to both assertoor tests green: ~5 min (local hardware is more generous than the GH runner).

CI also green on the amended commit: kurtosis / assertoor_glamsterdam_test: pass (12m54s) — back to the normal 12-min envelope (versus 1h07m / 1h38m on the previous version of this PR).

So the getLatestFromDb empty-authority bypass (fix #2 in the original #20483) was indeed the trigger. Glamsterdam's storagerefundtx spammer generates thousands of empty-value storage tombstones per block via DomainDel (rw_v3.go:805). With the bypass active, every subsequent read of those slots returned (ok=true, v=[]byte{}) where previously it returned (ok=false, v=nil). Some consumer in the BAL path under --experimental.bal isn't robust to that semantic flip. The narrowing keeps only the write-side tombstone-on-unwind, which doesn't change any read semantics and is sufficient for the original mainnet stale-read bug since tombstones are written at max(step, currentFilesEndStep) — already beyond the file range.

Follow-up work captured in the commit body:

• the read-side empty-authority bypass can be re-landed with a narrower gate if a future bug reproduces the original stale-read scenario (needs the bypass), but should exclude the post-Amsterdam / --experimental.bal path
• the LargeValues interrupted-prune cross-check from the original db/state: fix stale slot resurrection after unwind and deletion #20483 remains deferred

CI Gate is not happy: https://github.com/erigontech/erigon/actions/runs/24597293981/job/71929690553