OP Stack Flashblocks and the Evolution of L2 Architecture

The race for blockchain speed just took a sharp turn. While Ethereum processes blocks every 12 seconds, Flashblocks is shipping transaction confirmations in as little as 200 milliseconds.

• Flashblocks delivers 200ms transaction confirmations through streaming partial blocks that defer expensive computation
• Available now through Gelato RaaS - deploy your own Flashblocks-enabled OP Stack rollup
• Flashbots open-sourced this critical infrastructure including op-rbuilder (Rust block builder) and Rollup-Boost (TEE-based platform powering Unichain)
• Enables the Superchain vision where chain interactions feel instantaneous

Gelato RaaS provides production-ready Flashblocks support for OP Stack chains today. Whether you're launching a new rollup or upgrading an existing one, Gelato handles the infrastructure.

Getting started is simple: Contact the Gelato team to enable Flashblocks on your OP Stack chain.

Faster block confirmations unlock entirely new categories of blockchain applications—from high-frequency trading and real-time gaming to responsive payment systems—while making DeFi more capital efficient by reducing the time arbitrageurs need to correct price discrepancies.

A simple approach to achieving faster transaction confirmations would be to just drop the block time. But simply lowering block times isn't viable for sub-second confirmations. Sub-1s block times would require significant Geth/Reth modifications that harm EVM equivalence—a core protocol goal for the OP Stack to maintain 1:1 compatibility with anything built on Ethereum while minimizing protocol complexity. Additionally, calculating the state root for every 200ms block would create overhead that makes node syncing prohibitively slow as chain state grows.

This is why the OP Stack switched to 2-second block times—until a better, sustainable solution could be developed. That solution is Flashblocks.

Flashblocks are ephemeral, sub-second blocks that provide users with near-instant transaction confirmations without the computational overhead of traditional blocks. Think of them as "streaming blocks"—partial blocks that are continuously produced and sent to nodes so that execution confirmations can be received in milliseconds.

How does this happen? By deferring expensive computation like state root generation to full blocks while offering quick confirmations through lightweight partial blocks. This amortizes the computational cost across many transactions while providing users with the responsive experience they expect.

The development of Flashblocks should be seen as a significant collaborative effort across the industry, with Flashbots playing a central role in open-sourcing infrastructure:

op-rbuilder: Originally developed by Flashbots as next-generation block building infrastructure, op-rbuilder is a Rust-based block builder that has been adapted for rollups. This open-source project separates transaction execution from state commitment, enabling the deferred computation model that makes Flashblocks possible.

Rollup-Boost: Rollup-Boost is Flashbots' verifiable block building platform for rollups.

Open-source and powering Unichain and Base, the rbuilder/Rollup-Boost infrastructure enables a suite of exciting builder modifications that add custom functionality without changing the core protocol. These modular features include:

• Flashblocks: 200ms streaming blocks for ultra-fast confirmations
• Verifiable priority ordering in a TEE: Cryptographically provable transaction ordering
• Revert protection: Filters out failing transactions before inclusion
• Custom block building logic: Native price oracle updates, top-of-block auctions for MEV capture, and more

The genius of Flashblocks lies in its approach to computationally expensive operations. State root calculation and consensus—traditionally the bottlenecks in block production—are deferred and calculated only once for multiple partial blocks. This amortization strategy means that while users receive confirmations every 200ms, the heavy computational work happens only once per second, maintaining system efficiency while improving user experience.

This approach enables a multiple-fold increase in gas per second without proportionally increasing computational overhead. By separating the confirmation layer from the finalization layer, Flashblocks achieves faster confirmations without sacrificing security or significantly increasing hardware requirements for node operators.

Usually, the rollup’s sequencer is not directly exposed to the outside world. Instead, multiple full nodes run alongside it and serve RPC requests. This isolates the sequencer for better security and allows nodes to scale horizontally with increasing traffic. Whenever a block is produced by the sequencer, nodes sync and re-execute it to update their local state – this local state is what is served via RPC.

With the introduction of Flashblocks, users making RPC requests are no longer interested in the latest block state but rather the latest flashblock state. Otherwise, if user A sends ERC-20 tokens to user B and this transaction is executed in a flashblock, user B won’t know they received tokens until the full block is produced. In other words, user A receives an execution preconfirmation (given the transaction receipt in the flashblock) but neither user A nor user B know the resulting state until a full block is produced.

We want nodes to be able to serve early flashblock execution state via RPC. This requires the sequencer to stream Flashblocks to nodes and requires nodes to apply the resulting state to their local state – this can be performed in a few ways:

