Skip to content
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

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
184 changes: 184 additions & 0 deletions text/0117-unbrick-collective.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,184 @@
# 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 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.

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.
Copy link

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?

Copy link
Author

@pandres95 pandres95 Aug 26, 2024

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.


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.
pandres95 marked this conversation as resolved.
Show resolved Hide resolved

## 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.

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't get the JAM part. Even in JAM this could be build into the parachain service to be have the unbrick collective.

exceeds sudo permissions, so the unbrick collective cannot modify those state roots or code.

### The Unbrick Process
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO this should still require that the chain is actually bricked, aka not producing blocks. When the chain enables the unbrick collective it could for example pass a time out after which the chain is seen as "bricked".


```mermaid
flowchart TD
A[Start]

A -- Bricked --> C[Request para unlock via Root]
C -- Approved --> Y
C -- Rejected --> A

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 --> D
O -- Bricked --> E

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 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

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 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.

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 vector, 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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO most of the members should be from different parachain teams. This way it is a quid-pro-quo in longterm.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But depending on their involvement they could maybe get retroactive payment for helping with a certain fix.

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't get what you want to say with this point.

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
pandres95 marked this conversation as resolved.
Show resolved Hide resolved

<!-- 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