LayerZero Labs 🛠 Sending Cross Chain Messages - Matthew Krak

foreign [Music] and welcome to the super hack layer zero Workshop setting cross chain messages joining us today is Matthew crack who will be taking us through this session and without passing over to Matthew to get the session started here's Jim everybody Welcome in thank you guys for having me super excited to be presenting here for each Global um I'm sure that many of you have seen uh the Bounty that we've got going on for this hackathon so excited to see all the submissions you got going on and with that we'll kind of jump right into it real quick just pulling up my screen here for those of you who are unaware I'm with layer 0 and we're going to be talking a little bit about what Omni chain messaging is and hopefully jumping in a little bit more too with uh just how layer 0 works as a protocol so jumping straight into it I want to give you guys a little background about who we are layer 0 is an open source protocol for building Omni chain interoperable applications when we provide authentic and guaranteed message delivery without sacrificing decentralization efficiency or scalability what does that really mean though I want to jump in today and kind of explain what the concept of omnichine messaging is and how we provide authentic data delivery between not just l1s but l2s as well as optimism base and many of the chains you'll be working on during this hackathon so before we get into layer 0 I'd love to kind of walk you through the evolution of just cross-chain messaging as a service and kind of understand some of the shortcomings of previous Solutions so in the early days of just blockchain messaging you would have data existing on chain a and you'd like to ideally get it to chain B the main ways that you went about doing this for four were usually by having some Central third party take the data that you'd like to move from chain a and then they would write it themselves for you on chain be and this service worked initially but obviously the major shortcomings we had were that you were adding a level of centralization directly into you know the blockchain ecosystem and meant that you couldn't really verify that data integrity was being upheld and it also left a lot of systematic risk for the projects that were using this service once we kind of realized the issue with third parties and you know jumped in with some of the core principles for blockchain and try to build around that we came up with a solution of middle chains a middle chain was basically a chain that sat in the middle of chain a and chain B and try to preserve some of that ledger technology so that there wasn't a central third party that was responsible for relaying data the major issue with a middle chain solution like this was that one sometimes the validator sets are very limited so you would have potential for there to be false information broadcast across the network and the second issue is that even though you interest a new chain you didn't always guarantee that that chain was decentralized well enough to actually be able to preserve data Integrity some of the major risks that you you know really brought up in this solution were there's a lack of decentralization you were often forced to accept whatever that middle chain security profile was so if that meant that the chain had upgradable contracts you were forced to use those upgradable contracts regardless of whether your app wanted to or not and you were basically giving your app Security in the hands of this third party which in the case of many exploits led to systematic and uh contagion of risk that happened across the ecosystem uh you can think of the Ronin hack for example that happened with axi infinity as a clear-cut example of this so clearly this solution isn't scalable ideally the best way to improve Sending message data from chain a to chain B would be to have a way for you to own your own app security essentially being able to ensure that the data you're sending from A to B is one valid two not being changed in flight and three not able to be rolled back and that's kind of what we want to talk about today with layer zero if we were going to provide this solution how do we achieve it I think the first parameter you would need is that this would have to be a permissionless technology you would have to allow anyone who's anyone to build on top of the protocol the second feature would have to be immutability you would need that this solution have one the inability to change over time so that apps that had previously accepted a security profile wouldn't be at risk of a new update coming along and three this messaging protocol would have to be censorship resistant right that data would have to be able to be transmitted from A to B in every possible case and not have a third party potentially come in and block the flow data so how do we actually go about achieving this level of security that I talk about now the traditional approach like we outlined is you would have an off-chain entity sitting between A and B relaying that information but the problem is that with only one off chain entity you have susceptibility to that off-chain entity line right there's no way to confirm that they're going to tell the truth every single situation and every single time ideally if we had permissionless technology we could have multiple actors running their own off-chain security and being able to actually validate against a set of other off-chain providers what the validity of that data transfer is Additionally you would be able to own it and run it yourself if that was something that you wanted to do the second piece that I talked about was that we need to make sure that this data flow is not mutable we need to make sure that data being sent from chain a to chain B is not being changed when it's sent in flight and this is something that comes up a lot when we talk about cross-chain messaging if let's say that I'm confirming that I want to purchase tokens on a destination chain and I pay for them on the source how do I make sure that data is being sent through so that I actually receive at My Chosen wallet address for example right those tokens we need to make sure that this can't be changed once the message is sent making it immutable the final thing that I talked about was making it censorship resistant right traditionally if you had this third party entity in the middle the way that they would go about messaging was potentially prone to censorship you could cancel messages before they were delivered and actually logged on Chain by your destination blockchain uh ideally we need to use Smart contract enforcement to ensure that these messages that are being sent from chain a to chain B are always going to be delivered and not blocked or removed by potential failures of the system or the protocol so with that out of the way I'd love to kind of jump into layer zero and how we tackle these three prongs of security the first thing I want to outline is how layer 0 actually works from a technical level so we use Smart contracts that we have named endpoints as a way for transmitting this information from A to B all the layer 0 endpoint is is a set of immutable non-upgradable and that's the keyword smart contracts that handle transmission validation and receipt of transaction message data from a source blockchain Network to a destination blockchain Network and this case as I've outlined you could potentially send an endpoint on optimism and it would be connected to any of our other endpoint contracts across all other networks that we support for more information on this we'll definitely jump in and make sure that you guys understand it but from a high level this is the basis for layer Zero's protocol this endpoint to endpoint communication walking through a little bit more of how the user flow Works user applications are contracts that you're deploying yourselves so for all you hacking you are the guys who are building these user applications what we allow through the layer 0 protocol is essentially to specify in your user application using the data patterns that we've created or design patterns I mean is to specify what endpoint you're communicating with whether that's on chain a or chain B and then sending a configuration of not only your security that you want through this message Library called our uln but also being able to determine for example let's say how many block confirmations a transaction should wait while it's being routed or what security period I'd like we really want to make sure that you as a developer have the maximum level of configurability possible in order to build your application and that's something essential to layer Zero's protocol from here we have the Oracle and the relay repair these are two independent off-chain entities that we talked about earlier that are able to essentially vet and make sure that the transaction info sent on chain a is going to be delivered to chain B walking through a little bit of like a user flow you would send a message from your application which would be read by the endpoint and forwarded along to your message library of choice we would emit that message off chain in our Oracle or relayer would be listening you as an app developer could run your own relayer or choose what Oracle relayer pairing you want to use and the important part here is that these are two independent entities you would not have to rely on a single configuration of an off-chain entity in order to ensure that your message was going to be passed along from there on our destination side that message is picked up we confirm independently from both the Oracle and the relayer both a block header and a proof confirmation that basically ensures that the data has not been changed intermittedly while it's being sent before finally forwarding that message to our endpoint in our user application so I've gone through a lot here maybe a little too fast but just to overly or give a quick overview of what I've just said the whole point of layer 0's protocol is to ensure that the messages you're sending from your source application to your destination application are preserved through immutability censorship resistance and guaranteed delivery at that destination all through a process that you as a user are able to configure and predict that way you don't have to opt into any of those unnecessary updates all create updates that are outside of your control or potentially fall victim to security vulnerabilities in future patches that's the big group so moving forward to a couple examples that we can go through the major example you could build out in this hackathon is an oft an omnichane fungible token using that previous system that I talked about where you send messages from chain a to chain B you could send a message from chain a to burn a token and then mint that same token on network B using a contract that you've deployed from chain a and chain B this effectively allows you to now have a unified liquidity through your smart contracts where they are controlling the existence of tokens on chain air or chain B and where you still own the contracts on both networks looking in the chat really quickly uh yeah so actually that's a good question so similar in the sense that we have an oracle here in our our setup but you could choose a chain link Oracle there are other Oracle providers that you could allow the main idea of the Oracle and relayer setup is that you can choose essentially any parameter for your security or run your own security if you want to as well that's listening to those messages emitted on chain a and then relay the chain D you have more control basically over that security configuration um an example really quickly of how this might work in practice right let's say we have an erc20 we've deployed on ethereum already you could deploy a second contract called proxy oft which is inheriting our layer 0 library that we have already this contract would communicate with our endpoint on ethereum and enable you to use the same process I outlined before this burn and mint functionality to then burn or store a transaction from your era C20 on that Source chain and then mint a new token on optimism or on base wherever you'd like it to exist that has unified liquidity because your smart contracts are connected together you wouldn't have to worry about the erc20 token potentially falling victim to a wrapper attack where someone wraps your token and then you lose control over the actual asset itself you would basically have straight control over your asset's existence on all Chains It's deployed on this part here should say optimism or base but you can also Deploy on our original monaptos if you want to too uh really quickly I think what might help cement this a little better is let's actually jump into the code demo really quick so jumping over to my Redix remix IDE this is simply 50 lines of code if you exclude the comments and I'm going to have this repo posted for you guys both in the Discord Channel as well as I'll drop it in here as well too but the general idea is that you can deploy exactly that comment you can on my own Layer Two with OP stack yeah so I believe we have support for the op stack Library you might have to deploy your own endpoint uh or have us help you with the endpoint deployment there but the general idea is that you're able to essentially deploy across any of the supported endpoints that we offer currently and have that asset move uh uniformly based on your own security parameters there this contract is relatively simple all we're going to do is store a string on our source chain and then deliver that string to our destination all using one transaction call so again I'm going to put this GitHub repo out here with a full tutorial that you can read through if you want to follow along by yourself but really here's how we're going to deploy this contract this is your user application inside this Constructor argument I've outlined the address for a layer 0 endpoint and we're calling this non-blocking layer zero app that we have as just a design pattern right currently I'm on Gurley East and what I'm going to do is take my Gurley East endpoint address which I've mapped here and just basically tell my user application that hey this is the end point that we're going to communicate with on our source chain I'm going to hit deploy wait for the metamask from Hit confirm and then you should have a deployed contract pop up here at a moment and we're going to do the same thing again once this deploys let me just pull up here and make sure we're going Curly's a little slow there we go we're going to deploy the same exact contract only this time on optimism Gurley so we switch over in this case because I'm on optimism now I'm going to use our optimism Gurley endpoint address deploy here I'm going to cancel that and actually send it again sometimes we have a weird thing where estimated gas pops up with that error but it doesn't actually matter so while we're waiting for this there we go way faster we have two contracts deployed one as our source contract and one as our destination contract we're now going to link these contracts together in order for them to communicate it's very simple how we do this process we have this fill function here called set trusted remote all we're going to do is specify what chain our address is on uh or sorry what chain are destination contract is on and what that destination contract address is this is just a design pattern that we've set up to make it where your apps are natively able to communicate with each other and you don't have to worry about filtering any of the other messages that may be sent from other applications looking to communicate with your contract so since we're already on our optimism chain let's actually just copy this top contract address we're going to hop into our contract that's now deployed on optimism head over to set trusted remote address we're going to paste our girly contract and we're also going to take our layer 0 chain ID for Gurley paste it into our remote chain ID these are just chain IDs that we've specified for layer 0 endpoints because they're different than the actual blockchain IDs that we have natively for like wallets and then hit transact you shouldn't need to populate this with any message value but hit confirm we've set our trusted remote on optimism awesome we're now going to do the exact same thing again only this time on our girly contract so just switching back over to Gurley popping in to set trusted remote we are going to take our now optimism contract address paste it in here as well as our optimism destination chain ID paste in hit transact confirm and now essentially your contracts are linked together there are a few extra settings you have to go through for oft or onft deployments but if you're using our default adapter parameters in some of our default configs this is really the bulk of the work you have to do to start being able to send cross-chain messages so from here the last thing I want to walk you through is how do we know how much gas we have to pay when we're sending an on the Chain transaction well if we go down to our estimate fees function here relatively simple function we're again pulling this from our design pattern that we've already set up for you in our GitHub but our estimate fees function basically allows you to take the chain ID we're sending to let's just confirm that we are on Gurley yep so if we want to send from Gurley to optimism Gurley we'll paste our chain ID in here this lets us know that we're sending to optimism Gurley we're gonna then paste our adapter parameters this is something that can be custom customized a bit by you on your user application I'm not going to go into details here but in that GitHub repo I've specified how we actually come about getting to these default adapter parameters and why it looks this way so if you're interested tune in there or check out some of our documentation to learn more from there I'm just going to put in our test message let's say my first Omni chain message right and then hit call and you see here in a way this is actually the native feed that's needed exactly to pay for this message to be sent to optimism including our girly fee our optimism fee as well as the Oracle and relayer fee that's taken from layer 0 infrastructure protocol so we're going to pass that native C into here before we call our send function we're going to pass the same exact message in my first Omni chain message hit transact hit confirm and now you've set your first Omni chain message uh from here we're just going to confirm that it goes through on Gurley depending again on what blockchains you're deploying to as well as congestion at that time it may take a few minutes for it to be recorded uh but the handy thing that we've built for you because we know that it can be a little painful is a test net layer zero scan Explorer so this helps map for you where messages are being transferred to and from and really gives you a good idea of whether or not things are going accordingly to how you plan them in your tested environment so let's just make sure here that this is searching good in the meantime I'm going to hide the meeting controls so I can see this good and then hop back over to Gurley awesome we can see that our transaction was successfully confirmed on Gurley and now it is in slight to uh layer Zero's infrastructure and ultimately to optimism in the meantime while we're waiting for this to go through you can check in here actually it will be switch over to optimism girly again you can see in our destination contract when we call data it says nothing has been received yet this is important to note this shows you that none of this is hard-coded all this is changing live we're seeing that basically What's Happening Here is that we are overwriting this layer 0 receive function when we get that message sent through on our destination endpoint instead of having it say as we say in our Constructor here about you know having an empty string we'll see that once this message gets delivered give it one more second here while we're indexing we'll see this message change on girl eats or sorry on op Gurley to the message that we just sent from ethereum Gurley give it a little more time here but yeah in the meantime uh feel free to ask any questions and I will try my best to answer them for you also see if I can pull up the message controls that I just lost there we go show floating controls there we go this makes a lot of sense yes the message gets stored on chains awesome yeah in the meantime also drop uh this repo that I threw together for you guys as well this will give you a clear overview of actually everything that's happening behind the scenes in a little bit more detail into all the parameters that I'm filtering in uh and yeah what we're essentially trying to prove here is that outside of just being able to send a string right from your source to your destination chain we're really trying to show that you can pass any arbitrary data using layer Zero's protocol and what that means is besides storing strings right on a destination chain you could have a function from any Source chain that you'd like for example call an external contract or call an external function on your destination side this can be incredibly useful for building complex interactions where you want a user to pay on One Source chain to trigger an action on your destination or if you just simply want to take advantage of the bridging functionality and move assets natively it allows you within your own application without taking on any bridging risk to use this functionality yourself how does it prevent message spoofing good question so the two things that we look for going back into our example here we submit from our source chain basically a transaction proof right of what the message is on source and then on destination we're confirming that transaction proof matches with the block header that we have coming through from the Oracle so the ideas here is that we're trying to preserve message integrity that's being sent from source to destination to prevent that message from being switched up if you want a little more specifics on how that works feel free to ping me on Discord and happy to connect you with the correct resources real quick let's check back in here and see if we are moving through still a little slow again message congestion happens if it takes too long for this Workshop I will make sure to ping you and Discord with the configured uh not configured with a delivered message but the idea is here that you basically can now forward messages from any chain you'd like to any destination with limited impact to your application and also with complete customizability on the configuration you're not subscribing to a third-party bridge that could upgrade at any time and introduce a vulnerability you can basically choose your application security settings good so yeah we're in here on ether scan and then let me just double check sometimes indexing is slower than the actual arrival of the transaction but overall I hope this is helpful in kind of explaining how layer 0 works as a protocol and feel free to follow along in that GitHub repo that I've linked how to replicate this yourself and you can see on your own machine or through your own example on remix how exactly these messages are delivered yeah in the meantime let's see if there's any other questions up here if they're like oh can I show an example there are three or more chains yeah so good question if I was going to do three or more chains all I would do let's see if I have any Matic in here actually that would be a good way to figure this out uh or do I have enough police I don't okay bummer no I don't okay yeah the way you would go about deploying to a third or fourth chain is basically following this exact same process I outlined so you would deploy again another version of the Omni message contract you would input for the layer 0 endpoint our endpoint addresses that live uh on that scene you're deploying from so if it was for example uh I don't know base if you wanted to right you would go in and you could actually find this within our repo here I've listed I believe let's see here yeah so you can go in here into our layer 0 documentation go down to base and you would take this endpoint address plug it into your deploy function again or deploy script again right you would hit deploy uh assuming you obviously have gas on base and have the network configured in metamask deploy to base you would have a third contract pop up here you would follow the exact same process I did for sent trusted remote address the only thing is if you wanted to send from let's say ethereum and optimism to base you would have to configure that remote address twice essentially so you would link them all together and have them listed as a remote address that you're trusting and then if you wanted to let's say trigger a function call where I send from ethereum to optimism and then call something on base you would have to use our send and call functionality which you can find more of in solidity examples in our GitHub feel free to ping me though if you are looking to explore that exact interaction let's check here I think hopefully this is done we are doing some major upgrades right now um so there is a lot of congestion on the network and I know that test sets right now can sometimes be a little slow but is there a permissionless way to add extra chains let's say if you roll out my own LP L2 stack so there are ways to go about getting deployments onto other chains that layer 0 hasn't officially rolled out on yet I think that I'd like to connect you with an engineer who can help with that question better I've joined layer zero a little over a month ago so I'm not entirely sure exactly on adding your own endpoint but the whole point of leaders architecture is That's permissionless So if anything were to happen to layer 0 as a parent organization you could have access to all the contracts that we've already deployed on chains roll them out yourself it would take a lot of heavy lifting right for you to redeploy everything but the idea is basically to go through that process in the event of something happening to the protocol right the idea is that the protocol will last long after layer 0 is gone in terms of endpoints I also believe that we are making it easier to roll out on the op stack and other uh what's the word app change yeah can you go back to the link on our slides I was hooked on your architecture sure yeah we can jump in here while we're waiting also guys feel free to stop me if I'm running over time here I know I've been going on uh but yeah I think the question for is if you could post slides oh post flights oh the link the link to it I think I can do that yeah that shouldn't be an issue I can get that actually going into uh our Discord uh let's see if we're getting this through check one more time it's not um and we run out of time here we'll make sure that this gets sent through we've had uh some weird instances where it takes a little longer than 10 minutes but on Main net things are pretty instantaneous and yet while we're waiting here we can also just jump through too if you guys ever have any questions concerns want to reach out to me or anyone else from the team we're happy to help feel free to either message in our Discord channel that we have set up now with super app feel free to jump into layer Zero's own Discord you can follow the QR code here also feel free to ping me directly um I'm happy to answer questions either from Twitter telegram I'll actually throw my uh Twitter handle really quick into the zoom chat here so yeah feel free to uh just reach out if you have any questions if like more clarification on hopefully we get this going through here in a second if not though uh thank you guys for tuning in I hope this kind of gives you a better overview of how layer zero works like I said get a blink uh in the comments currently we'll have that posted in the Discord shortly for you same thing with this block confirmation once it goes through test that's gonna be annoying sometimes and unpredictable but uh I hope this kind of helps you better understand how layers 0 works as a protocol and how you can start building on it today awesome cheers for thanks Matt I mean let's try a wait to see if it could eventually goes through or not it's always when you want it to go through right it doesn't want to go awesome cheers well thanks uh thanks for the great uh Workshop presentation um thank you all for attending uh as well so yeah this was the last workshop for the day uh the opening ceremony is tomorrow and as Matt said yeah feel free to reach out to him on Discord or writing the partners um if you have any other questions yeah cheers guys thanks so much