• Nodes re-execute transactions contained in the flashblock to arrive at the resulting state themselves (no additional trust assumptions)
• Nodes receive the resulting state from the sequencer directly and update their local state without re-execution (more efficient, but trusting sequencer)
• Nodes receive the resulting state from the sequencer along with a proof that this state was reached legitimately (ZK proof, TEE attestation) Nodes serving early execution state is the Flashblocks endgame since it makes Flashblocks indistinguishable from full blocks. For example, a user can swap token A for token B and receive a confirmation from MetaMask that this was executed successfully 200ms later. Under the hood, MetaMask queries the user’s token balances and immediately displays the updated amounts. All of this happens within 200ms, whilst the actual block time may be 2 seconds, but the user won’t know the difference.

Whilst the roadmap includes plans to leverage TEEs for encrypted mempools, validity proofs for rollups to qualify as stage 2, TEE coprocessing, and so on, there is also potential for TEEs to attest to the validity of Flashblocks. This allows nodes to verify these attestations and directly apply resulting flashblock state to their local state without having to re-execute all contained transactions – this is a particularly interesting application. Note that this functionality is currently not yet available in the public rbuilder implementation.

At present, Rollup Boost is officially compatible with OP Stack chains. This unlocks customizable block building which allows you to define your rollup’s block building logic including native price oracle updates, top-of-block auction for MEV capture, and more.

This breakthrough isn't just about making one chain fast—it's about transforming the entire L2 ecosystem. Flashblocks represents a critical piece of infrastructure for realizing Optimism's broader Superchain vision.

The Superchain is Optimism's network of interoperable L2 chains that function as a unified ecosystem, treating blockchain compute as a commodity resource where applications can span across chains without users even noticing.

Building the best blockspace means having the best end user experience, and while 2 seconds of transaction latency is fast, it doesn't feel instant. Modern users expect the responsiveness they get from web2 applications—when they click a button, they want immediate feedback. This is especially critical for DeFi applications where faster transaction latency directly translates to more capital efficient markets. Research shows that liquidity providers on L2s with faster block times achieve 20% higher fee returns from arbitrage and 75% more concentrated liquidity around the midmarket price compared to Ethereum mainnet.

The OP Stack continues to push the boundaries of L2 innovation across multiple fronts. With OP Succinct, any OP Stack chain can leverage ZK proofs for fast finality. This reduces settlement from 7 days to minutes. It's the only L2 stack with full native Reth support, which unlocks the performance benefits of Rust-based execution. And now Flashblocks delivers the industry's fastest transaction confirmations at 200ms.

Base is an early adopter of Flashblocks and also a significant contributor to the ecosystem's infrastructure. Base has developed and open-sourced a critical piece of infrastructure: the Flashblocks WebSocket Proxy. This Rust-based service acts as an intermediary between the sequencer running Rollup-Boost and the broader network of RPC nodes. By subscribing to new Flashblocks from the sequencer and broadcasting them to downstream nodes, it protects the sequencer from being overwhelmed by direct node connections. It implements rate limiting through Redis for distributed control across multiple proxy instances. When Redis is unavailable, the system falls back to in-memory rate limiting.

The Base team has also contributed patches and improvements back to the core rbuilder project. Their base-reth binary includes integrated Flashblocks support, making it straightforward for node operators to enable this functionality.

While Flashblocks represents the OP Stack's evolution path, Arbitrum has developed Timeboost as its solution to the sequencing challenge.

The Direct Block Time Approach

Arbitrum achieves fast confirmations through the straightforward method of producing blocks every 250ms. While this delivers similar confirmation speeds to Flashblocks, it comes with EVM equivalence issues from modifying core execution clients, increased computational overhead from calculating state roots every 250ms, and sustainability concerns as chain state grows.

A Different Solution: Timeboost

Arbitrum has also introduced Timeboost, which aims to provide faster confirmations for some users who pay a priority fee. Although rather than improving latency, Timeboost actually increases transaction delay by introducing a time-based priority auction. Transactions can pay fees to receive a "time boost" of up to 500ms, moving their timestamp earlier in the queue. This mechanism captures MEV value for the protocol and solves the latency racing problem in FCFS systems.

By providing users 200ms confirmations out of protocol, Flashblocks have opened a design space with fast confirmations that don’t compromise the scalability of the underlying stack.

The block confirmation barrier has been broken, and the race is on to see who can best serve the next generation of crypto applications.

Reach out to us to deploy your own Flashblocks enabled OP Stack Rollup today to power low-latency applications by unlocking blazingly fast block times.

Further Reading

• Unichain Whitepaper
• Rollup Boost
• Base Implementation
• Flashblocks on Base
• Rbuilder
• Megaeth Miniblocks
• Megaeth API
• Ethresearch