Rollups are becoming mainstream components of the Ethereum ecosystem after years of community effort. Optimistic rollups, like Optimism and Arbitrum have been functional and live for months. Zero knowledge rollups are also poised to go live in the near future, with companies like Polygon and Scroll announcing testnets for their networks.
At Quantstamp, we’re impressed with all of these efforts. These systems are non-trivial to build and operate, requiring various components interacting perfectly to avoid exploits and liveness failures. As a result, we’re taking the time to ramp up on these ecosystems and the technologies in general. One area that we’re very interested in—in part because it’s not always discussed—is so-called escape hatches for rollups.
An escape hatch is a method by which users of a rollup can recover digital assets or program state from a rollup when the operators (sequencers or validators) are offline. This feature is critical for the security of these systems in the event that something goes wrong. Naturally, we hope they don’t, but preparing for the worst case scenario is just good security practice. This feature is especially important given the complexity of these systems; they are often more complicated than bridges, which introduces a large surface area for attacks if bugs are present.
Looking at L2Beat, not all rollups have taken the same approach—there’s no one way to design this feature. Understanding the trade-offs of each approach, and the risks associated with (or mitigated by) a particular escape hatch is important for developers, users, and operators.
We’ve spent a little bit of time thinking about this feature without diving into the specifics of some implementations, and we’ve come up with a menu for ideal properties. Some of these include:
- Being automatic & live
- Support for arbitrary state escape (what has value anyway?)
- Secure
For the full list, see my recent lightning talk at DevCon 2022, or look for our upcoming paper “Ideal Properties of Rollup Escape Hatches” to appear at the workshop for Distributed Infrastructure for the Common Good (DICG 2022) in Quebec City in November. You can find a preprint here.
This work is only the start of our exploration into this feature. We’re going to look at the trade-offs of specific designs, and try to find patterns within the implementations. We’re going to pay special care to look for security considerations. And we’re going to do our best to make sure this feature never needs to be used because of a security incident.
If you’ve got thoughts about these features, I want to hear them. We can collaborate to make the ecosystem more secure. Feel free to reach out by email or twitter (@jgorzny).
P.S. Quantstamp is hiring! Join us to do research like this and to help secure the future of web3.