Cross-chain EVM Calls in a Multichain Future

Transcript

[Music] thank you [Music] all right cool we're live um all right thanks thanks a lot for attending to this talk um this is a sort of we're going to start very generic and then we're going to go down into Moonbeam but the the idea here is it's a little bit of a discussion all right it's not going to be a workshop even though it was supposed to be a workshop but I feel

that you know like coding live it's not really a thing and so I prefer just to create a interesting discussion with the audience at the end for questions so my name is Alberto Viera I do developer relations at mumbim and today we're going to talk about cross chain evm calls in a multi-chain future right um if we think about I mean I guess the first question that we're going to ask is like why cross chain ebm calls are important all right that's sort of like super important uh to address this question first and so um basically if you think about the history of blockchain right so here what we have is time and then on the y-axis there's no y-axis but it's like the number of blockchains if you think about the history of blockchains um it was really hard to build blockchains back

then right you had Bitcoin then Litecoin and then Deutsche coin and then you know ethereum and so on but I mean right now if you think about where we stand today there are over 120 blockchains out there existing producing blogs decentralized and so on right and so there was a shift in sort of like the way people were thinking of like interacting with the centralized Technologies um back then like I said it was really hard to create blockchain saying right now thanks to things like the polka dot uh sorry the cosmos SDK substrate which is like the polka dot SDK and then the op stack you can create a blockchain in minutes and so you know you don't have to think about oh crap I have to program my runtime I need to program the client

side of things I need to program the peer-to-peer Network everything is sort of given to you as modules packages whatever you like to call them and then you got to work on ensuring that your logic is contained with it modules and things and code and so back then you had few blockchains and nowadays you know there are many many names now out there there's just it's difficult to keep track to be honest and so it is kind of clear that the future is both multi-chain and cross chain and actually I had a conversation with a guy in East Barcelona was I was calling the future multicham was like hey buddy you know like vitalik says that multi-chain is like multiple chains within one consensus that don't necessarily understand that there are

other chains with other consensus that's why I added the crossing bit so it's both multi multi-chain and cross chain at the same time so um when when a project says they're multi-chain nowadays right I mean we have an example of sushi swap where they say they're multi-chain what they actually mean is that they're either two type of multi-chain approaches basically okay the first one is it's what we call Centralized deployments in which um you have sort of like okay I have my deployment in XYZ blockchain but I am connected to all these different blockchains and if you want to use my protocol I'm asking you guys to actually bridge over funds to my protocol and interact with my protocol in the

blockchain that I've decided to deploy okay and and this is not great because you have the bridging user experience and security risk and you're also addressing the limited market the limited market beings that the users that are willing to assess the the risk of bridging and and going through the user experience okay the other type of deployments is what we called multi-instance deployments and this is where actually I should have mentioned sushi right so it means you can oh yeah we are multi-chain meaning that we have the same set of smart contracts deployed everywhere and so you're actually fragmenting users features and liquidity right so I mean we know uh the typical uni swap B2 style decks it's more efficient the more

liquidity it has but if you have multiple mini unit swap two deployments everywhere you're just you know you're not being as efficient as you could um you're fragmenting users right you have the the sushi swap Community now being fragmented among 10 12 13 15 20 different blockchains and then you're from mixing what I like to call experiences I mean it is it's terrible when you're like going to adapt and then you have a drop down of blockchain inside this multi-chain deployment is actually you know it's able to to be in this blockchains and then you have 20 to select from and like what what is that right I mean for me if you think about the mode chain and Crossing future it should be that people are interacting with blockchains without even them

knowing that they're they're doing it right I was at eat Bogota last year and then the hackathon there was a project uh called No chain or actually in Spanish and and um there there were there were a wallet that wanted to sort of abstract the idea of blockchain it's like you would have 100 uscc 100 usct without telling you that they were like in 10 different blockchains right and if you saw an investment in strategy let's say in XYZ blockchain they would internally do cross stream calls to ensure that your funds would move to this one blockchain and use that investment in strategy or whatever it is and that for me sort of like in my head the The multi-chain Crossing future that we should be targeting right because we're not going to onboard you know the next 100 million

users or whatever with 20 different blockchains telling them to move funds around that is not a great user experience and so with that uh we introduced the idea of something called connected contracts um it's it's just a fancy name marketing name it's nothing specific or bounded to mumbim chain link actually started talking about the same idea when they were actually they launched ccip like this week or something but uh they were start they started talking about the similar concept and the idea of connected context is that you should be able to reach any user any asset or any service from whatever blockchain you're interacting with without understanding all the complexities that are happening behind Okay so a great example of this is a project called Prime protocol on Moonbeam which is still not ideal for

