Polkadot Brussels Technical Summit 24’ - XCM Workshop
Host: Francisco | Parity
Slides
There were multiple agenda topics throughout the XCM Workshop
- XCM Testing & Debugging
- (Complex) Asset transfers
- Asset Trapping
- Estimating XCM Fees
- New Fees Mechanism - RFC53 - XCMv5
- New XCM runtime configurations
XCM Testing & Debugging
XCM Testing & Debugging seemed to be the most popular throughout the workshop, the group then went onto discuss the following;
- Chopsticks & polkadot-ecosystem-tests
- XCM-Emulator
- Logging & on-chain events
Chopsticks is a tool used to facilitate the testing & debugging of cross-chain messages [XCM]. It allows the dev’s to fork live chains and simulate multi-chain scenarios using actual, on-chain data.
What are the benefits?
- Provides a realistic testing environment
- Multi-chain scenarios
- Enhanced Debugging
The tl’dr is that Chopsticks aims to significantly improve the development testing and the debugging throughout the ecosystem.
XCM-Emulator is a tool that allows the devs to simulate and test XCM without needing to run a full network. The Emulator is implemented as a rust-lib.
Both the XCM-Emulator & Chopsticks both serve the same purpose of testing & debugging XCM messages.
Should we sunset the Emulator?
There was some discussion about testing what Chopsticks does the best. It seems like chopsticks probably covers all the cases the XCM-Emulator covers, or used to & more.
“I think the XCM Emulator stuff needs to die” - Basti | Senior Parity Engineer
The sentiment was that the simulator & emulator are both old, teams should be using Chopsticks going forward.
The XCM Simulator & Emulator are there only because we forked them & used them, that’s the only reason. In the future other tools will come about & that’s a good thing.
We do also have a lot of tests for the system parachains already done with this. Those tests could easily be done with Chopsticks and they’d use live data to do so.
Wrt to the XCM Simulator and emulator, overall both are still good tools for testing out different configurations & are also good for education purposes. The cookbook [WIP] uses the simulator and will more than likely continue to do so.
Estimating XCM Fees
Estimating XCM Fees was next on the agenda, looking forward there seems to be a lack of visibility that the client & dApp for estimating XCM Fees. For this reason, two new API’s are being introduced;
- XCM Payment API
- DryRunAPI
- Gives your the message that is sent so you can fill in all the gaps
- Can dry run cross-chain extrinsics on Chain A
A test below describes the entire flow, the dry run API returns;
- Success or failure
- List of events
- Sent XCM, if applicable
- Local XCM
Both of these API’s aim to enhance the accuracy and transparency of XCM Fee estimation for XCM messages.
Complex Asset Transfers
The next topic we discussed was ‘Complex Asset Transfers’
Asset Transfer Programme Builder
- Rust / JS XCM Builder tools / Libraries
- Hides away XCM complexity & gotchas
- Resulting XCM programmes can be directly executed on-chain through palet_XCM::execute()
More information: RFC: XCM Asset Transfer Program Builder · Issue #4736 · paritytech/polkadot-sdk · GitHub
Asset-transfer-api
- Covers most common scenarios
- Supports transfers through AH
- Supports transfers over bridge
- Up-2-date asset registry [GitHub - paritytech/asset-transfer-api-registry: Asset registry for asset-transfer-api] including information around teleports and reserves
More information: GitHub - paritytech/asset-transfer-api: Typescript API aiming to provide clear, and simple to use tools for transferring assets across common good parachains.
Essentially anyone can go ahead and write an XCM programme, no matter how complicated they are to write
You’d need to define some tags & assign them toa assets, you can then withdraw those assets without needing to specify location. You can then specify the next hub, you can then use that info to know the names of the assets
You could then execute with 1 instruction. On XCMv5 you can have an instruction that allows you to mix & match. You might also want to teleport your assets to AH as you’ve registered there.
This allows anyone to write an XCM programme as the whole process is becoming more simplified.
Asset Traps
Asset Traps were next on the menu, with Improve SetAssetClaimer being the first talking point.
An exploratory idea by the Parity Engineering team was proposed, which consisted of Complete removal of AssetTraps
- Assets are deposited to origins local SA
- Assets Accumulate
- Uses less storage
- One Challenge is to figure out good story for non-sufficient assets when SA doesn’t have ED yet:
- Maybe auto-exchange enough of “asset” for DOT to cover ED
- Maybe use hybrid model: SA if ED satisfied, trap otherwise
One thing we can do is clear the origin, but we set the location not as the origin but the location that can contain the assets. The issue is, if the origin is cleared, where would we send the left over assets?
More information: xcm-format/proposals/0037-custom-asset-claimer.md at 10726875bd3016c5e528c85ed6e82415e4b847d7 · polkadot-fellows/xcm-format · GitHub
Estimating XCM Fee’s
Estimating XCM’s was next! There are 2 new API’s available for estimating XCM fees;
New Fee’s Mechanism - RFC 53
The New Fee’s Mechanism [RFC 53] was also briefly mentioned. To read up more about RFC 53, check out the link here
- RFC 53 - Call 2 help on the RFC
- No more
BuyExecution, new instruction ‘Payfees’ - All assets passed into
payfeesgo to a fees register - This register can be used to pay any fees, both execution & delivery
- Could also be used to pay other types of fees - Chain-specific/custom fees.
- No more
XCM Runtime Config
XCM Runtime Config was the final topic. The consensus is that the majority of people need to know how to configure their chains.
A proposed ‘XCM Cookbook’ was discussed, below are some examples of what it could contain. Although throughout the discussion it was proposed that we’ll be looking to collaborate heavily with the Ecosystem on this initiative
- How to use DOT on your parachain
- How to use other parachain tokens
- How to register your assets on AH
Supporting paying fees in DOT but still have economic incentive for native XYZ token.
Open Question - What should be included in the cookbook?
Overall the sentiment was that there’s been a gap in the documentation, the wiki and the raw rust docs.
The XCM cookbook is definitely needed and the more that goes into it the better.
Linking this back to an earlier discussion about debugging, there needs to be an official and clear way to debug XCM messages.
There was also some discussion about potentially adding typescript code into the doc’s.
Action Items to consider
Overall the XCM Workshop was a great success, we’d like to extend a huge thank you to our XCM Experts @francisco.aguirre & @acatangiu for putting their presentation together & hosting the workshop.
We’ve included some action items below to consider, these points are only a guide & we encourage you, the community, to help us build upon what was discussed and come with some actionable recommendations for the teams.
- Contribute with tests to the ecosystem tests
- Participate in RFC discussions and proposed more RFC’s
- We want to engage the teams and community to actively participate in the RFC’s, at least reviewing and approving the ones you want
- Help needed, and community contribution encouraged regarding the XCM cookbook.
- Help needed with written examples for what should go into the cookbook
Please stay turned throughout the week & check out the polkadot-summit tag as more discussions and workshops will be released shortly.