The ABCs of Cross-Chain Messaging with LayerZero - ETHGlobal San Francisco 2024

[Music] uh first we are a permissionless service censorship resistant and immutable why does that actually matter when we talk about cross chain messaging bridging is something that comes up fairly often when you want to move assets from chain a to chain B but do we actually understand what's happening underneath the asset transfer from moving from a wallet to another wallet at at the core Bridge infrastructure is comprised of three different pieces uh the messaging service the function call layer and then ultimately the application that you build um diving in a little bit deeper into how this is a reality when we talk about cross chain you can understand that every chain especially now is starting to Niche down in the specific benefits that they offer some offer Speed some offer cost savings some offer more security than others and when we look at kind of the developer environment today over the last year this is the Electric Capital developer report on the screen in front of you uh you can see that more and more developers are becoming comfortable with deploying on more than one unique chain and ultimately this is needed because of the way that token transfers behave when we talk about token transfers in today's world looking at a simple erc20 smart contract it's relatively straightforward a transaction is atomic where a mapping gets updated from one user's balance and immediately changes the balance of another but when we talk about cross-chain Frameworks that immediately becomes way more complicated because you have these isolated networks that don't know about each other and so to update balance you need to invoke a function on chain a update the state on that chain and then somehow Rel that state change is final to the destination Network before you can actually receive the funds on the destination and if you can see from this flow there's a lot of opportunity for things to go wrong if someone's able to not only manipulate the state change but the people listening to that state um ultimately the way is an industry that we kind of moved around this was with the idea of Monolithic Bridge security the idea that there's some entity in the middle listening to events and you are subscribing to them guaranteeing that you know they will provide that security on your behalf but what happens when that security fails um ultimately not just your application but every application on the destination chain can fall prey to an exploit that falls from verification logic if a verifier is compromised that's reaying messages from chain a to chain B everyone is affected that's kind of why we've seen over the last decade the largest hacks in this entire industry come from bridging related monolithic security failures uh four of the five largest hacks can amount to nearly $2.5 billion in losses and the reason for that is fairly simple you're forcing every application into this fixed channel of security where if that security provider goes down every application is suddenly at risk so for us this is also a really nasty trade-off for the app developer um for the app developer you're forced to make a decision for your app on whether you pick pick point a on the network where every transaction is relatively cheap but insecure or point B where every transaction is secure but expensive um again the major trade-off here for you is that the switching cost is high an app is typically immutable on chain and so if you want to change the underlying security properties you're looking at changing the core contract re auditing and redeploying your code uh that's why I like to say if ethereum can be thought of as a dark Forest I consider cross chain a dark ocean you have multiple Islands of isolated connectivity where if a malicious actor gains control of the Waterway between them that Island faces an existential threat and similarly if your Port gets destroyed you also face an existential threat from the island no longer being able to land uh ships or in this case transactions um going back to this idea of what is the Omni chain Tech stack uh at the very core layer of it is this idea of omni chain messaging the idea that you can reasonably verify that a message has come from a source blockchain and that that state is final uh layer zero enables this by allowing you the application to actually Define what that channel looks like you can control per destination what type of verification providers are used the size scope and type of verification and configure that yourself within your text stack uh there's nothing that layer zero enforces that you have to use everything is customizable the second piece of this is the function call layer the idea that once a message is verified how do we actually deliver that transaction on the destination chain when you think about it if we had to have cross-chain messaging where every time I wanted to receive tokens I had to switch my metamask network and then actually make the function call myself you probably would see a lot less bridging today uh the way that we abstract this is layer zero is we run a executor as a service anyone on layer zero can permissionless execute messages by making the function call themselves but for a service fee our executor will automatically swap gas assets and execute subsequent transactions on your behalf defined obviously by your contract logic uh finally the last and probably most important piece is the actual application what do you define as the state change and why are you initiating that state change to begin with to make it a little bit easier for developers getting started we have defined an omn chain app standard that provides a lot of the common utilities you need in an omni chain app at the base layer and then extend it with two functionable uh contract standards one the oft Omni chain fungible token which is based on erc20 and on nft the non-fungible token variant um looking a little bit high level at this transaction workflow the way that you actually send a message is relatively straightforward you'll Define Farm your application a message that you want to send and it'll be encoded as bytes you'll Define a destination chain and finally this configuration that I mentioned before of who to emit the message to that you want to have verified um from there this message becomes verified out to each of these independent security modules known as dbn or decentralized verifier networks and emitted to your executor of choice once the message has been successfully emitted each of these dvns will go and relay the message to the destination chain which is then enforced by your apps configuration on that destination enforces the block confirmations that were wait waited for on the source chain the expected dvn threshold and addresses and makes it relatively straightforward to enforce this threshold on destination chain finally once it's been verified anyone can then permissionless execute that message through the destination chain which ultimately triggers the state change in your destination app this allows you to relay any type of data any type of assets any type of data and assets um moving a bit forward I'm going to skip through a couple parts here about the configuration stack just so we have a little bit more time at the end but this idea of modular security enables you to not only choose between point a and point B but actually configure every type of application in between using layer zero meaning that you have a lot more flexibility when it comes to security than you otherwise might um also what this means is that as new validation techniques come online applications can easily switch their security stack over to better and greatest practice or keep their config immutable depending on their application needs uh it's very much tailored around what your app is needing and needing to be serviced at that time on the execution side we also enable some separate transaction flows that you can take advantage of in this hackathon uh traditionally when you EX Ute a message on a blockchain this is known as vertical composability the idea that everything in the call stack either succeeds or everything either reverts and this is definitely useful in blockchains but can become a little bit difficult when you're working in a cross-chain world because if for example your call to Smart contract C fails the entire transaction reverts which might not be what the intended logic you want to have is for your application uh what layer zero offers is this concept of horizontal composability the IDE a that instead of having everything either succeed or fail you can actually define specific checkpoints in the transaction workflow so for example if I wanted to transfer a token in this first call this would deliver the token on the destination chain and then emit uh a message via this send compose method this is emitting an event basically out to the blockchain and telling the executor on the destination to execute a second workflow and the benefit here is that if let's say this token transfer and swap the swap side of it fails you can Define that the token transfer itself succeeds for the cross chain message so it enables you to have a little bit more flexibility when it comes to programming the experience a user has when moving assets to a destination chain or in the type of State changes that follow your cross chain message uh Beyond just the composability the executor also enables seamless gas drops to the destination chain so for a fee you can deliver let's say any native gas token that you want to your Des destion app in the form of gas limit or message value or if you want to relay that gas directly to an end user's address and have that be the only part of the transaction that is totally valid as well part of the workflow um so all of these things that I've mentioned in the last kind of 10 minutes or so build up to what I believe are on the Chain applications the idea that any smart contract on any network that layer zero supports can send a message permissionless without layer zero providing a enforced config around security or an enfor ment around how much gas you have to deliver and ultimately what that means is that you as the app get a lot of control over what you can do with layer zero anything can be sent via the protocol as bytes meaning that you can send Assets in the form of erc20 send param parameters you can send nfts you can send basically anything that can be codified and stored on a blockchain and ultimately that leads to a lot of interesting scenarios that I'll kind of dive into today um I'm going to switch over really quick to my IDE so you guys have a chance to look through it so in this repo I have here there'll be a link to this after in the session but I have a few example contracts here um I'll make this a little bit easier for everyone to see the first one that I think is a little bit relevant to the T title of this Workshop is Aba ABA you can think of as like a handshake agreement with tcpip uh the way that it works is you're able to Define in your contract itself essentially a return call back to the receiver so inside layer Zero's contract standard the O app we have two functions uh LZ send and LZ receive I'll start with LZ receive here and kind of Define and walk through how this logic works this function is called anytime a message is received to our destination app from the protocol contract the endpoint and what's happening in this call is it basically is decoding from that bytes message a few parameters in particular the first that I'm storing is just a simple string so if I wanted to for whatever reason send a string from a source chain to a destination I would encode that data in the send prams I'm defining an arbitrary message type and uh some gas settings that I want to return to the destination now what this receive call is doing is very simple but very interesting to me uh I'm essentially defining a message type called send ABA that if this type is received in the message call it will return back to the source sender a message and you can see here we can take advantage of a receive struct called origin which is part of the message workflow and B basically Define this return call back and so if we dive into a little bit more of the stack Trace here we can do um not composer but ABA and then crank up the verbosity just a little bit on this test and you can see here at the bottom basically what I'm asserting in this test is that on chain B it receives chain A's message and on chain B it receives chain A's message um this you know setup here for mocking your tests is really really helpful with layer zero we're basically able to inside our Foundry test here Define a mock chain a and a mock chain B and then set up uh an example endpoint with an example app on each of these chains this is just me encoding The Constructor Arguments for deploying locally each of these contracts and then uh simulate wiring them together using layer Zero's protocol uh before doing the actual testing itself in this test I'm simply just passing this simple string chain a says hello verifying the message and delivering it to chain B and then verifying again the message back to chain a um if this assertion holds true that B's data says chain A's message and A's data says chain B's message I know the test has worked and I've successfully handshake the message back from chain a to be back to a again uh overall this kind of testing framework is really really verbose because it enables you really quickly to see one on evm compatible blockchains uh what my actual messaging framework looks like and gives you a little bit more flexibility to go through some extra settings one which I'll jve into really quick uh is called batch sending this is another message pattern that we have defined in layer Zero's docs if you're curious about it uh basically what we're doing in this call is we are writing a for Loop within our send logic to basically ping an array of destination chains all with a single function call so from one chain I can send out uh essentially a web of different calls to various destinations all at once and relay State chain changes from there uh in this test I'll go through really really quickly we're doing something very similar I'm defining four mock chains uh one sender and then three receivers and then defining basically in this call again uh four different apps on each of these chains wiring them together and then in this function test uh again defining these arrays of destinations that I want to send to and then instead of relaying the state back I'm actually just updating State on all three of these destination networks and so if we do Forge test match contract again we'll just pumch this in really quick believe batch send should work great and then if we crank up verbosity one more time just so that we can see what's actually happening under the hood you can see again here we're basically updating State across all of these networks via this verify packet method to update State on three different chains all at once um you can understand that you know there might be some latency in between depending on the network and block confirmations that you wait but this pattern can be really really useful for if you need to uh you know trigger some type of State change on chain a and then Mass update the records on all the other networks that you're connected to uh the last one that I'll jump into really really quickly is just this idea of composing in the example I provided before I mentioned this idea of swapping tokens so the idea that I could send an of to a destination chain and mint the erc20 there and then swap it for another erc20 uh this contract composer is relatively straightforward it's just using safe erc20 inputting an IR C20 uh interface you know for the contract itself and then calling and defining this LZ compose method which basically enforces that the O app is the O app we expect and that the end point is the caller and if it receives tokens via an oft token transfer it will look for the amount of tokens that it received and then just erc20 safe transfer out uh an example amount and I actually have this one already deployed live so we can take a quick look at this one uh I'm going to go into this swap mock contract on arbitrum saoa uh hopefully get this up here really quick and if we go into uh perfect the token transfers here I'm going to zoom in just a little bit you can see that for every token transfer in that we do via my we get one token transfer back out in the form of this LZ compose method uh and if we take this transaction hash and we run into layer zero scan this is layer Zero's block Explorer for all of the message Pathways you can see here that uh this transaction and actually let me grab the LZ receive that corresponds to it um we can see here in our logs that this transaction was successfully delivered and this LZ compose correctly swapped those tokens to the receiver that we wanted so this kind of framework for messaging the ability to Define how your transaction on the destination chain responds to different events across multiple different blockchains can be really really useful in case you wanted to find things like kyc that trigger on different chains doing some type of private computation and then unlocking something on a different destination or just piping useful apps that are only available on certain networks uh so yeah hope you guys please build on layer zero and if you have any questions we can just jump uh right thank you [Applause] guys cool any questions if we want to jump in nope I I was curious you could talk more about the dvn I think I may yeah definitely um jumping back let me switch over here actually so uh let's see if I have this one not this deck so a little bit more about dvns basically dvns are just an interface that we've defined on chain for how the protocol receives messages from any messaging provider so this kind of design here uh I'll go actually one step higher that I did previously this kind of design interface is basically where we Define an interface on the source chain for emitting messages out uh whenever you send a message with the protocol you'll call A A assigned job method within the protocol stack this assigned job is basically assigning the role to each dvn and paying them a fee for relaying a message and then what's actually being done from the dvn side is it's routing uh the packet that has been emitted by the protocol hashing that packet and then delivering that hash to the destination chain in this message Library once that hash is delivered uh basically your app defines in uh onchain configuration uh in the form of a mapping that says what that configuration threshold has to be and if that threshold is met then the message can be executed but anything can be a dvn at the moment uh I took this slide out I wish I had it but I can pull up here if you go to our docs right now and go to supported security um we have 35 different dvn providers right now um looking at some of them uh the popular ones at the moment for example are polyhedra which is a ZK light client using ZK proofs to validate messages on the destination chain you could combine that with something like axel so using Axel's middle chain as verification or you could do something uh with layer zero in Google Cloud where these are traditional node-based verification platforms where you're using uh essentially multiple different signers in an offchain client that are attesting to messages on the source similar to an oracle yep any other questions or nope cool well thank you guys so much for coming out um we're going to be doing a $20,000 Bounty this weekend so would love to have you guys hack on us thanks so much [Music]