this like gold of end user that we do try to Target right but Prime protocol is it's a protocol that it's deployed to multiple blockchains and it has a sort of like a hub and spoke model all the Hub contracts are deployed on Moonbeam but then the spoke contracts are deployed everywhere what this allows is that for example a user that wants to Mint a stable coin on ethereum but they have their collateral in let's say Avalanche they can lock their collateral and Avalanche and then the protocol would say ah okay basically we are crossing protocols okay so this guy has a collateral Avalanche so I can actually mend the stable coin that it's backed by by you know collateralize basically by these assets in avalanche and the user then can can create can have this like liquidity this new liquidity in ethereum

without even knowing that they use Moonbeam knowing that they send a bunch of Crossing messages they're just worried about the prime is just worried about the user experience that the user is actually you know engaging on and so um the key Innovation that allows what I was just mentioning and connected contracts uh to happen it's called General message passing okay there are many terms for this I like Journal message passing there's arbitrary message passing cross chain bridging whatever you want to you want to call it um General message passing is it's what allows two blockchains to be aware of the other ecosystems right if you think about ethereum ethereum has no clue that moving exists or that Avalon exists or polygon they they're a self-sovereign

chain with their own consensus their consensus only cares about the state transitions that are happening within ethereum they don't care about what's happening on Avalanche at all they don't even know like a contract on ethereum literally doesn't know that a contract on Avalanche exists right and so General message passing allows these sort of like two blockchains ecosystem to communicate with each other and exchange messages there are many ways to do this okay but we'll get to that a little bit later and so basically what what this allows is that blockchain one can say oh crap I mean there's there's some multiple worlds of or like applications built on on blockchain one can are now aware that there is a million users out there on different ecosystems different assets different

Services they can access right so think about for example um I don't know I have a prediction Market running on on Moonbeam but then I'm a project on ethereum and maybe the prediction Market team on NuMe is great and I want to access that prediction Market service they could do it now with General message passing right so this creates sort of like an interaction between these two blockchains that can now communicate with each other and then exchange services or whatever they want to do and so now let's talk about consensus and crossing and so I'm first going to sort of like generalize the idea of of cross chain and then we're going to go through different sort of means of crossing right so I mean this this few slides are very generalized and then don't I mean don't don't judge me on that but then we'll sort of get more

into it so once again we have blockchain one blockchain two and two different self-sovereign chains that have their own consensus mechanisms right the the sort of like um premise here is that these consensus are robust right I mean they they can they can prove what you know enough bft that that the state transitions that are happening it's it's okay are okay and so basically General message passing what what it does at its core is connect isolated consensus systems like I mentioned before but the way that this they normally do this is that there's a Crossing message on blockchain one this crushing message all it is is it's a contract that states via an event saying hey user a wants to submit this

transaction with this data on chain XYZ okay and it's just going to emit an event that it's still if you think about it that it's still contained in the consensus of one that is not actually communicating the consensus one is not communicating that to another consensus that it's something that is happening on consensus one but then what you add it's it's an intermediate consensus or a GMP protocol that it's in the middle that it's able to fetch that event and understand it and say okay someone on on chain a or blockchain one wants to execute this call on blockchain too and so basically now you have an intermediate consensus layer that it's able to sort of understand this this this sort of ask and then execute it on blockchain too but then I mean look at

this picture right I mean now you have three different consensus mechanisms working together for one cross chain message to to move right and and this is one of the sort of the major sort of uh deal breakers for a lot of progress when they want to do cross chain execution is that now you have you don't have one consensus mechanism of a cell sovereign's chain you have three consensus mechanisms working together to execute a cross chain action and so I think that in my opinion you know a lot of the the the things that are happening right now with bridging and gmps it's it's due to the fact that it's sort of like early stages in how mature this technology is I mean I'm talking you to here and then we were like last week it was all the multi-chain drama right and things like that we've heard about hacks

with Wormhole with other bridging protocols that have happened and so in my opinion it's mainly because this technology is quite immature right now and we need to to be mature enough so that Crossing actions can now rely under in this intermediate consensus without without any issues um I also like compare this to ethereum in 2017 when we when we had hacks at a smart contract level that you know they were happening quite a lot and because right now these hacks are not really possible because we've learned so much of like how to prevent they still happen I'm not saying they're not they're not happening right but but you know it's just sort of like asking the technology matures these things will happen less and less often and so um one thing that is happening here if

you think about it is that there's a verification uh uh step that it's being done right in this case the verification step is done by the the GMP protocol at the middle which is has its own consensus like I said this is not always true but there's a verification of the message that happened on consensus one so that it can be executed on on consensus too and so generally speaking once again it's really hard to speak about all the different possibilities because you know we only have 50 minutes but generally speaking there are two main ways of verifying a verification mechanisms between two block scenes that are talking with each other um the first one and probably the most difficult to understand it's the native verification so this is not the example that I showed you before this is a

