Building on LayerZero - ETHGlobal London 2024

[Music] awesome uh super excited to talk about uh building on layer zero I think this is a quick introduction GM my name is Matt uh developer ecosystem lead at layer zero labs and I figured if we were going to talk about bridging uh one of the most important places to start would probably be with the London Bridge right uh real quick just as an analogy I think Bridges obviously connect isolated groups of people but more than just people the really interesting bit is connect information and with information you can do a lot of interesting things you can coordinate the exchange of goods and services between these isolated groups and parties you can also create financialization between isolated groups using that information uh within crypto it's very much the same thing when we talk about blockchains versus l1s l2s Etc you're constantly deciding as a user and as a developer to make trade-offs between speed cost security and also communities on top of each of these developer ecosystems so really when you're building you'd like to figure out how do I communicate between kind of these isolated Islands uh this has become more of a reality over the past year if you look in 2023 the Electric Capital developer report saw that over 30% of developers in the space are working on more than one chain and this number is significant been growing year-over-year and I think this makes sense because if you look at the blockchain ecosystem you have all these separate Islands however you need a common way to communicate between each of them and ideally if you're going to create some generic standard for how you message between different chains it needs to uphold the core principles of the blockchain itself self namely one it has to be permissionless anyone or any smart contract can interact with it and interact in a way where they can't be censored right they can't stop the flow of messages between two different blockchains and prevent those islands from speaking together and finally it has to be immutable you can't have code that's upgradeable that can potentially brick your implementation and also brick every other other application built on top of it but taking a step back and looking a little bit closer to kind of the most standard form of application on a blockchain token transfers with one blockchain it's relatively simple to know who you're sending from and who you're sending to you're just updating the underlying Ledger but as soon as you move to more than one blockchain you immediately have a problem you have these walled Gardens and these chains that don't know about each other so how do you have a common standard of interacting between them ideally we want some way to be able to transfer our funds on the source chain get that debiting interaction to work and then notify the destination chain to receive that asset in a way that doesn't violate any of the previous principles traditionally the way this is done was using some type of Monolithic Bridge Security in the middle the way you can think about this is a centralized provider or some type of collection of signers or a middle chain it doesn't really matter there's one validation technique that sits in the middle between these two chains but what happens when that validation fails this isn't more of a what if but an actual literal scenario if you look at the history of bridging time and time again applications promise some type of validation that securely transfers messages from a source to destination but at some point a validation technique either becomes stale outdated it fails a back door is unlocked there's a lack of client diversity and what ends up happening is not just you the application Builder but every application Builder that touched that validation technique is now suddenly at risk looking at the history of blockchain you can clearly see out of the five largest attack vectors and hacks that we've seen in the space four out of those five were due to this type of Monolithic Bridge security where one validation technique fails and every application underlying it is immediately essentially pwned right this is from the rec leader board you can check it out yourself uh and going back to kind of that narrative we have about cross chain being a reality where we have different tradeoffs that developers and users make between different blockchains why should bridging be any different why should I have to subscribe to one monolithic model of security one monolithic model of bridging in order to move not only information but assets between chains uh clearly a better approach would be to have some type of standard for an omni chain application where I the developer not only have control over how these Pathways interact and what validation techniques are used but also know that my configuration is unique in a way where not every application is suddenly at risk when one validation technique fails looking at how layer zero solves this this is from our Omni chain fungible token standard at a high level looking back at that token transfer logic we talked about earlier all the oft brings is a standard erc20 token and implements a special debit and credit Logic on the source blockchain and the destination blockchain but the really interesting bit is in the middle here with the security stack all a security stack is and the way you can think about it is another another configurable field that an application owner can apply any access controls that you normally would have to whether it's posible uh providing some type of multisig Etc but what it applies in the middle is the ability to choose not only the size of security validation techniques that you're using to verify messages between chains but also the type of validation techniques that are used at a high level what this means is that when you Deploy on layer zero not only can you control the validation techniques that are part of this overall security stack but in the worst case scenario if one validation technique outright fails entirely your flow of messaging is not stopped in any way shape or form you can continue message passing safely because you have collectively signed and said I want let's say two out of these three validation techniques to prove that this message is legitimate from a source blockchain you're not underlying risk from just one validation technique that could fail at any time looking at a high level of how this actually works any application whether or not they're using our contract standards can communicate with a layer zero endpoint contract on the source blockchain that message uses a configuration that you own as the application owner that's stored on chain in a message library that message Library controls not only what security stack you're communicating with what validation techniques I'm using but also how I want execution to happen on the destination chain from there uh configuration of those security signers will basically attest that that message is legitimate using each their own validation techniques in the previous example you saw there were four verifiers there's three validation techniques that out of that four have to sign off here it's enforced on chain on destination that hey this is the configuration of techniques that I actually want and then that message can be permissionless executed by any user or automatically executed by uh a production asset that layer zero runs directly to the destination app all through the protocol and what this means is that when you're looking at layer zero and trying to build a cross-chain application you don't have to subscribe to any one model you can actually include all of them or any size shape or form of this collection for your security stack where that's a z K light client that Aggregates 300,000 signatures on ethereum whether it's a traditional messaging service like ccip an established web to entity like Google Cloud for sanity checking that hey this is actually making sense and I want to have some kind of uh insurance on the back that makes sure that this message is legitimate it doesn't matter you can configure any size shape or type of validation you want for layer zero messaging and broadly what that means is that your application is future proof as new verification schemas come out and become more uh available for the average developer and average user you can easily configure security stack to add that schema on bo uh outside of just validation techniques some of the other interesting bits that you can control are the block confirmations for example that you have to wait on a source blockchain before a message gets emitted this protects you from reorg risk if your let's say application is based on a source chain that has high frequency reorgs that mess up the validity of transactions you can configure again the security stack so if I wanted say two out of these three validation techniques to sign off a message is legitimate you can also abstract away gas from your users using automatic message execution a user can only pay in a Source blockchain's Gas token and have that entirely swap for them on the destination chain for a five basis point fee and automatically deliver to the destination chain for execution or if let's say that executor disappears at any point in time any user can permissionless execute that message on the destination chain as well there's no limitation for what you can do here on top of those executor gas settings you can actually dive a little bit deeper and specifically price how much gas I want to use for the receive logic of my transaction so let's say I minted a token on the destination chain I have the amount of gas limit I'm providing the message value for minting that token and then I have a secondary transaction I want to execute after composing on that token transfer so let's say I want to take that minted token and swap it for an erc20 I can use the composed logic to not only Define the gas and message value I want for that transaction and I can also native drop options to drop native amounts of gas to a wallet let's say I need to an externally owned account to help a user's onboarding experience on that new chain or just fund a contract for it to use some type of pull method to pull that gas for a subsequent transaction uh you can also configure the order of messages by default messages are unordered so if a message fails in delivery the subsequent nonsense can continue to be executed without blocking the pathway but let's say I have a niche scenario where I need to develop let's say for governance being able to store that hey these users voted specifically in this order before a time stamp I can configure within the application Level that I want if message 2 fails for some out of gas reason that nonis 3 and four are blocked until non 2 is retried and cleared uh outside of that too you can also configure the max message size helping you standardize the data type that's actually being delivered on the destination chain protecting you from overflow or underflow of inputs from a source uh really what you can do with layer zero is extend composability instead of having to rely on packing all of your contract calls into to One Singular function and hoping that it succeeds else it reverts you instead automically pack out multiple messages on the destination chain that you want to add on to your transaction so in this example for here I want to receive that oft and immediately swap it as its own Atomic transaction thereby guaranteeing that if that swap fails the minting on the destination chain still occurred successfully uh overall this builds into what we view as an omni chain Tech stack where any application no matter what your use case is can communicate freely with a layer zero endpoint contract on any blockchain network and configure not only all of the settings after mentioned right but also know for sure that you're not at risk of any validation technique suddenly becoming outdated prone to vulnerabilities lack of diversity Etc uh and so we're going to dive into a live coding example and fingers crossed this goes well uh that's our new CLI toolkit I'll pull this back up at the end but we're actually just going to jump right in right now uh so here we go all right so just to get started all you have to do to start building on layer zero is run one really quick command LZ O app and latest make sure you're using node version 18 what this is going to do is create a boilerplate repo for you uh ignore the formatting there a little bit funny but basically It'll ask hey where do you want to start your project do you want to use the Omni chain fungible token or just the broad data passing layer well choose of what package manager I want to use do I want to install the dependencies it'll pull everything down and while we're waiting for those to get installed taking just a brief preview of what is included in this repo you can see that for contracts it pulls in the basic of contract all that of contract has is just again my of is inheriting the of standard of is an erc20 token uh asks you about hey what's the name of your token the symbol what layer zero endpoint for what chain you're using and then an owner for that contract right uh from there you also get brought in some tests for you you have Foundry tests and hard hat tests enabled by default for this package uh if you want you can use one or the other or both totally depends on what you want to do uh but the greatest thing I think that helps with Omni chain development is this hardh hat config extension we've done so super normal hard hot config the only difference is that you have the inclusion of an endpoint ID that identifies hey what chain are we actually working with here and then this layer zero config file that basically extends that npoint ID and says these are the contracts that I expect to be working with on each chain you instantiate them as part of the uh connection and then can Define whatever config settings you want in here uh for lack of time I'm going to jump to a repo I've already set up and jump in here uh you can see I have three main contracts I have an of tck has an open Mint function don't worry too much about that I have this swap mock which Pretend This is a contract that you want to actually interact with on the destination chain all it does is basically takes a composed message in and it says hey once I receive an oft from this token or from this contract uh transfer that erc20 to the designated receiver on the destination chain and so what we'll look at really quickly here is actually running this send and swap command all I'm going to do is use this task that I built ahead of time that just says Hey I want to send from Avalanche Fuji to this destination arbitrum Saia I want to send to this swap contract address an amount to swap a minimum amount to swap for slippage and then these gas options right I want to use 200,000 gas for the minting and 50,000 gas for the composed uh swapping this encoded compose message is just arbitrary bytes you can pass anything in here but let's run it and see what we get uh hopefully the internet works and my gas is funded uh but we should be good to go here once we run this task we will get out a transaction hash that we can plug directly into layer zero scan and so we're going to open uh it takes a minute to index just for the source chain should take 15 seconds or so provided nothing's gone crazy uh great there we go and so we can see from Avalanche Fuji this is the transaction fee that we paid we know who the sender is from The Source chain we know that the cargo within that transaction is one mock of that I'm sending from uh Avalanche to arbitrum sapoia and then while that message is being delivered it's going through those different validation techniques that the security stock has configured uh and then once that validation is confirmed the message will automatically be executed and this will update automatically for you you can see here it tells you uh what the source application is what the destination application is the amount of gas we paid for the receive Logic the amount of gas we paid for the compos logic you can see this execute button pops up once we know it's verified you don't have to use this but this is just in case the executor fails you can see now we're confirming that the transaction is legitimate and we're delivered on destination and so if you check uh my wallet balance here you can see that I had 78 I'm down to 77 I hop on over to arbit troia this mock token I now have 10 of from 9 and if we actually go to the contract address just to check that this hash is legitimate we can see great down here this LZ receive method was called we got our uh minting at least through and then from the compos end of the logic uh what we'll do is just pull up the uh swap mock contract deploy M on arbitr suia nice and pop on over toia scan great check erc20 token transfers and just to confirm at the top here you can see one minute ago an oft went in and 56 seconds ago that irc2 came out to my address and so really the limit is kind of endless here you can do anything that you want with sending arbitrary payloads and you're good to go as far as making sure that your message are a verified that you know that anyone can come and permission execute these messages and really uh start composing more and more protocols and more and more applications across multiple blockchains layer zero also allows for message passing from let's say I want to go from chain A to B to C and any other legs that I want to go all of that can be packed within your send logic and you can have multiple kind of nested calls within one send uh transaction uh but yeah that's it for the that's it for the presentation happy to take some questions from here [Applause] hi thanks for the presentation and I actually have two questions the first one is uh is there any easy way to migrate from V1 to V2 because this is the V2 the the new one right yeah so there are two things that come with fler Z V2 uh there's the integration of that security stack right so if we talk about this end right being able to choose any provider as part of your security stack that can all be migrated from V1 the way that this works works is if you look in this transaction flow we have a message Library the message library is a pend only so for layer Z V2 so the entry point is the same exactly for for for v2 what you can do is basically just say hey I want to use this new validation library that was appended to the registry and you can start using the security stack and executor setup all clear thanks and the other question is testing Omni chain like cross chain uh protocols is quite hard uh so you showed the example on the test which was actually deployed do you have some kind of library that allows you to transfer like you know locally without interacting with blockchain I do yeah so we actually have this Foundry package called test helper which recently got put out uh we had to update it to open Zeppelin V5 for some cord dependencies but what it lets you do is locally in your Foundry test toine hey here's some mock endpoint IDs I want to use one and two I want to deploy an of on each of these endpoints Define some users and then test through uh essentially wiring these contract together minting some initial balance and then testing the send function locally uh all you have to do from this end should just work out of the box once I pop in here is just run your normal Forge test commands then we'll be good to go uh but yeah um test helper you can find docs on uh layer zero. docs do or docs. layer z. Network and everything within that repo uh that I published will kind of show you kind of how to work through a lot of the local examples as well as kind of the deployed examples through testnet and using layer Zer scan yeah any other questions hey mat great job uh you messaged you mentioned something about Native drop messaging I think it was about potentially airdropping to um make it easier for new users not to pay gas yeah what was that yeah so basically within your options I think I showed you when we were doing that send example there's that add execut LZ receive option block of gas add execut LZ compose option this native drop option can be another one that you append onto it all you do is basically add that uh configuration to your send call with a destination receiver address and then an amount and you can airdrop that destination Chain's native gas token direct to that address uh all as part of the send call logic okay cool thank you yeah cool any other questions here are we good to go um like I said before feel free to try out this package while you're hacking uh I think it's super handy to get up and running for cross chain applications and we have two bounties one for oap we $2,500 one for oft worth 2500 so thanks so much for having me guys [Music]