fix(evmc-adapter): unproven cold-account probes, and an over-strict access gate

[abmcar]

Eight of the ten blocks that failed strict differential witness replay on a
1000-block mainnet corpus (25817835–25818834) now pass, under both DTVM and
evmone. The remaining two are a DTVM JIT defect, not addressed here.

Two independent defects, plus the tracing that localised them. Base is
evmc-backend-and-replay-docs (7ced99bf0).

---

31f5326a4 — unproven cold-account probes

evmone's call_impl performs its EIP-7702 delegation lookup (copy_code) and
its new-account surcharge check (account_exists) on the CALL target before
charging CALL_VALUE_COST. REVM charges the 9000 first, and additionally skips
the cold load outright once the remaining gas cannot cover the cold-access
surcharge, so a CALL that is already out of gas never reads its target at all.

An execution witness is built from the canonical REVM execution, so those two
probes can name an account the witness does not cover — not even with an
exclusion proof. Walking the pre-state trie by hand for the account on block
25817857 hits a missing node at depth 3, so the witness can prove neither
existence nor non-existence. The bridge turned a question about a doomed
instruction into a hard witness failure: 5 of 1000 blocks (25817857, 25818392,
25818430, 25818453, 25818505), identically under DTVM and evmone.

The three read-only probes (account_exists, get_code, get_code_hash) now
answer as the non-existent, codeless account they describe, and only when the
underlying load reports that the address lies outside the proof. Every other
callback stays fatal, the error is not latched, and the predicate compares the
address named by the error, so incompleteness raised for a different account
is still fatal.

Why this is safe: the answers are mutually consistent, they can only raise the
instruction's cost, and every path on which they could still be observed —
actually performing the call, or reading that account's balance or storage —
loads the same unproven account again and fails closed there. On top of that,
WitnessDb::into_verified_post_state_root verifies the post-state root against
the target header in every replay mode, so an answer that did escape would
fail loudly rather than be silently accepted.

Verified on block 25817857: DTVM completes with 902 strict database accesses,
item-for-item equal to the REVM reference leg, post-state root verified.

Upstream evmone moved the 9000 charge ahead of the probes in v0.23; the pinned
0.18 and DTVM still carry the old order.

---

⚠ defcb61f2 + 762e33ed3 — relaxing the access-sequence gate

This is a judgment call, not a fact. It loosens a correctness gate. A
reviewer may reasonably disagree, and it can be reverted on its own: both
commits sit at the tip of this branch and touch only
witness-db/src/replay.rs (plus one diagnostic in src/host.rs), so dropping
them leaves 31f5326a4 intact and working.

The gate demanded that the subject's and the reference's strict database access
sequences be equal. The two commits together replace that with: the subject
must be an order-preserving subsequence of the reference, after splitting a
post-execution withdrawal tail off both sides and comparing that tail as a set.

The failure it fixes is the opposite of the one the gate was built to catch —
the subject reads less, not more. Our bridge answers the EIP-2929 warm-up
callbacks (access_account, access_storage) from the journal without a cold
load; REVM loads first and charges afterwards. So an instruction that runs out
of gas at the cold-access charge never issues the read on our side, while REVM
already issued it. On block 25818316 the reference makes 4055 accesses and DTVM
4054, the missing one a cold SLOAD whose 2100 gas the frame could not pay.
Blocks 25818085 and 25818686 fail the same way.

The second commit exists because block 25818085 trips both effects at once: one
missing cold SLOAD and the 16 withdrawal beneficiaries loaded in evmone's
own order. The pre-existing withdrawal-tail allowance requires equal lengths;
the subsequence rule does not tolerate reordering. Each allowance alone still
rejects the block, so they have to compose.

Argument for why relaxing this direction is safe — please scrutinise it:

• Reading less cannot hide a wrong value. The execution result is compared
  before this gate, the bundle state after it, and the post-state root is
  verified against the target header in every replay mode.
• Reading something the reference never read is still rejected — that is the
  access-outside-the-proven-witness case, i.e. exactly the 31f5326a4 class.
• A withdrawal beneficiary the reference never loaded is still rejected.
• Accesses within a block are distinct (the journal serves every repeat from
  memory), which is what makes the greedy match an exact subsequence test rather
  than an approximation.

What is genuinely given up: the gate no longer proves the two legs read the
same set. It now proves the subject read a subset. If you want the stronger
property back, revert these two commits.

---

f6e2d5fce — tracing

EVMC_BRIDGE_TRACE=1 logs every account-touching HostBackend call;
EVMC_BRIDGE_TRACE_DIR dumps both strict access sequences plus the reference's
accesses around the index where the subject stopped;
EVMC_BRIDGE_ACCESS_COUNTS=1 (added in defcb61f2) prints only the counts.
All off by default and never consulted on a decision path.

---

Verification

Measured, not inferred:

• 8 of the 10 previously failing blocks pass; the 22-block normal control set
  (25817835–25817856) passes. Both figures hold for the DTVM and the evmone
  subject leg.
• On the 22 normal blocks, subject and reference access counts are equal
  block for block, before and after these commits, on both engines. The extra
  accesses are path-triggered (a cold CALL target in a frame already doomed to
  OOG), not systematic — roughly 5 occurrences per 1000 blocks.
• After the fixes, the only subject != reference counts in the batch are the
  five read-one-less cases (2863/2864, 3559/3560, 4054/4055).
• Ruled out by measurement: the failing-block set is identical block for
  block across 3 adapter revisions × 2 evmone versions (v0.18, v0.21). Not an
  artefact of a recent adapter change or of an evmone version bump.
• cargo test --lib passes in adapter-subject-backends and in
  adapter-subject-backends/witness-db. A few witness-db tests need
  RETH_SUBJECT_BACKEND and friends set; without them they fail identically on
  the unmodified base 7ced99bf0.

Not fixed here

Blocks 25818502 and 25818530 still fail under DTVM. That is a separate,
JIT-only DTVM defect — a null-pointer dereference inside JIT'd code that the
trap handler reports as out-of-bounds memory. Both blocks replay correctly under
RETH_SUBJECT_EVMC_OPTIONS="mode=interpreter". A partial DTVM-side fix (the
exceptional-halt gas rule) is upstream at DTVMStack/DTVM#605, and the
misclassification that let the crash pass as a consensus halt is at
DTVMStack/DTVM#604. The null dereference itself is still open: re-measured on a
fresh build carrying both DTVM changes, the two blocks still fail under JIT with
unchanged access counts at the fault (152 and 45).

Stated uncertainties

• geth replays the same 1000-block corpus with zero failures, which is why we
  treat the witnesses themselves as sound. Why geth is not affected by the
  first defect is not confirmed. Its gasCall also calls
  StateDB.Empty(address) before charging, so the likeliest explanation is a
  different witness format carrying enough trie nodes for an exclusion proof —
  but that is a hypothesis, not something we verified.
• The first fix's protection was reasoned through, and the post-state-root check
  does run in every mode, but we did not construct a subject-only test case in
  which an answer actually escapes.