different type of verification mechanism and this is the one that it's it's mainly used by Cosmos and IBC the way that this works once again the premise is that you have two separate blockchains that have two separate consensus mechanisms they they are self-sovereign and they don't trust each other why which is the premise of blockchain usually and then what happens is that there is a layer where they're crushing messages moving okay this could be relayers they could be that you know blockchain validators and blockchain one are aware of sorry validators on blockchain two are aware of like messages that are being sent by blockchain one there is a way for messages to move from blockchain one to blockchain two we're just generalizing it like that right but there's another layer on top of that which is called

live clients this is one example of native verification it's not the only one that is the one that is mostly used which is with light clients right I like the clients what they do is that blockchain two it's running some sort of client that it that it's the the only thing that this client is doing is providing the minimal things that it needs to check that the message was sent on blockchain one so it's not running the entire consensus name entire network the entire state is just running the a thing that is a slight as possible light client um of blockchain one to ensure that the the thing that happened on blockchain one actually happened and was finalized okay um like I said this is how Cosmos usually works with IBC

when you have two blockchains and Cosmos that are doing IBC cross chain they're running like clients of each other checking everything that that happened um I'm not an expert by the way in Cosmos or anything so I might be saying some things that are not right but I think generally this is how it works um this is this is a problem though if you think about it this is not really scalable right if we're talking that there's going to be I don't know if I mentioned it but there's like over 120 blockchains right I mean if you're thinking about one blockchain communicate with 10 others it means that they have to run like clients of 10 other blockchains but now scale is to 100 to 200 it's it's really hard to scale these Technologies like that the other type of external verifications what I actually showed you before uh

basically do you have an intermediate notice that in this case you don't have an intermediate consensus right why is that because blockchain too it's kind of running the consensus of blockchain one okay and so in this case now you have an intermediate consensus that acts as a relayer but also verification layer of the things that are happening on blockchain one okay so in this case now you're trusting this middleman this this party and that's how a lot of these like bridging protocols work nowadays this is this is way more common than native verification uh why is that because this is really more scalable as well if you think about it all that needs to happen is that this GMP protocol needs to be able to support all the different blockchains right and that's why you have for example protocols like Wormhole and XLR and and

layer zero or whatever like they're supporting many many different chains right because they can adapt their Tech their their client in the middle to sort of support all the the different protocols so cool um hopefully this is this is a little bit clearer actually optimistic Bridges which is also very famous um especially in l2s nowadays they they actually use external verification as well uh it's a little bit different because an optimistic bridging you're just like submitting a transaction and hoping uh you're saying optimistically I am actually telling the truth and if someone proves that I'm not telling the truth it will escalate and you might get slashed depending on how it works but you're relying on an external mechanism to say if something is valid or not cool

um so let's go through some examples of like cross stream protocols so we're going to talk about three because like I said there's like a gazillion so it's really hard to like you know to discuss them all a lot of them are actually variations of one one or the other uh they're also like CK ones but at the end of the day they're either native normally external or native verification mechanisms so the first one we're going to talk about it's axolar so axelr um basically they connect they're a cosmos SDK based chain proof of stake they have their own consensus mechanism like like I said based on proof of stake in which I think they Implement slashing if any of the validators does something malicious that might not be true but maybe I think it

is actually and so what happens is that apps and users on any of the blockchains that Axel are support they can interact with the Gateway contracts right and the Gateway contracts basically is like the middleman contracts or the intermediates between the apps and the users and the axolot protocol so generally speaking what happens is that you have some events that are emitted by the Gateway contracts and then the the validators of the axlr blockchain let's say they pick up these events they then discuss between themselves they sit in a table and say hey guys is this valid or not via NPC and other mechanisms and so basically they approve the message and then they get executed via relayers back to whatever blockchain that message was destined and then through the Gateway contract and to the end user or application more or less okay

what's important to understand once again is that this is normally what changes right the the consensus mechanism of the middle is what normally changes in external verification uh protocols like axler um axillar Works a little bit different as well in the sense that um if you want to send let's say tokens from ethereum to Moonbeam they actually will provide an address that you need to deposit this this funds to right so like I said the the nitty-gritty of each protocol is very very unique to themselves but the the general idea is normally this okay another uh very famous bridging protocol is called layer zero uh the way that I see layer 0 it's like a mix of light client technology with like oracles and

