Cross-Chain EVM Calls by Stephen Shelton

Uh, hi everyone. Uh, my name is Stephen Shelton and I'm a blockchain engineer on the Moon Beam team. Uh, before we jump in, uh, just a quick shout out to my colleague Alberto. Um, he created this content, was supposed to be here today, um, but he won't be in until a little closer. Thanks.

Uh, he'll be in next week. So, all right. Well, what is uh Moon Beam's role in a multi-chain future? So, if you're not familiar with uh Moon Beam, Moon Beam is a uh EVM compatible blockchain in the Polka Dot ecosystem. And if you're not familiar with Polka Dot, Polka Dot's big idea is that instead of having one blockchain that's going to do everything really well, what we expect is to see lots of blockchains uh that do one thing really well or maybe a few things really well.

And so true to this um Polka Dot itself really only does one thing and that is to provide block validation services to child uh blockchains. And so we sometimes refer to Polka Dot itself as the relay chain or layer zero and uh these pair chain or these child blockchains as parach chains or sometimes layer 1. And so Moon beam is itself uh a an EVM compatible um parachchain under polka dot but polka dot does one other thing uh that's very important and that is to route messages uh between parach chains. So it can send so pair chains can send messages to each other. They can send messages to the relay chain.

Relay chain can send messages to the pair chains um all birectionally. Uh oh. Um, loading is not good. Sorry, guys. Having some technical difficulties.

Not sure why we're loading here. See if I can make this bigger. So maybe slideshow isn't working, but um yeah, Wi-Fi might be having trouble here. we can do is uh I've got the slides here. Oh man.

Um well maybe I could just continue with this. I know it's really small less than optimal. Um so um as I was saying uh Moon Beam is a pair chain under Polka Dot. Polka dot um routes these messages. We call it XCM.

And so um uh one of the other things that Moon Beam uh does is uh that it's it's fully EVM compatible like I talked about. So um there are a lot of messaging protocols that interact with it and are able to talk to other blockchains. Um, so this puts Boom Beam in a good position where it can kind of act as a point of transmission and talk to uh not only other pair chains through XCM but also these messaging protocols. So if one of these other chains wants to talk to a uh another blockchain or uh they need to get into the um pair chain or the polka dot ecosystem, Moon Beam is a good point of transmission for that. Um and so as a good example of this um well so moon beam uh also makes available uh this XM feature through uh to smart contracts through pre-ompile.

So a smart contract is able to use um XM capabilities to talk to other parach chains in the ecosystem. And so as a good example of this, uh, Lido is able to, uh, use Moon Beam's XEM capabilities to invoke staking functionality on Polka Dot itself, um, through through their through the EVM. And so it can, uh, invoke uh, staking functionality on Polka Dot and then represent that as liquid staking tokens on Moon Beam itself. Um, and so this provides a a kind of a a much better user experience where instead of having to uh go through multiple steps to stake on Polka Dot, uh, you can just interact with it through Lido itself. Uh, so what is XCM?

Um, well, XCM is really just a a list of instructions. Um, and uh, it's a list of instructions that one pair chain wants to send to another. And these instructions themselves are very granular and uh don't necessarily do anything useful. Um go internet us. Thank you.

Um so these uh instructions are are not very useful in and of themselves. As a example, I might ask you to stand up and that wouldn't accomplish anything useful. But if I asked you to stand up and walk 10 paces to the left and then flip a switch, I could get you to turn the lights off or on. And um this is kind of the idea with XCM. So you take these granular instructions and uh the right combinations of them can do uh really useful things.

So um one fairly simple uh example of this would be a token transfer. So I could send an XCM to get a token sent from one relay chain to another. um and uh vice versa. Uh but maybe a more interesting example is where I invoke uh native functionality on another parach chain um through these instructions and we'll take a closer look at that today. Um so this is kind of what it looks like on Moon Beam.

Um what I've depicted here is uh a user Alice on Polka Dot and um she wants to in invoke some native functionality on Moon Beam. And so uh what we do is we we create what we call a multi-loation derivative account uh which is a way for us to represent Alice on Polka Dot as an Ethereum compatible account ID. Um and so then once we've done this we can invoke whatever uh functionality Alice wants to invoke. Um this working now? Nope.

Bad idea. Um so once we've done that we can invoke the functionality that she's requested as though it came from this multilocation derivative account ID that represents her. Uh and so a more um specific example is um remote EVM call. So uh we can use the same functionality to invoke uh the EVM on Moon Beam from an XM message from another parach chain. Um before we dive into that let's take a quick look.

