Starknet Escape Hatch Research

[TimG]

TL;DR

• In this post, we are exploring self-custody strategies for rollups and the unique challenges pertaining to ZKRollups
• In the context of StarkNet, we explore the Applicative Escape Hatch pattern
• Looking into the future, we explore how decentralization of the network solves censorship and self-custody concerns

---

StarkNet is designed to have strong security guarantees:

• All StarkNet state transitions inherit the security of Ethereum.
• The state of StarkNet can be recreated from data available to Ethereum.

While security of the Ethereum rollup is robust, decentralization is a journey, and StarkNet is at the genesis of it. StarkWare currently operates all sequencer and prover nodes in the network. This means that even though no invalid transactions can be executed, the chain is not yet decentralized, and hence, not yet censorship resistant.

How do we guarantee self-custody if dishonest sequencers refuse to include transactions?

What happens if the chain stops producing blocks and assets are stranded?

Escape hatches can be designed so that a rollup is censorship-resistant and assets can always be evacuated to Ethereum. This increased security comes at the cost of either increased protocol complexity or increased application complexity.

Forced Transaction Escape Hatch

Forced Transaction Escape Hatches can be created at the rollup protocol layer. Users are given the ability to Force Transactions by directly sending them to the rollup’s Layer 1 contract on Ethereum. These Forced Transactions are not able to be censored by the rollup’s Sequencers or Provers.

Arbitrum, an Optimistic Rollup, addresses this by allowing a user to submit transactions to the Layer 1 contract’s Delayed Inbox. These transactions are not included in the current block so they cannot be used for front-running, and if they are not processed within a 24 hour time period, they can be forced. For a ZKRollups like StarkNet, there are additional challenges to implementing Forced Transactions.

Unlike Optimistic Rollups, ZKRollups require proofs to be submitted to the validator on Ethereum. StarkNet’s Prover source code is closed source, so Stark proofs cannot be produced without going through a StarkWare-operated Prover. There is a proposal to allow the community to control the source code license when the protocol becomes decentralized.

StarkNet Sequencers currently discard invalid transactions before they get to the Prover. Every proof in a block on Starknet must be valid or else the whole block will be rejected. This makes it difficult to tell if a transaction is being censored or is simply unprovable. Sending invalid Forced Transactions could lead to denial of service attacks if they are forced to be accepted. There is a proposal to make all transactions provable in order to solve this issue.

For these reasons, Forced Transactions are not currently implemented on StarkNet, but could be an option in the future.

Applicative Escape Hatch

Bridging applications can also be constructed in a manner that gives users an escape hatch. Layer 1 bridge contracts can be given the power to pause and evacuate assets from Layer 2 under hostile conditions. This pattern has been called the Applicative Escape Hatch. This is possible on StarkNet today, but at the expense of simplicity.

Implementing An Applicative Escape Hatch On StarkNet

Ethereum Account Registry

On StarkNet, there is no way of automatically knowing which Ethereum address corresponds to a given StarkNet account. Because of this, bridge applications must maintain a registry in order to implement an Escape Hatch. This way, should there be a time when assets need to be evacuated to Ethereum, the application knows how to get them to the correct destination.

Keep Alive Messages

The Layer 1 bridge contract must be in control, therefore there must be a mechanism to freeze the Layer 2 asset contract in event of censorship or inactivity. This freeze must happen as a result of inaction rather than action. A keep-alive ping message from the Layer 1 bridge contract to the Layer 2 contract can provide this. Actions on the Layer 2 Contract will first check if the contract should be frozen based on the duration of time since the previous keep-alive message.

Forced Withdraw Attempt

Starknet provides a mechanism to send messages between L1 and L2. An application can provide users with a Forced Withdraw function, in the event a user is being censored on StarkNet. Invoking a Forced Withdraw function would allow the L1 address in the application’s L1→L2 registry to withdraw their assets back to Ethereum.

Evacuation Procedure

Should a Forced Withdraw request be censored or unable to be executed due to lack of rollup liveliness, an evacuation procedure can be initiated. The L1 contract will stop sending keep-alive messages, then wait for the duration period so that L2 is confirmed to be frozen. This will shut down the application on L2 and the bridge can allow all assets to be withdrawn to user’s addresses on L1.

Decentralization

Over time, StarkNet’s Sequencers and Provers will be operated by many unique entities. Once sufficient decentralization is achieved and the ecosystem matures, censorship will become less of a concern.