relayers so it's not native verification it's not fully external verification it's a little bit of a mix at least in my opinion and so basically what happens here is that you have apps and users that are interacting with what it's known as layer zero endpoints it's like axelr Gateway contracts just a different terminology and then these layers your endpoints kind of emulate something they called marketing name ultralight notes okay so the ultralight notes all they can do it's it's verify that a state transition uh happened on An Origin chain but they need external information they're not running like like clients they're not running the latest States hash and proofs and headers and everything of the other blockchain they

need they need the information to prove it okay so that is the main difference between ultra light notes 10 light notes at least from what I understand because this is like you know you got to understand like they're like a million bridging protocols so it's really hard to be a master in all of them so um so how this works is basically the layer zero endpoints On the Origin chain will you know basically the user will submit the transaction that they want to send and then the ultralight notes or the endpoints will basically tell the oracles and the relayers there are two components of security here that they're separated so instead of having one only consensus mechanism that is controlling everything now you have like two separate consensus right you have things called oracles and things called relayers and they cannot collude if they

collude layer zero security is sort of like thesis gets broken basically okay so ideally right if you use oracles as for example chain link as oracles chain link should be robust enough so that they they will not cheat right that's that's the whole premise and then basically the oracles will submit the block headers to the ultralight notes on the destination chain remember that I said that ultra light notes all they can do is proof it's validated the proof right and so basically by the Oracle submitting the headers and then the relayer submitting the transaction proof that can actually say okay this transaction is valid so I'm going to execute it under destination chain so this is a very quick summary of how layer 0 works and

um basically like I said this is like a mix of native external and a mix of native and external verification because it's using a little bit of the concept of like clients but it's not really like like clients like I was showing before and and then the cool thing about layer 0 is that you can choose as an application your own Oracle and relayer so you can actually run a POA so hey I trust my own Oracle and my own relayer that I'm running I can do it the problem is that you know if you you set up your Oracle and relayer and then for whatever reason they get compromised you are screwed basically so it is sort of like you can choose which is good but sometimes it's not good it just depends on on the security premises that you want uh I'm recycling a lot of the images as

you can see so this is now Wormhole uh Wormhole is is once again generally speaking similar to like external verification protocols in which you have now Wormhole contracts apps and users Wormhole contracts and all they do is is talk to what they call the Guardians the Wormhole Guardians okay so Wormhole Guardians are kind of like a proof of authority consensus in which they have really you know validators who have really good reputation in the in the ecosystem and so basically all they have to lose is sort of the reputation and and so basically I think they have 26 or 28 validators and so basically now the validators will say hey this message is actually valid but you know they they don't do the anything else they just say

hey this message is Valley a ballot and it's ready to be executed in whatever chain this message will be executed on and so now what happens is that a relayer needs to grab that message that it's uh it has like a baa what they call a Vaas like the proof that the message is valid and they go to the Wormhole contracts on the destination chain and then the Bea gets actually verified by the Wormhole contracts and then you can execute the message okay once again this is a very clear indication of external verification because you have an internal external consensus that it's it's sort of like you're trusting that consensus to communicate your two blockchains okay so um if you want to learn more uh to be honest this document it's it's really

helpful to understand Bridges and they have this is a uni swap Bridge assessment uh document that they release I think two months ago maybe um in this document they they were sort of thinking about what cross stream protocol they wanted to use for unisoft deployments that exists out there and uh and they their state this this is their opinion that's not that I share it or not I just don't want to be put on the spot but basically the unisoft decided to go with Wormhole and with axelr further Crossing deployments um they had really good comments on other Bridges as well and they will consider them as long as they make some changes and so on but it's really good because they provide a really high detail they provide a summary of how all the bridges work our main Bridges work and then uh uh no the details on like

the downsides of some and then the upsides of summon so it's really it's a really cool document that is really well summarized but this is like I said the opinion of the committee that worked on unisob on the bridge assessment side so um before going to this side I want you to remember the external verification slides right that you had three consensus mechanisms and then now you had to trust that any of the consent if any of these three consensus break the whole crashing premise basically it's broken okay it gets broken so let's talk about polka dots and Moonbeams crashing calls so I don't know if if you've forever heard the song Polka Dots and Moonbeams that's a Frank Sinatra song back in the day that's where the mummy name comes from uh and so yeah let's

talk about crushing calls and how it works in the polkadot ecosystem because if you don't know moomim it's it's a it's a blockchain inside the polka dot ecosystem and so I mean I think this image speaks by itself but but basically um in the xcm architecture of polka dot in the cross chain architecture of polkadot right para chains which are blockchains in the polka dot ecosystem already trust polka dot for security all right they the parent genes themselves are blockchains himself like moving they we don't have our own consensus we cannot say that a transaction is finalized or it's valid or not we trust on polkadot to give us that finality right and this is a big shift in how things normally work because um when the parent chain a or blockchain

