[Discussion/Idea] Domain/Pallet specific XCM language

[crystalin]

At the parachain summit we spent some time to discuss some ideas around XCM evolution, especially around what instructions we think should get into the language. Some of those (that are also mentioned in this Github) are domain specific instructions like Governance or Staking ones.

I agree we should go toward domain/feature oriented language. And I also agree that the language should be implementation/pallet agnostic. However I will share why it might be useful to still consider adding a pallet specific language.

I believe that a language should be designed to fill a "need" in order to become useful. However currently, parachains are able to communicate with each other without trouble (using transact). Obviously this won't be the case in the future once we have more and more parachains to communicate with and more features requiring communications. But I don't actually see a real need for a more extended language now.

Not only I don't see the need, but I also believe that those domain specific features are not yet well defined within the ecosystem. Governance seems to be an easy one, but what common language could work well (meaning "be compatible and complete enough to be useful") with governance v1 and v2.
Staking, which is also getting popular among parachains, doesn't even have a proper design for parachain and it seems that each parachain would want to implement it differently. It would be hard for us now to define a language for it.

The risk of designing such a language too early, is that it won't be common enough to the different implementations and clients/parachains will rely on a combination of specific instructions (Ex: Staking.stake...) and transact, making the use of those specific instructions useless.

What I would like to suggest is a incremental approach in order to reach a point where we will have the experience and the need to design those domain specific languages.
We could, as a first step, introduce a "pallet transact" (name is bad but couldn't find better) that would be aware of the pallet being called. This could be done, for exemple, by defining a unique id for pallets.
This would allow parachain to communicate the same way with all parachains implementing exactly that pallet.

This, of course, is not meant to be the final state of the language, but a way to simplify communication across parachain, and give us enough time and also visibility about which pallet and more importantly, which feature of those pallet, are commonly used and what language we should build for them.
If done in a timely manner, parachain using those "pallet transact" would have the possibility to switch those call to use the language dedicated to those features, allowing them to talk to a larger set of parachain would decided to support it.

To simplify it, you could see it as:

• step 1 => parachains are using "transact" which is a custom call for each parachain they communicate with (this is the current state)
• step 2 => parachains can use "pallet transact" which would be the same for each parachain using the given pallet
• step 3 => parachains will use "domain specific language" which will be the same for all parachains supporting the feature, no matter which pallet they use

Just my 2cts :p

[h4x3rotab]

Totally agree with an incremental approach.

Just to give another example. So far the XCM instructions are already a bit complex. Thinking about extending XCM to a new environment, e.g. the ink! contract, you will notice that to proper handle the various cases, a great amount of code must be ported.

Transact is powerful enough to support most of the communication. The problems are just that (1) the location could be unpredictive, and (2) the transact calls on parachains are not standardized. To overcome the first problem, @crystalin suggested to build a pallet to better manage it. This is very practical. For the second problem, essentially the ecosystem is not mature enough to emerge any kind of standard. Trying to build a DSL for the application level use cases too early could also be harmful, because it may discourage innovation in the ecosystem.

[crystalin]

I didn't see it before, but Gav also proposed a solution related to pallet specific query: https://github.com/paritytech/xcm-format/pull/22/files#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R687. That one is about querying the pallet information as opposed to directly transacting with the pallet as I suggested

[Polkadot-Forum]

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/how-xcm-will-actually-be-used-with-xcmp/190/6

[Polkadot-Forum]

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/xcm-dialects-plugging-into-xcm-to-create-standardized-and-predictable-api-surfaces/384/2