Unbrick Collective

Overview

This proposal is aiming to add a new Unbrick Collective to the Polkadot Collectives chain. The main duty of this collective is to help parachain teams to replace their head state and/or wasm to unbrick a bricked parachain. There will be no sub-treasury for this collective.

Motivation

Since the initial launch of Polkadot parachains, there has been many incidients causing parachains to be bricked and many occurrences that requires Polkadot governance to update the parachain state/wasm. This can be due to many reasons range from bad genesis registered, inability to use sudo key, bad runtime migration, bad weight configuration, and bug in Substrate/Polkadot-SDK. Currently root origin is required to perform such action and the governance process to invoke root origin is very time consuming. The long voting and enactment time could result significant damage to the parachain and its users. There were some previous discussions about how we can improve such situation. As a result, the idea of Unbrick Collective was proposed with minimal scope to ease the process of setting this up.

Explanation

The collective is unranked.

The collective does not have treasury and members are not paid.

A number of features and changes shall be implemented:

An extrinsic to allow parachain manager (only when unlocked) or parachain origin to opt-in to allow Unbrick Collective to set its head state and wasm
A new track and origin named "WhitelistedUnbrickCaller" shall be added to the relaychain governance
Another new origin named Unbrick
Add new extrinsic paras.unbrick(paraId: ParaId, wasm: Option<Vec<u8>>, head: Option<Vec<u8>>)
- Require "Unbrick" origin
- Require no new block from this para id for N relay blocks (two hour?)
Modify the whitelist pallet so that the execute origin depends on the dispatch origin. And configure it that the execute origin shall be Root when dispatch origin is the WhitelistedCaller origin and Unbrick origin for WhitelistedUnbrickCaller.
- This allows us to reuse the existing whitelist pallet without a new instance and extra configurations

This will allow bricked parachain to be rescued with following steps:

The parachain should opt-in to allow the Unbrick Collective to modify its head state and wasm first
One of the Unbrick Collective member can make motion to whitelist the a call to invoke paras.unbrick
Anyone can make proposal to the WhitelistedUnbrickCaller track to dispatch the whitelisted call
The parachain state / wasm shall be updated

Member requirement

The collective will be created without members. There will be additional governance proposal to setup the seed members.

Three origins can modify the members:

Fellows track (Approved by >=3 rank Core Fellowship Members)
Root track
More than 2/3 of the existing Unbrick Collective

The members are responsible to verify technical details of the unbrick requests. e.g. verify the wasm hash or the new chain state. Therefore they must have the technical capability to perform such task.

Suggested requirements to become a member:

Rank 3 or above in the Core Fellowship
OR CTO / Tech lead of a parachain team that have opt-in to allow Unbrick Collective to control the wasm/state

Additional Notes

The Unbrick Collective may be upgraded to Ecosystem Fellowship, which could be a paid and ranked collective. If that heppens, the Unbrick Collective members could become high rank members of the future Ecosystem Fellowship directly.

The ability to wasm head state and/or wasm means arbitrary modification of the parachain. e.g. take control the native parachain token or any bridged assets in the parachain. This could introduce a new attack vector and therefore such great power needs to be handled carefully.

Questions

What are the parameters for the WhitelistedUnbrickCaller track?
Any other methods that shall be updated to accept Unbrick origin?
Any other requirements to be come a member?
We would like to keep this simple so no sub-treasury but do we want to compensate the members somehow?
Do we want to have this collective offer additional technical support to help bricked parachains? e.g. help debug the code, create the rescue plan, create postmortem report, provide resources on how to avoid getting bricked

Oliver Tale-Yazdi

2024/03/14 11:17:25

head state and wasm

Could it be useful to split these two permissions, to allow some paras to only set either state or wasm?

Xiliang Chen

2024/03/15 01:43:58

can you list some potential use cases? if someone can modify wasm, obviously it is possible to add a new call to modify state. if someone can modify state, then they can could gain root permission to upgrade wasm as long as the wasm have any governance feature. so I don't really see much protection by having them separated

2024/03/19 12:07:03

yea i just wanted to make sure its considered :) but should not make a difference from security perspective indeed.

2024/03/14 11:18:19

OR CTO / Tech lead of a live parachain team

Maybe only for parachain CTOs whos chain also wants to opt-in.

2024/03/14 11:19:48

We would like to keep this simple so no sub-treasury but do we want to compensate the members somehow

It's kind of a quid-pro-quo, not sure if relay governance should pay them. Maybe the parachain governance for helping? I agree though that it would make sense to pay for the creation of the resources on prevention that you mention below (Edited)

