Investigate extending the `RelayChainStateProof` trie with `relay_chain::well_known_keys::para_head(sibling_para_id)` for relevant/configured sibling paraIDs.

[bkontur]

Relates to: #82

Motivation

The goal is to access the state_root of sibling parachain B from parachain A. While the relay chain can easily retrieve this information via paras::Heads, parachains currently only receive the para head of their own included/active parachain in RelayChainStateProof.

Example

A possible use case: Parachain A synchronizes and stores the latest state_roots of other parachains, such as parachain B. Parachain A could then expose an extrinsic that accepts trie proofs, e.g., do_some_magic(trie_proof_of_sibling_para), and internally validate the proof using the stored state_roots.

At least two existing use cases could benefit from this:

• Voting with remote proofs
• Message proofs between BridgeHub and AssetHubs

PoC

#7444

Questions

1. Is it feasible to extend RelayChainStateProof to include predefined/configured relevant paraIDs? As a non breaking change? or what are consenquences - restart node software?
2. How could this be implemented? Would it be safe?
3. Can we use any parachain block’s state_root, or should we rely only on finalized blocks? Are there any limitations?

[bkontur]

Relates to: #6235
Relates to: #82

[acatangiu]

This will also be needed for XCMP / ISMP / whatever offchain messaging protocol will replace HRMP.

#1960 and #4750

[bkchr]

This will also be needed for XCMP / ISMP / whatever offchain messaging protocol will replace HRMP.

Not really. You could also just input a proof over the other chain via the relay chain storage root.

[bkchr]

This issue goes a little bit into the direction of #82.

As an intermediate step I would propose that we have a runtime api that returns keys, that will be included in the storage proof. Then you can decide in the runtime which keys should be inserted.