Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Runtime agnostic Xcm Transact #853

Closed
olanod opened this issue Mar 15, 2022 · 3 comments
Closed

Runtime agnostic Xcm Transact #853

olanod opened this issue Mar 15, 2022 · 3 comments
Labels
T6-XCM This PR/Issue is related to XCM.

Comments

@olanod
Copy link
Contributor

olanod commented Mar 15, 2022

Based on my not in dept observation of the code in the xcm crate, it's my assumption that the Call in a Transact instruction must be crafted for the specific targeted chain, it seems that we either depend on the other chain's runtime to get its Call type to construct the DoubleEncoded call parameter of the Transact instruction or we use the opaque version where the encoded bytes usually come form the client. Either way the bytes encode not only the specific extrinsic of a given pallet but also it's "place" in the runtime represented by a prefix index which is the way SCALE encodes the enum of a runtime's calls.
Example taken from a test in orml:

let call = 
    relay::Call::System(frame_system::Call::<relay::Runtime>::remark_with_event { remark: vec![1, 1, 1] });

The disadvantage I see here is that this transact mechanism kind of encourages coupling among parachains, imagine several parachains have a kittens pallet with a meow extrinsic, also imagine a scare_other_kittens extrinsic that accepts a list of multi-locations used to send a message to several chains to make their kittens meow at the same time, I'd have to know in advance how the kittens pallet was declared in the other runtimes or pass the responsibility to the user of the extrinsic to tell me that, maybe I can query the other chain's metadata to know if they can meow and know the index of the pallet but delegating that to the client seems ugly and error prone, also parachains might just want to send XCM messages without user intervention.

I think a more "generic" Transact would be very useful, instead of calling specific extrinsics in a specific pallet mounted in a specific position it would be nice to just tell the other chain here's the data of the call that follows this interface. Or in practical terms, allow the call to be the bytes of the extrinsic without its index in the runtime and while we are at it maybe also ditch the index of the extrinsic within its pallet(e.g. in the encoded empty remark 0x000100 leave out the 0x0001) and replace those with an "interface identifier". The ID could come from a well known registry of interfaces or simpler can be to use the existing type information of runtimes to encode extrinsic name with the arguments type info that can be hashed to have something unique enough to be able to route the message. Parachain runtimes can generate the hash table that maps extrinsics at compile time, when the extrinsic name is not enough to avoid collisions(initially I think is good enough) an annotation in the extrinsic can help. Over time it can become the way teams "standardize" certain interfaces. e.g. #[interface="RoyalKittenAssociation_meow"] pub fn meow(...) so now we can scare_other_kittens without worrying if the sister chains even have the same meow implementation.

I might be ignoring important details that would make this impossible but anyway I hope others see the potential in solving this problem, it empowers more the community to experiment with potential future "standards" instead of relying on the core set of instructions to be extended which doesn't scale well.

@xlc
Copy link
Contributor

xlc commented Mar 15, 2022

this show solve it polkadot-fellows/xcm-format#22

@olanod
Copy link
Contributor Author

olanod commented Mar 15, 2022

Interesting ... I think I still like my idea better 😝 it could avoid the roundtrip of querying the pallet info and focuses more on the extrinsics and what they do and not on specific pallets and where things are defined. The hash I mention can also already solve the versioning problem, can be made more reliable if we hash not only the inputs(the arguments type info) but also the outputs(events,errors,?storage?), might even allow pallets to introduce new versions of extrinsics while keeping the old ones for backwards compatibility or refactor things out into different pallets 🤔 wdyt?

@Sophia-Gold Sophia-Gold transferred this issue from paritytech/polkadot Aug 24, 2023
claravanstaden pushed a commit to Snowfork/polkadot-sdk that referenced this issue Dec 8, 2023
* Fix nix setup

* Generate fixtures for next sync period & adding tests accordingly

* More cleanup

* Fix ci

* More tests

* Remove install foundry

* Fix&Refactoring for goerli main spec

* Resolve comments

* Resolve comments

* For comment

* Running beacon node with explicit node option

* Bug fix for withdrawalCredentials

* Use Box Type for storing prepared pubkeys

* More refactoring

* More cleanup

* More cleanup

* Fix benchmark fixture

* Update benchmark

* Update weights

* Resolve comments

* Ignore code path for coverage

* Update cumulus

* Speed up E2E

* Fix ci adding feature release back for benchmark
helin6 pushed a commit to boolnetwork/polkadot-sdk that referenced this issue Feb 5, 2024
* Add `safe` and `finalized` block tags support

* prettier
@franciscoaguirre franciscoaguirre added the T6-XCM This PR/Issue is related to XCM. label Mar 25, 2024
@acatangiu
Copy link
Contributor

topic moved here polkadot-fellows/xcm-format#28

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T6-XCM This PR/Issue is related to XCM.
Projects
None yet
Development

No branches or pull requests

4 participants