Intro to LayerZero V2 & Omnichain Apps for Beginners - ETHGlobal Brussels 2024

[Music] awesome cool well thank you guys all for coming I know you most of you have traveled a pretty long way to be here so super excited to see what gets built in the next couple days uh at a high level this Workshop will be going through what is layer zero how can you get started building on it what is the full stack of things that you can create using the tech and uh going through a little bit more in detail some code to get you guys started so without further Ado my name is Matt I'm a developer ecosystem lead on our devell team at layer zero Labs you can follow me at uncrackable on Twitter uh feel free to ping me at any point during the weekend if you guys have any issues that you run into or need support I'll be online for most of it um I always start off these presentations with the physical world representation of a bridge because I think it's important um most of us have seen a bridge but we probably don't think that deeply about you know what is a bridge doing at a high level um obviously it's connecting groups of people on different places right but more than just the people that's being connected it's the information that they hold um having a bridge at least in historical times was incredibly valuable because it meant that you could then coordinate the transfer of goods and services and with the transfer of goods and services came the financialization of those services so bridges in general are very very useful for moving information and value uh with cross chain it's no different uh if we look at the blockchain industry today Developers and users are constantly facing trade-offs depending on what chain you want to go to whether it's an L1 or an L2 depending about the finality on that chain and the time it takes for a transaction to be included in a block the cost of the block space itself each of these things make you as a developer face uh different realities about what you can and cannot build on each blockchain uh at a high level if we talk about maybe the most common use case for blockchains today the movement of value right this is a simple ear C20 contract on Linea uh at a high level when we think about moving assets right from point A to point B we like to think of it as an actual movement but really all we're doing is updating The Ledger State we're saying I want to deduct a amount of balance from one user and then credit that balance to a destination but as soon as you move to a cross-chain environment that immediately becomes a lot more complicated each of these chains are isolated they don't have any context about the other network and so as a developer we need to think about a way for us to call some sort of transfer function know that the Assets in question have been debited for sure and then somehow relay that message over to the destination Network and instruct it to call some function that receives those tokens for the intended user so this is the domain space that we're working with especially when it comes to Value transfer uh but if you're just working on that kind of value transfer level you need to also ensure that this cannot be abused right if we just allow anyone to make that receive call without good confirmation that this is a valid function call from a source blockchain you can easily wreck the network and wreck the protocol uh in general the way that we solve this over time was with a concept of Monolithic Bridge security you can think about this in the center here as some centralized provider that's listening to events on a source chain and writing them directly on the destination you could think about this as a collection of different verifiers you could think about this as a middle chain where the central verification schema is just a middle Chain Bridge uh but in general there would be some entity in the middle that you relied on and you uh basically put all of your trust in to ensure that they were going to be able to verify and deliver the messages on your behalf but again we have this problem here where if that is such an easy solution to the Cross chain space why are sofu people building on more than one chain right now this is from the Electric Capital developer report and these numbers have been going up more and more people are becoming familiar with cross chain development but the major problem I think right now is that we don't often think about what happens when these security guarantees fail or backfire as soon as your security goes down not only are you the single application at risk but every application on that network is simultaneously at risk that uses the protocol in the middle this could be due to a number of things whether it's just a Flatout centralized service moving messages between chains this could be due to the client software used to secure each of the validators that sign off on a message if that client software has a back door or it could just be due flat out to a lack of node diversity which is how the axi infinity Bridge hack happened so in general the main problem is that once a messaging protocol fails for Bridges every application that touches that messaging protocol fails as well and this has been a stark reality that we've seen in the last probably decade for blockchain development where uh the majority of hacks and exploits we see that have the largest value attack are due to this centralized or monolithic Bridge security so in my eyes the way I like to frame it is if you think of ethereum as a dark Forest cross chain is a dark ocean you have each of these islands that don't know about each other and the only way for you to get Knowledge from one chain to another is to rely on some actor to control that message and pass it through to the destination and if a malicious actor controls the port of entry for that Island the island itself faces an existential threat simultaneously if a centralized entity accidentally destroys the port via some upgrade to the contract or the interface itself uh the island also faces an existential threat from not being able to get reliable information to the chain so the way that we see layer zero is addressing these two issues the one of if the protocol fails every application fails and two the destruction of the actual interface that developers use because of the upgradeability of the contract interface layer zero is a permissionless protocol meaning that layer zero the uh entity that owns the endpoint contracts cannot block or whitelist or Blacklist anyone from using the contracts thems the endpoint interface is fully immutable and permissionless for anyone to use and furthermore it's censorship resistant in that once a message is emitted from a source blockchain a arbitrary user or arbitrary actor can't strike that message down uh without uh invalidating the protocol guarantees and finally as I mentioned before it's immutable this people go over quite a bit but I think it's more beneficial to probably see it in code um from the protocol stack for just majority of message passing on Bridges uh the way that message passing works is that there is at a low level an omni chain messaging layer the way this layer works is that it is focused mainly on the verification of messages from point A to point B this is that collection of different signers the testers the middle Chain Bridge whatever it may be layer zero allows the application to select the block confirmations you have to wait on a source chain the required verifiers in the stack the optional verifiers as part of that stack and the threshold needed for a message to be considered verified we'll dive in a little bit more into what that actually looks like um on top of this low-level layer for verification we need a way to actually route function call so this Omni chain function call layer operates on top of the message verifications and allows the app owner to control the amount of gas limit message value order of execution and the executor to use for each call uh we have two different call methods that you can use the LZ receive execution which is just part of the I layer zero receiver interface this is for receiving any message packets on a destination chain and I layer zero composer we'll dive in a little bit deeper too into that as well um and finally the most important bit for the application developer what you guys will be hacking on uh this app standard layer so applications on top of these two other parts of the stack will essentially use these different functions to enable different use cases within different evm environments uh we have an oap contract standard that lets you move arbitrary bytes between point a and point B we have an oft Omni chain fungible token standard for moving erc20 token balance and anft standard which lets you move nft transfers between chains uh at a high level this is the send workflow an application whenever they want to use layer zero will create a call on the layer zero endpoint called endpoint do send this call allows you to specify a message in bytes that you want to deliver to the destination chain you will specify the destination chain identifier as an endpoint ID and you will provide a send configuration of what offchain stack you want to use to deliver that message on your behalf for you uh as part of that configuration you can decide the amount of block confirmations that must be waited on the source chain before this offchain stack gets started and you can assign the job to specific verifiers and an executor of your choice uh today layer zero has 30 plus different verifiers to choose from and as part of this security guarantee you're able to choose the required number of verifiers so in this case let's say we ping four different decentralized verifier networks about this message in particular three out of four of them have to sign off on the message's integrity and this is enforced by the application from what they set on the destination chain again it matches your send config so in the send workflow we say wait this many confirmations the receive config enforces it it also enforces the expected dvns that are meant to sign off on the message and that threshold for security once the message has been verified you can simply have an Executor whether that's a user calling the endpoint directly or a automated executor that layer zero runs uh automatically deliver the message on their behalf with uh an automated gas abstraction for them so this is a high level at the workflow you initiate a send transaction it emits to some offchain entities based on your configuration your receiving app enforces that it matches the configuration you expect and then finally you execute that message through to the destination chain so this kind of builds into us what we think of as this Omni chain application the idea that any smart contract on any chain just has to interact with a single layer zero endpoint that is already deployed on that Network and can be routed to any other blockchain network within the stack furthermore we are able to configure things a little bit more deeply each application has a concept of this vtes message right so in general if you're used to ABI encoding bytes on solidity the way that it works is just ABI encode any data type that you want to deliver to the destination chain from there when you have the receiving call being made to the destination app you will decode that message and extract the bytes inputs with Abid code um for the of standard there's a message codec Library called message codec doso that I recommend you guys look into uh it'll give you a bit more advanced usage for how to splice bites out if you're interested uh and finally within the app there's a final little piece of application layer security each application sets a pure address for that pathway so you can see here on the send side we select this destination endpoint that we want to deliver to and what this security this pier is doing is I'm saying within my application from this endpoint ID I want to ensure that this is the address it's sending the message so it enforces once again that you have the verifiers that are checking the Integrity of the actual message itself and you know that the origin is coming from the place you expect to prevent any invariance uh again same thing works on the send side we check the pier and we just say get Pier or revert for that destination to ensure that you have configured a correct Pier on both chains uh going a little bit deeper into the text stack the way that the layer zero endpoint actually works is that it's an immutable smart contract interface and what I mean is layer zero once this endpoint is deployed cannot arbitrarily change configurations to rug your application the way that your application interacts with the endpoint is that you will use it for both the send and receiving function calls but you'll also use it to set your configuration once an app has set a selection of decentralized verifier networks by an array of their addresses and set the executor by its address there's nothing layer zero can do from RN to change it so entirely permissionless and entirely owned by the application uh underneath the endpoint we have a secondary contract called a message Library you might be wondering why is there a layer Z V2 if I haven't heard of layer Z V1 uh layer Zer V1 without getting too into it was a separate collection of smart contracts that enabled you to instead choose an Oracle and a relayer when we decided to create endpoint V2 we thought well we want to bring some of the benefits of this configurable security stack and separate execution logic to the the existing apps that were already built and so we added these appendable smart contracts these message libraries what this allowed you to do is as a application you could call this function and change which Library I was using for my application and enabled you to upgrade from this Oracle relayer setup to a slection of security from these different dvn providers and executor and so it was a guarantee for developers that they still had an upgrade path to the latest and greatest security without using upgradeable contracts just appendable configurations that the application owner set nothing forces a user to use this configuration once it's set it is purely optional and something that they are able to configure uh at their choice uh going a little bit deeper we have this idea of dvns right what are dvns well in general when we talk about dvns it can technically be anything uh most bridges have some method for essentially listening to The Source chain learning about the state and writing that state to the destination and so as an application this provides you a way to not only future appr proof your app by if a latest and greatest verification schema comes out that moves messages cheaper faster and more securely you can add it to your security stack but it means that you as the app owner aren't forced to accept a one-size fits-all model for security for cross-chain messaging you're able to easily configure any number and type of verification within your app and be able to Ure that if something better comes out that beats all of them on price your application isn't stuck and forced to redeploy contracts or completely change the infrastructure underneath uh so with all that in mind taking a more kind of Ste back approach to token transfers the way that layer zero does it is pretty straightforward you'll deploy an of contract on each chain you want to connect in this case Linea and ethereum and when a user interacts with that of contract all it's doing is calling a debit method which interacts with the underlying erc20 token interface to burn those tokens on a source chain route that message from the layer zero endpoint given the oft's unique security stock that they've configured and then once it's executed credit those tokens to a destination address for the amount listed um and what that means is going back to our previous example if one of these verifier networks outright fails your application at worst is simply paused until you reconfigure a new security network and your Thresh or at best is completely uninterrupted right if this is a two out of three security setup your application has not been halted at all and it gives you a future proof path to avoid any issues at the verification layer which is ultimately the most important um outside of that layer zero lets you configure a lot of other settings that we talked about for example the block confirmations the message execution for whether it's automatic where a user only pays in a Source Gas token and it will automatically be swapped for the the destination native gas that you need or if a user wants to make that call manually they can do that as well uh deeper on those execution gas settings we have specifically the amount of gas limit in message value for the receive call uh a composable call which I'll dive into in the code example and strict non ordering if you want to enforce that messages have to be delivered in a specific order um I recommend checking out the docs or coming to the booth afterward if you want a deeper dive into kind of what these conf options mean uh but finally I think the thing we care about mainly is what this all builds up to uh the Omni chain Tex stack for us is a way for any application use case whether it's defi social fi gaming Oracle feeds identity to be built in a way where they can control the not only type of security that they're using the type of execution logic that they hold and ensure that they're interacting with a common interface across every single chain you don't have to learn a completely new uh chain interface or application interface to unlock new security instead you can have a simple IM mutable interface that you've always used for your application and easily configure new types of security within your existing apps so uh I'm going to jump past these really quick I'm short on time if you want to scan this QR code it'll be the repo that I start going through in the next like one to two minutes the last 10 minutes of this talk will just be going through an example design pattern repo to kind of show you what is the design space that layer zero has and uh hopefully the demo code doesn't break but we should be good to go awesome so uh switching over here let's just take a look at this repo um before I dive in let me show you how you guys will actually get started building on layer zero if you want to use our CLI tool which I highly recommend the way you'll start is you'll run npx create lzo app at latest this will ask you a couple questions first what do you want to call your project um I'm going to call this new LZ O app and it'll have you choose a selection between an of template or an OA template uh in this case I will choose of it'll also ask for what package manager I'm going to use yarn because I like yarn and then install some dependencies um for me it's going to complain about node because I forgot to switch it so make sure you're using node version 18 and if you run into any issues like that all you need to do is CD into the application run yarn and it will pull down all the dependencies that you need um fortunately though I have another package that I've already set up so we don't have to realize uh that and one of the things that I think is most helpful about this you know repo setup is that inside it's a hybrid repo that contains both hard hat and Foundry so you can use common hard hat tasks that you're familiar with you can do common Foundry testing and I'm going to go through three contracts um first at a high level how do I deploy my of this is a strictly vanilla of the only change I've made is I've added this mint function to Mint 100 tokens to the message sender um within this repo what's really cool is we kind of expected you guys to start doing a lot of these deployments out of the box so you can run it's still going to complain about node which I'm going to cancel I'm just going to switch here to make sure we're set um perfect so I'll run LZ deploy what it'll do is it'll automatically compile uh your hard artifacts pull them in and it's going to read from your hard hat config in this case I've already set it up to include uh my seoa endpoint my arbitrum seoa endpoint this is just a handy package that comes standard with the repo to let you pull down what the endpoint identifiers are uh from here I'll hit oh don't want to hit enter there I want to hit enter in the terminal uh It'll ask what deploy scripts I want to use in this case I'm just going to use my my deploy scripts hit continue public rpcs will do their thing great I've just deployed two contract addresses on arbitrum seoa and one on seoa now once this is set I ideally want to be able to actually configure them to work together so um I'm going to use another handy configuration called npx hard hat LZ O app config init um with this I'm going to pass in the location that I want my configuration to be uh in this case I'll do it as example layer Z config TS and I'm also going to pass it a contract name uh in this case I'm going to pass it my that's the contract I'm working with and this will again ask me to select what networks I want to populate it for and it will generate this file in my working directory um it will pop out here in just a moment awesome so what does this actually give us um if we format this document we can see it sets up for us first an instance of the contract on each chain as an object itself arbitr fromia suppo contract tells us the endpoint we're working with uh and then it will automatically bring in the default configurations for this pathway um default configurations you can be thought of as like placeholders that layer zero has set for you to just to get tested and quickly started um these can be changed though with all of the addresses available in our docs if you go and look at the deployed contracts page um in this case the ones that we care about are how do we make sure we can send a message from arbitrum sapoia and then receive it onia I'm actually going to comment this part out just so you can see so we have a send config and we have a receive config the way you can think about it is that in this top part of the repo for arbitrum sapoia tooa I'm just specifying a send configuration that Will Call some functions on arbitrum sapoia as the from contract uh it'll set what my required dvn is the block confirmations I need to wait and then similarly for theoa contract it will provide its receive configuration the important thing is that this receive configuration matches this send configuration right so from arbitrum to seoa we're sending from spolia to arbit spolia we're receiving awesome from there I can run npx lzo app wire pass in the OA config that I have provided uh example layer z.c config.sys it will basically output and check what that looks like from your end but we are good to go uh in that case I'm just going to do a simple send transfer so I've included a simple task in this repo to send tokens you can see how this task works it just takes in an amount I want to send in this case one token to my destination seoa to this wallet address from this network arbitrum seoa uh from here I can hit send uh public rpcs will do their thing we'll send one token to the network and then we'll get this send transaction initiated with a layer Zer scan link so I'm going to open this up we can see here that once it's indexed on the source chain it'll immediately populate in layer zero scan you can see the message is in Flight the cargo is one mock of from this address and you can see went to the burn address here uh you can see which applications are in it what gas is being used on the destination chain and we can wait for this message to be delivered um I don't want to waste any time so while that's being delivered um let's see if we can jump back over here perfect um I have three other example contracts in this repo that aren't basic ofs these are some more advanced design patterns that you guys can Implement uh the first one is an ABA type call so this is for you to send a transaction that returns an acknowledgement back to the original sender um the way this contract works at a high level is that we basically will take in a couple parameters uh when we do the send function we'll take in the destination that we're sending to in this case a string message uh and some gas settings that I've specified I have the ability to add on top of some required gas settings some optional ones that I'm having the developer use so uh I would play around with this in the repo when you get a chance uh from there we initialize a send call it will emit message sent and then on the receive side decode that message check if the message type is this return acknowledge M and return a secondary send call back to the original sender which you can see here we're using this origin struct provided as part of the receive call here so returning back to the sender uh a message in this case a predefined one that I've said chain B says goodbye so I don't have this one deployed instead what I'm going to do is actually take advantage of The Foundry test helper that we've built uh we have a special test helper contract that you can use in your Foundry unit tests to kind of mock layer zero implementations within Foundry Forge um in this case we want to do test ABA and we're going to crank the verbosity on this one it's going to compile hopefully pretty quick hello awesome oh yeah are we on time okay isn't it minutes minutes oh five minutes gotcha awesome I'm going to try and speedrun this um but yeah you can see here if you run the same command in this repo uh we can see for the ABA contract on chain B when we call this data field and let's just pull up that test so we can make sure that I'm not lying we can see here in test ABA that the assertion is basically checking for the chain B data that it says chain a says hello and we can see it's asserting for chain a sender that it says chain B says goodbye so we know that their messages were received on destination and acknowledged um I don't think I have time to go through the other two unfortunately but if you want please come by the booth I will show you myself one of them is batch sending so being able to in one send call uh essentially do a for Loop that sends to multiple different destination chains if you wanted to mass update data on other chains for one call and the other call or other contract that we have is a simp composed example that shows you basically how after I Reed some tokens from my of transfer I could have a external function call here which executes after the receive logic but I think for now I'm just going to pause and open up the questions through a lot at you guys thank you guys for the [Applause] patience cool any questions Let's uh speedrun them yeah is it propagated already the first test you did yes uh this which test this one the first message oh yeah let's take a look um yep delivered so we can go on destination check here uh and the way to check and make sure it's delivered you can check the decoded input data see that this is the source endpoint ID it came from what nons it is the message and then in the logs here we care about the actual value being transferred you can see a of received event emitted here with amount received uh yes [Music] so there's a way to transfer native tokens you can see in this gas setting here uh within this call this LZ receive gas this is 65,000 way of the Native gas token on sapoia so ethon sapoia uh we allow you for the executor to specify message value in gas in the native gas token up to a native gas cap so if you want to do large transfers of native gas you're going to need something else but this is how you would do it in the calls yeah any other questions or yep the difference so the O that's a good question um exactly yeah so if we look at the of contract if you go in the stack here and go into of core of core is an OA OA is just a standard contract interface that brings in all of the basic configuration logic things you might need in your interface yep exactly you could do it for erc20 tokens or if you had a different token standard you would just modify on top of O app yeah cool yes uh for oh to on destination chain there is a Max gas uh Max gas Li it yes it's it varies per pathway but you can read it on chain yeah yes yeah cool we can yes you can yeah um yeah and if you need more gas than what's provided by layer zero you can use Stargate which is a native bridge and just use their interface to get even more native gas assets via the bridge itself C set by there's a there's a cap set by layer zero for the execution options I can explain it a little bit more too and then Stargate has no cap it's whatever you pay for you get yeah yeah cool yeah thanks guys [Music]