-
Notifications
You must be signed in to change notification settings - Fork 766
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
Comments
this show solve it polkadot-fellows/xcm-format#22 |
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? |
* 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
* Add `safe` and `finalized` block tags support * prettier
topic moved here polkadot-fellows/xcm-format#28 |
Based on my not in dept observation of the code in the xcm crate, it's my assumption that the
Call
in aTransact
instruction must be crafted for the specific targeted chain, it seems that we either depend on the other chain's runtime to get itsCall
type to construct theDoubleEncoded
call parameter of theTransact
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:
The disadvantage I see here is that this transact mechanism kind of encourages coupling among parachains, imagine several parachains have a
kittens
pallet with ameow
extrinsic, also imagine ascare_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 remark0x000100
leave out the0x0001
) 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 canscare_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.
The text was updated successfully, but these errors were encountered: