- 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 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.
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.
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.
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.
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.
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.
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.