Partnered With:

Arbitrum Founder: Three solutions for Rollup delay attack

Read this article in 16 Minutes

A delicate issue for the Rollup protocol designers is how to respond to delayed attacks.

原文标题：《 Arbitrum 创始人：针对 Rollup 延迟攻击的三种解决方案》

原文作者：Ed Felten， Offchain Labs 联合创始人

The DeFi way

A delicate issue for the Rollup protocol designers is how to respond to delayed attacks. In this article, I will discuss what they are and how Arbitrum can guard against them to bring about some exciting new developments.

Deferred attacks are malicious attempts to prevent progress by the Rollup protocol; they do not attack the security of the protocol, that is, they do not attempt to force validation of incorrect results. In contrast, delayed attacks attack liveness of protocols by attempting to block or delay confirmation of any outcome.

These issues can be subtle, and to be honest, protocol designers generally don't like to talk about delayed attacks, but every Layer 2 system, whether Optimistic Rollup, ZK Rollup, or others, has to deal with issues about delays and protocol progress.

This paper delved into the delayed attack problem and discussed how various versions of the Arbitrum rollup protocol deal with it.

What is a delayed attack?

In a delayed attack, a malicious party (or group of malicious parties) takes action within the Rollup protocol, following a policy designed to block or delay the return of confirmation results to the L1 chain.

This is different from a denial of service (DoS) attack, in which the attacker tries to prevent any action from being taken in the protocol. In a delayed attack, by contrast, the action continues to occur, but the attacker acts in a way that blocks or delays confirmation of the result (that is, delays extraction of assets to L1) and forces the honest verifier to burn gas.

Any plausible Rollup agreement requires participants to pledge, so a delay attacker is bound to lose one or more pledged interests. We assume here that the attacker is willing to sacrifice the pledge interest within certain limits in pursuit of their attack.

We will also conservatively assume that the attacker has an advantage in bringing the transaction up the chain, so that whenever an attacker competes with an honest party for the first right to an on-chain transaction, the attacker will always win.

Finally, we assume that an attacker could review access to the underlying L1 blockchain to exclude Rollup transactions, but only for a limited period of time, which we call the "challenge period." In particular, an attacker can enable and disable a conceptual "censorship mode." When the audit mode is enabled, the attacker has complete control over which transactions reach L1. However, the attacker can only enable the audit mode for one challenge period. (We assume that any set of review pattern periods that add up to more than one challenge period will trigger a social response in the L1 community to discourage censorship attempts.)

Evaluate the protocol for deferred attacks

In evaluating the agreement, we can ask six questions:

Does the agreement have a fraud proof mechanism? (Otherwise, a delayed attack makes no sense, because the participant cannot delay confirmation of any result-not even a fraudulent one.)

Is there a centralized operator or prover that can stop progress by simply stopping or withholding data? If so, that party may cause unlimited delay.

Does the agreement provide a trust-free guarantee of eventual progress? In other words, can an honest actor force progress in the end, no matter what the attacker does?

If the protocol guarantees untrusted processes, what is the upper limit of delay an attacker can impose?

How is the cost to the attacker proportional to the delay time caused?

How is the total cost of an honest party's response measured?

With these criteria determined, let's evaluate the two historical versions of the Arbitrum rollup protocol.

Protocol 1: Academic Paper agreement

Arbitrum 2018 academic papers ‌ generally USES the following agreement (ignoring has nothing to do with the consistent mode). Any pledgor can assert the result of a proposal, which we call an assertion. Within a window of time, any subset of the other pledgees can challenge the assertion, and the assertion must defend its assertion against each challenger, one challenger at a time. At the end of each challenge, the loser loses their interest in the pledge.

(Note that it is necessary to allow multiple pledgees to object to the assertion and to give each challenger the opportunity 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 beat incorrect assertions, no matter how many malicious parties intentionally lose the challenge.)

If there are no challenges, or if the assertor wins all challenges, then the assertion is confirmed and the agreement moves forward. But if the asserting person loses any challenge, its assertion is rejected, and the protocol state is rolled back to the state before the assertion was made.

evaluation

The agreement has a valid proof of fraud, but does not guarantee progress, because malicious actors can endlessly make incorrect assertions, sacrificing the pledge interest each time, but leading to an endless cycle of making and rejecting the same assertions, resulting in continuous rollbacks and lack of progress.

