diff --git a/pages/operators/chain-operators/features.mdx b/pages/operators/chain-operators/features.mdx index 6a7bc96e8..689d40b4a 100644 --- a/pages/operators/chain-operators/features.mdx +++ b/pages/operators/chain-operators/features.mdx @@ -31,4 +31,6 @@ This section provides information on various features for chain operators. You'l + + diff --git a/pages/operators/chain-operators/features/_meta.json b/pages/operators/chain-operators/features/_meta.json index d19ff2aed..a88282967 100644 --- a/pages/operators/chain-operators/features/_meta.json +++ b/pages/operators/chain-operators/features/_meta.json @@ -1,5 +1,6 @@ { "preinstalls": "Preinstalls", + "flashblocks": "Flashblocks", "alt-da-mode": "Run an Alt-DA Mode chain", "span-batches": "Use and enable span batches on your chain", "bridged-usdc-standard": "Bridged USDC Standard for the OP Stack" diff --git a/pages/operators/chain-operators/features/flashblocks.mdx b/pages/operators/chain-operators/features/flashblocks.mdx new file mode 100644 index 000000000..b35122fb0 --- /dev/null +++ b/pages/operators/chain-operators/features/flashblocks.mdx @@ -0,0 +1,30 @@ +--- +title: Flashblocks +lang: en-US +description: >- + Learn about Flashblocks for lightning-fast transaction confirmations on OP Stack chains. + This guide provides detailed information for both app developers and chain operators. +content_type: landing-page +topic: flashblocks +personas: + - app-developer + - chain-operator + - protocol-developer +categories: + - protocol + - block-production + - developer-tools +is_imported_content: 'false' +--- + +import { Card, Cards } from 'nextra/components' + +# Flashblocks + +Flashblocks delivers sub-second transaction confirmations on OP Stack chains, enabling lightning-fast user experiences without compromising security. This section provides comprehensive guides for both app developers and chain operators. + + + + + + diff --git a/pages/operators/chain-operators/features/flashblocks/_meta.json b/pages/operators/chain-operators/features/flashblocks/_meta.json new file mode 100644 index 000000000..64f005fe9 --- /dev/null +++ b/pages/operators/chain-operators/features/flashblocks/_meta.json @@ -0,0 +1,4 @@ +{ + "apps": "Apps", + "chain-operators": "Chain Operators" +} diff --git a/pages/operators/chain-operators/features/flashblocks/apps.mdx b/pages/operators/chain-operators/features/flashblocks/apps.mdx new file mode 100644 index 000000000..7b1048347 --- /dev/null +++ b/pages/operators/chain-operators/features/flashblocks/apps.mdx @@ -0,0 +1,244 @@ +--- +title: Flashblocks +description: Learn how to integrate Flashblocks for lightning-fast transaction confirmations on OP Stack, with pre-confirmations in just 200 milliseconds. +lang: en-US +content_type: guide +topic: flashblocks +personas: + - app-developer + - protocol-developer + - chain-operator +categories: + - protocol + - block-production + - developer-tools +is_imported_content: 'false' +--- + +# Flashblocks + +Flashblocks is a block builder sidecar for OP Stack chains that delivers sub-second transaction confirmations - 250 ms on OP Mainnet, configurable down to 200 ms. + +By streaming pre-confirmations, "signals" that arrive before the next block is finalized, Flashblocks make OP Stack chains up to 10x faster, unlocking seamless user experiences without compromising security guarantees. + +Built for developers who need lightning fast UX, flashblocks are ideal for DeFi apps, payments, games, and real-time interactions where instant is the only answer. + +* **Payments**: Instant payment confirmations +* **DeFi**: Swaps and positions that update immediately +* **Marketplaces**: Fast, frictionless checkout flows +* **Games**: Real-time actions with no waiting between moves + +## How it works + +By default, blocks are produced every 1–2 seconds. +Flashblocks break that window into smaller intervals so instead of waiting the full block time to execute all transactions, the execution client continuously creates and broadcasts a "flash" block every few hundred milliseconds. + +Each flashblock includes all transactions processed so far, along with updated balances and contract states. +Apps can query this near-real-time state using RPC providers (Ankr, QuickNode, Alchemy, etc) and deliver the speed their users expect. + +## Integrate Flashblocks + +Integration is designed to be simple and low-friction. Most apps benefit with minimal code changes. + +* In production, point your app to a a Flashblocks‑aware RPC endpoint from your provider of choice. If your provider doesn't support flashblocks yet, let us know on Discord + and we'll work with them to get it added. +* Alternatively, you can run your own flashblocks-aware node using Base's [reth](https://github.com/base/node-reth) image. + +### Supported RPC methods + +Developers can access Flashblocks using the same familiar Ethereum JSON-RPC calls. +The difference is using the "pending" tag to query the pre-confirmed state instead of the last finalized block. + +* **`eth_getBlockByNumber`**: Use the `pending` tag to retrieve the latest flashblock snapshot. +
+ Sample response + + ```json + { + "jsonrpc": "2.0", + "id": 1, + "result": { + "number": "0x1234", + "hash": "0x...", + "transactions": [...] + } + } + ``` +
+ +* **`eth_call`**: Use the `pending` tag to execute calls against the most recent pre-confirmed state. + +
+ Sample request + + ```json + { + "jsonrpc": "2.0", + "method": "eth_call", + "params": [{"to": "0x...", "data": "0x..."}, "pending"], + "id": 1 + } + ``` +
+ +* `eth_getBalance` / `eth_getTransactionCount`: Use the `pending` tag to fetch balances or transaction counts as they evolve within the block window. + +
+ Sample response for `eth_getBalance` + + ```json + { + "jsonrpc": "2.0", + "id": 1, + "result": "0x0234" + } + ``` +
+ +
+ Sample response for `eth_getTransactionCount` + + ```json + { + "jsonrpc": "2.0", + "id": 1, + "result": "0x1b" // 27 transactions + } + ``` +
+ + Other methods, like `eth_getTransactionReceipt` and `eth_getTransactionByHash`, return data from pre-confirmed transactions without requiring the `pending` tag. + Consult the [Flashblocks specification](https://specs.optimism.io/protocol/flashblocks.html#flashblock-json-rpc-apis) for more details on each of these methods. + +## Libraries + +You will need a Flashblocks‑aware RPC endpoint to use the following libraries: + +### Viem + +```ts +import { createPublicClient, createWalletClient, http, parseEther } from 'viem'; +import { privateKeyToAccount } from 'viem/accounts'; +import { opSepolia } from 'viem/chains'; +import { publicActionsL2, walletActionsL2 } from 'viem/op-stack'; + +const account = privateKeyToAccount(`0x${process.env.PRIVATE_KEY}`); + +const walletClient = createWalletClient({ + account, + chain: opSepolia, + transport: http("https://sepolia.optimism.io"), +}).extend(walletActionsL2()); + +const publicClient = createPublicClient({ + chain: opSepolia, + transport: http("https://sepolia.optimism.io"), +}).extend(publicActionsL2()); + +const submissionTime = new Date(); +const hash = await walletClient.sendTransaction({ + to: '0x...', + value: parseEther('0.0001'), +}); + +// Wait for pre-confirmation +const receipt = await publicClient.waitForTransactionReceipt({ hash }); +const confirmTime = new Date(); +console.log('pre-confirmed in ms:', confirmTime.getTime() - submissionTime.getTime()); +``` + +### Ethers + +```ts +import { ethers } from 'ethers'; + +// Here, provider is a Flashblocks-enabled RPC provider +const provider = new ethers.JsonRpcProvider("https://sepolia.optimism.io"); +const wallet = new ethers.Wallet(process.env.PRIVATE_KEY as string, provider); + +const tx = { to: '0x...', value: ethers.parseEther('0.0001') }; +const submission = new Date(); + +const sent = await wallet.sendTransaction(tx); + +await sent.wait(0); +const confirmed = new Date(); + +// should represent the transaction (pre)confirmation faster than standard RPC +console.log('Pre-confirmed in ms:', confirmed.getTime() - submission.getTime()); + +// validates the transaction hash returned by the pre-confirmed transaction above +const receipt = await provider.getTransactionReceipt(sent.hash); +console.log('Receipt validated in ms:', validated.getTime() - submission.getTime()); +console.log('Transaction receipt:', receipt); + +``` + +## Flashblocks FAQ + +### Block building and availability + +
+ How often are Flashblocks produced? + The flashblocks target interval is variable. + OP Mainnet runs flashblocks at 250ms while Base and Unichain run them at 200ms. + A 2-second block at 250 ms produces 9 flashblocks, indexed 0 to 8. + The index-0 block contains deposit-only transactions, followed by 8 normal Flashblocks. +
+ +
+ Will the number of Flashblocks per block always be the maximum? + Not always. Heavy execution in one interval may reduce time available for subsequent intervals. The FLASHBLOCKS\_TIME setting is a target, not a strict guarantee. +
+ +
+ Do large gas transactions get delayed? + High gas transactions can be included in any flashblock with sufficient gas capacity. Placement is optimized by heuristics, but available gas decreases as transactions fill earlier flashblocks. +
+ +### High availability and safety + +
+ What happens if the flashblocks builder fails? + In a default/non-HA setup, the system falls back to regular block building while preserving pre-confirmations. In an HA setup, `op-conductor` seamlessly transfers leadership to a healthy sequencer without interruption. + When leadership changes, streaming continues seamlessly from the new leader so downstream consumers always receive a continuous stream from a single stable endpoint. +
+ +
+ How is continuity handled in high availability setups with multiple sequencers? + Only the current leader streams Flashblocks. On leader change, streaming continues from the new leader so downstream consumers see a continuous stream from a single stable endpoint. For details on high-availability sequencer setups, see the [op-conductor documentation](https://docs.optimism.io/operators/chain-operators/tools/op-conductor). +
+ +
+ Do flashblocks change the safety model of the chain? + No. Each flashblock is validated by the same execution engine as normal blocks. +
+ +### Pre-confirmations and reorgs + +
+ Can pre-confirmations be revoked? + Rarely. If the sequencer reorgs, pre-confirmed state may change - but this carries no more risk than the reorg of normal blocks. +
+ +
+ Why can a pre-confirmed transaction later disappear? + If the sequencer reorgs, pre-confirmed state can be replaced. This does not add risk beyond the pending state reorg risk that already exists. +
+ +
+ Does Flashblocks change liveness or withdrawals? + No. Protocol guarantees remain the same; Flashblocks only speed up transaction confirmation. +
+ +
+ What is the structure of a pre-confirmation response? + In pre-confirmation responses, `blockHash`, `stateRoot`, and `receiptsRoot` are the values that represent the cumulative state of all transactions included up to that point in the block. The blockNumber reflects the current pending block number. + Each flashblock's view shows the complete state incorporating all transactions processed so far. +
+ +## Next steps + +* Explore the [high-level guide](/operators/chain-operators/features/flashblocks/chain-operators) for operators. +* Review the [technical specs](https://specs.optimism.io/protocol/flashblocks.html) for architecture details. +* Join our [community](https://discord.gg/jPQhHTdemH) to share best practices and get support! diff --git a/pages/operators/chain-operators/features/flashblocks/chain-operators.mdx b/pages/operators/chain-operators/features/flashblocks/chain-operators.mdx new file mode 100644 index 000000000..3869be847 --- /dev/null +++ b/pages/operators/chain-operators/features/flashblocks/chain-operators.mdx @@ -0,0 +1,153 @@ +--- +title: "Flashblocks: A Guide for Chain Operators" +description: "Technical guide for chain operators on Flashblocks, covering components, operation, transaction flow, and leader selection." +lang: en-US +content_type: guide +topic: flashblocks +personas: + - chain-operator +categories: + - protocol + - block-production +is_imported_content: 'false' +--- + +import { Callout } from 'nextra/components' + +# Flashblocks for Chain Operators + + + We recommend chain operators read through [Flashbots' docs](https://rollup-boost.flashbots.net/operators/index.html#for-rollup-operators) on how to set up and run Flashblocks locally, in production, and in HA setups. + We'll be updating our docs over the next few weeks to bring the same level of detail here. + + +Flashblocks is a `rollup-boost` module that accelerates confirmation times by dividing block construction into smaller, incremental sections. +This enables pre-confirmations and improves user experience, while finalization still occurs at standard block intervals. + +The Flashblocks setup involves three main components: + +* **`rollup-boost`**: Coordination layer with Flashblocks enabled +* **`op-rbuilder`**: Execution client and builder with Flashblocks support +* **`op-geth`**: Fallback builder, a standard EL node (can be `op-reth` as well) + +Flashblocks are streamed from the `op-rbuilder` to `rollup-boost` over WebSockets, minimizing latency between the sequencer and the pre-confirmed state. + +For full details on design choices, data structures, and invariants, see the [Flashblocks specification](https://specs.optimism.io/protocol/flashblocks.html). + +## Flashblocks components + +Flashblocks relies on several components working together: + +* **`op-node`**: Consensus layer, initiates `engine_forkchoiceUpdated` calls and leads block building. +* **`op-geth`**: Default block builder, produces standard blocks. +* **`op-rbuilder`**: Reth-based execution client that builds both standard blocks and flashblocks. + * Exposes flashblocks on a WebSocket stream (not recommended for public exposure). + * Each event on the stream corresponds to a 250 ms flashblock. +* **`rollup-boost`**: Sits between `op-node` and execution layers, coordinating block building in flashblocks mode. + * Validates `op-rbuilder` payloads against `op-geth` + * Falls back to `op-geth` if `op-rbuilder` diverges or lags +* **`flashblocks-websocket-proxy`**: Relays the flashblocks stream from the active sequencer to RPC providers. +* **`op-node-rbuilder`** *(optional)*: `op-node` pointing only to `op-rbuilder`, used for syncing at startup. +* **`op-conductor`** *(optional but recommended)*: Manages multiple sequencers, ensuring only one healthy leader streams blocks. + +See the [System architecture section](https://specs.optimism.io/protocol/flashblocks.html#system-architecture) to learn more. + +## Flashblocks lifecycle + +```mermaid +flowchart LR + subgraph Sequencer + ON[OP Node] + RB[Rollup Boost] + FEL[Fallback EL] + BB[Block Builder] + end + + subgraph Network + WSP[WebSocket Proxy] + end + + subgraph Clients + RPC[RPC Providers] + Users[End Users] + end + + ON --> RB + RB --> FEL + RB <--> BB + RB --> WSP + WSP --> RPC + RPC --> Users +``` + +* Single-sequencer setup. +* `op-node` coordinates block production through `rollup-boost`, targeting `op-rbuilder` instead of `op-geth`. +* `op-rbuilder` acts as a full execution client: it builds blocks, exposes Ethereum JSON-RPC, and processes transactions. +* In addition, `op-rbuilder` emits flashblocks every 250 ms, streamed over a WebSocket interface (e.g. `wss://`). +* These flashblocks give early visibility into transaction inclusion before the final regular block is sealed. + +For full details on construction rules, validation, and lifecycle steps, see [Flashblocks lifecycle in the specification](https://specs.optimism.io/protocol/flashblocks.html#flashblock-lifecycle). + +## How to set up and run rollup-boost + +Flashblocks relies on `rollup-boost` as the coordination layer for block building. +To run Flashblocks, you'll configure `rollup-boost` alongside your sequencer and execution clients. + +* [Running rollup-boost locally](https://rollup-boost.flashbots.net/operators/local.html) +* [Running rollup-boost in production](https://rollup-boost.flashbots.net/operators/production.html) +* [HA setup for rollup-boost](https://rollup-boost.flashbots.net/operators/ha-setup.html) + +### Single‑sequencer setup + +As suggested in the above links, in a single-sequencer setup, Flashblocks are streamed from `rollup-boost` (or `op-rbuilder`) to `flashblocks-websocket-proxy` by setting the following environment variable in flashblocks-websocket-proxy: + +```jsx +UPSTREAM_WS: ws:///ws +``` + +### HA‑compliant multi‑sequencer setup + +While Flashblocks can be enabled in a single-sequencer setup, we **highly recommend running a high-availability (HA) multi-sequencer setup** managed by [`op-conductor`](/operators/chain-operators/tools/op-conductor). + +In an HA setup, multiple `op-conductor` instances form a [Raft](https://raft.github.io/) group. At any time, only one healthy sequencer acts as the active leader responsible for block building, while others remain in follower mode. Leadership changes automatically if the active sequencer becomes unhealthy. + +For Flashblocks, each sequencer (leader and followers) runs its own dedicated components, including `rollup-boost` and `op-rbuilder`. +Only the leader's `op-rbuilder` produces flashblocks; follower instances remain idle. + +In this setup, the connection between `rollup-boost` and the `flashblocks-websocket-proxy` is mediated by `op-conductor`. + +* `op-conductor` listens to Flashblocks from `rollup-boost` (or `op-rbuilder`). +* If it is the active leader, it forwards the Flashblocks to `flashblocks-websocket-proxy`. +* If it is not the leader, it does not forward anything. + +The rest of the data flow remains unchanged. + +### HA configuration + +**1. Configure `op-conductor`** to listen for Flashblocks and forward them if leader: + +```yaml +OP_CONDUCTOR_WEBSOCKET_SERVER_PORT: "8546" +OP_CONDUCTOR_ROLLUPBOOST_WS_URL: ws:///ws +OP_CONDUCTOR_ROLLUP_BOOST_ENABLED: "true" +OP_CONDUCTOR_EXECUTION_RPC: http://:8551 +``` + +* **Variable descriptions:** + * `OP_CONDUCTOR_WEBSOCKET_SERVER_PORT`: Port where `op-conductor` exposes Flashblocks if it is the leader. For example: `ws://:8546/ws`. + * `OP_CONDUCTOR_ROLLUPBOOST_WS_URL`: Direct URL of `rollup-boost` (or `op-rbuilder`) where Flashblocks are available. In a single-sequencer setup, this is the same URL you'd pass directly to `flashblocks-websocket-proxy`. + * `OP_CONDUCTOR_ROLLUP_BOOST_ENABLED`: Enables health checks for `rollup-boost` (and indirectly `op-rbuilder`) so leadership can fail over if either becomes unhealthy. + * `OP_CONDUCTOR_EXECUTION_RPC`: Execution RPC URL of `rollup-boost`. Same as `OP_NODE_L2_ENGINE_RPC` configured on `op-node`. + +**2. Configure `flashblocks-websocket-proxy`** to consume Flashblocks from all sequencer conductors: + +```yaml +UPSTREAM_WS: ws://:8546/ws,ws://:8546/ws,ws://:8546/ws +``` + +This way, the proxy always connects to the active leader via its `op-conductor`. + +Optional rate limits for `flashblocks-websocket-proxy`: + +* `PER_IP_CONNECTIONS_LIMIT`: Max connections allowed per client IP. +* `INSTANCE_CONNECTION_LIMIT`: Max total connections allowed per proxy instance. diff --git a/pages/stack/transactions.mdx b/pages/stack/transactions.mdx index 9d99f94fc..73b491f20 100644 --- a/pages/stack/transactions.mdx +++ b/pages/stack/transactions.mdx @@ -43,4 +43,6 @@ Documentation covering Cross Domain, Deposit Flow, Fees, Forced Transaction, Tra + + diff --git a/pages/stack/transactions/flashblocks.mdx b/pages/stack/transactions/flashblocks.mdx new file mode 100644 index 000000000..1af08ad36 --- /dev/null +++ b/pages/stack/transactions/flashblocks.mdx @@ -0,0 +1,244 @@ +--- +title: Flashblocks +description: Learn how to integrate Flashblocks for lightning-fast transaction confirmations on OP Stack, with pre-confirmations in just 200 milliseconds. +lang: en-US +content_type: guide +topic: flashblocks +personas: + - app-developer + - protocol-developer + - chain-operator +categories: + - protocol + - block-production + - developer-tools +is_imported_content: 'false' +--- + +# Flashblocks + +Flashblocks is a block builder sidecar for OP Stack chains that delivers sub-second transaction confirmations - 250 ms on OP Mainnet, configurable down to 200 ms. + +By streaming pre-confirmations, "signals" that arrive before the next block is finalized, Flashblocks make OP Stack chains up to 10x faster, unlocking seamless user experiences without compromising security guarantees. + +Built for developers who need lightning fast UX, flashblocks are ideal for DeFi apps, payments, games, and real-time interactions where instant is the only answer. + +* **Payments**: Instant payment confirmations +* **DeFi**: Swaps and positions that update immediately +* **Marketplaces**: Fast, frictionless checkout flows +* **Games**: Real-time actions with no waiting between moves + +## How it works + +By default, blocks are produced every 1–2 seconds. +Flashblocks break that window into smaller intervals so instead of waiting the full block time to execute all transactions, the execution client continuously creates and broadcasts a "flash" block every few hundred milliseconds. + +Each flashblock includes all transactions processed so far, along with updated balances and contract states. +Apps can query this near-real-time state using RPC providers (Ankr, QuickNode, Alchemy, etc) and deliver the speed their users expect. + +## Integrate Flashblocks + +Integration is designed to be simple and low-friction. Most apps benefit with minimal code changes. + +* In production, point your app to a a Flashblocks‑aware RPC endpoint from your provider of choice. If your provider doesn't support flashblocks yet, let us know on Discord + and we'll work with them to get it added. +* Alternatively, you can run your own flashblocks-aware node using Base's [reth](https://github.com/base/node-reth) image. + +### Supported RPC methods + +Developers can access Flashblocks using the same familiar Ethereum JSON-RPC calls. +The difference is using the "pending" tag to query the pre-confirmed state instead of the last finalized block. + +* **`eth_getBlockByNumber`**: Use the `pending` tag to retrieve the latest flashblock snapshot. +
+ Sample response + + ```json + { + "jsonrpc": "2.0", + "id": 1, + "result": { + "number": "0x1234", + "hash": "0x...", + "transactions": [...] + } + } + ``` +
+ +* **`eth_call`**: Use the `pending` tag to execute calls against the most recent pre-confirmed state. + +
+ Sample request + + ```json + { + "jsonrpc": "2.0", + "method": "eth_call", + "params": [{"to": "0x...", "data": "0x..."}, "pending"], + "id": 1 + } + ``` +
+ +* `eth_getBalance` / `eth_getTransactionCount`: Use the `pending` tag to fetch balances or transaction counts as they evolve within the block window. + +
+ Sample response for `eth_getBalance` + + ```json + { + "jsonrpc": "2.0", + "id": 1, + "result": "0x0234" + } + ``` +
+ +
+ Sample response for `eth_getTransactionCount` + + ```json + { + "jsonrpc": "2.0", + "id": 1, + "result": "0x1b" // 27 transactions + } + ``` +
+ + Other methods, like `eth_getTransactionReceipt` and `eth_getTransactionByHash`, return data from pre-confirmed transactions without requiring the `pending` tag. + Consult the specs (insert link) for more details on each of these methods. + +## Libraries + +You will need a Flashblocks‑aware RPC endpoint to use the following libraries: + +### Viem + +```ts +import { createPublicClient, createWalletClient, http, parseEther } from 'viem'; +import { privateKeyToAccount } from 'viem/accounts'; +import { opSepolia } from 'viem/chains'; +import { publicActionsL2, walletActionsL2 } from 'viem/op-stack'; + +const account = privateKeyToAccount(`0x${process.env.PRIVATE_KEY}`); + +const walletClient = createWalletClient({ + account, + chain: opSepolia, + transport: http("https://sepolia.optimism.io"), +}).extend(walletActionsL2()); + +const publicClient = createPublicClient({ + chain: opSepolia, + transport: http("https://sepolia.optimism.io"), +}).extend(publicActionsL2()); + +const submissionTime = new Date(); +const hash = await walletClient.sendTransaction({ + to: '0x...', + value: parseEther('0.0001'), +}); + +// Wait for pre-confirmation +const receipt = await publicClient.waitForTransactionReceipt({ hash }); +const confirmTime = new Date(); +console.log('pre-confirmed in ms:', confirmTime.getTime() - submissionTime.getTime()); +``` + +### Ethers + +```ts +import { ethers } from 'ethers'; + +// Here, provider is a Flashblocks-enabled RPC provider +const provider = new ethers.JsonRpcProvider("https://sepolia.optimism.io"); +const wallet = new ethers.Wallet(process.env.PRIVATE_KEY as string, provider); + +const tx = { to: '0x...', value: ethers.parseEther('0.0001') }; +const submission = new Date(); + +const sent = await wallet.sendTransaction(tx); + +await sent.wait(0); +const confirmed = new Date(); + +// should represent the transaction (pre)confirmation faster than standard RPC +console.log('Pre-confirmed in ms:', confirmed.getTime() - submission.getTime()); + +// validates the transaction hash returned by the pre-confirmed transaction above +const receipt = await provider.getTransactionReceipt(sent.hash); +console.log('Receipt validated in ms:', validated.getTime() - submission.getTime()); +console.log('Transaction receipt:', receipt); + +``` + +## Flashblocks FAQ + +### Block building and availability + +
+ How often are Flashblocks produced? + The flashblocks target interval is variable. + OP Mainnet runs flashblocks at 250ms while Base and Unichain run them at 200ms. + A 2-second block at 250 ms produces 9 flashblocks, indexed 0 to 8. + The index-0 block contains deposit-only transactions, followed by 8 normal Flashblocks. +
+ +
+ Will the number of Flashblocks per block always be the maximum? + Not always. Heavy execution in one interval may reduce time available for subsequent intervals. The FLASHBLOCKS\_TIME setting is a target, not a strict guarantee. +
+ +
+ Do large gas transactions get delayed? + High gas transactions can be included in any flashblock with sufficient gas capacity. Placement is optimized by heuristics, but available gas decreases as transactions fill earlier flashblocks. +
+ +### High availability and safety + +
+ What happens if the flashblocks builder fails? + In a default/non-HA setup, the system falls back to regular block building while preserving pre-confirmations. In an HA setup, `op-conductor` seamlessly transfers leadership to a healthy sequencer without interruption. + When leadership changes, streaming continues seamlessly from the new leader so downstream consumers always receive a continuous stream from a single stable endpoint. +
+ +
+ How is continuity handled in high availability setups with multiple sequencers? + Only the current leader streams Flashblocks. On leader change, streaming continues from the new leader so downstream consumers see a continuous stream from a single stable endpoint. For details on high-availability sequencer setups, see the [op-conductor documentation](https://docs.optimism.io/operators/chain-operators/tools/op-conductor). +
+ +
+ Do flashblocks change the safety model of the chain? + No. Each flashblock is validated by the same execution engine as normal blocks. +
+ +### Pre-confirmations and reorgs + +
+ Can pre-confirmations be revoked? + Rarely. If the sequencer reorgs, pre-confirmed state may change - but this carries no more risk than the reorg of normal blocks. +
+ +
+ Why can a pre-confirmed transaction later disappear? + If the sequencer reorgs, pre-confirmed state can be replaced. This does not add risk beyond the pending state reorg risk that already exists. +
+ +
+ Does Flashblocks change liveness or withdrawals? + No. Protocol guarantees remain the same; Flashblocks only speed up transaction confirmation. +
+ +
+ What is the structure of a pre-confirmation response? + In pre-confirmation responses, `blockHash`, `stateRoot`, and `receiptsRoot` are the values that represent the cumulative state of all transactions included up to that point in the block. The blockNumber reflects the current pending block number. + Each flashblock's view shows the complete state incorporating all transactions processed so far. +
+ +## Next steps + +* Explore the [high-level guide](/operators/chain-operators/features/flashblocks/chain-operators) for operators. +* Review the [technical specs](https://specs.optimism.io/protocol/flashblocks.html) for architecture details. +* Join our [community](https://discord.gg/jPQhHTdemH) to share best practices and get support! diff --git a/words.txt b/words.txt index fc0e645e4..65eb75e8f 100644 --- a/words.txt +++ b/words.txt @@ -1,7 +1,7 @@ -accountqueue ACCOUNTQUEUE -accountslots +accountqueue ACCOUNTSLOTS +accountslots ACDC ADDI ADDIU @@ -9,58 +9,58 @@ ADDU airgap Allnodes allocs -alphanet Alphanet -alphanets +alphanet Alphanets +alphanets altda ANDI Ankr Apeworx Arweave authrpc -autorelay Autorelay +autorelay autorelayer basefee bcde -betanet Betanet -betanets +betanet Betanets +betanets BGEZ BGTZ Biconomy BLEZ -blobpool BLOBPOOL +blobpool blobspace Blockdaemon blockhash blocklists -blocklogs BLOCKLOGS -blockprofilerate +blocklogs BLOCKPROFILERATE +blockprofilerate Blockscout -blockspace Blockspace +blockspace blocktime -blocktimes Blocktimes -bloomfilter +blocktimes BLOOMFILTER +bloomfilter BLTZ Bootcamp bootnode -bootnodes -Bootnodes BOOTNODES +Bootnodes +bootnodes bottlenecked -brotli Brotli -callouts +brotli Callouts +callouts CCIP cdef Celestia @@ -73,67 +73,71 @@ chaosnet Chugsplash Clabby codebases -collateralized Collateralized +collateralized compr Comprensive -computependingblock COMPUTEPENDINGBLOCK +computependingblock confs corsdomain counterfactually -crosschain Crosschain +crosschain Crossmint daserver -datacap DATACAP -datadir +datacap DATADIR +datadir Defi Defillama's delegatecall -devnet Devnet -devnets +devnet Devnets +devnets devs direnv -disabletxpoolgossip DISABLETXPOOLGOSSIP -discv +disabletxpoolgossip Discv +discv DIVU Drand dripcheck Drippie Eigen EIPs -enabledeprecatedpersonal ENABLEDEPRECATEDPERSONAL +enabledeprecatedpersonal enginekind -erigon Erigon -etherbase +erigon ETHERBASE +etherbase Ethernity Ethernow -ethstats ETHSTATS -evmtimeout +ethstats EVMTIMEOUT +evmtimeout executability exfiltrate -exitwhensynced EXITWHENSYNCED +exitwhensynced extensibly -extradata EXTRADATA +extradata Farcaster Faultproof -fdlimit FDLIMIT +fdlimit +flashblock +flashblock's +FLASHBLOCKS Flashblocks +flashblocks Flashbots forkable forkchoice @@ -141,51 +145,51 @@ FPVM FPVMs Fraxtal Funct -gascap GASCAP +gascap gaslessly -gcmode GCMODE +gcmode Gelato gifs -globalqueue GLOBALQUEUE -globalslots +globalqueue GLOBALSLOTS +globalslots gokzg growthepie hardfork hardforks -healthcheck HEALTHCHECK +healthcheck healthchecks -historicalrpc HISTORICALRPC -historicalrpctimeout +historicalrpc HISTORICALRPCTIMEOUT -holesky -Holesky +historicalrpctimeout HOLESKY +Holesky +holesky IERC -ignoreprice IGNOREPRICE +ignoreprice Immunefi -inator Inator -influxdbv +inator INFLUXDBV +influxdbv initcode -ipcdisable IPCDISABLE +ipcdisable ipcfile -ipcpath IPCPATH +ipcpath IPFS JALR -journalremotes JOURNALREMOTES -jspath +journalremotes JSPATH +jspath jwtsecret Keccak leveldb @@ -194,34 +198,34 @@ Lisk logfile logfmt Mainnets -maxage MAXAGE -maxbackups +maxage MAXBACKUPS -maxpeers +maxbackups MAXPEERS -maxpendpeers +maxpeers MAXPENDPEERS -maxprice +maxpendpeers MAXPRICE -memprofilerate +maxprice MEMPROFILERATE -merkle +memprofilerate Merkle +merkle MFHI MFLO Mgas Minato -minfreedisk MINFREEDISK -minsuggestedpriorityfee +minfreedisk MINSUGGESTEDPRIORITYFEE +minsuggestedpriorityfee Mintable Mintplex MIPSEVM Mitigations -monitorism Monitorism +monitorism Moralis Mordor MOVN @@ -230,145 +234,145 @@ MTHI MTLO MULT multiaddr -multichain Multichain +multichain multiclient multisigs MULTU Nethermind -netrestrict NETRESTRICT -networkid +netrestrict NETWORKID -newpayload +networkid NEWPAYLOAD +newpayload nextra -nocompaction NOCOMPACTION -nodekey +nocompaction NODEKEY -nodekeyhex +nodekey NODEKEYHEX +nodekeyhex nodename Nodies -nodiscover NODISCOVER -nolocals +nodiscover NOLOCALS -noprefetch +nolocals NOPREFETCH -nopruning +noprefetch NOPRUNING -nosyncserve +nopruning NOSYNCSERVE +nosyncserve Numba NVME -offchain Offchain +offchain onlyreqtostatic opchaina opchainb -opcm OPCM +opcm Openfort oplabs opnode's outfile outperformance pcscdpath -pectra Pectra +pectra Pectra's -peerstore Peerstore +peerstore peerstores -permissioned Permissioned +permissioned permissioning -permissionless Permissionless +permissionless permissionlessly Perps Peta Pimlico POAP POAPs -pprof PPROF -precommitments +pprof Precommitments +precommitments preconfigured predeploy -predeployed Predeployed -predeploys +predeployed Predeploys +predeploys prefunded -preimage Preimage -preimages +preimage PREIMAGES +preimages preinstall -preinstalls Preinstalls -prestate +preinstalls Prestate +prestate prestates PREVRANDAO -pricebump PRICEBUMP -pricelimit +pricebump PRICELIMIT +pricelimit productionize productionized Protip Proxied -proxyd Proxyd +proxyd Pyth Pyth's QRNG -quicknode Quicknode +quicknode quickstarts rebalancing reemit Reemitting -regenesis Regenesis +regenesis Reimagine -rejournal REJOURNAL -remotedb +rejournal REMOTEDB +remotedb Reown Reown's replayability replayor reposts reproven -requiredblocks REQUIREDBLOCKS +requiredblocks rollouts -rollups Rollups +rollups Routescan rpckind -rpcprefix RPCPREFIX +rpcprefix rpcs RPGF -runbooks Runbooks +runbooks RWAs safedb Schnorr -sepolia -Sepolia SEPOLIA +Sepolia +sepolia seqnr -sequencerhttp SEQUENCERHTTP +sequencerhttp serv signup SLLV @@ -377,16 +381,16 @@ SLTIU SLTU smartcard snapshotlog -snapsync Snapsync +snapsync Solana Soneium soyboy Spearbit SRAV SRLV -stablecoins Stablecoins +stablecoins statefulset structs subcomponents @@ -395,21 +399,21 @@ subheaders subsecond SUBU Sunnyside -superchain -Superchain SUPERCHAIN +Superchain +superchain Superchain's superchainerc Superlend Superloans Superscan Superseed -supersim Supersim -syncmode +supersim SYNCMODE -synctarget +syncmode SYNCTARGET +synctarget syscalls SYSCON thirdweb @@ -423,8 +427,8 @@ Twei txfeecap txmgr txns -txpool TXPOOL +txpool txproxy txproxyd uncensorable @@ -434,21 +438,21 @@ Unichain Unprotect unsubmitted UPNP -verkle VERKLE -vhosts +verkle VHOSTS -viem +vhosts Viem -viem's +viem Viem's -vmdebug +viem's VMDEBUG -vmodule +vmdebug VMODULE +vmodule xlarge XORI ZKPs ZKVM -zora Zora +zora