With the blockspace thesis gaining traction and Polkadot leading the way in innovating appchain infrastructure, we have to expect more and more chains to be created. We are seeing discussions around mid-term blockspace allocations, on-demand parachains, and Tanssi paving the way to reduce time to market for parachain teams and offer appchain-as-a-service offerings.
With the increase in chain creations, we can similarly expect that more chains will go out of commission in planned and unplanned ways. This leads us to look for ways to rescue assets that originated on other chains if a chain goes down unexpectedly or with too little advance warning for users.
Imagine a future where a DeFi chain goes live as a proof of concept. Thanks to pay-as-you-go blockspace, only a bit of DOT is required to keep the chain producing blocks. Tanssi offers the infrastructure to instantiate collators, RPCs, etc. and we even get to a point where some chains offer permissionless channel openings. The product is popular and a few million dollars worth of value get deposited in a few weeks from 10 different chains. But the project hits a few roadblocks and the creators lose interest to develop it further. Everything goes silent for a few weeks, then the chain suddenly halts.
How can we ensure that users can easily and quickly retrieve their assets back to the originating chains?
In the Ethereum world, we see the concept of escape hatches. “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.” (quoted from Quantstamp)
Escape hatches are not a generic solution, they are rather very specific to the L2 implementation of a given Ethereum rollup. Usually, they consider mechanisms that allow users to retrieve funds back from an L1 bridge contract in case the rollup goes offline for an extended period of time. Additional complications arise in the case of ZK rollups. See one writeup from Starknet as an example: Starknet Escape Hatch Research
In Polkadot, the situation gets even more complex. First, we don’t have bridge smart contracts that allow us to deploy additional logic to Polkadot in case a parachain goes down. Second, users are not only able to transfer in DOT from the base layer, but also assets from many different parachains, where the assets sit in the respective sovereign account of a parachain in the other parachain.
After initiating a discussion on Twitter about the issue, I gathered a few points for discussion and am summarizing them here (and in this tweet) for your reference.
Thanks to @alexei, @seunlanlege & @PeterMangata for comments.
-
Asking Polkadot governance is a good measure for last resort, but is definitely not the most accessible approach. Any proposals to governance might get rejected and don’t offer guarantees to users to reclaim their assets. Governance is a long and tedious process, especially when a lot of value is involved. There would have to be manual work involved in analyzing the data, and creating corresponding proposals. Recovery transactions might not even fit into a single call. Last, governance calls might be constructed wrongly and might result in followup issues.
-
Extending Polkadot itself with escape mechanisms doesn’t seem to be a good fit. Parachains are sovereign in how they store assets, handle user accounts etc and Polkadot wants to refrain from taking opinions on how parachains deal with that. Additionally, Polkadot can only deal with its own assets. Parachain assets are a completely separate matter and again it would be hard to come up with a generic solution.
-
Parts of a possible solution were proposed:
- Originating tokens on AssetHub instead of different parachains would reduce the complexity during recovery operations and give more control to Polkadot. It’s hard to imagine that there can emerge universal consensus towards this solution though.
- A common good rescue parachain specifically for this contingency. Alternatively smart contracts on another chain facilitating this job. This also seems suboptimal, since it forces chains to give up autonomy and delegate power to other systems, add complexity and introduce new sources of errors
- SPREEs have been suggested by @PeterMangata as a possible solution. As far as I understand, they live on the relaychain, are immutable and offer arbitrary logic that can act as a contract between 2 (or more?) chains. SPREEs on the Polkadot Wiki. From everything I have seen in this discussion so far, this looks like the most promising contact.
It appears there is still ample time to solve this issue, but we will need to find sustainable solutions. I appreciate any feedback and discussion.
