Reviving this thread as this has now also become an issue on kintsugi and with gov2, it looks like there’s no practically feasiable way to fast-track a proposal (which is a separate issue).
From my perspective, parachain recovery should have the following properties:
Each parachain should have a way to recover itself from not producing blocks.
Relay-chain governance should not play any part in parachain recovery.
Parachains receive a service from the relay-chain: safety and liveness. I agree with @rphmeier that there is a political dimension. Relay chain governance is not the right place to decide (politically or otherwise) about the fate of a parachain. Hence, each parachain should determine how to recover themselves. What the wider ecosystem can offer though is a common good chain that implements a way for parachains to recover.
I think @xlc proposal is pretty good and could even done in a very simple approach at first.
Assume there’s a common good chain that allows to call paras.forceSetCurrentCode on the relay-chain based on (1) a check that for x minutes no block has been produced for that parachain and (2) by somesort of authority.
Parachains would determine that authority from their parachains prior to being bricked. IMO in the very first iteration, that authority could just be the TC if it’s elected on a parachain. The more involved votings by verifying governance token holdings from the parachain etc. can be added at a later iteration.
I broadly agree, @dom - but also, to be sure, it seems quite possible to build this infrastructure on an existing smart contract chain such as Moonbeam or Astar without the addition of any new common-good chain.
Both OpenGov and Gov1 provide the capability for tokens to be delegated to an external account. I believe that a sensible architecture is to build a smart contract which controls an account on the relay-chain, which is delegated to by the parachain, and obeys the following rules:
If the parachain is not down, simply forward governance votes from the parachain. The parachain intending to vote would just send an XCM to the smart contract, which would in turn send an XCM to the relay chain to vote.
If the parachain is down, according to relay-chain state proofs, the smart contract can implement an alternative fallback mechanism for deciding how to vote. This could be a vote according to account holders on the parachain itself, using parachain state proofs.
The smart contract can also act as the parachain manager, and retain the ability to upgrade code/state on the parachain but only when the parachain is down. I believe that pallet-preimage on the relay-chain can be used to avoid sending the code blob itself over XCM, which is not viable. Needs some investigation.
The main reason to do this in a smart contract instead of on a common-good chain is that the alternative fallback voting mechanism will need to be pluggable and customizable to the particular needs and storage formats of the client chain it acts on behalf of. There is no one-size-fits-all solution here; it needs to be programmable.
I agree that whatever the solution is, that it needs to be programmable. Personally, I’d much prefer a pallet over a smart contract since we could add this e.g., to frame or orml and many parachains, not just the ones with smart contracts, can then support the recovery mechanism.
The pallet (or whatever implements the code) should be the acting parachain manager. The fallback mechanism should not rely on relay chain governance as is.
My proposal for how this could work:
Parachains can add a pallet to their runtime (if they opt-in) that allows other parachains to delegate emergency rights to them. Implementation can be based on parachain requirements. Some parachains might just want to have privileged accounts like a TC that can invoke emergency procedures. Some might want to mirror their governance and be able to vote on the measures.
In case of an emergency, the pallet on the recovery parachain is able to paras.forceSetCurrentCode on the relay chain (decided by whatever emergency procedure a particular parachain has configured).
One way around sending the blob over XCM would be if there was a “parachain” governance track:
The parachain team could note a preimage with paras.forceSetCurrentCode and open a “parachain” track proposal
From a recovery parachain, the parachain that wants to recover sends an XCM message that approves the upgrade. For this, the relay-chain would have to track which parachain(s) and which origins from that chain are allowed to approve.
Instead of using each others parachains for recovery, this could also be placed on an existing common good chain. To be very resilient, a parachain could also have a recovery option from two or more parachains.
As we discussed this last week, I would also be in favor of putting this onto some common good parachain dedicated to this purpose. This parachain could provide ways to create DAOs that are controlled in different ways. However, as this chain should not support all possible DAO configuration, it could also host pallet_contracts to have custom DAO contracts running.
The good thing about having this as a common good chain running. If there are problems with this chain, there are no issues involved with the relay chain token holders rescuing this chain
However, the entire rescue part should be really the last resort. We need to improve testing of parachains. We need to see what try-runtime, fudge and chopsticks already provide us with. Then we need to work together in the community to extend these tools. I don’t think there should only exist one tool. Having multiple tools, where each of them supports one special use case really good is better than having one tool that does all, you know We could even come up with shared test cases that are basic tests for all chains using certain pallets or whatever. The possibilities are endlessly when it comes to testing. If we are all working together on this, I think we can create great tools!
I believe a common good chain with pallet contracts is a great idea, considering these contracts can only be instantiated by root or a parachain’s sovereign account, that would make this a highly customizable environment for deploying custom emergency governance systems once and coming back to use it only when needed, but it would also maintain the purpose of the CGP without opening the doors for random user accounts to deploy contracts.
There is also a W3F-RFP entering the review phase that should address a subset of these behaviors (but do so in a robust way - likely requires low level changes so not imminently available)…
We could even come up with shared test cases that are basic tests for all chains using certain pallets or whatever. The possibilities are endlessly when it comes to testing. If we are all working together on this, I think we can create great tools!