Revert Protection for Rollup
category
MEV
date
Mar 10, 2025
slug
revert-protection-for-rollup
type
Post
lang
en
status
Published
This post aims to explain the importance and challenges of revert protection on rollups, and to increase contributors in that area. Revert protection improves the user experience by preventing not only general users but also arbitrageurs from having to pay unnecessary gas fees. Even though we participate in intents protocols such as Across and UniswapX, there were cases in certain rollups where we had to pay unnecessary gas fees. To solve such problems, we implemented a PoC of revert protection that functions on rollups, as well as an environment in which it can be tested locally. However, there are still remaining challenges. Ultimately, we raise these issues in this article, with the hope that the industry will be able to resolve them.
1. What is Revert Protection
- Transaction Reversion: This occurs when an error arises during the execution of a smart contract, causing the state transition of that transaction not to be executed. For users, even if a transaction reverts, the gas consumed is not refunded, meaning they incur costs by having to pay for the failed transaction.
- Revert Protection: This is a mechanism in which block builders simulate transactions in advance and discard those that are likely to fail from the block. By doing so, users do not have to pay unnecessary gas fees, and only successful transactions are included in the block, thereby increasing the effective number of transactions per block.
In Ethereum, revert protection has already been incorporated into several services. Notable examples include Flashbots Protect provided by Flashbots and MEV Blocker provided by CoW DAO. Flashbots Protect works by sending transactions to a private mempool and selecting only those that do not revert when including them in a block, thereby sparing users the cost of reverted transactions. Similarly, MEV Blocker aims to discard transactions that would revert. These services operate as endpoints, and eventually, the transaction is forwarded to the block builder.
The diagram below illustrates the process described in op-rbuilder, where transactions go through simulation, execution, and broadcast from the pool.
Block builders simulate each transaction in the OrderSimulationPool before constructing a block, detecting those that would revert in advance and excluding them from the block. This allows users and searchers to benefit from not being charged gas fees when a transaction fails, making it easier for them to participate in the market.
On the other hand, block builders “forfeit the fees that would have been earned from transactions that would have reverted,” which directly results in a loss for them. However, for users and searchers, sending transactions to block builders that implement revert protection is advantageous. This indirectly suggests that block builders’ fee revenue could increase as indicated. Vitalik has also made a tweet echoing this view, mentioning that revert protection directly improves the user experience while potentially increasing block builders’ revenue indirectly.
Thus, revert protection is an important mechanism that improves user experience and market efficiency, benefiting a wide range of stakeholders including users, searchers, block builders, and validators. However, on rollups today, revert protection according to this definition either does not exist or is incomplete (note that three days prior to the publication of this article, Flashbots fixed part of it). Therefore, our focus is on revert protection on rollups rather than on L1.
2. Revert Protection for Rollup
When applying revert protection to rollups, considerations different from those on L1 are necessary.
There are two main differences from L1. The first is that there is no public mempool. In many rollups, transactions are sent directly to the sequencer without passing through a public mempool. The second is that in rollups, the sequencer fulfills multiple roles, including that of block builder. For example, in rollups, the sequencer is essentially responsible for determining the order of transactions and constructing blocks. Therefore, the sequencer itself must have the logic to pre-validate the execution of each transaction and exclude those that would revert from the block.
As an example, in Base and Unichain, transactions are sent directly to the sequencer without going through a public mempool and are processed through block construction. In the block construction process, a verifiable mechanism utilizing a TEE called Rollup-Boost is implemented. One of its features, known as Flashblocks, divides a block into multiple sub-blocks, enabling fast pre-validation of transactions. This Flashblocks functionality is noted to not only provide pre-validation but also implement revert protection as mentioned.
However, in the current Base Sepolia and Unichain environments, there are still cases where reverted transactions are included in blocks, as confirmed, indicating that revert protection is not yet fully functional. In fact, on Base Sepolia, reverted transactions can be viewed through the explorer.
To fix the issue where revert protection is only partially guaranteed, we modified
op-rbuilder and implemented revert protection. Within the existing process, there is a step that simulates transactions before block generation, allowing any transaction that results in an error to be excluded.However, while this process can exclude errors such as nonce errors from the block, it does not exclude transactions that encounter errors within the contract.
When a transaction fails, we added a process that registers the failed transaction in a list using
info.invalid_transactions(…) and excludes it from being added to the block. With this implementation, only successful transactions remain in the block.Additionally, after block construction, a process is executed to remove transactions marked as invalid from the pool by calling
pool.remove_transactions(...). Without this implementation, reverted transactions would persist indefinitely in the mempool.his simple implementation excludes transactions that would revert during block creation and also removes them from the private mempool. With this process, revert protection can be fully guaranteed on all rollups such as Base and Unichain.
Next, we explain the steps to build and verify its functionality locally.
3. Building on a Local Devnet
To verify the operation of revert protection on L2, a prototype can be built in an Optimism environment. Below are the steps to run a local environment using
op-rbuilder.1. Starting op-node and op-rbuilder
First, start op-node and op-rbuilder. Detailed instructions on how to build op-node and op-rbuilder are available here. Here, we only cover a simplified procedure.
op-node
op-rbuilder
2. Deploy a Test Contract
Using the scripts within the
revert-protection repository, deploy a test smart contract on the local devnet. This contract is designed to intentionally trigger a revert under specific conditions.To deploy, please run the following command:
3. Sending a Reverting Transaction
Send a transaction to the deployed contract. You can verify through the logs of
op-rbuilder and the block contents that the transaction which reverts has been excluded from the block, and that the user does not incur gas fees for the reverted transaction.There is no error handling for transactions that revert. As a result, when sending a transaction via cast send, the process does not terminate.
4. Further Challenges and Future Work
While the current implementation is kept simple, several improvements are necessary for practical deployment.
- DoS Attack Mitigation for Sequencers: With revert protection, fees are not charged for failed transactions, which introduces the risk that malicious users could intentionally send a large number of invalid transactions to overload the sequencer—a potential DoS attack. As countermeasures, one could consider implementing a reputation system based on wallet addresses or setting up dedicated endpoints that guarantee revert protection (similar to Flashbots Protect) to impose rate limits on an IP address basis. These measures are expected to suppress spam-like failed transaction submissions from malicious sources and enhance the security of the sequencer.
- Separation of the Mempool and Simulation Pool: In the current implementation, transactions that fail simulation are simply removed from the mempool. However, a future architecture might include a dedicated pool for simulation results, separate from the regular mempool, from which blocks are constructed using only successful transactions. This would allow for more efficient block proposals that are independent of the transaction ordering in the regular pool, while also enabling advanced optimizations and further isolation from the effects of failed transactions.
Improving these aspects will enable revert protection to be provided by default in rollup frameworks such as OP Stack and Arbitrum Orbit, delivering an enhanced user experience across a broader range of chains. We are actively pursuing research and development to address these challenges. If you are interested in discussing or implementing revert protection, or if your chain or project is involved, please contact us here.