Flashblocks on Base: 200ms preconfirmations

• Sequencer side — The Rollup-Boost sidecar is installed next to the Base 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_getBlockByNumber with pending tag
  • eth_getTransactionReceipt
  • eth_getBalance with pending tag
  • eth_getTransactionCount with pending tag
  • eth_getTransactionByHash with pending tag
  • eth_call with pending tag
  • eth_sendRawTransactionSync
• The transaction ordering is done at the Flashblocks level instead of the block level.

• eth_subscribe newFlashblockTransactions — stream individual transactions as they are pre-confirmed (~200ms each)
• eth_subscribe pendingLogs — stream filtered event logs from pre-confirmed transactions
• eth_subscribe newFlashblocks — stream full Flashblock payload objects from the sequencer

​

Quick Flashblock vs. full block data comparison

• 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 empty stateRoot at 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.

"stateRoot": "0x0000000000000000000000000000000000000000000000000000000000000000",
"receiptsRoot": "0x5f2dd9fbe32e2c22e47d84edbe6a300e75a004495191ff9f6228ce5de8f7c6f8",
"blockHash": "0x61792b40d824cb6e99ad07de112c823e0f86995063c00486e8dd3ef9667b40fc",

"stateRoot": "0x16a1375def73d111a7dcfcd39acbcdbe935acf011e645c8f37af2a05af72af71",
"receiptsRoot": "0x26dc0c64a01f87aecf3e112fa92c06845757dbc72b708bf783c97b425828cdb5",
"blockHash": "0xb09354e0fd87cd9c379c456ab41ea9b4ff1c684bea7705e19bb237f621b588f0",

​

Transaction latency test tool

​

Performance expectations

• 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

​

About the author

Ake

Director of Developer Experience @ Chainstack
Talk to me all things Web3
20 years in technology | 8+ years in Web3 full time years experience