Governance parachain fallback

[burdges]

I think https://github.com/polkadot-fellows/RFCs/pull/32 makes sense for Kusama as written, but we've always envisioned Polkadot holding up even when finality stalls, just using longest chain. Approvals depends upon grandpa however, so parachains become completely insecure under longest chain, so even system parachains like governance cannot be trusted.

@AlistairStewart and I have discussed a few fallback models for this, but one simple-ish model goes like:

• Governance depends upon beefy self proofs for relay parent, and hence messaging, not merely relay chain state. If grandpa stalls, then governance can still message the relay chain, but not anybody else.
• We add a "manual execute" option by which governance can order 2+ full parachain blocks to be executed within the relay chain block, one of which itself communicates the "manual execute" command. This can advance the state of the governance chain, even without beefy proofs.

We do not imho require this complexity to deploy on Kusama, but we'd ideally do something along these lines before Polkadot, and supersedes https://github.com/paritytech/polkadot-sdk/issues/1963

[bkchr]

We already talked about this, we can just keep the governance configured on the relay chain. Just as some fallback when something breaks. We probably only need a way to proof the holding of coins for voting. To make this secure we may should have a way to keep the latest finalized parachain state to use this as the proofing point.

[burdges]

You mean: There are only voting and locks in the governance chain state, and they do not live forever. We'll need to reference staked accounts elsewhere anyways from the locks. We can therefore run a vote on the relay chain state too, if we can reference the locks elsewhere, or not use the locks. And the relay chain can send the result back as a message.

Yeah okay this sound fine. And the extra generality of what I wrote above sounds not worth the trouble.