Skip to content

Latest commit

 

History

History
172 lines (120 loc) · 7.28 KB

0117-unbrick-collective.md

File metadata and controls

172 lines (120 loc) · 7.28 KB
Raw

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

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

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

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

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