In this article, we explore the concept of challenge periods in Optimistic Rollups. We discuss why these challenge periods exist, how they ensure the security of user transactions, and why they typically last for seven days. By breaking down complex cryptographic and economic principles into simple terms, we aim to provide beginners with a clear understanding of why challenge periods are important in Optimistic Rollups and how they contribute to a safer and more efficient decentralized ecosystem.
Big thanks to Kelvin Fichter for his article “Why is the Optimistic Rollup challenge period 7 days?”
Optimistic Rollup represents a Layer-2 scaling solution tailored for blockchain networks, introducing efficiencies in transaction processing without compromising security. Its distinctive feature lies in its “optimistic” approach, whereby transactions are initially presumed valid until proven otherwise through a challenge process. This presumption of legitimacy significantly reduces gas costs and facilitates higher throughput, making it financially feasible for applications requiring extensive computational resources, such as those employing advanced encryption services.
The underlying principle of Optimistic Rollup revolves around offloading computational burdens from the main Ethereum chain by processing transactions off-chain. Once processed, these transactions are aggregated and published on the main chain. Unlike alternative Layer-2 solutions, Optimistic Rollup does not mandate proofs of validity for transaction batches posted on-chain. Instead, it relies on the submission of fraud proofs by vigilant network participants detecting irregularities in transactions.
In the event of detected fraud, smart contracts on the Ethereum mainnet undertake thorough verification processes, scrutinizing individual transactions or entire blocks to assess their validity. Any confirmed instances of fraudulent behavior result in penalties for the batch submitter, often referred to as the Sequencer, such as having their stake slashed. This intricate mechanism not only incentivizes adherence to protocol guidelines but also serves as a deterrent against malicious activities, ultimately upholding the security and integrity of the Optimistic Rollup ecosystem.
When you use the “standard” bridges on the Optimism network, you may have noticed that transactions take 7 days to process. While most activities are now facilitated by fast bridges, the standard bridges still tend to be slower. This period is exactly 7 days. The reason behind this duration is actually related to various aspects of the crypto world. This article will attempt to explain this in simple terms.
Before delving into the specifics of why the withdrawal period in Optimistic Rollup takes 7 days, it’s essential to understand why any delay exists at all. The withdrawal delay is a crucial component of the Optimistic Rollup mechanism. Essentially, when a user initiates a withdrawal from the Optimistic Rollup to Ethereum, they make a claim about the state of their assets.
However, due to the design of Optimistic Rollups, where the main Ethereum chain (L1) doesn’t directly execute the transactions on the layer 2 chain (L2), there’s no automatic verification of these claims. Unlike ZK Rollups, which provide cryptographic proofs of validity to the main chain, Optimistic Rollups require claims to undergo a challenge process before being accepted as valid withdrawals. During this challenge period, challengers have the opportunity to dispute the validity of the claim. If challenged, an on-chain process is initiated to determine the legitimacy of the claim.
The necessity of a challenge period stems from the time it takes for someone to detect and challenge an invalid claim. Without this period, there would be no opportunity for challenges to be raised, undermining the security and integrity of the system.
Transactions sent from L1 to L2 take approximately 1–3 minutes to get from Ethereum to OP Mainnet, or from Sepolia to OP Sepolia. This is because the Sequencer waits for a certain number of L1 blocks to be created before including L1 to L2 transactions in order to avoid potentially annoying reorgs.
Transactions sent from L2 to L1 typically take around 7 days to move from OP Mainnet to Ethereum or from OP Sepolia to Sepolia. This delay occurs because the bridge contract on L1 must wait for the L2 state to be verified on the L1 chain before relaying the message.
The process of transmitting transactions from L2 to L1 involves four main steps:
The L2 transaction, which sends a message to L1, is initiated and confirmed by the Sequencer. This process usually takes just a few seconds.
The block containing the L2 transaction is proposed to the L1 chain, which typically takes approximately 20 minutes.
A proof of the transaction is submitted to the Optimism Portal contract on L1. This step can be completed anytime after step 2 is finished.
Finalization of the transaction on L1 can only occur after the fault challenge period has passed. This period lasts 7 days on Ethereum and just a few seconds on Sepolia. This waiting period is an integral aspect of the security model of the OP Stack and cannot be bypassed.
Understanding the interaction between Layer 1 (L1) and Layer 2 (L2) is crucial, especially regarding the delay in relaying messages from L2 to L1. When you send messages from L2 to L1, they cannot be relayed for at least 7 days. This waiting period is known as the “challenge period,” during which transactions can be challenged with a fault proof.
Optimistic Rollups operate on the optimistic assumption that transaction results published to Ethereum are correct without actually executing the transactions on Ethereum itself. However, to prevent incorrect transaction results from being published, there’s a safeguard in place called the “fault proof.” During the challenge period, anyone can re-execute the transaction on Ethereum to verify its accuracy.
If someone successfully proves that a transaction result is faulty, it gets invalidated, and others can publish a corrected result. Financial penalties deter publishers from submitting incorrect results. Once the challenge period elapses without any disputes, the transaction result is deemed valid.
It’s essential not to act on L2 transaction results within a smart contract on L1 until the challenge period ends. Otherwise, there’s a risk of basing decisions on invalid transaction results. Therefore, messages sent from L2 to L1 using standard messenger contracts cannot be relayed until the challenge period is over.
Let’s outline some key constraints. In modern Optimistic Rollup challenges, users engage in a back-and-forth process, with approximately 10 steps involved. While the minimum time for this process is around 2 minutes in ideal conditions, real-world factors necessitate a buffer of about 20 minutes. However, this falls far short of the 7-day challenge period. There are evidently other factors influencing this duration.
In the world of Optimistic Rollups, there's a big concern about potential attackers trying to cheat the system. These attackers could steal a lot of money by making false claims and tricking the network. Imagine someone trying to steal billions of dollars - they'd likely be willing to spend a lot of money to pull off their scheme. So, what could these attackers do with all that money? Well, their main goal is to stop others from challenging their false claims. If challengers can prove them wrong, the attack fails. Attackers have a few tricks up their sleeve:
They could launch direct attacks on challengers' computers to stop them from interacting with the network.
They might flood the network with lots of expensive transactions to make it hard for challengers to do anything.
They could control many validators to stop challengers from participating. In reality, attackers would probably use a mix of these tactics to stop challengers. While we usually don't worry too much about the first tactic because it's easy to prevent, the other two are more concerning. Ultimately, the length of the challenge period needs to be longer than the time it takes for attackers to shut down all challengers. That's the basic idea behind it.
Why do we wait for 7 days during the challenge period in Optimistic Rollups? This waiting time might seem longer than necessary, but there are good reasons behind it.
Firstly, the 7-day timeframe gives the entire Ethereum community a chance to respond if there’s an attempt to cheat the system. Imagine if someone tried to steal money from the network by making false claims. This would cause a lot of frustration and anger among users. However, with a 7-day window, honest members of the community have enough time to work together and stop the attack.
Now, you might wonder why we don’t opt for a shorter delay, like 3 days. Well, even after waiting for just 1 day, users still have to wait around, so extending the period a bit longer doesn’t make much difference in terms of user experience. Additionally, waiting for 7 days makes it easier for people to keep track of when they started the withdrawal process.
Another reason for the widespread use of the 7-day period is that it’s a commonly
accepted standard across the Optimistic Rollup ecosystem. Many systems are already set up to use this timeframe automatically, and there’s a sense of consistency and familiarity among users across different platforms.
In essence, the 7-day challenge period serves as a safety net for the network. It provides ample time for the community to respond to potential threats and ensures that everyone is aligned and prepared to take action if needed.