Protocol 2: Forks and trims

The current Arbitrum protocol (which has been deployed on every version of Arbitrum since 2020), improves on the previous protocol by introducing branches. The idea is to allow multiple pledgees to make competing assertions, and to treat competing assertions as forked chains. A series of challenges then pitted the branches against each other, eventually cutting out all but one branch and allowing the remaining branch to be confirmed.

The specific ways are as follows. Each Rollup block in the blockchain keeps track of the timestamp when its first subblock (the successor block) was created by the pledgee. Additional subblocks can be created by other pledges. Each subassertion implicitly claims that all of its older blocks are incorrect.

The pledgee who created the assertion needs to pledge it, and other pledgees may choose to pledge it.

If two pledgees are siblings of a claim and neither pledgees are challenging, a challenge can be made between two siblings where the earlier pledgee in the sister's claim is defending the validity of the older sister's claim and the other pledgee is challenging the siblings' claim. The pledgee who loses the challenge will lose his pledge interest and be removed from the pledgee set.

The agreement includes a deadline for action. First, the deadline for creating a child assertion of the parent assertion is a challenge period after the first child assertion is created. Second, the deadline for pledging an assertion is a challenge period after the assertion is created.

If the deadline for pledging an assertion has passed and no pledgee has pledged the assertion, the assertion will be deleted. Any offspring, grandchildren, or other offspring of the pruned assertion are also pruned away at the same time.

If an assertion predates a challenge period and there are no unpruned sister assertions, the assertion can be confirmed, thus representing progress in the agreement.

evaluation

The protocol has a valid proof of fraud, and no centralized operator or prover can stop the process, so any participant can drive the process. To facilitate the process, an honest pledgee can issue a correct sub-assertion (if it does not already exist). After that, a limited amount of time will pass before the deadline to ensure that no more sister assertions are created and that no more pledgees can bet on existing sister assertions. From then on, the honest pledgee is involved in a series of challenges, defeating and removing the wrongful pledgee party at once (if multiple honest participants are involved in the pledgee, they can defeat the opponent at the same time). Once all of these parties have been removed, the correct subassertions can be confirmed.

The most effective delay attack against this protocol is to have one malicious pledgee pledge an incorrect sister claim and N-1 malicious pledgee pledge a correct sister claim. No matter how many honest pledgees bet on the correct sister assertion, the attacker will be able to arrange for the incorrect pledgees to challenge their Allies before the honest party does (pessimistically, this assumes that the attacker will always get into the deal before the honest party does). Allies will also deliberately forgo challenges to stall for as long as possible (due to the delay rule, each ally may need one or two challenge periods). Only after all of the N-1 Allies have sacrificed themselves, is the misbet pledgee asked to take on the honest party, who wins, ultimately weeding out the misbet pledgee.

This attack achieves a delay of approximately N challenge periods at the cost of N pledged equity to the attacker.

The honesty policy's cost of such an attack is linearly related to the number of honest parties, since each honest party needs to pledge before the pledge deadline.

Summary:

Guarantee process

There is a linear relationship between the cost of the attack and the delay caused

There is a linear relationship between the cost of honest parties and the quantity of honest parties

Permissive verification

The delay attack problem faced by Protocol 2 currently deployed on Arbitrum is the reason why we chose to temporarily limit the verifier role to a set of licensed parties, rather than making verification completely permissionless. Implementing the final step without license validation requires a version of the protocol that is most resistant to latency attacks. As you may have guessed, there is a version of this protocol, and we are currently working to implement it.

The upcoming Protocol 3

This article is already long, so I'm not going to provide a specific description of the new protocol. That's what a later article will cover.

Briefly to the point: The next version of the Arbitrum protocol makes some small, but (I think) elegant changes to the way assertions and challenges work, so that a worst-case delay attack can only cause a delay of one challenge period (no matter how much pledged equity the attacker is willing to lose).

This is based on a technical breakthrough by Arbitrum's research team that has made the "all-against-all" challenge feasible and efficient. This allows an honest pledgee to effectively defeat a large group of attackers Posting malicious branch assertions.

The specifications of the new agreement have been fully established and are now being implemented. Of course, we won't launch it on the main Web until the code has been thoroughly tested and reviewed.

In future articles, I will explore this new protocol in depth.