Understanding Flashblocks
Recently, Base posted that using Flashblocks has made them the fastest EVM chain in the ecosystem. Flashblocks have allowed Base to reduce their block times from two minutes to 200ms, which is a 10x improvement in testnet.
Base is not the only L2 that has used this technology. Uniswap also leveraged the same technology to implement 250ms second block times on their Layer 2 Unichain.
Block time in blockchains is the average time it takes for the network to create and add a new block to the chain. A block is like a page in a ledger, storing a batch of transactions (e.g., sending crypto, executing smart contracts). Block time affects how fast transactions are processed and confirmed, making it a key feature of a blockchain’s design.
Shorter block times mean faster transaction confirmations, suitable for payments or real-time apps. More blocks per minute(throughput) can handle more transactions, boosting capacity (though size limits apply too).
Flashblocks has a fascinating background. It is an example of a “roll-up extension” built using the new Rollup-Boost system created by the Flashbots team, OP Labs, and Uniswap Labs.
Before we look at Flashblocks, let’s understand Rollup boost first.
Rollup-Boost is a verifiable block-building platform for optimistic rollups enabled by a Trusted Execution Environment(TEE). Rollup-boost allows optimistic rollups to create modules or pluggable components that could address some key problem areas that have forced them to trade between better UX and achieving decentralization.
One such problem area is how to reduce transaction confirmation times for the end user without, at the least, breaking the existing security guarantees.
Let’s understand this statement.
Currently, an optimistic rollup like Unichain has a block time of one second (two seconds for other chains), meaning transactions have to wait for one second before they can be confirmed by the chain, i.e. added to a block.
This is a “soft confirmation” instead of an L1 confirmation, which takes days for optimistic rollups because of the seven-day fraud-proof window. The implicit security assumption here is that the one-second (or two-second) wait time guarantees that the transactions get included in a block before being sent to Ethereum. This guarantee must not be removed or nullified in any way. In other words, the new (reduced) confirmation time must provide similar (or better, if possible) guarantees.
Can this problem be solved using Rollup-Boost?
According to the team behind rollup-boost, it can be, so they created Flashblocks.
Flashblocks breaks the one-second block time into four 250ms blocks, each with its confirmation called a “pre-confirmation,” which gives the end users a near-instant UX.
Since transactions are bundled inside a TEE, which prevents alteration under normal conditions, there’s an implicit guarantee they’ll be pre-confirmed in 200–250ms and soft-confirmed within the standard rollup timeline of 1–2 seconds. This provides a better guarantee because TEEs add a layer of verifiability, potentially reducing sequencer-induced reorgs. Of course, a sequencer can still go ahead and soft confirm one thing and then sequence something else.
Regarding the finality of soft confirmation, having a TEE does not make any difference as finality is achieved after the challenge period expires (e.g., 7 days on Optimism) and the rollup state is thoroughly verified and accepted on the Ethereum mainnet.
So, a TEE provides similar (if not better) security guarantees, allows for sub-second transaction confirmation speeds, but adds a trust assumption because of the new TEE environment.
Another critical aspect of the rollup-boost design is that it helps “internalize” MEV. What does this mean?
“Internalizing” MEV refers to keeping that extra profit (the MEV) within the system or application (like a DEX) that generates it rather than letting outside actors — like independent bots or searchers — take it.
Along with flashblocks, the team has also released another extension called “verifiable priority ordering.” With “verifiable priority ordering,” the rollup can decide which transactions go first in its blocks based on rules it sets, allowing for greater control over ordering. For example, an app like Uniswap could prioritize users’ trades to prevent outsiders from front-running them, keeping the profit (MEV) inside its ecosystem.
Now, using this ordering system within flashblocks adds another difficulty for bots. The 250ms Flashblocks mean transactions get confirmed (pre-confirmed technically) so quickly that these bots have less time to spot and exploit opportunities. If an app can process its trades fast and in a controlled way, it can grab the MEV before outsiders do.
Having the MEV stay within the protocol or dApp is excellent news for the rollup, especially if they consider transitioning into a based rollup.
For those unaware, based rollups are rollups that outsource their sequencing duties to Ethereum validators in return for better interoperability, security, and decentralization. However, they will lose all the MEV they create by doing this.
Flashblocks with verified priority ordering will help such rollups generate micro MEV by ordering the flashbacks instead of the L2 block and compensating for this loss. Thus, they will address one of rollups’ most significant concerns with based sequencing.
