rust!: update reth to v2.6.0

[joshklop]

Moves op-reth onto the reth v2.6.0 dependency stack so it remains aligned with current reth, REVM, and Alloy APIs. Every cherry-pick on the previous fork pin is in v2.6.0 or superseded upstream. The new pin (ethereum-optimism/reth#15) carries the upstream fixes paradigmxyz/reth#27129, #27247, #27252, #27286, #27429, #27634, #27782 and #27832. Problems the reviews found that already exist on develop are tracked separately on the Protocol Team board.

Migration notes:

• --db.rocksdb-block-cache-size now takes effect. Before, it was ignored in favor of the 128 MiB builder default, so operators with a larger configured value may see higher memory use after upgrading.
• Changed defaults:
  • --engine.persistence-threshold now defaults to 50 instead of 7.
  • --rpc-cache.max-cached-tx-hashes now defaults to 100000 instead of 30000.
• --rpc-cache.max-headers is now a hidden no-op.
• reth v2.6.0 adds state masking (--engine.num-state-masking-blocks, default 30 upstream). op-reth keeps it off: the flag defaults to 0, is hidden, and any nonzero value is rejected at startup. Turning it back on is tracked in https://github.com/ethereum-optimism/protocol-team/issues/457.
• New controls are available for HTTP compression and inline JWT secrets.
• The default negotiated eth wire protocol between upgraded peers changes from eth/69 to eth/71. Compatibility with older peers is retained through highest-common-version negotiation.
• --txpool.minimum-priority-fee now also rejects local and private (conditional) transactions; before, it applied only to transactions received over p2p. On a sequencer that covers nearly all RPC submissions; those below the minimum are now rejected with an error (fix(txpool): enforce minimum priority fee for local transactions paradigmxyz/reth#26861).
• eth_getLogs returns errors where it used to return []:
  • a range whose receipts are missing returns error 4444 "pruned history unavailable", for example pre-Bedrock ranges on datadirs created with op-reth init-state --without-ovm (fix(rpc): reject eth_getLogs queries over pruned receipts paradigmxyz/reth#27002);
  • a fromBlock beyond the head returns -32602, which polling indexers that request lastSeen + 1 on fast chains will hit (fix(rpc): return invalid params error for eth_getLogs fromBlock beyond head paradigmxyz/reth#26891).
• --txpool.max-batch-size 0 is now rejected at startup (fix(txpool): reject zero transaction batch size paradigmxyz/reth#26806).
• --engine.persistence-threshold can now also be set with RETH_ENGINE_PERSISTENCE_THRESHOLD. A nonzero RETH_ENGINE_NUM_STATE_MASKING_BLOCKS is rejected like the flag.
• The transaction fetcher was rewritten (refactor(net): rewrite transaction fetcher paradigmxyz/reth#26924). Each peer is limited to 4096 announced hashes, with no flag; announcements above the limit are dropped. --max-tx-pending-fetch now also counts in-flight hashes.
• RocksDB keeps all table files open (max_open_files = -1) when RLIMIT_NOFILE is at least 131072 (fix(rocksdb): better max_open_files config paradigmxyz/reth#26812).

Proofs history (--proofs-history):

• Execution no longer uses reth's parent-state provider. reth v2.6.0's state providers build an overlay anchored at the Finish checkpoint for every bytecode and block-hash read. That fails during pipeline sync and gets expensive during catch-up. The proofs ExEx now reads bytecode and block hashes from a snapshot of reth's in-memory chain, then from reth's database.
• Blocks from an abandoned fork. Because of that change, a block from a fork reth has left can fail execution. The ExEx hands such a block to the sync loop only when reth has replaced it at that height; otherwise it fails as on develop.
• op-reth proofs init refuses to copy a state trie that lags reth's tip.
• Everything else in failure handling and acknowledgement is unchanged from develop. Known develop issues are tracked in https://github.com/ethereum-optimism/protocol-team/issues/464, https://github.com/ethereum-optimism/protocol-team/issues/465, https://github.com/ethereum-optimism/protocol-team/issues/477 and https://github.com/ethereum-optimism/protocol-team/issues/478.

BREAKING CHANGE: op-reth no longer accepts reth's block access list (BAL) options, because OP blocks do not carry EIP-7928 block access lists. This affects operators whose op-reth command lines or unit files pass any of these flags, which previous releases accepted:

• --rpc-cache.max-bals
• --db.balstore-cache-size, on node and every other subcommand (db, init, prune, stage, proofs, ...)
• --engine.disable-bal-parallel-execution
• --engine.disable-bal-parallel-state-root
• --engine.disable-bal-batch-io

They are hidden from help, and using any of them now makes op-reth exit with "Block access list options are not supported by op-reth". The BAL options new in reth v2.6.0 (--rpc-cache.cache-computed-bals, --rpc-cache.prewarm-bals) are rejected the same way. To migrate, remove these flags. None of them had any effect on OP chains.

op-reth also does not serve the block access list RPC methods eth_getBlockAccessList, eth_getBlockAccessListByBlockHash, eth_getBlockAccessListByBlockNumber, eth_getBlockAccessListRaw and debug_getRawBlockAccessList. They now return method not found (-32601).

Verified with the Rust workspace checks, feature combinations, mirror audit, and the affected CL sync, EL sync, and restart acceptance scenarios using both op-node and kona-node. After 4dcdefc, the op-reth trie and ExEx tests and just lint were rerun. The acceptance scenarios were not.

Fixes https://github.com/ethereum-optimism/protocol-team/issues/354

[joshklop]

Full reth/revm/alloy update sweep found six runtime/build risks and two compatibility notes; details are inline. Coverage included all 283 reth commits, the complete revm/alloy ranges, both lockfiles, fork ancestry, and all changed mirror annotations. just mirrors stale --json and git diff --check passed; affected-package tests passed. The revm/asyncdb feature-unification failure was reproduced locally despite the standard CI matrix being green.

[sebastianst]

Review against docs/ai/reth-update-review.md, including the partitioned full-range sweep (#23063): every commit in reth 3a83ccc546..dfcb10454c (v2.5.2 fork base → v2.6.0), revm v115..v119, alloy-evm 0.38→0.39, revm-inspectors, alloy-eip7928, alloy-hardforks and reth-core 0.6→0.7. The results are a per-commit verdict ledger, the mirror funnel, and a check of the adaptation diff. Mirrors: all 63 advanced tags match their upstream diffs. Old fork cherry-picks are all contained in v2.6.0.

Four blocking findings. For each, a red test fails on this head and passes with the fix. Fixes and tests are ready to share.

1. [blocking, consensus] Isthmus withdrawals_root is wrong over a masked state trie.
parent_state() is now an OverlayStateProvider (reth f0166c32e2), and state masking is on by default (--engine.num-state-masking-blocks 30, bd61f3919e). Upstream OverlayStateProvider::storage_root (reth crates/storage/storage-overlay/src/provider.rs:573) builds the overlay but passes only its hashed storage to DbStorageRoot::overlay_root. That drops the overlay trie nodes and walks the DB storage trie directly. storage_proof and storage_multiproof have the same problem. Under partial persistence, disjointed_merge_batch skips DB trie nodes that the masking suffix overwrites. Their cached child hashes therefore predate the persisted hashed storage, and siblings outside the prefix set are hashed with stale values.

Ethereum never uses storage_root for consensus. OP does, twice: the validator's Isthmus check (node/src/engine.rs:149) and the sequencer's header (evm/src/build.rs:81). Each node's DB layout depends on its own persistence timing, so op-reth nodes can disagree with each other, not only with kona/op-program.

A regression test in consensus/src/validation/isthmus.rs writes L2ToL1MessagePasser storage across the persisted batch, the masking suffix and an in-memory block, over v1 and v2 storage. It compares withdrawals_root via OverlayStateProviderFactory::database_provider_ro() against a from-scratch root. The masked cases fail (0x9334cfa9…acc4 vs 0xa976ad4c…672a); the unmasked controls pass. The same scenario as an upstream storage-overlay test is red at v2.6.0 and green once storage_root/storage_proof/storage_multiproof read nodes through InMemoryTrieCursorFactory over the overlay nodes, with the full reth-storage-overlay suite passing.

The fix belongs upstream, then backported to the fork pin. Until then, the only mitigation I see is forcing num_state_masking_blocks = 0 in op-reth. The same flaw affects the conditional-tx storage roots (rpc/src/eth/ext.rs:93). eth_getProof uses proof and is not affected.

2. [blocking] op-reth proofs init seeds a corrupt proofs store after an unclean shutdown.
With masking on, a datadir left by a crash, OOM or SIGKILL, or a snapshot of a running node, has Finish.block_number at the tip. The hashed and trie tables, however, hold a disjointed merge at Finish.partial_state_trie. reth repairs that only at node launch (launch/common.rs:553). proofs init opens with RoInconsistent, anchors at chain_info().best_number and copies the tables unchecked (cli/src/commands/op_proofs/init.rs:161,179, trie/src/initialize.rs). This PR adapted the ExEx to partial_state_trie but not init.

A repro persists blocks via the real save_blocks with frontiers 6/3. Init returns Ok, seeding slot values from before the tip and a state root that differs from header #6. With V2 plus backfill (the default), backfill then fails with StateRootMismatch, and re-running init reports "already initialized", so the proofs dir must be deleted. With --proofs-history.skip-backfill or V1, the node silently serves wrong historical proofs; --proofs-history.verification-interval defaults to 0.

Suggested fix: InitializationJob::run reads the Finish checkpoint in its copy transaction and refuses when partial_state_trie < block_number, with an actionable error ("start op-reth node once and stop it cleanly"). Reading both in one transaction also closes the existing race between chain_info() and the copy.

3. [blocking] BAL disablement is incomplete (inline on node.rs).

4. [blocking, downstream API] Filtered flashblock log streams return nothing.
reth #26946 (1ca1201167) added if !filter.matches_bloom(header.logs_bloom()) { return Ok(vec![]) } to matching_block_logs_with_tx_hashes. The synthetic header in OpEthApi::flashblock_receipts_stream (rpc/src/eth/mod.rs:180) leaves logs_bloom zeroed. So since this bump, any filter with an address or topic yields no logs. Only the empty filter still works.

A unit test fails for the address and topic filters (0 logs, expected 1). It passes once the header carries alloy_primitives::logs_bloom(fb.metadata.receipts.values().flat_map(|r| r.logs())). Nothing in-tree calls the method (eth_subscribe logs uses upstream's canonical log_stream), so only downstream users of this public API are affected.

Follow-ups referenced in threads were closed. #23096 (+12 pending timestamp) and #23103 (pending logs in latest..pending) were closed unmerged after the replies pointing at them. Only issues #22685 and #23104 remain, and #23104 still names the closed PR. #23106 (proofs ExEx acks) is an open draft; see the inline note on exex/src/lib.rs, which shows the problem also applies in live mode.

Migration notes: missing items

• Startup failure. --engine.persistence-threshold ≤ 35 now fails startup unless --engine.num-state-masking-blocks 0 is also set (EngineArgs::validate). This includes the old default of 7 when it is pinned via flag or RETH_ENGINE_PERSISTENCE_THRESHOLD.
• Env vars. The engine flags now also read RETH_ENGINE_PERSISTENCE_THRESHOLD and RETH_ENGINE_NUM_STATE_MASKING_BLOCKS.
• Priority fee. --txpool.minimum-priority-fee now also rejects local and private (conditional) txs (74ce7f1b2b).
• Tx fetcher. New per-peer cap of 4096 announced hashes, with no CLI flag. --max-tx-pending-fetch now also counts inflight hashes (b2d7bd7f3f).
• eth_getLogs. Errors instead of [] on missing receipts, for example pre-Bedrock ranges on init-state --without-ovm datadirs (d5cd94331e). Also errors when fromBlock is beyond head (1e9a9438ad).
• RocksDB. max_open_files is now -1 (keep all open) when RLIMIT_NOFILE ≥ 131072 (853a42db1c).
• Tx pool. --txpool.max-batch-size 0 is now rejected.

payload_handoff.rs removal. The removal is fine, but the stated reason isn't quite right. Upstream #26917 (68877d5fd7) removed the persistence lease/handoff mechanism entirely, including #26708's own test, rather than the cherry-pick becoming redundant.

The revm/asyncdb dismissal holds: the feature is enabled in neither lock nor in op-rbuilder. Other non-blocking notes are inline.

🤖 Co-created with Claude Opus 5.5