a wants to communicate with pair chain b or blockchain B they're already trusting the polka dot consensus so they don't really need to trust an external consensus to do cross chain and that's that's a big shift on how things work even in Cosmos right Cosmos that's one of the biggest differences when people ask me about the difference between polka dot and Cosmos this is the main difference that I normally tell that this is called in polka dot this is called the shared security and customers kind of understood that this is a deal take it for a lot of people because in polka dot I can build my own blockchain to upload pictures of my cats if I if I want to do that because I'm a weird person and I just like to have my cats my picture of my cats in blockchain and from day Zero they'll be finalized by

the blockchain the polka dot security right while on Cosmos for example I need to create an accountant model that will allow me to secure my blockchain of you know my pictures of the cats right so that's not really that feasible and so the whole premise of polka dot is that these blockchains these participants on the polka dot ecosystem will get security from the polka dot relay chain and so when these pair of chains start uh exchanging Axiom messages you can see clearly see the difference between this and the model that I was showing before right in this case all the participants here are trusting on the same consensus so basically the state transitions that are going to happen on parent chain a or blockchain a are going to be validated by the same

consensus that it's going to validate the state transitions that are going to happen in parachain b blockchain b and so I really love this picture compared to the other one because it clearly shows that you only have one consensus basically checking everything and so this is this actually pretty cool for interoperability and so with that introduction um let's talk about xcm and xcm if you're not familiar this is like the language that polka dot blockchains or para chains use to enter operate internally between between them right so if you think about what we were discussing before on on Crossing calls between axillary Wormhole and everything normally the calls what they have is

basically you need to know the contract that you're targeting if it's an evm blockchain and the data that you want to execute on that contract right that's normally what happens uh token bridging all it does is it's basically wrap these calls into a token abstraction layer in which now the general message is going to be the same but instead of just being that you're gonna just mint go to this contract and mint these tokens and give it to this user right and so in xcm it's a little bit different because it's more generalized it's it's a little bit of the of the outside of the ebm world and so basically evm xcm from a really practical and simplified perspective it's a message with Axiom instructions okay so um if you want to do something you just

don't say one instruction and that's it a combination of instructions will result in a concrete action happening in destination blockchain okay so it could be think about it it could be like hey ethereum I want to buy some of your execution time some of your blog space I want you to grab this call executed on the smart contract and whatever funds are left just just deposit it to this address that is something you can do on xcm because you the instructions that if you combine them can actually do that sort of action and so basically if parenting a wants to communicate with pair chain B pair chain a will execute some instructions on the origin chain and then some instructions are going to be executed on the destination chain and then like I said the combination will result in something

so if for example you want to do token transfers you just grab a set of instructions right you just grab some instructions on Moonbeams some instructions on the destination chain execute them and the end result is going to be a token transfer of let's say dot from polka dot to Moonbeam or something like that you can also do remote execution right you can actually say hey from polkadot I want to call this evm contract on Moonbeam and do XYZ so I actually have for example a demo in which someone on polka dot can do a uni swap V2 swap on Moonbeam right without even having to sort of like go to Moonbeam change the wallet okay let me take my letter out let me plug it in change the wallet here from from this network to this network

and then execute the call that could happen remotely completely I can just be in polkadot you know use my polka dot wallet that I love I don't have to jump ships or everything you can do it from the origin chain which is actually pretty powerful and so in in xcm there's a concept called The Sovereign account which you can if you know about token bridging normally what happens is that you lock the tokens on one contract on one side and then you mint the representation asset on the other side of the bridge right Sovereign accounts it's it's kind of similar to these smart contracts where you lock the tokens but they're actually accounts they're not contracts they don't have code in it and so basically in polkadot if you've never seen this image this is a typical image

of how polka dot looks right you have the polka dot relay chain or the polka dot blockchain which is securing a bunch of of like ships that connect to it and one of them is basically and so this means that for example polkadot has an account on Moonbeam it's a keyless account it doesn't I mean it has a private key but no one knows what it is and basically uh the only way to control it is via xcm actions okay so via xcm messages via crashing messages and The Sovereign account basically is the message sender the first message sender of a Crossing call okay then you can actually change it if you want and so this is really cool because in xcm you can do something that you cannot do with cross-chain evm calls right and

if you think about it right if I am on ethereum and I'm doing a crushing call to Avalanche The Message Center on Avalanche is not going to be me and it's not an account that I control it's going to be someone in the bridge the relay or whatever it is and that limits a lot of what you can do because you're going to create this experience that I was talking about in which you can stay in your own chain and remotely executing some other chains uh you know in like with like a virtual account that you have right um I think you can do something like that with account abstraction but I've never seen like an implementation of this actually live or anything so with xcm you can do that and and the cool thing is that using some special fancy xcm instructions you can actually say