2024/03/15 01:51:22

Maybe we can make this to be able to accept donations from parachains?

2024/03/19 12:08:02

Yea would be very reasonable i think.

joepetrowski

2024/03/14 12:47:38

A new track and origin named “WhitelistedUnbrickCaller” shall be added to the relaychain governance

To me this sounds like overkill. You could just have the single `Unbrick` origin from the collective itself, and configure its Referenda pallet to allow anyone to submit referenda. Then there is no need for a public referendum at all.

Guest Valdez2024/03/14 23:44:39

I do agree, this might be one of those very concrete use cases that don't need to raise the vote to the whole community. This scenarios require quick action

Alejandro Martinez

2024/03/14 23:46:33

Above comment is mine :P

2024/03/15 01:46:45

The idea is that the ability to modify wasm/state can basically takeover the parachain. This is a very big power and therefore should require extra protection. i.e. approval from the community as well. But it doesn't need to have like the 5% approval requirement as the whitelisted caller track. This is more of a extra security protection in case the unbrick collection is compromised

2024/03/14 23:54:35

Any other methods that shall be updated to accept Unbrick origin?

"Hot-swapping" parachain heads have the risk of creating mismatches of mqc heads. I don't think there is any extrinsic available to mutate the state or pin point changes to that storage without opening a public gov referenda right now

2024/03/15 01:52:27

we just need to ensure the new para state contains the right mqc heads? is there anything needs to be done on the relay side?

2024/03/16 17:50:33

Yeah, that should be enough to avoid mutating relay state.

brenzi

2024/03/16 09:20:05

Opt-in is tricky because the power granted to the collective is de-facto unlimited. Do we really want to trust each other's CTO's that much? And I'm sure many teams will miss to opt in and then get bricked before they do. Can we require proof of brick? I.e. no blocks produced for N relay blocks? Tricky to define a threshold with agile coretime I guess An immature thought: instead of a collective: what if we collect state proofs for the bricked chain (we still have read access) and (offchain) signatures to implement token voting? This way the stakeholders of para X can vote with their X tokens on the unbrick action. The voting could happen on another systemchain (or extend collectives? Could be interesting to do crosschain voting for other use cases too) (Edited)

2024/03/16 17:56:48

To maybe maintain the involved individuals accountable they could need both, to lock some amount of tokens and be approved by the existing members ? Then, if misbehaving, they could be slashed by a concrete Origin ?

2024/03/21 01:59:56

we can make this only able to modify chain that failed to produce blocks for like 2 hours. for the token voting idea, we can discuss it here https://github.com/polkadot-fellows/RFCs/issues/16

2024/03/16 18:13:41

I think that a service like this is something the ecosystem could definitely benefit from! Has been previously discussed and marked as something needed. At the same time I feel that maybe restricting who is part of this collective is not needed. For instance, we have [PAL](https://polkadotassurance.com/) and other teams like SEAL, presented by @samczsun during Sub0 2024, that could already cover these doings, and many other individuals that might be willing to assist the existing teams. This collective could then just wrap a concrete Origin that has the right to dispatch the mentioned extrinsics to mutate the needed information for this parachain. Allowing the existing parachain manager accounts to request help and allowing an open market of white hat hackers to help them. The requester should approve that a certain provided solution indeed works before any call is dispatched form this highly privileged Origin.

2024/03/16 18:16:33

Usually bug bounties are something teams pay for. E.g. Polkadot is doing it with the Substrate <> Substrate bridges. So, it might even make sense that requesters lock a deposit to reward the entity providing a solution. Also, proving that a solution works should be fairly easy with existing tools like Chopsticks.

2024/03/18 00:53:55

that make sense but I feel unbrick chain and security bounties are two different things. also this may eventually become an Ecosystem Fellowship and when that happens, we surely will want to onboard a wider ecosystem contributors and that could include SEAL for example

Bastian Köcher

2024/03/17 18:43:06

Note if the parachain is unlocked, the parachain manager can opt-in even when the parachain is already bricked

If the parachain is unlocked, it doesn't need this collective to unbrick.

2024/03/18 00:45:07

yeah you are right

2024/03/17 18:58:50

One of the Unbrick Collective member can make motion to whitelist the a call to invoke paras.force_set_current_code and/or paras.force_set_current_head

IMO the requirements should be put quite high. This means that it requires quite a lot of support. The origin should maybe also only be allowed when the parachain is down for some time.

2024/03/18 00:50:01

updated