Practical crosschain interaction

[xlc]

Not sure if this is the best place for this, but post here anyway.

I am currently designing how to make a parachain act as a staking pool, which will have the requirement of sending upward message, and query relaychain storages.

Sending upward message is mostly working now so that's good.

We don't have much light currently on how the reading storages is going to work.

To implement the staking liquidity protocol, we need to query many different storages from relaychain, includes

• account balances
  • we will have handful of staking accounts and only interest about balances for those accounts
• pallet-staking storages
  • validator list
  • staking ledger
  • slashes
  • era information
• pallet-democracy storages
  • ongoing referendum indices
• maybe bunch more like pallet-collectives etc

AFAIK, there won't be any direct cross-chain storage read ability, instead we need a relayer (possible implemented with offchain-worker) to relay relaychain storage to parachain using extrinsic, which will include a storage proof to allow parachian runtime to verify storage.

So the extrinsic will be something like

fn update_relaychain_state(origin, values: Vec<(StorageKey, StorageValue)>, proof: StroageProof)

But in practice, this is really hard to use. We need to reimplement something decl_storage does to parse and decode the key, decode the value, generate a suitable Rust interface for consumption. It is definitely doable, but a lot of work.

I would like to explorer if it is possible to reuse decl_storage to handle the decoding & type generation.

So basically in update_relaychain_state, after verification, it directly write the key value pairs into a child storage, or replace / rehash the prefix and write to storage directly.

Next step is basically redeclare the storages / import storages from relaychain runtime and we will be able to access them normally.

But there are still few more questions:

• How to ensure relayer don't relay unnecessary information?
  • I guess a prefix whitelist combined with custom checker can do
• How to ensure the data is not outdated?
  • The easy way is storage last updated block, and make transactions depending on relaychain fail if last updated was too long ago. People can them relayer the information themself and continue transact. But we probably wants a better way.
• How to efficiently relay the state?
  • Is it possible to generate a change trie for a subset of prefix so only the change needs to be relayed?
• How to handle storage migration on relaychain runtime?

[gavofyork]

Storage migration would need to be handled by the parachain for now, but I don’t see the alternation of major storage items as being at all likely in the short-medium term.

Not sure what you mean exactly by efficiently relating state; but for now the simplest would Be to relay all items you might need, every block.

Generally chains should be designed so that they don’t use huge amounts of data from other chains - if that is happening then it could be that the functional split between chains in suboptimal.

For the relay chain in particular we do plan on optimising a lot of this, for example by allowing a limited amount of data from nominated storage items to be fed directly into the parachain each block. This could e.g. include state roots of other parachains or balances of particular accounts.

[xlc]

Relay unchanged data sounds inefficient, so it will be good if it can send changes. Like for staking related data, many of them once change once per era.

Also does this means the relaychain will allow parachain to specify some storage key (prefix?) and relaychian will send those data to parachain every block?

If that's possible, it will ensure parachian will never have stale relaychain state, which will be useful.

[bkchr]

@xlc is this issue still relevant or can be closed?

[xlc]

Mostly addressed by paritytech/polkadot-sdk#82 and polkadot-fellows/xcm-format#22 so can be closed. The DX side still need more consideration but that can be happen later after the primitive building blocks are ready.