Okay Alberto on Moonbeam has an account on polka dot and Alberto and Lumin has an account on whatever other blockchain and this is the example that I was I was telling you before that I can control I can do whatever action I want on polka dot so I could do staking on polka dot but I can just do it from Moonbeam if an application would be built that you can do that okay so this is once again really powerful because this is completely decentralized and trustless and you can create these crashing experiences that are way better than the typical bridging experience that we have today and so this is sort of the premise of what I've been talking about right now with remote dispatchers is that you know in polka dot you'll have an ecosystem of

blockchains that will offer services all right so for example there's there's a blockchain in polka dot that can do automation it means that imagine you're in a decks right let's say Sushi swap or whatever and you're doing farming and then you want to claim your farm uh rewards and then you want to re-put them in liquidity you got to do how many clicks you know how often you got to do it it's a terrible user experience but on Moonbeam using xcm and remote Dispatchers in your application you could have a little button that says automate this annoying action by clicking here and just signing a transaction and what would happen is that Moomin will communicate to a blockchain that does Automation and then this blockchain will like every so often talk to Mummy men say hey buddy it is time to do this uh farming and then you

do this farming and you put this asset back to this liquidity pool etc etc right so the cool thing about polka dot and the ecosystem that it's creating around this crushing experiences is that you'll have you know moving will be much more than just another evm it will be an ebn that will provide services via crushing Integrations and then all these other services can tap into mum CVM for crossing calls yeah so let's go a little bit into uh cross chain evm calls bixem so we talked about a little bit before about you know Crossing calls generally speaking with Bridges like Wormhole axelr uh layer zero but let's now go through sort of like how this works on on mumbi and so first let's sort of understand at a very

high level how a regular evm call works on Moonbeam okay so and and some of the things actually are applicable to other blockchains as well so you're familiar with the term ethereum compatibility right I mean you have ethereum for sure ethereum is ethereum compatible but then you have Avalanche you have polygon you have a BSC and they're all ethereum compatible what they mean with that is that they have an evm right an evm is a state transition machine that it's able to say I have a state I'm going to execute these transactions and I'm going to calculate a new state um but you also have much more than that um I don't know here if you're familiar but hard hat ether JS metamask and all these tools all they do is provide a

nice interface for users and Developers for the ethereum Json RPC right at the end of the day hard hat or truffle or whatever they're doing a gazillion of Json RPC calls to a client right and the client is able to understand these RPC calls and then it's executing an evm call if it's doing an evm call or whatever and so when a chain says that it's ethereum compatible they have a lot more than just an AVM they have an ethereum compatible client in the sense that when you connect metamask to Avalanche metamask doesn't know that it's I mean it does know that it's Avalanche but what they're actually doing is just sending a bunch of Json RPC calls to this endpoint that it's an avalanche endpoint and the Avalanche endpoint is able to understand the RPC

codes and say oh okay hey this guy is actually asking me for this balance of this account I'm gonna return it and then metamask is able to understand that and display it nicely to the user and so this is at a very high level how this works on mummy it's exactly what I just described so basically you have apps and users that are interacting with what we called Frontier RPC extension so this is basically What receives the ethereum Json RPC callers okay so let's do eat get balance or each send raw transaction or whatever it is and it's able to sort of like translate this into like substrate or like rust the the substrated framework that mumi misspelled on top of so that substrate terminologies or substrate things right

and then we have these modules that are part of Boom beam that each each do something very specific right so the first one is the ethereum model which is going to validate the transaction is going to ensure that the transaction is valid from like a signature perspective whatever it is and so that you know it's not failing because if it doesn't have gas or whatever and then it's going to sort of like send about transaction to the rust DVM so our evm is based on the Sputnik like well is it is it Sputnik or open open rust evm or whatever it is and then you you're accessing our evm via a module called the palette evm or the evm module which is like the the dispatcher to the ebm and now the evm is like a it's like a like I said it's a state

it's a basically a state transition machine in which you provide some inputs and it's going to calculate the output right and that output is going to result at a high level in some ethereum logs right and the ethereum locks is what you actually see uh in the get transaction received or like an ether scan that they just show it in a really nice interface and so on but basically this is really straightforward because you have a user signing a transaction with their private key that it's interacted with Frontier or whatever RPC client you're using and then this there's then with some magic you get to the evm and then there's some logs okay now when you're doing uh remote calls via the xcm remote evm calls via xcm it's a little bit different because

