polkadot-fellows / xcm-format

Polkadot Cross Consensus-system Message format.
Apache License 2.0
179 stars 41 forks source link

Discoverability and versioning for transacting #22

Open gavofyork opened 3 years ago

xlc commented 3 years ago

Should we have a Query/QueryResponse message with version: (u32, u32), keys: Vec<u8> to query storage from a pallet? The storage / key encode will be done on sender side (and semvar ensures compatibility). The dest chain just need to check compatibility and add pallet prefix and response the storage.

h4x3rotab commented 3 years ago

Should we have a Query/QueryResponse message with version: (u32, u32), keys: Vec<u8> to query storage from a pallet? The storage / key encode will be done on sender side (and semvar ensures compatibility). The dest chain just need to check compatibility and add pallet prefix and response the storage.

Maybe also add another Query to get the state root of the remote parachain, so that we can verify any storage item at a certain block height locally.

yrong commented 3 years ago

@xlc I just did some test to invoke transact xcm and face the same challenge you mentioned here

Is there any progress for this issue or what is the safe way to invoke relay chain callable function from parachain side?

apopiak commented 3 years ago

This does not discuss how to get information on the execution of a regular XCM. (e.g. DepositAsset) Is this out of scope? I imagine chains and users would want to get an indication about the execution status of an XCM. Is the plan for users (or their frontend client) to monitor the target chain for execution status?

gavofyork commented 3 years ago

This does not discuss how to get information on the execution of a regular XCM. (e.g. DepositAsset) Is this out of scope? I imagine chains and users would want to get an indication about the execution status of an XCM. Is the plan for users (or their frontend client) to monitor the target chain for execution status?

The contents of this PR has nothing to do with regular XCM.