A Holistic view of solutions to reduce 7-day Finality in OP Rollups

Optimistic rollups or OP Rollups are the key contenders in the battle of Layer2 scaling solutions. With leading projects like Optimism (OP) Mainnet, Arbitrum One/Nova, Zora, Base, and Mantle network– Optimistic rollups have now become a top choice for innovative dApps and web3 projects. Despite all the features and benefits, OP rollups are often challenged for its 7-days finality window. While this week-long confirmation window is designed to ensure solid security and rollup integrity, a significant reduction in this duration can make Optimistic rollups even more popular with enhanced user experience and protocol robustness.

This article talks about some of the interesting models proposed by industry experts who envision a better future for OP Rollups. Reading this, you will get an all-encompassing view of how different points present distinct improvement plans to reduce 7-day Finality in optimistic Rollups.

But, why is the challenge period a week?

Let’s first understand the core idea behind having this 7-days window. Well, the concept is simple– “giving enough time for verifiers,” that’s it. The fraud proving process in OP rollups requires multi–round challenges. Hence, a week’s length has been decided to allow honest validators to submit a fraud proof in case they witness any invalid state transition. 

If we talk about a shorter challenge window, it will definitely speed up the transaction process and allow for quick withdrawals. But, it can also increase the risk of adding fraudulent transactions in the blocks because validators won’t have enough time to authenticate all the transactions. Also, the longer finality slot accommodates the time required to detect bugs in the rollup network’s software or state transition function.

Models proposed to reduce 7-day Finality of Optimistic Rollups

The discussion for reducing the waiting period in Optimistic rollups has been active since 2020. However, due to the continuation of critical issues like consensus failures on Ethereum, the majority kept on favoring the concept of a fixed 7-day 7-day Finality in optimistic Rollups. Now that Ethereum and most Ethereum-compatible blockchains have transitioned to proof-of-stake from proof-of-work and the duration of consensus failure is notably reduced, the arguments around reducing 1-week finality are heating once again. Below are some of the tweets justifying the ‘challenge period’ as downside of OP rollups.

In this regard, let’s discuss the popular models proposed to reduce the 7-day challenge window in Optimistic rollups.

1- Check-in model— Nick Dadson @ Fuel Labs

The Ethereum Research post by Nick Dadson on “Check-in model” for fast OP rollup finality has gathered huge traction in the rollup space, also discussed at EthDenver. This check-in model introduces a new censorship-resistant scheme for Optimistic rollups, aiming to reduce the confirmation window from a week to just a few blocks while retaining the single honest minority assumption. 

The core idea here is to replace the conventional approach of validation in which honest minority validators are supposed to submit a challenge whenever some invalid state transition is identified. Now, the check-in model suggests that all the validators must aggressively check if they have missed any check-in transaction, which can happen in case of offline activity or censorship. Based on the situation, the finality window will expand dynamically, up to 7-days. 

Validators in a check-in based model are accountable to submit transactions periodically for every epoch, let’s say for every 64 Ethereum blocks. Regarding the check-in mechanism, it will work based on the following three conditions:

1. True, in case there are no invalid transactions in the past epoch.
2. False, if an invalid transaction is detected in the past epoch.
3. No-report, the node is down or honest minorities have been censored.

In case of True, all the validators will check-in with true, allowing the state to be finalized in just 64 blocks 9 (or an epoche). 

In case of False, either all or just one validator will check-in with False, enabling the fraud proving window to remain open until the state is finalized and the result is concluded. 

For no-report, it is assumed that an honest minority has been censored and thus the window keeps on being extended until its maximum time frame so that fraud proof can be submitted to undo the mistake.

This approach empowers Optimistic rollup protocols to thwart massive censorship attacks on their network through honest minority validators. 

2. The idea of ‘ Forked block censorship oracle’ from Ed Felten– The Co-founder @Offchain Labs

Ed Felten, in his intense research on Optimistic Rollups’ challenge period proposed the idea of building “censorship oracle ” within the smart contract to implement the following two conditions. Note that this idea is based on the fact that proof-of-stake networks are now optimized to easily detect censorship. 

1. There has been zero censorship in N blocks (for example, total blocks in the last 23-hour periods).
2. No conclusion is reached.

If no censorship is detected, the rollup network can accept Layer2 state assertion and confirm transactions rapidly. However, if the oracles do not guarantee surety, then the rollup protocol still has to wait till 7 days for the challenge period to complete. 

Here’s a sample contract reflecting implementation of censorship oracle in the rollup’s smart contract:

interface CensorshipOracle {

    function testParameters(

        uint64 percentNoncensoringValidators,

        uint64 inverseConfidenceLevel,

    ) pure returns (

uint64,  // test duration

uint64,  // max missing blocks allowing test to pass

);

    function startTest(

        uint64 percentNoncensoringValidators,

        uint64 inverseConfidenceLevel,

    ) returns (bytes32, uint64, uint64);

