[Deribit] Making Sense of Rollups, Part 2: Dispute Resolution on Arbitrum and Optimism

I want to note my implicit bias at the outset. I recently participated in Offchain Labs’ latest fundraising round, as did Mechanism Capital. While feigning objectivity is futile, my hope is that this piece helps the reader to grasp some of the crucial differences between the two projects, biased though I may be.

All rollups follow a similar basic architecture and internal logic. Nevertheless, as we saw in the first part of this mini series, the single distinction between Optimistic and Zero Knowledge Rollups—how the “review process” works on each—generates a host of downstream differences in security, usability, and EVM compatibility.

Something similar is true within each category of rollups. While Arbitrum and Optimism, the leading Optimistic Rollups, share much in common, it’s not just tribal loyalties that separate the two. In particular, the differences in their respective approaches to dispute resolution produce some important performance tradeoffs. These are tradeoffs that merit discussion, given that both platforms aim to offer full scaling functionality for Ethereum over the coming months.

Early beginnings

First, some brief historical background about each project is in order. As it happens, both have somewhat distinctive origin stories.

On a frigid Princeton morning six and a half years ago, a group of undergraduates working with Professor Ed Felten delivered a presentation on the project they had signed up to build: a blockchain-based arbitration system. The objective was to circumvent some of the anticipated scaling challenges of smart contract platforms, and the plan was to design a blockchain that relied on a system of challenges and dispute resolution to lighten the computational workload for traditional miners. “Arbitrum,” as the system was called, would have suffered the same fate as most other promising academic computer science projects, if not for two ambitious PhD students, Steven Goldfeder and Harry Kalodner, who approached Felten a few years later with the idea of building out a robust layer 2 solution based upon the initial concept. Soon thereafter, Felten, Goldfeder, and Kalodner co-founded Offchain Labs and have since shepherded Arbitrum from abstract idea to concrete reality.

Optimism, too, has a history that predates its current form. In mid 2017, Vitalik Buterin and Joseph Poon co-authored a paper proposing Plasma, an early scaling solution for Ethereum. A group of core Ethereum researchers took up the mantle and formed a non-profit research group to build out the vision. Development stalled in late 2019, as some critical design limitations of Plasma became apparent. Undeterred, three of Plasma’s lead researchers—Karl Floersch, Jinglan Wang, and Ben Jones—decided to pivot toward what seemed to be Plasma’s natural successor, the Optimistic Rollup. They formed Optimism PBC in early 2020.

Dispute resolution: a very brief (re-)introduction

Recall that Optimistic Rollups take an “innocent until proven guilty” approach to transaction validity. Optimistic Rollups process transactions and feed the result back to Ethereum for final inclusion in the base chain. A dispute period ensures that anyone monitoring the state of the rollup can submit a challenge if the rollup sequencer has processed transactions invalidly. This challenge immediately triggers a dispute resolution process. The difference between Arbitrum and Optimism is how the dispute resolution process works—including how much it costs and how long it takes.

Initial comparison of Arbitrum’s and Optimism on dispute resolution

The simplest way to describe the difference is that Optimism’s dispute resolution relies more heavily on the Ethereum Virtual Machine (EVM) than Arbitrum’s. When someone submits a challenge on Optimism, the entire transaction in question is run through the EVM. By contrast, Arbitrum uses an offchain dispute resolution process to whittle down the dispute to a single step within a transaction. The protocol then sends this single step assertion, as opposed to the entire transaction, to the EVM for final verification. Conceptually, Optimism’s dispute resolution process is thus considerably simpler than Arbitrum’s.

For its part, Arbitrum uses a recursive bisection algorithm for the offchain component of its dispute resolution process. This sounds complex, but in reality, the algorithm simply forces the “asserter” (the party that processed the transaction) and the “challenger” (the party submitting a challenge) to go back and forth to narrow down the point of dispute, in the manner illustrated by the diagram below. Interestingly enough, this back-and-forth resolution process via recursive bisection was part of the initial Arbitrum concept from 2015.

Source: OffChain Labs Dev Center

Optimism’s approach to dispute resolution—i.e. running entire transactions through the EVM—is not just conceptually simpler: it’s quicker too. There aren’t “multiple rounds” of back and forth, as there are in Arbitrum’s process. In fact, for this reason, Optimism’s rollups are often called “single round” whereas Arbitrum’s are “multi round.” Practically speaking, this means that in the case of a disputed transaction, final confirmation on Ethereum is delayed in Arbitrum’s case longer than it is in Optimism’s case. As we explored in Part One of this series, the speed of dispute resolution is important because it determines how long it takes for users to withdraw their tokens from the rollup back to Ethereum.

On the flip side, the advantage of Arbitrum’s dispute resolution is that it is cheaper in terms of onchain (i.e. on Ethereum) transaction costs. The bite-sized chunk of code that the EVM eventually processes after the completion of the back-and-forth dispute resolution process requires much less gas (in most cases[1]) than it does to re-process the entire transaction onchain.

Reframing the comparison

It would seem that the fundamental tradeoff between the two dispute resolution designs is simply one of speed versus onchain cost. But in reality, this framing is somewhat naive, since disputes are rarely expected to arise for two reasons:

