Overview

This document proposes extensions to crates/optimism/flashblocks/:

  1. Validation — Detect reorgs and sequence gaps to clear stale pending state
  2. Speculative execution — Stop discarding flashblocks that arrive before their canonical parent
  3. Extended RPC — Let clients subscribe to real-time updates instead of polling
  4. Transaction caching — Incrementally apply flashblocks to avoid repeated flashblock execution

All changes integrate into the existing FlashBlockService rather than creating a parallel execution pipeline.

Background

Flashblocks are partial block updates streamed via WebSocket from the sequencer. They arrive with lower latency than canonical blocks, which propagate through P2P gossip. A typical OP Stack block period (2 seconds) produces multiple flashblocks at 200ms intervals, each containing the transactions processed since the previous update. The complete set of flashblocks for a single canonical block is called a sequence.

This latency difference creates an opportunity: nodes can act on flashblock data before the corresponding canonical block arrives, improving responsiveness for downstream consumers. A trading bot, for example, can observe a pending transaction 500ms before that transaction becomes part of a canonical block.

However, this opportunity comes with complexity. Flashblocks may arrive out of order. The canonical chain may diverge from what flashblocks predicted (a reorg). Pending state must be reconciled when canonical blocks eventually arrive.

Current State

The reth-optimism-flashblocks crate processes incoming flashblocks and executes their transactions to produce pending state. The flow works as follows:

  1. FlashBlockService receives flashblocks from an incoming stream and inserts them into a SequenceManager
  2. SequenceManager accumulates flashblocks into sequences and caches up to three completed sequences in a ring buffer
  3. When the service attempts to execute, it calls next_buildable_args() which checks if any sequence's parent hash matches the canonical tip
  4. FlashBlockWorker executes the transactions against the canonical state provider and produces a PendingFlashBlock

The produced PendingFlashBlock serves two purposes: