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

[bkontur]

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