(source)

Table of Contents

• RFC-0117: The Unbrick Collective
  • Summary
  • Motivation
  • Stakeholders
  • Explanation
    • The Collective
    • The Unbrick Process
    • Belonging to the Collective
  • Drawbacks
  • Testing, Security, and Privacy
  • Performance, Ergonomics, and Compatibility
    • Performance
    • Ergonomics
    • Compatibility
  • Prior Art and References
  • Unresolved Questions

RFC-0117: The Unbrick Collective

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

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

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
• How to Recover a Parachain, Polkadot Forum
• Unbrick Collective, Polkadot Forum

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