Building Omnichain Tokens - ETHGlobal Singapore 2024_

[Music] cool I think we can get started um first of all thank you guys again for jumping in um I'll be talking a little bit today about layer zero and how you can get started building on me chain tokens I think to begin just a quick introduction my name is Matt I'm developer ecosystem lead at layer zero Labs uh that's my Twitter handle at uncrackable if you want to follow me on Twitter um a little bit more about bridging in general um at layer zero we kind have three core principles that we want to keep in mind um we believe that moving any type of data between chains requires you to have one uh permissionless interoperability so anyone no matter who they are on chain can interact with the protocol and send messages uh two that these messages are then censorship resistant meaning the protocol can't arbitrarily flag messages as being valid or invalid uh we can't control how messaging is sent and finally three it's immutable um there's no point in having this messaging protocol exist if we can upgrade the codee and change how it behaves at any point in time and so ultimately for us we view layer zero as Bridge infrastructure the way for you app developers to not only safely send messages between chains but then configure that bridging process based on your own applications needs and you know necessary handling uh a little bit why about why Bridges even exist um I like to really compare it to an analogy with the real world bridges in general connect isolated islands of people and more importantly than the islands of people people they connect they connect the flow of information between them and that flow of information can be really really valuable because using that information you're suddenly able to unlock things like the coordination of goods and services and Beyond the goods and services themselves the financialization of different assets between those parties so connecting groups of people really really valuable and it's no different within blockchain uh while this isn't 100% accurate you can see very very quickly that different chains have different use cases different benefits different communities and tradeoffs and being able to flexibly pick between these different networks rather than subscribe to only one for your application can be really really beneficial you may be able to unlock use cases for example on arbitrum that simply aren't fible uh feasible at all with Bitcoin so we've seen this overall in Market develop pretty consistently uh this is from the Electric Capital developer report from 2023 more and more developers are moving to deploying on Cross chain environments you can see here that uh over the last year more and more developers have said they start deploying on more than one chain rather than just one and in general let's walk through what bridging actually looks like to kind of give you an idea of what we'll be working with today uh token transfers in General on a single blockchain are relatively straightforward an erc20 token is simply a mapping of balances between a users's address and the amount of tokens that they own uh when I move tokens to a new wallet I'm not really moving anything in reality I'm simply updating this mapping to debit the amount of tokens from one user and credit them to another but as soon as soon as you move to a cross train world that immediately becomes a little bit more challenging first of all these islands don't know about each other the chain Linea for example has no idea of the consensus or state of ethereum and so how do we do this type of token transfer where we update a balance of a user on one chain and then credit it to another on a destination we need some way of invoking a function method on the source chain Linea that actually goes through and is for sure final in debiting the user on the source chain and then is able to somehow ping the destination chain and execute a receiving function to credit the amount of tokens and update that state for the destination user traditionally um this ran into a lot of issues because as you can see from this example if you don't have a clear way of proving that something has happened on a source chain then someone can very easily take advantage of the fact that you're able to infinitely update these mappings and change these balances over time so the way that historically we got around this as an industry was with something known as monolithic Bridge security uh when I say monolithic the way you can think about this is literally as either a centralized provider that is manually writing state to the destination chain that you trust you could think about this as a collection of different signers you could think about this as a middle Chain Bridge but the most important takeaway from this kind of example is that we subscribed to one provider that validated for us and we subscribed to them the trust assumptions that we had about their protocol in order to validate this workflow of sending messages to a new ch and this worked for a while but one thing that went wrong very quickly is what happens when that validation fails when you have only one validation network uh very quickly the same problem that we mentioned before can happen but at a much larger scale instead of one application falling prey to this validation logic failing every application that used this validator network suddenly became compromised and that meant that in the blockchain industry it led to massive amounts of loss for the majority of users who interacted with those applications that depended on the validation network uh four of the five largest hacks in crypto in general are due to this type of Monolithic Bridge security where one validation Network that everyone trusts fails and then you're left to pick up the pieces from a hack uh ultimately this problem is due to this type of single channel for messaging where one validation Network secures all of the validation between point a and point B and ultimately forces every application to use that channel regardless of the different properties that they have uh Beyond just you know the channel basis of it it also forced you the app developer to be fixed into a model that might necess not necessarily fix uh your application's needs for example let's take the case of having two different monolithic validator networks here Network a and network B uh in this example Network a has a very low level of security but is very very cheap to use and so every app is a accepting that while the security threshold is low you're able to get very good cost benefit from it for Network B the opposite every app has a high cost Associated for using this validation Network for the fees they're paying but they're able to incur a much higher level of security but the hard part for you the app developer is that the switching cost between these validation networks is really really high typically you're forced to change your contract interface to match whatever validator Network you're using and the redeployment costs are usually very very high either requires you to use upgradeable contracts which can fall prey to their own vulnerabilities it can require you to go through re Audits and redeployments of core contract code and ultimately is not a very desirable setup um that's why I say if you view ethereum as being a dark Forest I see cross chain as being a dark ocean where you have all these different islands of blockchain connectivity but very very quickly can be taken advantage of if a malicious actor takes control of the pathway between those different Islands uh similarly if the actors that are helping navigate and land on these islands are destroyed you can also be just stuck on that chain with no way of escaping so with layer zero what we view as kind of the solution to this is this idea of an omni chain protocol stack the idea that you're able to take advantage of a core Omni chain messaging layer that you the application can configure uh this framework that I'm showing you below is how apps typically interact with layer zero we have two layer zero endpoint contracts that are immutable deployed on chain a and chain b and a security stack of different verifier networks that you're able to configure within the framework itself so for this particular app they've configured three different decentralized verifier networks and because of its modularity you can easily configure between them uh Beyond just the base messaging layer you also have questions now about how do we deliver messages layer zero supports this broad function call layer for cross cross chain messaging where an Executor can automatically deliver messages on the destination chain on the user behalf and provide a specified amount of gas in the native gas token on the destination chain for them this further simplifies kind of the workflow for messaging and finally this app layer this idea that on top of both you know the verification and the execution of messages you have different contract standards that let you easily deploy things for yourself that are not necessarily needed to be made out of the box every single time we have three contract support uh standards that we support currently the O app which is the Bas messaging primitive the ability to move just raw bites between chains uh an extension of the O app called of that lets you deploy a native erc20 token on multiple chains and connect them with cross chain functionality and an O nft the Omni chain nonf fungible token which does the exact same thing as the of but with an ERC 721 uh at a high level this message workflow is super desirable because it means that you the app developer can specify any type of message that you want to send a Destin chain and a configuration comprised of these different verifier networks and an Executor that you want to admit to and then enforce on the destination chain via your destination app that these verifier networks are actually the ones signing off and providing the threshold of security that you desire and then finally once that threshold has been met executing that message through the destination chain using the parameters that you want to have executed so this enables you to move data or assets or data plus assets is the way that we think about it uh at a little bit higher level layer zero enforces this kind of immutability at the endpoint level the layer zero endpoint is basically the interface or API that you use for all cross chain configurations within the layer zero protocol it enables you to configure on a per Channel basis the ability of how you send messages and what data is encoded the configuration options that you have for what verifier networks you use what block confirmations you wait and what executor you decide to use and then we provide this uh framework for message libraries underneath the endpoint it's basically a way for you to for those configurations specify what the offchain world actually looks like to your contract um you can see here on screen this concept of an Oracle and relayer for layer Zer V1 the older version of a protocol we had a slightly different setup that allowed you to configure only one verifier Network and a custom executor uh by deploying a new contract this UL 301 we enabled apps to permissionless opt into this new security framework which meant that not only were they able to take advantage of new security properties as the protocol became more and more developed but it meant that no one was forced into upgrades like the traditional path with upgradeability so this idea of uh allowing developers to basically set configurations gives you a lot more flexibility too for your application and what that means is that from that security cost curve I mentioned before layer zero doesn't just support one network type or another we support every single point on the curve and for every single app that uses layer zero if a new validation technique comes online that says is strictly faster better and more secure than any other primitive before it it means that these apps if they choose to can seamlessly migrate to that validation technique without having to redeploy their contracts without having to change core contract code or can decide not to use it and say that their existing setup is good enough burn the keys or burn the uh authority over their configuration option and that app is forever using that configuration setup so for verifier networks it gives you a lot of flexibility you're able to then decide between a ZK light client as your security proof mechanism a uh message service provider that already exists like ccip or axlr or a combination of all of them or any of them which means that you're able to broadly adopt any verification schema that you think is fit for your application network uh and the cool thing about this model is that it means that anyone can permissionless run these validation networks too uh the idea of a dvn is really just a contract that takes in an input from a source chain and delivers a payload hash to a destination and so giving you this open framework we actually expect to see a lot more creative use cases come online in the near future that are all independently using their own validation methods uh diving in a bit deeper into the execution workflow the way the executor works is that you're able to very easily swap a source chains gas asset in this case this is ethereum to uh polygon you can swap the gas asset on the source chain so a user will only ever pay in ethereum the native token and then deliver a call to whatever smart contracts you want to evoke is part of the uh LZ receive logic right so typically this could be a token transfer that does a swap a stake and then some other third action on the erc20 but there's slightly problematic workflow for execution here uh the typically with ethereum contracts the way that they work is they're Atomic where if one of these calls fails all of them revert which is very very annoying in a cross-chain workflow where a user expects to only pay on the source chain and expects everything to go through seamlessly on destination so layer zero created a slightly new primitive that you can take advantage of called horizontal composability this idea where as part of your receive logic going back to that token an example I can receive that token on the destination chain and then execute a secondary function call that is entirely separate from the first transaction and what that means is you're able to then not only deliver for sure the token transfer you want to make sure that is actually you know enabled for the user on the destination chain but let's say if that swap fails it doesn't have this full Atomic revert where nothing has happened on destination so it gives you more flexibility as a developer to essentially interact with more and more contracts as part of your cross chain call without needing to worry about everything being packed into single function method uh besides just you know the transaction workflow layer zero also supports gas dropping so as I mentioned previously when a user pays on the source chain ethereum that token is swapped via the executor's price feed and delivered to whatever destination chain you want and destination application uh inside the layer zero docs you can see this under enforced options and it'll kind of go through and explain you can drop either to that contract method that I mentioned before the LZ receive call the LZ compose call or just drop directly to an end user's address on a chain so very very useful in case you need something just you know very easy and quick to deliver gas for your users or for your application um and this all kind of builds up into what I think of as the on chain application this idea that any smart contract on any blockchain network layer zero supports can permissionless interact and send messages between chains without having to rely on anyone but themselves if they want to and that means that you have a incredibly flexible permissionless model for not only controlling configurations per chain but also controlling what your application moves through um I think I'll skip through this is because I'm short on time uh there's a lot of other application specific guarantees that we have as part of the contract standard that you can look through later uh but basically this model basically going back to the ERC token transfer I mentioned before boils down to this uh app developers can create multiple contracts on different chains that take in some data types on the source chain incode those inputs and Trigger some State change on the source make sure that the message is validated in the middle and then deliver the necessary State change that you want on the destination chain via layer Zero's protocol and what this means is that if a validation Network ever goes down you the application developer are safe from erroneous delivery you're protected from validation that completely wipes out your users and it means that not every application is at risk of a single validation Network um I'm going to take some time for questions now that we have about 5 minutes left I know that I went through a lot of different topics so would like to get an idea from you guys if there's anything else I can answer and then if you're looking for a CLI example I've actually included in this QR code here on the top right my eth online Workshop that goes end to end through deploying on the CLI getting an oft spun up and yeah this should be really really helpful I think for for you guys along with a couple other example repos but yeah thank you guys so [Applause] much any any questions at all from from the presentation NOP uh so this QR code will go to uh a link tree that has the full presentation it has a YouTube video that goes through through this uh example slides for the first like 15 minutes and then a full code example for the next 15 uh and then an example design patterns repo so beyond just the protocol and the things I demo today there's a bunch of design patterns that we've included for sending to uh multiple different chains all at once uh batch sending is the way that we think of it I can actually see if I have an example diagram up here for it uh but yeah basically going through end to end all the different protocol settings that you can take ADV of app every ch right exactly yeah so in this workflow here if an oft is deployed on these four chains you've deployed that contract on each of the networks and then you've called some configuration function called endpoint do setconfig and that method uh basically says which contract am I expecting from this network and what is the actual verifier Network I'm going to use per pathway yeah yes yeah so uh this actually was done in eth Brussels uh a team submitted a project that basically piped transaction hashes from ethereum to arbitrum and then used aover to basically prove that something happened From the ethereum Block cashes on arbitrum yeah I do yeah so the uh the command that you'll run for this I'll just go to the documentation really quick for anyone who's interested for deploying self-service uh go to the CLI setup guide in the documentation this uh command is an npx package called create lzo app create lzo app basically deploys or sorry creates in your working directory a joint repo of hard hat and Foundry it comes pre-built with a bunch of sample hard hat tasks that help immensely with Going Through the Wire up you can see here that you can pull in basically all of the contract standards that we currently support and then the commands that you'll run to get started uh you can either use LZ deploy you know to run a sample hard hat script that'll deploy everything for you out of the box uh and then these are some configuration inits that basically create a new configuration file and and if you look at what this actually shows you in here it basically is a mapping of these different contracts that you've deployed with the different config options that you want to set so it's pretty flexible for whatever you want to configure can also add exactly yeah so after it's deployed all you need to do to add a new network is basically add to your hard hat config file the new network deploy the contract there and then just make sure that you're still the admin of the contract so you can call them methods yeah cool yeah so if you want to basically provide an attestation on different network um the way you can think about it is that you'll uh have whichever The Source train is that is providing the attestation the the source of Truth basically for your application and then you'll use a layer zero message to pipe that atation to a new chain so the example that you probably want to take a look at is the Omni chain app standard um you'll essentially just encode as part of your payload uh whatever the at to station contests are right so in this example here you can do ai. incode and then for ly receive you can decode the data type back out and then use that data type of the ad testation on the destination chain that needs it essentially to prove something has happened cool I think we're out of time um thank you guys again so much though for coming and let me know if you need any help or I can answer more questions at the booth too cool thank you [Music]