Research Summary: Ideal Properties of Rollup Escape Hatches

[jgorzny]

TLDR

The paper contains a “menu” of (possibly conflicting) properties that an escape hatch could or should have.

Core Research Question

An escape hatch is a mechanism to “escape” assets or state from a rollup if it becomes inoperable. What properties should this feature satisfy?

Citation

Jan Gorzny, Lin Po-An, and Martin Derka. 2022. Ideal properties of rollup escape hatches. In Proceedings of the 3rd International Workshop on Distributed Infrastructure for the Common Good (DICG '22). Association for Computing Machinery, New York, NY, USA, 7–12. https://doi.org/10.1145/3565383.3566107. A pre-print is here.

Background

A rollup is a type of popular “layer two” scaling solution for slow-but-secure blockchains like Ethereum. A rollup performs computation of blockchain state updates off-chain but posts the inputs and the data to the underlying blockchain in order to benefit from its security.

However, if rollup operators go offline, further state updates are no longer possible through the rollup; instead, state updates to the layer two state must be forced on the underlying blockchain. Such a mechanism is called an escape hatch as it allows state, and in particular digital assets, to escape from an inoperative rollup.

Summary

This work…

• reviews the approaches from rollups developed by the community and highlights potential issues; and,

• establishes a “wishlist” of properties that an escape hatch mechanism should (or could) have to be considered trustworthy and compatible with decentralization.

Method

The paper considers the escape hatch functionality for rollups. It builds on the architecture defined previously by some of the authors for bridges to describe some components, like a custodian for holding bridge funds (see here for these terms).

Properties for escape hatches are defined in the main section of the paper (and described in the next section of this summary), and references to real rollups with escape hatches that may satisfy each property are provided. These references are sourced from L2Beat.com. The kinds of escape hatch mechanisms for current rollups are:

• transact Using layer one,

• propose Blocks (possibly using some zero-knowledge systems),

• Force an exit to laye one,

or none. The work uses the L2Beat definitions for these terms, due to page limits.

Results

The paper describes the following (potential) properties of rollup escape hatches.

• Basic properties. Escape functionality should be modular (clear in the code), secure (not introduce more attack surface), and correcting (should not require users to perform another set of actions to escape if possible).

• Support for Arbitrary State Escape. It may be clear that ERC-20 tokens have value to end-users, but perhaps other state does too. For example, ERC-721 (NFT) tokens. More generally, it would be ideal if non-tokenized state be defined and migrated through these features (if it makes sense to do this).

• Built-In. The rollup should support this feature for end-users without the users needing extra development or work.

• Transaction Efficient. Ideally, the use of an escape hatch should not introduce a gas war on an underlying layer (and should be feasible even if such a gas war already exists).

• Global. Escape hatches should not be application specific. This is problematic at least for dApp developers, but probably also end-users too.

• Automatic & Live. The escape hatch should always be available, and ideally it can be triggered without the need for social or manual consensus by privileged parties.

Discussion and Key Takeaways

The “menu” of properties may not include compatible properties, and no rollup satisfies the entire list at the time of publication. It may also be the case that this list is infeasible or incomplete. However, it provides a reference for future rollup developers. Moreover, interested end-users can see if a particular approach is likely to satisfy an important property.

Implications and Follow-ups

The list of idealized properties may be incomplete and the approaches required to satisfy these properties may not be clear. The researchers do not suggest methods for implementing any particular feature. Thus, future work includes developing novel solutions to satisfy these properties.

Moreover, it would be helpful to establish if any of these properties are infeasible, impossible, or require unpopular ideas.

Choosing to prioritize some of these properties may contribute to the increased security of the ecosystem at large. This increase in security is only possible if escape hatches are thought about and reviewed before they are necessary.

L2Beat also differentiates between validator and sequencer failures, and does not provide formal definitions of the escape hatch mechanisms. The authors plan to look at the differentiation of failure sources to see if that introduces or refines any of these properties, as well as precisely and formally defining each escape hatch mechanism, in the future.

Applicability

This work is intended to help develop and review real-world implementations of escape hatches. These features are receiving more attention now as they were not necessarily included in initial versions of rollups. This could help end users evaluate risk, dApp developers support escape hatches, and rollup developers build these features.

[Chrisarch]

Thank you @jgorzny for this summary on the properties and details on Rollup Escape Hatches.

Through your summary, one can understand that when a rollup becomes incapable of performing its functions when an operator goes offline, an Escape hatch is deployed to avoid assets from being blocked and allow state updates.

This mechanism which occurs after a rollup operator goes offline and makes state updates impossible through rollup, helps to allow state and digital assets escape from a non functional rollup.

Reading through the research paper, I understand that this escape hatch is crucial in blockchain as it helps to secure users’ assets by preventing it to be blocked or frozen.

The characteristics of escape hatches are at an edge of ensuring proper regulation to the blockchain. One of its basic properties details on correcting the escape. Basically, when an operator returns online, the operation is returned on the existing blockchain and this is to prevent having a continuous escape hatches on the already underlying blockchain.

On security, every user would like to have an efficient and secured assets that are void of any impending danger. The Escape Hatches for rollup are not required to deal with malicious operators as these are guarded against by the fraud proof and validity proof of optimistic and ZK rollups respectively. Also the escape hatches’ functionality could create a larger surface for an attack, hence, requiring a good security measure to avoid exploitation.

I was pondering on what would happen to Layer 1 with minimum scalability if there is a bulk or congested transaction traffic, if it would be able to hold it up, until reading through the transaction property, and could see that it permits the feasibility of mass-exit for transactions if congested on the underlaying layer during an escape hatch. This property would ensure no overload on the underlying blockchain and would help users have smooth transactions.

However, the research explains that if an operator fails to publish update, a user’s assets locks up and that a forced transaction must be censored by an operator. Hence, an offline operator is akin to one who censors all transaction, therefore, an offline operator deploys the escape hatch before going offline since they are to be aware of all transactions?

An escape hatch is considered to be part of the rollup functionality called Validity bridge which could create a large surface area for an attack, therefore, when an operator goes offline, do other operators not try to manipulate some transactions in the blockchain?

[jgorzny]

@Chrisarch

an offline operator deploys the escape hatch before going offline since they are to be aware of all transactions?

The ideal situation is that the functionality is deployed at the time of creation for the rollup. Relying on them to “Activate it” or add it, may defeat the purpose.

therefore, when an operator goes offline, do other operators not try to manipulate some transactions in the blockchain?

If there are other operators, perhaps. If new operators can come online, that is one way to create an “escape” but it’s not clear that such a system has been attempted. The ideal solution does not create more headaches and introduce new threats.