From 42a9ad6bf961066e06d441e131043641b4ce7480 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pablo=20Andr=C3=A9s=20Dorado=20Su=C3=A1rez?= Date: Fri, 23 Aug 2024 19:07:59 -0500 Subject: [PATCH 1/6] feat(text): unbrick collective --- text/0000-unbrick-collective.md | 172 ++++++++++++++++++++++++++++++++ 1 file changed, 172 insertions(+) create mode 100644 text/0000-unbrick-collective.md diff --git a/text/0000-unbrick-collective.md b/text/0000-unbrick-collective.md new file mode 100644 index 000000000..8c7c91ffb --- /dev/null +++ b/text/0000-unbrick-collective.md @@ -0,0 +1,172 @@ +# RFC-0000: The Unbrick Collective + +| | | +| --------------- | ---------------------------------------------------------------------------------------- | +| **Start Date** | 22 August 2024 | +| **Description** | The Unbrick Collective aims to help teams rescuing a para once it stops producing blocks | +| **Authors** | Bryan Chen, Pablo Dorado | + +## Summary + +A followup of the [RFC-0014]. This RFC proposes adding a new collective to the Polkadot Collectives +Chain: The Unbrick Collective, as well as improvements in the mechanisms that will allow teams +operating paras that had stopped producing blocks to be assisted, in order to restore the production +of blocks of these paras. + +## Motivation + +Since the initial launch of Polkadot parachains, there has been many incidients causing parachains +to stop producing new blocks (therefore, being _bricked_) and many occurrences that requires +Polkadot governance to update the parachain head state/wasm. This can be due to many reasons range +from incorrectly registering the initial head state, inability to use sudo key, bad runtime +migration, bad weight configuration, and bugs in the development of the Polkadot SDK. + +Currently, when the para is not unlocked in the _paras registrar_[^1], the `Root` origin is required to +perform such actions, involving the governance process to invoke this origin, which can be very +resource expensive for the teams. The long voting and enactment times also could result significant +damage to the parachain and users. + +Finally, other instances of governance that might enact a call using the `Root` origin (like the +Polkadot Fellowship), due to the nature of their mission, are not fit to carry these kind of tasks. + +In consequence, the idea of a Unbrick Collective that can provide assistance to para teams when +they brick and further protection against future halts is reasonable enough. + +## Stakeholders + +- Parachain teams +- Parachain users +- OpenGov users +- Polkadot Fellowship + +## Explanation + +### The Collective + +The Unbrick Collective is defined as an unranked collective of members, not paid by the Polkadot +Treasury. Its main goal is to serve as a point of contact and assistance for enacting the actions +needed to unbrick a para. Such actions are: + +- Updating the Parachain Verification Function (a.k.a. a new WASM) of a para. +- Updating the head state of a para. +- A combination of the above. + +In order to ensure these changes are safe enough for the network, actions enacted by the Unbrick +Collective must be whitelisted via similar mechanisms followed by collectives like the Polkadot +Fellowship. This will prevent unintended, not overseen changes on other paras to occur. + +Also, teams might opt-in to delegate handling their para in the registry to the Collective. This +allows to perform similar actions using the _paras registrar_, allowing for a shorter path to unbrick a +para. + +### The Unbrick Process + +```mermaid +flowchart TD + A[Start] + + A -- Bricked --> C[Request Unbrick «via governance»] + C --> D[unbrick call proposal on WhitelistedUnbrickCaller] + C --> E[whitelist call proposal on the Unbrick governance] + E -- call whitelisted --> F[unbrick call enacted] + D -- unbrick called --> F + F --> Y + + A -- Not bricked --> O[Opt-in to the Collective] + O -- Bricked --> P[Collective calls registrar] + P --> Y + + Y[update PVF / head state] -- Unbricked --> Z[End] +``` + +Initially, a para team has two paths to handle a potential unbrick of their para in the case it +stops producing blocks. + +1. **Opt-in to the Unbrick Collective**: This is done by delegating the handling of the para + in the _paras registrar_ to the Collective. This doesn't require unlocking the para. This way, + the collective is enabled to perform changes in the _paras registrar_ without the need for + whitelisting. +2. **Request an Unbrick Process**: In case the para hasn't delegated its handling in the _paras + registrar_, it'll be still possible for the para team to submit a proposal to unbrick the para, + assisted by the Collective. This process is expected to be more expedite (and less expensive) + for a team to perform than submitting a proposal on the `Root` governance track. + +### Belonging to the Collective + +The collective will be initially created without members (no seeding). There will be additional +governance proposals to setup the seed members. + +The origins able to modify the members of the collective are: + +- The `Fellows` track in the Polkadot Fellowship. +- `Root` track in the Relay. +- More than two thrids of the existing Unbrick Collective. + +The members are responsible to verify the technical details of the unbrick requests (i.e. the hash +of the new PVF being set). Therefore, they must have the technical capacity to perform such tasks. + +Suggested requirements to become a member are the following: + +- Rank 3 or above in the Polkadot Fellowship. +- Being a CTO or Technical Lead in a para team that has opted-in to delegate the Unbrick Collective + to manage the PVF/head state of the para. + +## Drawbacks + +The ability to modify the Head State and/or the PVF of a para means a possibility to perform +arbitrary modifications of it (i.e. take control the native parachain token or any bridged assets +in the para). + +This could introduce a new attack vectorm, and therefore, such great power needs to be handled +carefully. + +## Testing, Security, and Privacy + +The implementation of this RFC will be tested on testnets (Rococo and Westend) first. + +An audit will be required to ensure the implementation doesn't introduce unwanted side effects. + +There are no privacy related concerns. + +## Performance, Ergonomics, and Compatibility + +### Performance + +This RFC should not introduce any performance impact. + +### Ergonomics + +This RFC should improve the experience for new and existing parachain teams, lowering the barrier +to unbrick a stalled para. + +### Compatibility + +This RFC is fully compatible with existing interfaces. + +## Prior Art and References + +- [RFC-0014: Improve Locking Mechanisms for Parachains][RFC-0014] +- [How to Recover a Parachain, Polkadot Forum][forum:673] +- [Unbrick Collective, Polkadot Forum][forum:6931] + +## Unresolved Questions + +- What are the parameters for the `WhitelistedUnbrickCaller` track? +- Any other methods that shall be updated to accept `Unbrick` origin? +- Any other requirements to become a member? +- We would like to keep this simple, so no funding support from the Polkadot treasury. But do we + want to compensate the members somehow? i.e. Allow parachain teams to donate to the collective +- Do we want to have this collective offer additional technical support to help bricked parachains? + i.e. help debug the code, create the rescue plan, create postmortem report, provide resources on + how to avoid getting bricked + + + +[^1]: The _paras registrar_ refers to a pallet in the Relay, responsible to gather registration info +of the paras, the locked/unlocked state, and the manager info. + + + +[RFC-0014]: ./0014-improve-locking-mechanism-for-parachains +[forum:673]: https://forum.polkadot.network/t/how-to-recover-a-parachain/673 +[forum:6931]: https://forum.polkadot.network/t/unbrick-collective/6931 From f383a54a406f12d6ba6fd02288a7258f4458123d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pablo=20Andr=C3=A9s=20Dorado=20Su=C3=A1rez?= Date: Fri, 23 Aug 2024 19:11:07 -0500 Subject: [PATCH 2/6] change(text): got RFC number --- text/{0000-unbrick-collective.md => 0117-unbrick-collective.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename text/{0000-unbrick-collective.md => 0117-unbrick-collective.md} (99%) diff --git a/text/0000-unbrick-collective.md b/text/0117-unbrick-collective.md similarity index 99% rename from text/0000-unbrick-collective.md rename to text/0117-unbrick-collective.md index 8c7c91ffb..a6b741e30 100644 --- a/text/0000-unbrick-collective.md +++ b/text/0117-unbrick-collective.md @@ -1,4 +1,4 @@ -# RFC-0000: The Unbrick Collective +# RFC-0117: The Unbrick Collective | | | | --------------- | ---------------------------------------------------------------------------------------- | From bc502648fbbd49f071a67d05962a77af30a4c3c7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pablo=20Andr=C3=A9s=20Dorado=20Su=C3=A1rez?= Date: Tue, 15 Oct 2024 00:04:26 -0500 Subject: [PATCH 3/6] change(unbrick-collective): address suggestions --- text/0117-unbrick-collective.md | 40 +++++++++++++++++++++------------ 1 file changed, 26 insertions(+), 14 deletions(-) diff --git a/text/0117-unbrick-collective.md b/text/0117-unbrick-collective.md index a6b741e30..e7f71fba5 100644 --- a/text/0117-unbrick-collective.md +++ b/text/0117-unbrick-collective.md @@ -59,23 +59,30 @@ Also, teams might opt-in to delegate handling their para in the registry to the allows to perform similar actions using the _paras registrar_, allowing for a shorter path to unbrick a para. +Initially, the unbrick collective has powers similar to a parachains own sudo, but permits more +decentralized control. In the future, Polkadot shall provide functionality like SPREE or JAM that +exceeds sudo permissions, so the unbrick collective cannot modify those state roots or code. + ### The Unbrick Process ```mermaid flowchart TD A[Start] + + A -- Bricked --> C[Request para unlock via Root] + C -- Approved --> Y + C -- Rejected --> A - A -- Bricked --> C[Request Unbrick «via governance»] - C --> D[unbrick call proposal on WhitelistedUnbrickCaller] - C --> E[whitelist call proposal on the Unbrick governance] + D[unbrick call proposal on WhitelistedUnbrickCaller] + E[whitelist call proposal on the Unbrick governance] E -- call whitelisted --> F[unbrick call enacted] D -- unbrick called --> F F --> Y A -- Not bricked --> O[Opt-in to the Collective] - O -- Bricked --> P[Collective calls registrar] - P --> Y - + O -- Bricked --> D + O -- Bricked --> E + Y[update PVF / head state] -- Unbricked --> Z[End] ``` @@ -83,13 +90,13 @@ Initially, a para team has two paths to handle a potential unbrick of their para stops producing blocks. 1. **Opt-in to the Unbrick Collective**: This is done by delegating the handling of the para - in the _paras registrar_ to the Collective. This doesn't require unlocking the para. This way, - the collective is enabled to perform changes in the _paras registrar_ without the need for - whitelisting. -2. **Request an Unbrick Process**: In case the para hasn't delegated its handling in the _paras - registrar_, it'll be still possible for the para team to submit a proposal to unbrick the para, - assisted by the Collective. This process is expected to be more expedite (and less expensive) - for a team to perform than submitting a proposal on the `Root` governance track. + in the _paras registrar_ to an origin related to the Collective. This doesn't require unlocking + the para. This way, the collective is enabled to perform changes in the _paras_ module, after + the **Unbrick Process** proceeds. +2. **Request a Para Unlock**: In case the para hasn't delegated its handling in the _paras + registrar_, it'll be still possible for the para team to submit a proposal to unlock the para, + which can be assisted by the Collective. However, this involves submitting a proposal to the `Root` + governance origin. ### Belonging to the Collective @@ -155,7 +162,12 @@ This RFC is fully compatible with existing interfaces. - Any other methods that shall be updated to accept `Unbrick` origin? - Any other requirements to become a member? - We would like to keep this simple, so no funding support from the Polkadot treasury. But do we - want to compensate the members somehow? i.e. Allow parachain teams to donate to the collective + want to compensate the members somehow? i.e. Allow parachain teams to donate to the collective. +- We hope SPREE/JAM would be carefully audited for miss-use risks before being + provided to parachain teams, but could the unbrick collective have an elections + that warranted trust beyond sudo powers? +- An auditing framework/collective makes sense parachain code upgrades, but + could also strengthen the unbrick collective. - Do we want to have this collective offer additional technical support to help bricked parachains? i.e. help debug the code, create the rescue plan, create postmortem report, provide resources on how to avoid getting bricked From d9b91122c028ada080531678a9b89cff3212d652 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pablo=20Andr=C3=A9s=20Dorado=20Su=C3=A1rez?= Date: Thu, 24 Oct 2024 11:08:27 -0500 Subject: [PATCH 4/6] Update text/0117-unbrick-collective.md Co-authored-by: Alejandro Martinez Andres <11448715+al3mart@users.noreply.github.com> --- text/0117-unbrick-collective.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0117-unbrick-collective.md b/text/0117-unbrick-collective.md index e7f71fba5..51c8ba73f 100644 --- a/text/0117-unbrick-collective.md +++ b/text/0117-unbrick-collective.md @@ -124,7 +124,7 @@ The ability to modify the Head State and/or the PVF of a para means a possibilit arbitrary modifications of it (i.e. take control the native parachain token or any bridged assets in the para). -This could introduce a new attack vectorm, and therefore, such great power needs to be handled +This could introduce a new attack vector, and therefore, such great power needs to be handled carefully. ## Testing, Security, and Privacy From 7fe2dd554be21d161d86906ae326a35fdbe07c62 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pablo=20Andr=C3=A9s=20Dorado=20Su=C3=A1rez?= Date: Thu, 24 Oct 2024 11:09:00 -0500 Subject: [PATCH 5/6] Update text/0117-unbrick-collective.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Bastian Köcher --- text/0117-unbrick-collective.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0117-unbrick-collective.md b/text/0117-unbrick-collective.md index 51c8ba73f..6ce778020 100644 --- a/text/0117-unbrick-collective.md +++ b/text/0117-unbrick-collective.md @@ -107,7 +107,7 @@ The origins able to modify the members of the collective are: - The `Fellows` track in the Polkadot Fellowship. - `Root` track in the Relay. -- More than two thrids of the existing Unbrick Collective. +- More than two thirds of the existing Unbrick Collective. The members are responsible to verify the technical details of the unbrick requests (i.e. the hash of the new PVF being set). Therefore, they must have the technical capacity to perform such tasks. From 18bdeaaeb0854f861077e069509eb97b413e6eb7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pablo=20Andr=C3=A9s=20Dorado=20Su=C3=A1rez?= Date: Thu, 24 Oct 2024 11:09:06 -0500 Subject: [PATCH 6/6] Update text/0117-unbrick-collective.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Bastian Köcher --- text/0117-unbrick-collective.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0117-unbrick-collective.md b/text/0117-unbrick-collective.md index 6ce778020..d79b20d39 100644 --- a/text/0117-unbrick-collective.md +++ b/text/0117-unbrick-collective.md @@ -16,7 +16,7 @@ of blocks of these paras. ## Motivation Since the initial launch of Polkadot parachains, there has been many incidients causing parachains -to stop producing new blocks (therefore, being _bricked_) and many occurrences that requires +to stop producing new blocks (therefore, being _bricked_) and many occurrences that required Polkadot governance to update the parachain head state/wasm. This can be due to many reasons range from incorrectly registering the initial head state, inability to use sudo key, bad runtime migration, bad weight configuration, and bugs in the development of the Polkadot SDK.