Point-evaluation precompile: BAL parallel-exec optimisations

Performance

Same-sender Amsterdam BAL parallel newPayload validate, EEST 150 M point_evaluation workload (linear projection from a 9 × 5 M synthesised in-process run):

+----------------+----------+---------+
| variant        | before   | after   |
+----------------+----------+---------+
| 150 M cachable | ~1940 ms | ~305 ms |
| 150 M uncach.  |  ~305 ms | ~300 ms |
+----------------+----------+---------+

• 6.4× speedup on the same-sender (cachable) path.
• Multi-sender unaffected; the bug only fired under same-sender BAL.
• invalid=0 retries on the user-tx block (was invalid=8, ~47 % retry rate).

Issue & root cause

validateRead in execution/state/versionmap.go invalidated every same-sender tx under BAL pre-pop, forcing serial re-execution and collapsing parallel throughput.

The AddressPath / MVReadResultNone arm used BalancePath as a proxy for "a prior tx created this account":

if valid == VersionValid {
    balRR := vm.Read(addr, BalancePath, ..., txIndex)
    if balRR.Status() == MVReadResultDone {
        valid = VersionInvalid
    }
}

BalancePath is written by three events, only one of which is a creation:

1. CreateAccount (the real bug PR Fix bal-devnet-2 system address filter and AccessedAddresses propagation #19628 was trying to catch).
2. UpdateAccountData on a pre-existing account — fires for every gas-paying same-sender tx.
3. BAL pre-population for every BAL-listed balance change.

Under same-sender BAL workloads (the EEST point_evaluation cachable benchmark), the BAL pre-populates BalancePath at TxIdx = 0..N-1 for the shared sender. Every tx after tx 0 then false-invalidated its AddressPath storage-fallback read, producing the retry storm.

Fix

Replace the BalancePath cross-check with an IncarnationPath cross-check. IncarnationPath is the specific signal for account-existence change: written only by CreateAccount and SelfDestruct, never by UpdateAccountData, never by WriteChanges (BAL pre-pop). The existing versionedRead storage-zero-out path already uses IncarnationPath this way for StoragePath.

if valid == VersionValid {
    incRR := vm.Read(addr, IncarnationPath, ..., txIndex)
    if incRR.Status() == MVReadResultDone {
        valid = VersionInvalid
    }
}

This also subsumes the secondary "precompile-touch records phantom AddressPath read" retry-storm path: precompiles are never CreateAccount'd or SelfDestruct'd, so a TouchAccount on 0x01-0x0a no longer trips invalidation under the new cross-check. No EVM-level change needed.

Correctness

• PR Fix bal-devnet-2 system address filter and AccessedAddresses propagation #19628 still covered. A genuine CreateAccount writes IncarnationPath, so the stale-AddressPath-after-account-creation case is still caught. New unit test TestValidateRead_PriorAccountCreation_DetectedViaIncarnationPath asserts this (failed without the cross-check, passes with the IncarnationPath form).
• SelfDestruct path unchanged. SelfDestructPath cross-check remains in place at the start of the arm.
• No-BAL same-sender conflicts still caught. When same-sender txs run without BAL, conflict detection happens through the MVReadResultDone arm's value-tiebreaker, which is untouched by this change. New unit test TestNoBAL_SameSenderTxs_DetectsConflicts exercises the 9-tx-same-sender flow and asserts 8 invalidations.
• No false positives under BAL. WriteChanges (BAL pre-pop) doesn't touch IncarnationPath, so for pure balance/nonce/code/storage updates the cross-check stays silent. New unit test TestBALPrePop_SameSenderTxs_NoConflicts confirms zero conflicts on the synthesised 9-tx BAL workload.

Tests added

execution/state/versionmap_test.go:

• TestBALPrePop_SameSenderTxs_NoConflicts — same-sender BAL retry-storm reproducer; green after the fix.
• TestValidateRead_PriorAccountCreation_DetectedViaIncarnationPath — PR Fix bal-devnet-2 system address filter and AccessedAddresses propagation #19628 regression coverage; red without the cross-check, green with the IncarnationPath version.
• TestNoBAL_SameSenderTxs_DetectsConflicts — confirms the no-BAL conflict-detection path still fires.

execution/engineapi/amsterdam_bal_point_eval_bench_test.go (new file, gated by EXEC3_PARALLEL=true) — in-process Amsterdam BAL benchmark that produced the performance numbers above. Mirrors the EEST point_evaluation workload (9 txs × ~5 M gas calling KZG-loop contract) end-to-end via MockCl.BuildNewPayload + InsertNewPayload.