This research and post is a collaboration between @guthl and myself.

[RoboTeddy]

Great writeup. Two thoughts in support of forced transactions:

1. Saving application developers (and users) from complexity is a very big deal. Starkware has a bunch of super talented software engineers; if you can use them to design a protocol which is easier for app developers to use, it’s huge win. The applicative escape hatch could look even more complex for applications that are more complex than ERC20 tokens.
2. Liveness guarantees are better and more general than withdrawal escape hatches. Picture e.g. a defi protocol with margining; if censorship prevents liquidations or prevents adding capital, very bad things happen. Also, withdrawals to L1 may not be practical for many users due to eventual L1 fees. It’s just bad in many ways to not be able to depend on your application continuing to run.

---

Also, a relevant slide from DevConnect in amsterdam:

[TimG]

Good points. Applicative Escape Hatch has been mentioned in this forum a few times and I noticed that some components of this approach are being used by the starknet-dai-bridge. I was hoping to use this post to really dig into what it would take to implement. The result is a lot of complexity and as you pointed out. And for more complex protocols, it is less practical. You also bring up a good point about liquidations and time sensitive transactions. Even the forced transactions implemented by optimistic rollups could censor liquidations for long enough since the transaction can be delayed for a period of time before inclusion.

Ideally there is a way to make all transactions provable and a mechanism at the protocol layer to support generic forced-transactions. That way it would support not only withdrawal but any action that a complex defined protocol implements (unstake, add capital, etc). Maybe there is a middle ground where a subset of actions can be forced at the protocol level.

The slide brings up some interesting points around the complexity that comes up with data availability layers. Can you post a link? I am interested in the context around it and to see what solutions are outlined. You mentioned liveliness guarantees, can you elaborate on that?

[RoboTeddy]

Ideally there is a way to make all transactions provable and a mechanism at the protocol layer to support generic forced-transactions. That way it would support not only withdrawal but any action that a complex defined protocol implements (unstake, add capital, etc).

Yes, this would offer the best dev experience.

Maybe there is a middle ground where a subset of actions can be forced at the protocol level.

Maybe this limited form, supporting a subset of actions, could be a good “version 1” (with the idea of supporting generic forced transactions later.)

The slide brings up some interesting points around the complexity that comes up with data availability layers. Can you post a link?

It’s from the currently ongoing DevConnect — see https://streameth.tv/event/l2-amsterdam morning session at around 2:32:30 in the video (Dankrad Feist’s talk)

You mentioned liveliness guarantees, can you elaborate on that?

Oh I just meant that from the perspective of a StarkNet application, if tx related to the app are censored indefinitely, then the application is no longer live. (Forced generic tx thus seem necessary for application-level liveness)

---

I should note that I don’t actually know which solution is best to implement because I don’t have a full view into the technical design & engineering required for forced transactions, or the size of any ongoing costs due to carrying more protocol complexity. That said, when looking strictly from the perspective of application developers (ignoring any other costs, delays, or complexity at the protocol level), forced tx seem to be superior.

[Kartik]

In case a user’s transaction is being censored and forced withdraw action is being initiated. 1. Does the user still need to generate a proof for L1 for the withdrawal to be completed? 2. What if the funds are time locked in a borrowing/lending platform?

[TimG]

Does the user still need to generate a proof for L1 for the withdrawal to be completed?

There is no way for a starknet user to generate a proof right now so in this scenario the forced transaction would be done via L1->L2 message. And the only thing keeping that message from being censored as well is the threat of the L1 bridge contract freezing it’s L2 counterpart and releasing bridged assets to L1.

What if the funds are time locked in a borrowing/lending platform?

This pattern is assuming all assets are free in the user-owned L2 wallet specified via the registry

[maciejka]

Another argument against Aplicative Escape Hatch approach, beside impracticality pointed by @RoboTeddy, is that in some cases it might be counter effective. Applicative Escape Hatch works under the assumption that threat of freezing an application is an incentive strong enough to prevent sequencer operator from censoring. There might be situations when this assumption does not hold, for example, when law enforcement agency comes to the operator with explicit request to freeze given application.

[GiantDole]

Given the Sierra update and the fact that every transaction can now be proven, what prevents the introduction of a sequencer/proposer escape hatch (Forced Transactions)?
The initial con argument was that sequencers had to discard invalid transactions to prevent DoS attacks. With the update, this shouldn’t be a concern anymore. Would love to hear about updates on this, if any!