-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The Unbrick Collective #117
Draft
pandres95
wants to merge
2
commits into
polkadot-fellows:main
Choose a base branch
from
pandres95:unbrick-collective
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,172 @@ | ||
# RFC-0117: 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||
|
||
## 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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||
|
||
<!-- Footnotes --> | ||
|
||
[^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. | ||
|
||
<!-- Links --> | ||
|
||
[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 |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sentence is too hard to parse. It's they're too busy, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not necessarily. It's just a matter of mission and scope. 😅
Same case with the Unbrick Collective: it's scope would be providing assistance to para teams which need help unbricking their para, not helping teams design their newest runtime version, or auditing code (in which case, your suggestion of an auditing collective sounds great).
Adhering to a single responsibility principle sometimes can be in the best interest of decentralisation.