The Unbrick Collective

[pandres95]

Rendered document

Related to polkadot-fellows/runtimes#376, this RFC defines the process of constituting the collective and the mechanisms needed by the collective to fulfill its mission.

[burdges]

An unbricking call could also issue assets of course. A parachain could turstile foreign assets, so that unbricking could only issue native assets, and steal wrapped foreign assets, but not issue foreign assets.

Yet, we've long envisioned synchronous privliged library calls, initially the SPREE idea by Gav or whoever, seemingly now folded into JAM. All these proposals exist firstly so that assets can be native on multiple parachains, so then unbricking could issue foreign assets in theory.

We've no alternatives of course, since staying bricked maybe worse, but unbricking could demand audits based upon usage of SPREE-like or JAM functionality. It's not necessarily assets either, so in general pallets or whatever should document their security concerns, and unbricking should review these. You'd expect mostly they say nothing, but in general you would not be permitted to say roll back your own DOT SPREE state to a known good state.

A parachain could've a maximum block gap configuration so the parachain itself could respond to the unbricking calls. If a parachains wants one block every six seconds, then maybe they want to unbrick within minutes. If a parachain makes one block every 24 hours, then maybe they require days.

[xlc]

Maybe worthwhile to mention that:

Before this change, a parachain will be one of two state: unlocked (para manager essentially have sudo permission), or locked (para manager don't have any permission).

After this change, a parachain will be one of three state: unlocked, locked, and managed by Unbrick Collective. The new state sets between fully centralized (controlled by one account or wasm), fully decentralized (only controlled by the wasm). The chain is controlled by the wasm or the Unbrick Collective + OpenGov. The goal is trying to find the right balance between fully centralized (bad) and fully decentralized (inefficient).

Another thing is that on how to determine if a parachain is bricked. With the old parachain slot model, it is relatively easy that we can assume if no block is produced for sufficiently long time, there must be something wrong. However this heuristic no long works with core time model. So maybe we need a mechanism like @burdges suggested that when a parachain opt-in, it should also set how many blocks are required to consider the parachain is bricked.

[burdges]

We'd maybe want declared estimates for how often parachains make blocks elsewhere, like in some flavours of off-chain messaging. If so, we might make this number mandatory even for parachains who do not join the unbrick colelctive, or maybe that's a slightly different number, but regardless that's future work.

---

I'll clarify my comments above:

In future, we'll have functionality that's more sensitive than a parachains own code, so an unlocked/sudo parachain could use such functionalities, but could not change the code or state of that functionality. The unbrick collective might be similarly limited, or maybe not, depending upon how its ellections work in practice.

Initially, I'd suggest the unbrick collective be limited to what sudo does, meaning it cannot touch SPREE-like code or state. We'd consider strengthening the unbrick colelctive if the ellections are polkadot wide and seems strong like our original faster pre-opengov governance (unlikely). We've no difference anyways right now, since we do not yet have SPREE, JAM, etc, so this could be discussed once those come into being.

In other words, my SPREE comments do not propose changing this RFC per se, except maybe notes in the seeding section and/or Unresolved Questions.

Auditing requirements provides another option, which slows everything down, but nothing like the opengov slowdown. At the extreme, auditors could be selected at random after the new code & state were proposed, almost like running the machine elves protocol or the sampling beefy off-chain among humans, but that's likely too complex. It's also possible parachains themselves would want auditing before unbricking, beyond merely the delay.

Auditing could be defined by some future RFCs which would maybe take things in other directions, like maybe parachains want auditing for regular upgrades, etc. In other words, my auditing comments do not propose changing this RFC per se, except maybe notes in Unresolved Questions.

[burdges]

This sentence is too hard to parse. It's they're too busy, right?

[pandres95]

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.

[burdges]

Initially, the unbrick collective has powers similar to a parachains own sudo, but
permits more decentralized control.  In future, polkadot shall provide functionality
like SPREE or JAM that exceeds sudo permissions, so the unbrick collective cannot
modify those state roots or code.

[burdges]

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