[AHM] PoC for D-Day governance rescue feature on CollectivesWestend

[bkontur]

Relates to: #5588 (comment)
Relates to: #7591
Relates to: @kianenigma's initial demo

TL;DR

This PR includes several key features:

• CollectivesWestend D-Day referenda setup: Enables voting by AssetHub accounts (multi-key) with AssetHub proofs (+ showcases a unit test for voting with real proofs downloaded from AssetHubWestend).
• SkipCheckIf transaction extension wrapper: Allows defining conditions under which the inner transaction extension execution can be skipped (e.g., in CollectivesWestend transaction extensions, skipping CheckNonce when valid proof).

---

Motivation and Context

Currently, governance on the relay chain has the ability to trigger Paras::force_set_current_code(Root, para_id, new_code), for example, to rescue a stalled parachain (although there may be other reasons as well).

A major thing is approaching: the AssetHub migration (AHM). One key aspect of this migration is the transfer of relay chain governance to AssetHub. This means that governance will no longer exist on the relay chain but will instead be fully migrated to AssetHub.

D-Day (Doomsday) governance serves as a backup plan or a last resort in case the AssetHub parachain stalls - that is, it stops producing blocks. In such a scenario, AssetHub’s governance would be unable to trigger Paras::force_set_current_code(..) on itself.

Proposed Solution

• CollectivesWestend has configured a new pallet_bridge_proof_root_store:
  • Stores the Relay Chain block number and storage_root with OnSystemEvent
  • (This pallet is just cherry-picked from other Bridges PR for other use-case)
• CollectivesWestend has configured a pallet_referenda instance (DDayReferendaInstance):
  • Only rank3+ fellows can submit and start referenda with a specific call, e.g.,

    pallet_xcm::send(Location::parent(), Xcm(Transact(Paras::authorize_force_set_current_code_hash(1000, fixed_code))))

• CollectivesWestend has configured a new pallet_dday_voting: (copied from conviction-voting and adjusted)
  • Voting is allowed only if the AssetHub state root is present.
  • Voting via pallet_dday_voting::Call::vote(signed_user, proof) requires a valid AssetHub proof containing:
    • Account balance
    • Total and inactive issuance
  • The signed_user represents an (AssetHub) account signed with a secret key, and the accountId is used as part of the proof key.
  • The proof can be generated for a stalled AssetHub block using the RPC:

    state.getReadProof(keys, at)

  • The proof is validated against the stored AssetHub state root. A dedicated runtime API could also be added to simplify UI integration.
  • Total issuance/inactive issuance is updated in Tally to calculate support(..) (see also Questionable / Weak Points).

Questionable / Weak Points

• DDay conviction voting requires knowledge of AssetHub’s "total" issuance (total - inactive):
  • Voting works only if AssetHub is stalled, meaning we have a single state root/block number.
  • Total and inactive issuance are part of the proofs, and for the same block number, they shouldn't change.
• PoC does not expect/require an AssetHub account to have a balance on the Collectives chain:
  • The main issue arises with CheckNonce (verifying an account’s providers/sufficients) and ChargeTransactionPayment.
  • The current fix involves adding the SkipCheckIf transaction extension wrapper. If a DDayVoting::vote call is valid and includes valid proofs (only when AssetHub is stalled), then CheckNonce and ChargeTransactionPayment are skipped. (In other words, if AssetHub is not stalled, nothing is skipped.)
  • ❓ Uncertainty: Is this approach sufficient, or could it lead to potential free spamming? Does it create a vulnerability?
• We could avoid RelayChain proofs, but then we need to read para head from RelayChainStateProof_** (see Follow-ups).
  • (This feature will be prioritized, as it will also optimize Bridges.)

Testing

• Unit test demonstrating proof validation using real data downloaded from AssetHubWestend at a specific block:
  • fn asset_hub_account_prover_works() / fn verify_proof_root_works()
• Unit test verifying DDayReferenda / DDayVoting by proof-based voting:
  • The vote is submitted as a real extrinsic to pass all transaction extensions.
  • The user does not have an account or balance on the Collectives chain.
  • fn dday_referenda_and_voting_works()

TODO

• Review, decide, and confirm if this PR is the right approach; check questionable/weak points:
  • DDay conviction voting and active issuance?
  • Is SkipCheckIf acceptable? (If not then what alternative approach?)
• Complete the PR:
  • Fix all code TODOs
  • Benchmarking and tests
  • Runtime API for pallet_dday_detection::LastKnownHead or pallet_dday_detection::IsStalled::stalled_head()

Follow-ups

Read para head from RelayChainStateProof:

• Investigate extending the RelayChainStateProof trie with relay_chain::well_known_keys::para_head(sibling_para_id) for relevant/configured sibling paraIDs. #7445
  -Support custom storage proof from the relay-chain #82

Force setting the current code from a parachain to the relay chain:

• Add Paras authorize_code_hash + apply_authorized_code feature #7592
• Fetch parachain runtime code from the relay chain #78 (A dynamic approach to avoid the need for coordinating collators with an updated chain spec containing codeSubstitutes after force_set_current_code.)

[bkontur]

/cmd fmt

[bkontur]

/cmd fmt

[paritytech-workflow-stopper]

All GitHub workflows were cancelled due to failure one of the required jobs.
Failed workflow url: https://github.com/paritytech/polkadot-sdk/actions/runs/16687494536
Failed job name: fmt

[MN0B]

@bkontur is there an ETA for this ?