Um, this is probably a little too small to see, but uh what this is really depicting here is uh a user who wants to send a transaction um to Moon Beam and have it evoked uh through the EVM. And um so this user signs a transaction with ECDSA and sends it to a RPC service. And this RPC service um can then put it into a transaction pool where it can be validated. Um, and if it's a valid transaction, it might be applied through the EVM and we can then see a uh state change occur. Um, so this is all kind of normal normal stuff here.

Now, when it goes through the through XCM, it works a little bit differently. Um, I know it's too small to see here on the right side, but um, basically, uh, the user is going to submit a transaction potentially through another parachchain, and the cryptography could be different there. Uh so we can't make any assumptions that it's ECDSA it could be SR25519 um or there might not be any um any signature at all. So um what this is one of the reasons why we come up with the multilocation derivative account ID um that way we can represent it on our chain in a way we understand. Um but there are also a couple other changes that we'll have to make uh to account for this.

Um however once all of this is done it can then enter the EVM and from that point on it looks exactly like a normal transaction. Um, we finally connected. Hey, look at that. Um, so, um, some of the other differences that we have, uh, there's there's a global knots. So, since there's no signature, it's entirely possible for two transactions that have the same fields to produce, uh, the same hash and cause a hash collision.

And so, um, what we do is, uh, we have a global nons. That way, we can salt every transaction with a unique number. Um also because there's no signature, there is no uh EC recover. Um so uh what we do instead is we take this multilocation derivative account ID that we talked about and we substitute it in the from and the message sender um when it goes into the EVM. And then we also do something similar uh with some of our RPC responses.

Uh and then lastly, we set the gas price to zero. Um, and this is uh mostly because we have a different mechanism for paying for fees. So when you get into the EVM, you'll see that the gas price is set to zero. Um, so these transactions can still be queried in the normal way. Uh, here's an example of a curl call that's just going to call get transaction by hash.

And uh, such a transaction might look something like this. So in this case, we've replaced the from with the multilocation derivative account ID that we talked about. Uh, we've replaced the gas price with zero. Um, and you'll see that the VR and S have been set to some arbitrary constants, and that's because they're entirely unusful in this case. Um, so I'm going to walk through an example where we um we're going to invoke a unis swap contract on Moon Beam from Polka Dot itself.

And uh here's a link to a tutorial. It's basically the same content with quite a bit more uh detail if you're interested. So basically what we're going to walk through is uh we've got Alice again here on Polka Dot and she's going to build an XCM message send it to Moon Beam and then when Moon gets this we're it's going to calculate its multilocation derivative account uh to represent her on Polka Dot and then it will invoke the EVM which we'll call the unis swap contract and then we can uh see that there'll be a swap that happened. Uh so to so to do all this we're going to need about four different steps here. Um and so uh basically we're going to take call data that goes to the EVM and then we need to wrap it in a higher level call.

Um and then we need to wrap that in an XDM message. And so uh this is kind of an encapsulation technique. I kind of think of it as layers of an onion. So the first layer of the onion like I said is going to be our EVM call data. And then the next thing we're going to need to do is build up a what we call a pallet Ethereum XM call.

Um and that will result in another layer of call data. And then from there we'll need to head over to a polka dot pair chain uh relay chain and then create a XCM message um with this call data. And then finally we can send it and it will head over to Moon Beam. Um so let's take a look at the first step here. This is um unis swap.

So what we have here is a unis swap deployment on our moon beam test net um along with the UI. And so, um, it's it's worth pointing out here that, um, while this looks a little gnarly, uh, in a real world scenario, you would expect this to be all done pro programmatically, and this would not be part of the UX. Um, but we're kind of doing it, uh, by hand here. So, what we do is we go to the UI and we set up a swap and we start interacting with MetaMask. But instead of sending the transaction, what we're going to do is uh, hit the hex tab here and um, we're going to scrape this data here.

This is the the low-level EVM call data. And so, um, now we're going to dissect it a little bit and replace a couple things. So, uh, here's the call data from the last slide. And you can see that the function selector maps to swap exact ETH for tokens. Uh, and then there's a number of other fields and we're going to replace a couple of them.

