Thanks to Daniel Goldman and Kelvin Fichter for their comments.
A lot has been said about the security of optimistic rollups. In many cases, the concerns about the ORU security properties stem from the lack of availability of literature that expands on the fundamental properties of ORUs.
In this short piece, I attempt to tackle the concerns that I come across on a frequent basis when discussing the security properties of ORUs.
Optimistic rollups are optimistic (duh!). In other words, ORUs enforce state transition correctness under the presumption of innocence (i.e. innocent until proven guilty). When an ORU batch and its corresponding state root are committed to the underlying layer, the validating bridge allocates a predefined amount of time, known as the challenge window. Typically, the challenge window is set to 7 days (please refer to this great article by Kelvin Fichter for a deeper dive into the rationale behind the seemingly arbitrary window span). Within the aforementioned challenge window, any onlooker can initiate a challenge to dispute the correctness of the state root commitment (I won't bore you with the details about the dispute resolution mechanisms).
A keen-eyed reader might have deduced that successful enforcement of the correctness of the state transition relies on an honesty assumption. Specifically, a 1-of-N (where N can be unbounded) honesty assumption. While on paper, this might feel like a significant downgrade from zero-knowledge rollups, which only rely on mathematical assumptions, in reality, the difference is not that drastic. For the assumption to hold, there has to be at least one entity running an ORU full node capable of flagging an invalid state root commitment and challenging its correctness before the expiration of the challenge window. Assuming that the hardware requirements for running an ORU full node are not prohibitively high, I struggle to imagine a scenario in which not a single full node is operating correctly at any given point in time. The vanishingly small probability becomes negligible when you assume that infrastructure providers operating on top of the ORUs, such as liquidity bridge operators, are financially incentivized to preserve the correctness of the ORU chain. In other words, as long as the protocol has a decent user base, the probability of an invalid state commitment being successfully finalized by the validating bridge is negligible.
The phrase "you have to wait for 7 days for an ORU transaction to be finalized!!!" likely triggers everyone working on an ORU (sorry for bringing it up, guys!). Is there any truth to that phrase? Yes and no.
First, let's unpack certain peculiarities of ORUs. In ORUs, the process of ordering transactions is completely disintermediated from the process of execution. Meaning that if a Sequencer were to commit a batch containing an invalid transaction (e.g. a transaction with an incorrectly formed signature), the entire batch does not have to be discarded; instead, the Executor has to skip the aforementioned transaction when computing a new state root.
As you might have guessed from the previous sentence, disintermediation means that an ORU full node can compute the output state of a batch as soon as the corresponding batch commitment is finalized on the underlying layer. "Well, why do you need a 7-day-long challenge window???" you might rightfully ask. You see, there's a catch. While an ORU full node can be convinced that a certain state derived from the finalized batch commitment has been finalized, the validating bridge isn't aware of it and so has to wait for 7 days to confirm the correctness of the resultant state. As such, the views on finality in ORU full nodes and the validating bridge diverge: the former finalizes the state as soon as the corresponding batch commitment is finalized on the base layer, and the latter finalizes the state after the expiration of the challenge window. If you’re transacting within the ORU and not bridging back to the underlying base layer, you shouldn't care about the validating bridge finality. However, if you're bridging back to the underlying layer, then you're forced to wait for the validating bridge finality.
A few weeks ago, Anatoly Yakovenko brought up a potential attack vector in ORUs associated with challenger censorship. While at first glance, the aforementioned attack might seem to be an insurmountable challenge (no pun intended) for any optimistic protocol relying on the security properties of another protocol for dispute resolution, the reality, as always, is much more complicated.
The attack boils down to the following: a dishonest supermajority on the underlying base layer commits an invalid state root (either themselves or by bribing an ORU operator), enabling them to drain the funds locked in the validating bridge. For the entire duration of the challenge window, the aforementioned dishonest majority do everything in their power to censor a transaction initiating the dispute, including not voting and orphaning any block, including said transaction. After the expiration of the challenge window, the dishonest majority can withdraw all the locked funds thanks to the validating bridge being convinced that said action is completely legal.
Let's now dissect the described attack. The invalid state root commitment will be flagged near-instantaneously, assuming the given ORU has a non-negligible number of correctly operating full nodes. Once the challenge initiation transaction is propagated to the underlying layer, its censorship attempts should become fairly obvious to anyone following the attempts at inclusion. As such, the ORU community should have plenty of time remaining within the challenge window to create as much noise as possible to rally the base layer community to fork from the censoring chain. It's unlikely that the major stakeholders in the protocol (e.g. infrastructure operators, applications deployed on top of the protocol, CEXs, etc.) are willing to support a chain actively attempting to steal user funds, resulting in those entities joining the minority fork. At that point, the dishonest majority has two options:
Stop the censorship attempts and include the challenge transactions or
Continue building on a majority fork that no major entity supports, resulting in a scenario similar to EthPoW, in which a chain is de-facto dead due to non-existent support from the application operators despite technically still operating.
Consequentially, attempts to steal the funds bridged to an ORU through an invalid state commitment and subsequent censorship of the corresponding attempts to dispute the state commitment are highly unlikely to succeed.
Many myths surrounding ORUs result from the novelty of the underlying technology and the slow accrual of the publicly-accessible literature covering the related subjects (we can't even agree on the concrete definition of a "rollup"!).
In this short piece, I have attempted to dispel the myths that I encountered the most throughout my time debating about rollups with others. If you can think of any other ORU-related myth that was not outlined in this piece, feel free to let me know!