Manual Para Lock

[shawntabrizi]

This PR changes the behavior of the parachain lock, which prevents the parachain registration owner from performing actions on behalf of their chain. It additionally exposes the extrinsics schedule_code_upgrade and set_current_head from within the paras_registrar pallet.

---

Before, the parachain would be locked automatically once it is upgraded to a parachain or it has won a crowdloan.

Now, the parachain is locked manually, when the registration owner, the parachain, or ROOT deems it appropriate by calling add_lock.

To unlock the parachain, either ROOT or the parachain itself must call the remove_lock function.

While the parachain is unlocked, the parachain registration owner has access to the following functions:

1. deregister - Which registers a parachain from the system.
2. swap - Which signals that a parachain is willing to trade leases with another parachain.
3. schedule_code_upgrade - Which allows a new runtime code to be scheduled at a future block, just like if the parachain were to schedule an upgrade.
4. set_current_head - Which allows new head data to be set for a parachain.

While a parachain is unlocked, the chain should be considered the same as if the Sudo module was installed on that chain. For many parachains, there will be a period where being unlocked will be helpful for onboarding, and at a future point, the chain can be locked. Until then, the lock status of a chain should be a consideration for any users participating in crowdloans, using that chain, or even other parachains seeking to interact with that chain.

[crystalin]

Speaking for Moonbeam, I don't fully agree. I think executing XCM from the parachain is fairly easy and usually not an issue (requires doing a test on similar relay chain to ensure weight and params), and the guarantee that a parachain "owner" can't control the parachain anymore is an important point.

This lock has became an issue for us because we created a dummy parachain for managing the lease renewal/swap and didn't think we would require it to produce blocks to be used.

I would suggest to offer the possibility to future parachains when registering to specify if it should be locked or not.

[shawntabrizi]

I would suggest to offer the possibility to future parachains when registering to specify if it should be locked or not.

Can you elaborate how this would look? Are you saying from the initial parachain registration, a registrant could say "never lock my chain", and that would just be something users know about when to participate in a crowdloan?

[crystalin]

Yes, such an option would be highly visible to the user to make sure they are aware of what it means. The decision would be taken when registering the parachain and applied when the parachain is registered. The could also be the option to lock it afterward (but never to unlock it, except with root)

[shawntabrizi]

The could also be the option to lock it afterward (but never to unlock it, except with root)

This seems reasonable. I would like to hear what the other parachain teams think. I still feel, in the short term, this change would save a lot of wasted time on behalf of parachain management.

[xlc]

I think the best way is by default owner has those permissions, but can give up the permissions to become trustless. i.e. they can choose when to lock the parachain and maybe require the parachain root to unlock it. This is similar to how most of the parachains starts with sudo and later give up the sudo.

This could means for new chains, they can update the state & wasm by themselves (without requiring governance of relaychain), and once everything is fully setup & working, they can flip the switch and become a decentralized blockchain.

[shawntabrizi]

@xlc @crystalin How is this looking now?

[akru]

This is definitely a good point that parachain should be unlocked by default, for example, parachain could be registered with wrong state/runtime, unlock by default will make maintenance much more easy.

Whats about trustless, imo parachain users should care about it, not Polkadot relay force they to do it.

Unfortunately sending XCM not works when parachain unable to produce blocks from start or something wrong with governance modules.

[bkchr]

@shawntabrizi we really need this :P

[Polkadot-Forum]

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/how-to-recover-a-parachain/673/2

[gavofyork]

I'm fine with parachains themselves unlocking. I'm less fine with it being the default configuration.

[shawntabrizi]

I'm less fine with it being the default configuration.

The thing is that this is most useful in those first few weeks of being a parachain.

The times they need this is when they are initially onboarding, messed up the wasm or head, doing some kind of initial runtime upgrade, etc... It could be chains are not yet able to submit a call to unlock their parachain if they were locked by default.

[shawntabrizi]

bot rebase

[paritytech-processbot[bot]]

Rebased

[eskimor]

Whats about trustless, imo parachain users should care about it, not Polkadot relay force they to do it.

I actually strongly disagree with this. Polkadot is about shared security so it should play an active role in guaranteeing that security among its parachains.

For this particular issue, it feels to me like the users (crowd loaners) should have a say here. Like, with general terms and conditions: We are going to change X, if you don't oppose by date Y, the change will take effect. Then if people oppose, they get their crowdloan back ... - like they terminate their subscription, because well that is not what I signed up for.

[shawntabrizi]

bot merge

[Polkadot-Forum]

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/polkadot-release-analysis/1026/2

[Polkadot-Forum]

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/how-to-recover-a-parachain/673/9