Summary
Currently cache warming for block execution is split across multiple locations:
BlocksReadAhead (exec/blocks_read_ahead.go) — warms state domain (accounts, code, storage) for EVM execution
- BAL prefetch loop in
executeBlocks (exec3.go) — warms commitment domain (branch trie nodes) from BAL write set
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
Blocked on
🤖 Generated with Claude Code
Summary
Currently cache warming for block execution is split across multiple locations:
BlocksReadAhead(exec/blocks_read_ahead.go) — warms state domain (accounts, code, storage) for EVM executionexecuteBlocks(exec3.go) — warms commitment domain (branch trie nodes) from BAL write setTouchPlainKeycallback →BranchPrefetcher— warms commitment domain during execution as keys are touchedWhen 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:BlocksReadAheadBenefits
Context
BlocksReadAheadpredates BALs and uses sender/recipient heuristicsBlocked on
🤖 Generated with Claude Code