- Sequencer side — The Rollup-Boost sidecar is installed next to the OP Stack sequencer by the Base team.
- Node side — The Flashblocks module is implemented on the Base fork of the Reth node.
- Base sequencer creates regular 2-second blocks and additionally creates sub-blocks called Flashblocks every 200ms.
- Base sequencer streams these Flashblocks every 200ms over WebSocket to the Base Reth nodes that have the Flashblocks module enabled.
- The sequencer-streamed Flashblocks & Flashblock states can then be retrieved by apps over the standard Base RPC endpoints & methods:
eth_getBlockByNumberwithpendingtageth_getTransactionReceipteth_getBalancewithpendingtageth_getTransactionCountwithpendingtageth_getTransactionByHashwithpendingtageth_callwithpendingtageth_sendRawTransactionSync
- The transaction ordering is done at the Flashblocks level instead of the block level.
Quick Flashblock vs. full block data comparison
Let’s call an eth_getBlockByNumber with thepending tag to get the latest block data on a Flashblocks-enabled and non-Flashblocks-enabled node at the same time as block 33228756 was being formed on the Base mainnet.
See the results in the Chainstack Labs base-flashblocks-transaction-latency-test repository:
eth-get-block-by-number-pending-examples/preconfirmed-flashblock.log— the result of running"method":"eth_getBlockByNumber","params":["pending",true]on a Flashblocks-enabled node as block 33228756 was forming.eth-get-block-by-number-pending-examples/confirmed-block.log— the result of running"method":"eth_getBlockByNumber","params":["pending",true]on a non-Flashblocks-enabled node as block 33228756 was formed.
- Transaction count — 52 in the Flashblock vs. 167 in the fully formed block.
stateRoot— empty in the Flashblock vs. computed in the fully formed block. An emptystateRootat this point means there’s no final chain state for the block, hence “preconfirmation” in the name.blockHash— different in the Flashblock and the fully formed block. The finalized transactions will have the hash of the fully formed block attributed to them.receiptsRoot— different in the Flashblock and the fully formed block.
- Preconfirmed 200ms Flashblock
- Confirmed regular 2s block
Transaction latency test tool
See the Chainstack Labs base-flashblocks-transaction-latency-test repository for the latency test tool and the comprehensive README file.Performance expectations
Flashblocks are produced at 200ms intervals, but actual confirmation times will be higher due to network latency:- Standard Base endpoint — ~2000ms (2-second block time)
- Flashblocks-enabled endpoint — ~300-500ms (200ms Flashblock interval + network travel time)
- Network latency to/from the Base node
- Transaction processing time
- Time until next Flashblock (up to 200ms)
- Network travel time for confirmation response
Additional resources
- Chainstack blog: Flashblocks is live on Chainstack: even faster Base RPC
- Base Flashblocks transaction latency test repository
- Base documentation: Flashblocks
- Base blog: We’re making Base 10x faster with Flashblocks
- Flashbots blog: Introducing Rollup-Boost
- Original spec for Rollup-Boost idea: External Block Production
