Enabling Cross Chain Assets on Moonbeam with XCM Stephen Shelton; Kevin Neilson

so steven and i are super excited to be here today and talk to you about enabling cross chain assets on moonbeam with xcm if you'd like to follow along with the slides you can do so at bit.ly xcm 2022 so first let's start with an introduction to polka dot so the philosophy behind polkadot is that there are many best blockchains that they specialize in doing something really really well and that if we can find a way to connect them together such that they can be connected in a secure and scalable manner then perhaps we can have an ecosystem that's a lot more valuable than the sum of just the parts and the way that polka dot achieves this is through a a relay chain you can think of this as the layer zero the job of the relay chain is to control the security of the overall network to manage governance functions and to determine who gets to run a para chain uh on top of this so pair chains are scarce resources they are limited so we need to be able to determine um the right block chains they can run in an efficient manner and so the relay chain actually has somewhat minimal functionality so you can't run smart contracts on the relay chain uh you have to do that on a pair chain and so any functionality that's not kind of directly implemented by the relay chain that's delegated to the pair of chains and so pair chains are these specialized layer one block chains as an example um these blockchains specialize in things like privacy so manta network uh you have blockchains that specialize in identity like kilt and you have blockchains that specialize in smart contracts like moonbeam and all of these pair chains have their own collator nodes these collator nodes collect transactions uh and package them into blocks and then they submit these blocks to the relay chain to be finalized now polka dot relay chain has its own set of validators and what they do is they verify that the state transitions are valid in these blocks that are presented to them and if they are then shortly thereafter these blocks will be finalized and xcm is the technology that links all of these pair chains together and we will get to that in just a moment but first let's do an introduction to moonbeam so moonbeam is an ethereum compatible smart contract platform on polkadot our goal is to be provide the most seamless development and deployment experience for ethereum devs and enable you to gain access to the rapidly growing polka dot ecosystem moonbeam is built with substrate which means that its underlying architecture is quite a bit different from ethereum but the developer experience and the end user experience is quite familiar and quite similar and again we have interoperability that's enabled by xcm and that's the reason we're here today and we're so excited to talk to you about it so with this diagram here you can see that at its core moonbeam provides an evm but we provide much more than an evm we have a fully built out web3rpc and you can query it with the same requests that you would an ethereum node the only minor differences are with things like difficulty which don't make sense in moonbeam because moonbeam is a proof-of-stake protocol and one of the key features that enables moonbeam's seamless ethereum compatibility is our unified account structure so typically if you're trying to deploy an evm pair chain on pokedot you'll need to maintain two different sets of accounts or the end user using your chain will have to maintain two different types of accounts that's because polkadot uses a different type of address to ethereum's h160 and you're going to need an ethereum address to interact with smart contracts in the evm and you'll also need to have a polka dot address to do substrate native functionality such as interact with governance and staking and these two different types of accounts require different private keys and so for the end user this is confusing and managing these different accounts and figure out when you use them where so instead what moonbeam did is developed a unified account structure this was a huge uh and complicated you know early engineering task but it's a bet that's paid off because it's made the end user experience much much better and it's also enabled a number of developer integrations so all the tools that you're familiar with all the development integrations that you're familiar with working with they're all available for you when you come and build on moonbeam allow me to introduce xcm so xcm is a generic message format specification it is uh not an app it's not a protocol it's all it is is a spec for composing messages and it used to be called um well xcm it used to stand for cross-chain messaging um but now it stands for cross-consensus mess messaging and the reason for that uh is to indicate that we're not just trying to communicate between like chains we're trying to actually communicate between chains that could have entirely different consensus protocols so that's what xcm stands for and xcm is extensible so it's not opinionated at all it's very very powerful you can do a ton with xcm it's really really cool but because of that when you're composing these messages you have to be somewhat deliberate and somewhat explicit about exactly what you want to do so it can compare it can appear complex right but moonbeam does a number of things that actually makes this a lot easier for the developer which we'll get to later xcm is forwards and backwards compatible which is really quite interesting when you think about xcm like any technology it needs to be able to evolve it needs to change but we can't just break the existing use cases that are already out there and so part of the way that this is accomplished is by always specifying an xcm version in the message that you're sending so the receiving chain will see the first part of that message is typically that version number and then it will know how to interpret the rest of the message and then it will know how to act on that xcm instruction xcm is also lightweight and efficient so it's designed to run in an on-chain environment it's designed to work on many different platforms and it's designed to run in an environment where execution resources are metered or it could run in a fee free environment before you can send an xcm message you need to first have an xcm channel set up so these channels they're one way they have a set origin and a set destination so if you want to have back and forth communication you need to set up two different channels and the way that channel setup happens is you have a request that's made by the origin chain which is then accepted by the destination chain and here we have an example this is the new polka dot logo at the top right below vertical message passing and vertical message passing is when you're passing messages between the polka dot relay chain and a pair of chains so we call it vertical right because the um the relay chain is at the top and then you're passing down to a pair chain and then on the right we have cross chain message passing or xcmp and right now this is what the structure looks like so if we want to send a message from moonbeam to another pair chain the message will first be routed up to the polka dot relay chain and then it will be sent down to another para chain now in the future this actually might change and you can have direct pair chain to paratran communication just a single hop but for now in all the polka dot ecosystem everything goes through the polka dot relay chain i want to introduce the concept of a sovereign account and give you an example of how the sovereign account enables trustless transfers in this example from polka dot to moonbeam so a sovereign account is a very special type of account it does not have private keys and funds can only be transferred from it via xcm instructions via valid xcm instructions and so as an example a use case really let's say we want to send dot from the polkadot relay chain to moonbeam we would first send that dot to moonbeam's sovereign account on polkadot and then shortly thereafter a derivative xcdot asset would be minted on moonbeam and there would be some bookkeeping on the moonbeam chain to keep track of this balance in the sovereign account now the really big thing about the sovereign account is that this is similar to it's a sovereign account right it's not owned by a single entity it's owned by the pair chains owned by moonbeam and it can be verified right so users can be assured that the xc dot is actually backed one to one in a manner that is trustless and it's very powerful because we're not relying on any third-party entities and continuing with the prior example right this is a similar diagram but if alice wants to send a dot to moonbeam she first transfers the dot to moonbeam sovereign account and then those xc dots are minted on moonbeam and vice versa if we wanted to go backwards charlie first has to burn these xc dots this is done via the substrate assets palette so we're not just sending to a random burn address and then a message will be received by the moonbeam sovereign account and xcm message which will then transfer the native dots back to charlie and finally for my part i want to introduce xc20s and xc20s are really cool new asset type introduced by moonbeam and these are substrate native assets that are natively compatible with xcm but they're also indistinguishable from erc20s they look they feel they behave just like erc20 so what that means is that they're accessible via a precompile and this precompile handles the erc20 interface to the substrate asset conversion so into the underlying substrate asset but all of this you know when you're integrating this into your defy applications all of this is indistinguishable from a typical erc20 so it's extremely powerful next i'm going to pass it along to stephen who's going to talk about xcm architecture all right thanks kevin so i'd like to dive into what makes uh what goes into an xcm message and how these are handled on a remote chain so an xcm message is really just a sequence of instructions and these instructions are remotely executed on a destination chain in the proper order they're executed by a virtual machine which is custom built for safely telling another chain what to do and it includes a custom instruction set that is purpose-built for safely handling currency execution resources and fees in an untrusted environment on the right you'll see a sample xcm message that has five instructions the first withdraw asset would attempt to take funds under the center's control and place them into a holding register and then by execution would take those funds in the holding register and attempt to purchase execution resources with them you can think of this as paying for fees then transact would take those execution resources and do something natively on chain with them and finally refund surplus and deposit asset will take the unspent transaction fees and return them to the center some sample instructions that this vm supports our withdrawal asset and deposit asset which we saw withdraw asset moves funds held under the user's control to a holding register while deposit asset moves funds from the holding register to a target account transfer asset moves funds held under the user's control to directly to a target account by execution purchases reach purchases execution resources and refund surplus refunds these when they're not spent transact attempts to make a call to do something natively on chain and we'll talk more about this in a minute subscribe version and unsubscribe version requests that the destination chain tell the sending chain about any changes to its supported xcm versions which allows the two chains to upgrade their xcm independently of each other while still being able to talk to each other xcm supports a very flexible fee mechanism fees can be sent in just about any asset so long as those assets can be held in the holding register and are permitted by the destination chain this can give rise to many different fee strategies including accepting only the native token for fee payment this is essentially how most blockchains work today and is the safest thing to do they could accept specific non-native tokens presumably ones which hold are expected to hold their value over time they could accept non-native tokens but perform a swap first before paying fees or perhaps charge no fees at all this might be the case for a project which has multiple pair chains that need to talk to each other let's take a closer look at the transact instruction transact attempts to make an arbitrary call with purchased execution resources to do something native on the remote chain this is essentially limitless in the sense that it could potentially do anything that a normal account could it's entirely up to the destination chain to decide which transact calls are permissible and which ones aren't one potential way this could be used is that in the future it might be possible to invoke moonbeams evm remotely through x through xcm imagine a user on polkadot who has some dot token and wants to use the xyz chain with its native token it could accomplish all this by sending an xcm message to moonbeam along with some dot have moonbeam invoke the evm in order to perform a swap in some liquidity pool and then send an xcm message back to the xyz chain with its new tokens one consequence of all this flexibility is that xcm can be very complicated to use there exists a library called x tokens which has as a set of convenience utilities for using xcm in the simplified case where all it needs to do is transfer tokens this is exposed this is available in development versions of moonbeam and is also exposed as an evm precompile allowing smart contracts to leverage it to briefly take a look at its functionality it supports a simple transfer that operates on just an xc20 contract or a transfer multi asset which works on an arbitrary asset potentially one that is not native to moonbeam itself moonbeam is currently offering two bounties at the ethimber hackathon the first is uh to build a dap that uses xc20s and we break this down into two scenarios the first is for a user that already has xc20s on moonbeam and this integration would look a lot like just using a custom erc20 contract the second is for a user who does not already have xc20s on moonbeam and needs some sort of cross-chain functionality in order to enable them we also have a bounty for using moonbeams democracy pre-compile which would allow a smart contract to interact with moonbeams on-chain governance you can find out more details about these bounties at the top of the slide at the link at the top of the slide here and of course we'd love to talk to you these are some different ways that you can get a hold of us and we will also have a booth at sport sport castle thank you very much