Epic: Sub-second pre-confirmations (flashblock-style streaming)

[tac0turtle]

Summary

Implement a pre-confirmation system that gives end users sub-second transaction confirmation UX, inspired by Base's Flashblocks (200ms pre-confirmations) but adapted for ev-reth's Engine API-driven architecture.

Motivation

ev-reth's current confirmation latency is bounded by block time. For payment, trading, and interactive dApp use cases, users expect near-instant feedback. Base shipped Flashblocks in July 2025 on Reth v1.8 and achieved ~200-500ms effective confirmation latency -- comparable to centralized payment systems.

Since ev-reth already controls transaction ordering via Engine API (no mempool), the sequencer has full knowledge of pending transactions and can stream partial block updates to clients before the block is finalized.

Architecture

How Flashblocks work (Base/OP Stack reference)

1. Sequencer builds a block incrementally in "flashblocks" (e.g., 10 per 2s block = 200ms each)
2. Each flashblock contains a subset of transactions with provisional receipts
3. Flashblocks are streamed to nodes via WebSocket (--flashblocks-url)
4. RPC nodes update the pending block tag to reflect the latest flashblock state
5. When the full block is sealed, flashblocks are collapsed into the canonical block

Adaptation for ev-reth

Since ev-reth submits transactions through engine_forkchoiceUpdatedV3 payload attributes (not mempool), the flow would be:

1. Sequencer (ev-node) accumulates transactions and periodically streams partial execution results
2. ev-reth receives flashblock updates via WebSocket sidecar or Engine API extension
3. RPC layer exposes provisional receipts to clients with a confidence indicator
4. Finalization: full block sealed via normal Engine API flow; flashblocks become canonical

Key design decisions

• Streaming protocol: WebSocket (Base's approach) vs Engine API extension vs custom RPC subscription
• Granularity: Fixed interval (200ms) vs transaction-count-based vs adaptive
• Revert handling: How to handle flashblock state that gets reverted at block seal time
• Receipt semantics: How to distinguish provisional vs finalized receipts in RPC responses

Sub-issues

• Design: streaming protocol and flashblock format
• Design: RPC semantics for provisional vs finalized state
• Implement: flashblock producer in payload builder
• Implement: WebSocket streaming endpoint
• Implement: RPC pending tag mapped to latest flashblock
• Implement: flashblock-aware eth_getTransactionReceipt
• Testing: latency benchmarks, revert scenarios, concurrent flashblock consumers

Relationship to Top-of-Block auctions (#94)

This epic subsumes the pre-confirmation and block-streaming aspects of #94. The ToB auction design question (who gets priority ordering and at what price) becomes a policy layer on top of the flashblock infrastructure:

• Flashblocks define the streaming mechanism -- how partial blocks are built and distributed
• ToB auctions define the ordering policy -- who gets the first slots in each flashblock and how they bid for it
• Revenue share, bid mechanics, and censorship resistance from Research & Design — Top-of-Block Auctions for Rollkit #94 apply as a policy module that plugs into the flashblock producer

The auction mechanism can be implemented as a separate component that feeds ordered transactions into the flashblock pipeline, rather than requiring its own block-level infrastructure.

Closing #94 in favor of tracking the auction policy as a sub-task of this epic.

Prior art

• Base Flashblocks Deep Dive -- 200ms pre-confirmations, live on mainnet since July 2025
• Reth reth-optimism-flashblocks crate -- Native flashblock support in Reth v1.8+
• Flashblocks on Chainstack
• Tempo: sub-second finality -- 500ms blocks, ~600ms deterministic finality
• Research & Design — Top-of-Block Auctions for Rollkit #94 -- Original ToB auction research (incorporated here)

[tac0turtle]

Closing: at 100ms block times, flashblock-style pre-confirmations don't add meaningful latency improvement -- the block itself is already sub-perceptual. The actual customer need is guaranteed blockspace throughput under congestion, which is payment lanes / priority lanes. Tracked in a new issue.