So, since we're doing this by hand and it might take a little while, we increase the deadline and we also increase the slippage amount in case the price moves on us. And more interesting we also replace the uh account ID with a multilocation derivative account ID that we talked about and this again represents Alice on Polka Dot. And so the next thing we need to do is uh what we call the pallet Ethereum XCM call. So a a pallet is uh kind of like a smart contract in that it's um it has functions that can be called um and so you can kind of think of it as the same way. So what we do here is uh uh let me explain this UI a little bit.

So this is a a crude UI that um that wraps the low-level functionality exposed by Moon Beam. Uh and you'll find the same UI exists for just about every uh blockchain in Polka Dot. Um so what we're doing here is we create a uh a call to pallet Ethereum XM. We're going to call the transact function and then uh this probably looks a little familiar. The parameters we're going to pass in uh look a lot like a an Ethereum transaction where we have a gas limit.

We have an action that is a call as opposed to a create. Um and then we have a a contract address that we're going to specify a value. And then these input bytes at the end are the the EVM data, the EVM call data that we just looked at. And so now we've we're kind of creating the second layer of our onion. Um we now have call data that represents everything above.

That's the Ethereum XM call um including the EVM call embedded into it. And so now what we need to do is take this call data and move over to uh the polka dot pair chain relay chain um or really our test net version of it. Um and so you see the same UI here, but we are on a different different blockchain now. And so we have Alice who wants to invoke the uh XCM pallet and she's going to call the send function there. And um there's going to be quite a few different fields here, so I'm going to kind of gloss over them.

Uh the first ones here towards the bottom specify basically which chain it's going to go to. So this specifies that this XM message should go to uh Moon Beam. Um and then from here, we're going to build up the list of instructions like we talked about earlier. Uh so the first one is withdraw asset. What this really does is take funds held under the control of Alice and puts them into a holding register, which is kind of a temporary place that exists for the duration of the XCM execution.

Um, and the next one is buy execution. And so that takes uh funds that are held in the holding register and basically uses them to pay for fees. And then the uh the interesting part is the transact instruction. And so um here again you see uh the encoded uh bytes. This is our encoded Ethereum XCM call data that we looked at previously.

So now we've taken that, we've moved over to the relay chain and we're putting it all into inside a XM message. Um, and then uh finally is is deposit asset. And all this really does is is refund unspent fees. Um, and so if Alice were to do all this and hit submit, then uh it would go over to Moon Beam, uh, be unwrapped by the Ethereum XM pallet, uh, and then it would be and then the inner EVM call data would be sent to the EVM that would trigger a, um, call to the unis swap contract. And finally, we can see here that a swap occurred.

So, um, we have our our tokens that were swapped. Uh also of interest is that um we have a gas price of zero although we do still have um gas that was used. So there is a gasometer and it is still uh respected in the normal way. Um and again we can call get transaction by hash to use uh the the normal Ethereum RPC. And here you can see that uh we get a response but the the nons has been replaced with the global nons.

We've replaced uh the from with our multilocation derivative account. Gas price set to zero. Still consume some gas and VR ands are still their their useless constants. All right. Well, um thank you all very much.

Uh sorry for the the technical issues earlier. Um but if you're interested in today's slides, uh there's a QR code at the top right, a bitly link at the bottom left. Um there's a a QR code to to the right for some more Moon Beam related resources. uh and then some of our socials as well. Um also want to point out that we will have a booth next week.

We'll be at uh DevTia booth R. Um I'll also hang around in case anyone is interested in chatting about this and we might have time to take some questions as well. Um, so is this only to make the call to another EVM that's on the par chain or to go? No, it has um nothing specifically to do with the EVM. So, um, it it basically is a way to send instructions to another chain and those instructions can do just about anything.

They could just move tokens around or they could uh query some state on that chain. uh in our specific case we're invoking the the EVM but that is kind of one specific use case of XCM. So XM is very flexible. Anything else? What limitations if any do you see going to say back to Ethereum or even L2s things like that?

Um well uh so XCM is kind of a completely separate thing. So um I think anything you could do with XCM would be uh kind of a different thing. So you could kind of add these things together, but they they don't necessarily um uh overlap in that way. Okay. So for the remote EVM calls, how do you think about those?

Uh so the remote EVM calls that's that's uh another chain sending an XM message to uh Moon Beam and the Moon Beam is going to go in and invoke its EVM. Um and so that could for example interact with a messaging protocol that wants to go to another blockchain uh and interact with it. Um that that kind of get your question does. Yeah. Thank you.

All right. Well, thank you all very much. Appreciate your time.