Arbitrum Co-founder: Three Solutions to Rollup Delay Attacks
What is a Rollup delay attack? How do various versions of the Arbitrum Rollup protocol address this issue?Author: Ed Felten, Co-founder of Offchain Labs
Compiled by: DeFi Dao
A subtle problem faced by rollup protocol designers is how to deal with delay attacks. In this article, I will discuss what they are and how Arbitrum defends against them, leading to some exciting new developments.
Delay attacks are malicious actions that attempt to prevent the rollup protocol from making progress. They do not attack the security of the protocol, meaning they do not try to force the confirmation of incorrect results. Instead, delay attacks target the liveness of the protocol by attempting to block or delay the confirmation of any result.
These issues can be subtle, and honestly, protocol designers often do not like to talk about delay attacks, but every Layer 2 system, whether it is Optimistic Rollup, ZK Rollup, or others, needs to address issues related to delays and protocol progress.
This article delves into the issue of delay attacks and discusses how various versions of the Arbitrum rollup protocol handle this problem.
What are Delay Attacks?
In a delay attack, a malicious party (or a group of malicious parties) takes actions within the rollup protocol, following a strategy designed to obstruct or delay the confirmation of results back to the L1 chain.
This is different from a denial-of-service (DoS) attack, where the attacker tries to prevent any actions from taking place in the protocol. In contrast, in a delay attack, actions continue to occur, but the way the attacker behaves obstructs or delays the confirmation of results (i.e., delaying the withdrawal of assets to L1), forcing honest validators to burn gas.
Any seemingly reasonable rollup protocol requires participants to stake, so delay attackers will inevitably lose one or more stakes. We assume here that attackers are willing to sacrifice their staked assets to a certain extent to pursue their attack.
We will also conservatively assume that attackers have an advantage in getting transactions on-chain, so whenever attackers compete with an honest party for priority in on-chain transactions, the attackers always win.
Finally, we assume that attackers can enable and disable a conceptual "censorship mode" to review access to the underlying L1 blockchain to exclude rollup transactions, but only for a limited period, which we call the "challenge period." Specifically, when censorship mode is enabled, attackers can fully control which transactions can reach L1. However, attackers can only enable censorship mode within one challenge period. (We assume that any set of censorship mode periods that add up to more than one challenge period will trigger a social response from the L1 community to prevent censorship attempts.)
Evaluating Protocols Against Delay Attacks
When evaluating protocols, we can ask six questions:
Does the protocol have a fraud-proof mechanism? (Otherwise, delay attacks have no practical significance, as participants cannot delay the confirmation of any result—even fraudulent ones.)
Is there a centralized operator or prover that can block progress simply by stopping or withholding data? If so, that party could cause infinite delays.
Does the protocol provide a trustless guarantee of eventual progress? In other words, regardless of what the attacker does, can an honest participant force eventual progress?
If the protocol guarantees a trustless process, what is the maximum delay that attackers can cause?
How do the costs for attackers scale with the delay time they cause?
How do we measure the total cost for honest parties to respond?
Once these criteria are established, let's evaluate two historical versions of the Arbitrum rollup protocol.
Protocol 1: Academic Paper Protocol
The Arbitrum academic paper from 2018 roughly used the following protocol (ignoring unrelated consensus patterns). Any staker can assert a proposed result, which we call an assertion. Within a time window, any subset of other stakers can challenge the assertion, and the assertor must defend their assertion against each challenger, one at a time. At the end of each challenge, the losing party will lose their staked assets.
(Note that it is necessary to allow multiple stakers to oppose an assertion and give each challenger a chance to overturn the assertion. This is necessary because malicious parties may deliberately lose challenges they "should" win. Giving each challenger a separate challenge ensures that an honest challenger can defeat an incorrect assertion, regardless of how many malicious parties deliberately lose challenges.)
If there are no challenges, or if the assertor wins all challenges, then the assertion will be confirmed, and the protocol will continue. However, if the assertor loses any challenge, their assertion will be rejected, and the protocol state will roll back to the state before the assertion was made.
Evaluation
This protocol has effective fraud proofs but does not guarantee progress, as malicious participants can endlessly make incorrect assertions, sacrificing their staked assets each time, leading to an endless loop of making and rejecting the same assertion, resulting in continuous rollbacks and a lack of progress.
Protocol 2: Forking and Pruning
The current Arbitrum protocol (deployed in every version of Arbitrum since 2020) improves upon the previous protocol by introducing forking. The idea is to allow multiple stakers to make competing assertions and treat these competing assertions as forked chains. Then, a series of challenges pits the forks against each other, ultimately pruning all branches except one, allowing the remaining branch to be confirmed.
The specifics are as follows. Each rollup block in the blockchain tracks the timestamp of its first sub-block (i.e., the successor block) when created by a staker. Other stakers can create additional sub-blocks. Each sub-assertion implicitly claims that all its older blocks are incorrect.
The staker creating the assertion needs to stake it, and other stakers can choose to stake it as well.
If two stakers bet on sibling assertions, and neither staker is in a challenge, a challenge can be initiated between the two stakers, where the staker of the older sibling assertion defends the correctness of that older sibling assertion, while the other staker challenges that correctness. The staker who loses the challenge will lose their staked assets and be removed from the staker set.
This protocol includes deadlines for actions. First, the deadline for creating a sub-assertion of the parent assertion is one challenge period after the creation of the first sub-assertion. Second, the deadline for staking on the assertion is one challenge period after the assertion is created.
If the staking deadline for the assertion has passed and no staker has staked on that assertion, the assertion will be deleted. Any descendants, grandchildren, or other progeny of the pruned assertion will also be pruned.
If an assertion is made before a challenge period and there are no unpruned sibling assertions, that assertion can be confirmed, representing progress for the protocol.
Evaluation
This protocol has effective fraud proofs, and there is no centralized operator or prover that can block progress, so any participant can push progress forward. To push progress, an honest staker can publish a correct sub-assertion (if one does not already exist). After this, a limited amount of time will pass before the deadline to ensure that no more sibling assertions are created and no more stakers can bet on the existing sibling assertions. From that point on, honest stakers will engage in a series of challenges, defeating and removing the incorrectly staked party (if multiple honest participants are involved in staking, they can defeat the opponent simultaneously). Once all these parties are removed, the correct sub-assertion can be confirmed.
The most effective delay attack against this protocol is for a malicious staker to stake on an incorrect sibling assertion and have N-1 malicious stakers stake on the correct sibling assertion. Regardless of how many honest stakers bet on the correct sibling assertion, the attacker can arrange for the incorrect staker to challenge their ally before the honest party initiates a challenge (pessimistically assuming that the attacker can always enter the transaction before the honest party). Allies will also deliberately forfeit challenges to delay as much as possible (due to the delay rules, each ally may need one to two challenge periods). Only after all N-1 allies have sacrificed themselves will the incorrectly staked staker be required to challenge the honest party, who will win and ultimately eliminate the incorrectly staked staker.
This attack achieves a delay of about N challenge periods at the cost of N staked assets.
The cost for honest parties to respond to this attack scales linearly with the number of honest parties, as each honest party needs to stake before the staking deadline.
Summary:
- Guarantees progress
- Attack costs scale linearly with the delay caused
- Costs for honest parties scale linearly with the number of honest parties
Permissioned Validation
The delay attack issues faced by Protocol 2 currently deployed on Arbitrum are the reason we have chosen to temporarily restrict the role of validators to a set of permissioned parties rather than making validation completely permissionless. The final step to achieving permissionless validation requires a version of the protocol that maximally resists delay attacks. You may have guessed that such a version exists, and we are currently working to implement it.
Upcoming Protocol 3
This article has already been long, so I will not provide specific details about the new protocol; that will be covered in future articles.
To briefly summarize the key points: The next version of the Arbitrum protocol makes some small but (I believe) elegant changes to how assertions and challenges work, such that the worst-case delay attack can only cause a delay of one challenge period (regardless of how much staked assets the attacker is willing to lose).
This is based on a technical breakthrough from the Arbitrum research team that makes "all-against-all" challenges feasible and efficient. This allows an honest staker to effectively defeat a large group of attackers issuing malicious forked assertions.
The specifications for the new protocol have been fully determined and are currently being implemented. Of course, we will not launch it on the mainnet until we have thoroughly tested and audited the code.
In future articles, I will delve deeper into this new protocol.
