feat: AL-direct prefetch from EIP-2930 access lists at block build time

[defistar]

Background

Reth's block execution bottleneck is MDBX I/O — when the EVM executes a transaction, it reads account state and storage slots from disk on demand. These reads happen serially on the critical path, directly adding to block build latency and capping TPS.

The existing solution (feature/txn-execution-cache-warming) uses simulation workers: background rayon threads continuously simulate pending transactions to discover which accounts/slots they'll touch, store those keys in a PreWarmedCache, and then at block build time
parallel-load the values from MDBX into CachedReads before the EVM runs. This achieves ~99% cache hit rates but introduces CPU competition between simulation workers and block execution.

What & Why

This branch introduces a simpler, zero-worker alternative: instead of simulating transactions to discover keys, we read them directly from EIP-2930 access lists.

EIP-2930 (type 0x01) transactions carry an explicit AccessList field — a list of (address, [storage_slots]) pairs that the transaction declares it will touch. This is exactly the prefetch oracle we need, already embedded in the transaction itself. No simulation
required.

At block build time, before handing the state DB to the EVM:

1. Iterate all pending pool transactions
2. For each transaction with a non-empty access list, extract declared addresses and slots
3. Pre-load them from MDBX into CachedReads via CachedReadsDbMut
4. EVM executes against the warm cache — near 100% hits on declared keys

Trade-offs vs simulation approach:

┌────────────────────┬──────────────────────────────────────────────┬───────────────────────────────────────────┐
│                    │              Simulation workers              │                AL prefetch                │
├────────────────────┼──────────────────────────────────────────────┼───────────────────────────────────────────┤
│ Key discovery      │ EVM simulation (discovers all touched state) │ EIP-2930 access list (only declared keys) │
├────────────────────┼──────────────────────────────────────────────┼───────────────────────────────────────────┤
│ Background workers │ Yes (rayon pool, CPU competition)            │ None                                      │
├────────────────────┼──────────────────────────────────────────────┼───────────────────────────────────────────┤
│ Coverage           │ All transactions                             │ Only EIP-2930 transactions                │
├────────────────────┼──────────────────────────────────────────────┼───────────────────────────────────────────┤
│ Complexity         │ High                                         │ Minimal (~160 lines)                      │
├────────────────────┼──────────────────────────────────────────────┼───────────────────────────────────────────┤
│ CPU overhead       │ Continuous (competes with block exec)        │ Zero between blocks                       │
└────────────────────┴──────────────────────────────────────────────┴───────────────────────────────────────────┘

This is the right approach when the workload uses EIP-2930 transactions (as the adventure benchmark does with ADVENTURE_USE_ACCESS_LIST=true).

Deduplication

A critical optimization in the implementation: keys are deduplicated before any MDBX reads.

In a busy mempool, hot contracts (USDC, WETH, DEX routers) appear in thousands of pending transactions. Without deduplication, a naïve implementation would call basic(usdc_address) once per transaction that touches USDC — if that's 5,000 transactions, that's 5,000
calls. Only the first is an MDBX round-trip; the rest are cache hits inside CachedReadsDbMut, but thousands of redundant function calls still add measurable overhead at full mempool scale.

The fix is a two-pass approach:

• Pass 1 (no I/O): iterate all pending transactions, insert every declared address and (address, slot) pair into HashSets
• Pass 2 (MDBX reads): iterate the deduplicated sets — exactly one basic() per unique address, one storage() per unique (address, slot) pair

Result: MDBX reads scale with unique key count, not with mempool size × access list size.

Implementation

• crates/optimism/payload/src/al_prefetch.rs — new module, prefetch_from_pool() function
• crates/optimism/payload/src/builder.rs — 8-line hook in build_payload(), guarded by al_prefetch::is_enabled()
• Controlled by TXPOOL_AL_PREFETCH_ONLY=1 env var (runtime, no recompile needed)
• Emits 3 Prometheus metrics: reth_al_prefetch_tx_with_access_list_total, reth_al_prefetch_keys_extracted_total, reth_al_prefetch_duration_seconds
• No new cargo feature flag — the module is always compiled, dormant unless env var is set

[cliff0412]

The prefetch reads the same MDBX data on the same thread, sequentially. There's no parallelism gain

we only need to prefetch for txs included in a block

[cliff0412]

The prefetch reads the same MDBX data on the same thread, sequentially