search

paritytech / polkadot-sdk

The Parity Polkadot Blockchain SDK
https://polkadot.network/
1.67k stars 594 forks source link

[XCM] META: XCM additions #686

Open franciscoaguirre opened 1 year ago

franciscoaguirre commented 1 year ago

Rationale

We want to make XCM more powerful, specifically in our journey to get all non-security functionality out of the relay chain. For this we need to support more and more use cases over XCM, and make them more ergonomic and less error-prone. A use case this new version aims to attack is staking, looking at a future staking parachain (stakemine? :thinking:).

This was originally an issue for tracking the development of v4, but v4 had to be a simple renaming upgrade. Because of the XCM RFC process, new versions will just be a list of accepted RFCs to be implemented. The below instructions are intended to be added at some point, but they'll only be added once an approved RFC comes along. The RFCs live in the xcm-format.

New instructions

Holding and slashing

Instructions for holding assets and freeing them. Similar to the locking instructions introduced in v3 (LockAsset, UnlockAsset, NoteUnlockable, RequestUnlock).

This instructions would allow one system to communicate to another one that they are effectively holding assets and they are allowed to be slashed if the need arises. While locking might work for proving you can vote on a different chain, holding and slashing allows for things like (but is not limited to) staking.

Good UX would be for voting and staking messages to a different chain (NoteUnlockable and NoteReleasable) to be free given that you've already locked/held a certain amount of assets. Free always means rate limited. This might be for locking/holding assets over a certain amount (e. g. 10 DOT).

Setting an agent (controller account) to operate in a different system on behalf of the origin

Instructions to set and reset an agent on another system. This agent can perform actions on the receiver as if you the origin had an account there.

This instructions will be interpreted differently based on the receiver. For example, if the receiver is a staking parachain, the agent will have the privilege to stake on behalf of the origin who set it. In this case, you might need to hold assets locally (or via XCM, like on statemint) and let the agent know you have held them. The agent account can then receive staking rewards and slash your held assets over XCM if necessary.

Another example is the agent lives in a voting parachain. In that case you'd need to lock some assets locally (or on statemint) and let the agent know so it can vote for you.

Voting instructions

Governance is a really useful and frequent feature of consensus systems. Because of this, v4 might have specific voting instructions like the following:

Querying exchange rate

New instruction to query the exchange rate between two assets, could work for NFTs as well.

Might also be something like HintExchangeRate, it won't swap assets, it will just return an estimation of how much of one asset you'd get by swapping some amount of some other asset.

Temporary account

An instruction to create a temporary account on the receiver to be able to add liquidity or transfer assets.

WithClearOrigin

An instruction to be able to "pop" the latest origin while executing another XCM but then returning to the original origin. This provides a more ergonomic way to deal with multi-chain interactions.

It would be used like:

// Executing Xcm instructions with a particular origin
WithClearOrigin(Xcm(vec![
  // Do things without origin
]))
// Keep on executing Xcm instructions with the same origin as before

Low priority instructions

Adding/removing liquidity

Instruction to add/remove liquidity to a liquidity pool. It's a useful function but specific, many systems wouldn't implement it. Right now can be done via the Transact instruction.

Sync metadata

An instruction to sync asset metadata, for example for NFTs. Might be too specific, heavy and might be able to be implemented with Transact already.

xlc commented 1 year ago

Can I suggest that we have a spec draft before implementation? https://github.com/paritytech/xcm-format There should be a RFC process for XCM

franciscoaguirre commented 1 year ago

Certainly! I created this issue here first for bookkeeping purposes while I figure out an RFC format for the xcm-format repo. Will be creating RFCs in that repo in the following days.

Polkadot-Forum commented 1 year ago

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

https://forum.polkadot.network/t/xcm-rfc-process/2447/1

ntn-x2 commented 1 year ago

I see the issue has ben put into the project "Deadline Q4 2023". Can we then expect a Polkadot release with XCM v4 by the end of the year?

KiChjang commented 1 year ago

XCM v4 is actually going to be using the new RFC process to make changes to XCM itself. We will in fact be creating RFCs for each and every individual feature that Francisco has written down on this issue.

As such, it's hard to say exactly for sure when we can release XCM v4, as it first depends upon community agreement on the new features that we want to introduce to v4, and then it depends upon the implementation difficulty of said features. However, assuming absolutely everything goes smoothly, we believe that we can release it by the end of the year, but do keep in mind that this is the optimistic happy path.