    function getTestInfo(

        bytes32 testId,

     ) view returns (

        uint64,  // percent non-censoring validators

        uint64,  // inverse confidence level

        uint64,  // test start timestamp

        uint64,  // test result available timestamp

        bool,    // test has finished

        bool     // (test has finished) && (non-censored block was included)

     );

    function finishAndGetTestInfo(bytes32 testId) returns (

        bytes32 testId,

     ) returns (

        uint64,  // percent non-censoring validators

        uint64,  // inverse confidence level

        uint64,  // test start timestamp

        uint64,  // test result available timestamp

        bool,    // test has finished (will be false if result not available yet)

        bool     // (test has finished) && (non-censored block was included)

     );

}

3. ‘Dynamic challenge period model’ from Three Sigma:

Taking into account Ed Felten’s idea of a “censorship oracle’ and a few important concepts of the Optimistic Rollup challenge period, 3Sigma has proposed a unique ‘Dynamic Challenge Period model’ that works with the following two main concepts:

1. Reducing the 7-days challenge period based on the level of risk involved in the transactions: 

As you may already know, the main idea behind a week’s finality time is to make it long enough and extremely expensive for malicious sequencers to perform DoS attacks. However, they can still succeed by enforcing the high transaction fee strategy from the moment batches are submitted on layer1 till completion of the challenge period. A good example of this is the incident in the Fomo3D game’s contest. 

Considering such scenarios, 3Sigma suggests that the rollup protocol should employ tactics to identify malicious sequencers or attackers so that transaction fees collected from them should be greater than the profit they can earn from the batch. This means that the maximum profit should be equal to or more than the batch’s aggregate value. What we understand from this statement is that batches with high-value transactions will not have to wait for any challenge period. This will obviously improve user experience on the network as finality time will be reduced. At the same time, the roll-up protocol’s security will be preserved because of more non-malicious sequencers. 

1. Transition from centralized to decentralized sequencer network:  

This concept emphasizes the decentralization of the sequencer network to improve security and thus reduce the chances of attacks. However, the selection of validators should be done on critical parameters so that all of them are honest with no history of indulging in malicious activities. Further, Sigma’s dynamic challenge period model allows for adding a governance-adjusted time factor for each sequence that works to continuously reduce the finality time as sequencers gain a higher reputation. This way, high-value transactions benefit from extremely shorter confirmation time. Multi-slot sequencer selection process and multi-slot sequencer selection process are the two proposed approaches that Three Sigma’s research suggests for selection of honest, decentralized sequencers.

Apart from the three models we discussed, there’s also a sliding window challenge mechanism based on the fee oracle system. The model is proposed by Patrick McCorry (CEO of PISA Research) in collaboration with research professionals–Ayelet Lotem, Sarah Azouvi, and Aviv Zohar, which suggests adjusting the challenge window as per the congestion on Layer 1. For example, if the fee oracle detected high congestion on Ethereum, it would allow for an extended challenge window. Similarly, if the congestion is low to moderate, the window will be reduced. However, this approach is difficult to adopt in case of extremely busy blockspace as extension of the window will be hard to determine. 

Here’s a TL,DR

1- 7-days finality in Optimistic rollups is advantageous to censor all the fraudulent transactions, keeping the protocol safe.

2- The Check-in model, Forked block censorship oracle, Dynamic challenge period model and Sliding window challenge– all focus on a common goal of reducing 7-finality in rollups, but their approach is different.
3- These models also come with shortcomings:

• The censorship oracle may not be suitable for scenarios when block producers perform the censor outside the protocol. 
• The governance inclusion approach in dynamic window challenge will pose issues to the fundamental assumption around honest minority.
• For check-in Windows, it may negatively affect the honest validators if slashing is applied. It is up to the rollup networks which method they find suitable for reducing the confirmation window on their network.

4- Optimistic rollup projects can adopt any of these models to enable fast-finality on their protocol for higher sustainability.

5- The finality window can be reduced from 24 hours to a maximum of 7-days, based on the protocol-specific scenarios.

Launch your custom OP Rollups quickly with Zeeve RaaS

Zeeve RaaS allows enterprises and web3 projects to launch custom Optimistic Rollups with their modular frameworks– OP Stack and Arbitrum Orbit. In a few clicks, you can launch Layer2 rollups and enhance its usability with 30+ third-party integrations such as Avail, Near DA, Celestia, Biconomy,  Chainlink, Blocksout, Axelar, Espresso, and more. With this, the Zeeve RaaS platform saves up to 97% of your deployment and 60% of management costs. On top of all these, you get a unified dashboard for monitoring and management of all your rollups.

For more details on how Zeeve is simplifying the launch of custom Optimistic rollups, get in touch with our expert. You can drop an email or set up a one-to-one call for a detailed discussion.