um the the signature happens in a completely different chain right it could be a completely different consensus mechanism they could sign with only uh you know fruits or whatever you don't really care how like their consensus mechanism is but then when the xcm call arrives on noon beam you got to be able to dispatch this call to execute it on the evm right and so the way that this works is that there's a new module called ethereum xcm module that it's going to check that transaction is valid before executing the evm one of the key differences here is that the signature happens on the origin chain but when it reaches booming the signature has no validity basically we cannot say how we interpret this this signature because

like I said it could not be using ecdsa maybe he's using sr25549 which is what subtrade uses right and so we have to forget on we got to forget okay the signature doesn't really care how do we make this transaction valid and this is via xcm instructions so there's an xcm instruction like I was showing you that it's gonna it's it's able to create a new account on moomim that it's a keyless account so we don't know the private key if we don't know the private key how do we sign this transaction we don't really sign the transaction because we know that this trend this this account that we generated we calculated it's coming from a signed trans account a sinus intrinsic or science transfer On An Origin chain so

the only way that we can calculate and we know what origin chain is in polka dot everyone Every Chain knows what the other chain is basically by like a chain ID which is called the parenting ID and so we can know okay this transaction right here was signed by Alberto on parachain XYZ and if I hash that it's not exactly that but if I hash that information I'm going to calculate this new account okay and so it is non-reversible and there's no way that someone can impersonate another person because if it's not me signing if it's him you know the hash will result in something else and so now this new account is going to be the one that is going to be the message sender now but it has no signature okay so the

signature the vrs value are like 0x1 0x1 0x1 and this actually creates a funny situation because if you don't have a signature you can have transaction hash collusion because a transaction hash it basically uh the hash of the signed transaction all right and the the uniqueness of that is the nons and the actual signature and so that's why remote evm calls have a global loans meaning that you can only do maybe it's a un256 so there's a limit on the amount of remote VM calls you can do but I don't think we'll reach it in a very long time and so basically now we skip the validation because the validation happens in the ethereum xcm module and then everything else is the same now you're calling the evm and then you're gonna you know execute the call

you're going to get a new state and then you're going to get some ethereum logs um I didn't show it because of of space but fun thing is that when you get the receipt here you will see that the transaction signature is 0x1 0x1 so it's really dumb you cannot do easy recover for example and that the execution it's free because the X you pay you pay the evm execution at an xcm level when you're executing the xcm not you're not paying at an evm level so when we access the evm here basically the gas price is zero and so you're not paying the evm is not charging you for the execution because you were already charged beforehand okay it's kind of like a the two main differences I would say

and so with this premise I think I have a lot of time still but with this premise um the main idea is that moomim can access as a port of call in and out of the polka dot ecosystem right so you have blockchains like I was saying before the future is multi-chain is cross chain and so how do we how do we communicate I mean how would you do Crossing Integrations that are seamless and and super super nice I mean it's it's a developer's job to do that it's not easy but if if someone in the ecosystem of polka dot wants to access assets and services on avalanche on Cosmos on on ethereum on BSC they can do it through mumbi because we offer seamless ethereum compatibility we're connected with all the major bridging

providers GMP providers that exist and we'll be supporting many more and so you can create this Crossing experiences that are simple for users like I was shown with the example of prime protocol uh but not only that you know you can actually for example move liquidity in from ethereum to a pair of chain in polka dot if they're they need liquidity I'm going to give you two really cool examples of things that happened on Moonbeam like this um one of them is is that uh I don't know if you're familiar with osmosis it's it's a cosmos SDK based chain they're like a DEX that somebody said like that um and they wanted to get dot liquidity right so you're like okay dot liquidity so liquidity from polka dot on a cosmos-based chain how would you do it

polka dot is not connected with any Bridge like they don't have any bridging provider right so how do you do it so basically the way that the guys worked it out with Axel R Us and the folks from polka dot is that you go to a UI you put one dot from polka dot to osmosis you click and that's it it's it it works right and the way that this works is that via xcm you're sending dot to mumbi okay and now you have it as an in you have it as an erc20 this Dot and so now XLR can say okay I'm going to grab the crc20 and I'm going to move it with XLR to the cosmos ecosystem and then once I have it in my Cosmos chain in XLR I'm going to use IBC to move this this dots and Route it to

osmosis so you're talking about three different GMP protocols working together to create a Crossing experience right it's not one it's not two is three but ideally from the user they have no clue that that happened I mean they're just saying I want one dot on osmosis right so that is the main idea of connected contracts that you want to simplify the user experience for cross chain Integrations or interactions abstracting all the complexities out of end users because end users should not suffer or shouldn't have to go to the through the burden of like switching chains and moving for moving around and so on um yeah I think that was the main example that I wanted to give the other example that we're working on right now is not actually live but we're in

