commitment: consolidate BAL-driven cache warming into single entry point #19955

Summary

Currently cache warming for block execution is split across multiple locations:

1. BlocksReadAhead (exec/blocks_read_ahead.go) — warms state domain (accounts, code, storage) for EVM execution
2. BAL prefetch loop in executeBlocks (exec3.go) — warms commitment domain (branch trie nodes) from BAL write set
3. TouchPlainKey callback → BranchPrefetcher — warms commitment domain during execution as keys are touched

When BALs become the primary source of truth for what a block will touch, all of this should be unified into a single WarmBlockFromBAL(bal) call that:

• Prefetches state domain data (accounts, storage, code) — replacing BlocksReadAhead
• Prefetches commitment domain data (branch trie nodes) — replacing the inline BAL loop and TouchKey callback
• Runs in a background goroutine as soon as the BAL is decoded, before execution starts

Benefits

• Single place to understand all cache warming logic
• BAL gives complete write set ahead of time — no need for heuristic read-ahead
• Cleaner code path: one BAL → one warmup call → all domains
• Foundation for further BAL-driven optimizations (e.g., pre-computing state diffs)

Context

• PR commitment: add persistent branch cache across Process() calls #19954 introduces the persistent BranchCache and BranchPrefetcher
• The BAL prefetch loop was added in the same PR
• BlocksReadAhead predates BALs and uses sender/recipient heuristics

Blocked on

• BAL availability on mainnet (currently only on devnets)
• PR commitment: add persistent branch cache across Process() calls #19954 merge

🤖 Generated with Claude Code