1. Transaction processors on both Arbitrum and Optimism are economically disincentivized from processing transactions fraudulently. They are forced to put up stakes/bonds beforehand, which are then slashed in the case of a fraudulent transaction.
2. Parties monitoring the state of the rollup are disincentivized from submitting errant fraud proofs—in Optimism, because the challenger has to pay the onchain gas fee of the fraud proof, and in Arbitrum, because the challenger has to put up a bond that it forfeits in the case of a lost dispute.

So why exactly does the structure of the dispute resolution process matter if disputes are expected to be few and far between?

Even though disputes will be infrequent, rollups must be designed such that a dispute could arise at any time. Consequently, the design of the “disputed” case influences the structure of the prevailing “happy” (i.e. non-disputed) case.

Because Optimism must be able to run each transaction through the EVM in the case of a dispute, it cannot process transactions that surpass the Ethereum gas limit, as these could not be properly verified onchain. Arbitrum, by contrast, can execute transactions that are arbitrarily large, even if they exceed Ethereum’s gas limit, since transactions are never run wholesale through the EVM but are first broken into tiny “step assertions.”

It’s unclear how much of a practical constraint the gas limit on Optimism will pose for applications. But another, perhaps more important implication of the difference in dispute resolution design is that Arbitrum can save gas by checkpointing onchain (updating the “state root”) less frequently. More specifically, Arbitrum can assign a large amount of offchain computation to one update, since that state root update could theoretically include (miniscule) single-step fraud proofs of all of the transactions contained therein. Optimism, on the other hand, must checkpoint onchain after every transaction, significantly raising its onchain footprint.

In sum, Arbitrum should be more gas efficient than Optimism—and therefore cheaper for users—not only in the rare case of a dispute, but also in the predominant “happy” case.

Dispute resolution and potential attack vectors

One final point on these differing dispute resolution processes is worth discussing: namely, how resistant each design is to potential attacks. Above, we touched upon the economic incentives that discourage spamming attacks. More specifically, validators on both Optimism and Arbitrum are disincentivized from submitting unwarranted challenges.

But what about the case of a malicious attacker who does not mind bearing the economic cost of spamming the rollup? In other words, what happens if a person or entity is so committed to slowing down an Optimistic Rollup’s progress that they’re willing to do so even if it means repeatedly paying for bogus challenges?

As mentioned above, Optimism’s dispute resolution process is much simpler and quicker than Arbitrum’s, since it simply feeds disputed transactions through the EVM. This speed is to Optimism’s advantage here, since disputes can be resolved quickly and will not prevent future progress of the rollup chain.

The concern arises with a “multi-round” dispute resolution process such as the one Arbitrum uses. In theory, at least, a spammer could stop progress of the rollup by launching a salvo of consecutive challenges that each takes considerable time to resolve. Indeed, this is a problem that would have plagued a previous iteration of Arbitrum.

However, Arbitrum’s updated protocol applies to this problem an elegant solution called “pipelining.” Pipelining allows network validators to continue processing transactions for final approval even if a previously-processed transaction is under dispute. What this creates is a “pipeline” of recently-processed but yet-to-be-finalized transactions, instead of a bottleneck that prevents the sequencer from processing transactions and network parties from submitting challenges.

Pipelining is possible because anyone monitoring the network can know immediately whether a dispute is valid or invalid even before the dispute resolution process is finished. In essence, validators can operate as if the disputed transaction is already finalized and continue building the chain (i.e. processing transactions) on whichever outcome, or “branch,” is correct. This process, depicted by the diagram below[2], blunts the force of any would-be spamming attack[3].

Source: OffChain Labs Dev Center

Conclusion

In addition to the design of the dispute resolution process, there are other significant differences between Arbitrum and Optimism, especially

1. their codebase architectures, and
2. their approaches to Miner Extractable Value (MEV)

To very briefly summarize these differences: Optimism’s codebase is comparatively minimalist, while Arbitrum’s is more complex and ambitious; Optimism has in the past indicated that it favors a MEV Auction approach, while Arbitrum plans to implement a Fair Sequencing Service (FSS). Naturally, both of these points of comparison merit their own separate articles. MEV, in particular, is an issue of philosophical contention between the two projects—though at least in the early days after launch, both are expected to use a trusted sequencer model for simplicity.

Ultimately, stepping back from the protocol-level nuances—important though they are—what will differentiate these two heavyweights is the “soft” stuff as well: bootstrapping strategies, incentive design, and community ethos, to name just a few. Indeed, if they are to succeed in the long run, Optimistic Rollups will have to become worlds unto their own, not simply appendages of Ethereum. Scaling is thus less of an arms race than it is a multi-front war. It might have one winner; it might have multiple. It might rage for years; it might have an end in sight sooner rather than later. It will certainly be consequential for crypto’s future.

Nothing in this piece constitutes investment advice.

[1] If the transaction uses contracts that have never been part of a fraud proof before, those will all need to be re-deployed on Ethereum, which is very gas-intensive. Thanks to transmissions11 for clarifying this point.

[2] “DA” stands for “disputable assertion,” which is the technical term for a processed transaction that is subject to potential challenge.

[3] It’s also worth listening to Ed Felten’s lucid presentation of the pipelining process at ETHDenver last year.

AUTHOR(S)

THANKS TO

Hasu, t11s, Jason Choi, and Marc Weinstein

RECENT ARTICLES