testnet is that a lot of these spoke about para chains uh they need liquidity and so for example we have dex's parents that are dexes but they don't have any VM or they're not connected with any Bridges right but in liquidity to work I mean that's the whole point of a DEX right and so the way that this is working now is that we're providing one-click Solutions via wormhole in which you know any Wormhole connected chain will have a nice looking UI that you say I want to for example move one eth from ethereum to the spirit chain and what's going to happen is that Wormhole is going to bring that ethereum to mumbim as an erc20 and then on Moonbeam this erc20 can be moved with xcm to the destination parenting like for example Hydra DX and then it will have they will have

liquidity in Hydro DX and once again this can be done with one click on the user signing a message on ethereum it's not multi-hopping it's not doing anything and there you have two different GMP protocols working together you have Wormhole GMP to Moonbeam and then xcm routing that liquidity to the parity and we call it liquidity that's like the fancy name and so I think that's all I had if you really like the slides I saw some some folks taking a lot of pictures you can actually just scan the QR code and you'll get access to all the images um I mean I think we have time for questions so I'm really open to the discussion right I don't consider myself a crushing expert I want to hear like your thoughts on like cross chain if you think this is the future or not uh here

you have all the things about Moonbeam Twitter handle telegram Discord and the website um and then on the right hand side you have my Twitter I'm not a you know I don't do a lot of Twitter but anyways and then telegram if you want to contact me if you have any questions and things that you want to learn if you want to learn more about moving I'm always happy to chat so yeah thanks a lot for your attention is there any questions any comments any sort of discussions that you want to get going yeah yeah did you need to talk to the mic because of the live stream sorry sir thank you very much for the presentations so as you mentioned so you

will have different concerns use if we you are taking liquidity from uh maybe uh that uh ZK uh hold up or optimism how do you manage the finality with this workflow that is a great question let me let me take a sip of water and I'll get to it so yeah um Roll-Ups are really popular right now right they're they're super popular like everyone is talking about arbitrary optimism and so on and one of the issues that they actually have is that they have two type of finalities right they have soul finality and hard finality maybe there are other names and the feedback that we've gotten from Bridges is that they kind of hate l2s because finality can take up to three minutes right and so it's really it provides a

really bad user experience and also for developers right because for example in the prime protocol example that I was giving imagine you lock your collateral and optimism and you have to wait three minutes to ensure that that transaction was Final there so that you can actually pass the message right so a lot of these GMP protocols that that I've showed they they check for finality they don't check for the transaction inclusion because they cannot actually uh do that you know they need to ensure that at least a transaction is marked as final On the Origin chain so they can actually execute it on the destination chain because they're taking on all that risk like if if for example let's say I move 100 million uscc's I don't have that money I just this is just an example so let's say I move 100 million uscc's from

ethereum to mumbim and that transaction is not finalized on ethereum but Wormhole mins this 100 million uscc's on mumbim and then that transaction never happens it gets reverted or whatever reorg on ethereum Wormhole is the the protocol that is affected right because they cannot pay out for those 100 million uscc's now so remember that bridging tokens is specifically it's like you lock Assets in a contract and you get a piece of paper that represents that you have these assets on the contract so if you print it more pieces of paper that you can actually redeem it's like inflation and countries right I mean you they're going to lose value basically and so um it is it's it's going to happen like l2s are here to stay but they will have

other blockchains as well and there will be caveats in crashing communication for example developers love interacting between Avalanche and Moonbeam because finalities are so small that the the user experience and even the even testing is so much nicer right and so but I guess they'll have to adapt that's why I also like optimistic bridges are actually a good solution because you can have intermediate parties that are willing to take on the risk of saying go for it buddy I mean but mint your your nft your wrapped token on on Moonbeam and I'll take on I fully take on the risk if this doesn't happen right and so I think optimistic Bridges will be a solution for like finality lags on on l2s to be honest but that's a great

question so cool any other questions comments yeah so I mean another thing that I was sort of like discussing uh like a couple weeks ago was was about l2s as well that you know a lot of people think that l2s are going to be the thing and so they're they're working on bridging Solutions on L2 and that's it they don't really want to communicate outside of L2 and that provides a really good bridging experience right because if you if you provide an optimistic original too you can just say go for it the finality is instant and then and then you can actually settle on on ethereum L1 and so I I I'm I think that their solution is sort of like they don't want to deal with this like finality outside and then this like really bad user experience and

they just focusing on l2s and they think that there will be like hops of l2s secured by different l1s but yeah I I personally I don't see that so cool all right thanks a lot and yeah I'll be around if you want to have some questions afterwards so thanks [Music] [Applause] [Music] [Music] thank you foreign

[Applause]