D-Day Governance

[kianenigma]

Write a new governance pallet that should reside in the relay chain, while the main governance apparatus resides on Asset Hub.

The main usage of this pallet is when AH and/or Collectives are not producing blocks, and therefore can no longer access Root on the relay chain.

The assumption of this pallet is that it can have access to the latests state root of both Collectives and AH, and also has some notion of "soft metadata" of Collectives and AH. As in, it knows that a state proof corresponding to a specific hard-coded key prefix is associated with e.g. the balance of a user in AH.

A few key properties of this pallet:

• Proposals can only be created by:
  • the Collectives parachain (fellowship)
  • membership proof in the fellowship (should collectives be offline)
  • the pallet knows that AH has not produced blocks for some period of time.
• Voting can be done through submitting a proof of one's balance on AH
• Note that this voting is fee-less, so making it Sybil-resistant is a concern
  • vote txs are prioritized by the vote value. If spammed, the larger votes should make it onchain faster than small ones.
  • 1st vote is free
  • Votes cannot be flipped

Relies on #5400. @shawntabrizi would you like to work on this after your current work? It seems to fit your aptitude very well.

[shawntabrizi]

Acknowledging the issue.

Not sure how much availability I have, but I can def mentor someone. Depends on urgency. If not urgent, I could probably get small pieces of this story done over the weeks.

[kianenigma]

This falls into the more long term requirements of Asset Hub, not being needed until the very final days. In that sense, I was going to suggest you start working on it after your current project is done and roughly by end of DevCon?

[bkchr]

Relies on #5400. @shawntabrizi would you like to work on this after your current work? It seems to fit your aptitude very well.

This is using a binary merkle tree and the chain is using a 16 patricia merkle tree. They are not compatible. We already have other code in historical session that does the checking of proofs already.

Generally, with the development of JAM, we will not have this luxury of having an extra governance sitting on the relay chain. So, when in JAM all chains stop, we don't have governance as well. So, a little bit questionable if we need this pallet at all. Or do you just want it for the period where governance switches over to AH and we are afraid of it not working properly on AH?

[burdges]

Afaik XCMP need real state proofs into other parachain's state, so one could abstract that somewhat.

We'll avoid starving "true system parachains" ala #4632 (comment). We've not concretely defined that term yet, maybe audited like polkadot itself and no flexible execution aka no smart contracts. Also maybe no advanced collator communication, which maybe forbids elastic scaling. We've discussed reverting code upgrades automagically too, but afaik nothing currently in progress, and maybe imposes design restrictions.

We've more ways individual parachains can brick of course. Also JAM should bring much new brickage, but "true system parachain" could forbid non-trivial accumulation, which again maybe forbids elastic scaling.

Anyways, if collectives were kept relatively simple, than maybe collectives alone could provide this? Or maybe some simpler multi-sig derived from collectives? AH doing governance directly maybe a design mistake too, because doing so add tension between different concerns.

[shawntabrizi]

@bkchr I actually switched to a compact base 16 trie because the binary tree libraries were unusable in the runtime currently

[kianenigma]

Or do you just want it for the period where governance switches over to AH and we are afraid of it not working properly on AH?

Exactly for this period.

[kianenigma]

@bkchr I actually switched to a compact base 16 trie because the binary tree libraries were unusable in the runtime currently

I assume with this comment, there is no blocker to implement this, right?

It would be great to get a prototype of a pallet that tightly couples with the parachain pallets (e.g. can only work in RC), and can request to read the state of a parachain based on its latest state root: as in, have an extrinsic where anyone can provide a state proof of a parachain, and it would verify it based on the last known state root of the given para.

/// Provide the state `proof` for `id` at `block`, or the latest block if not provided
fn poc_read_para_state(id: ParaId, proof: Vec<Vec<u8>>, block: Option<BlockNumber>)

@bkchr do you know if this exists anywhere?

If this can be built, I will have no doubts that the rest of this issue can also be done.

[bkchr]

It doesn't exist yet. However, building it should be straightforward, but it would also not support every parachain. Parachains are not required to use any specific state layout. But for the system chains we can make it work.

[kianenigma]

Some code to demonstrate:

• How to detect if AH is stalled
• How to receive proofs for a given key in it

https://github.com/paritytech/polkadot-sdk/compare/kiz-dday-demo?expand=1

[burdges]

We'll want parachains that never stall for PJR tests and DKGs, but they'd avoid censorship vectors like smart contracts, and never make too many blocks either, aka no elastic scaling.

In principle, relay chain governance could always take place on some non-stallable parachain, so not AssetHub, but using proofs into AssetHub state.