Hyperlane 🛠 Building Interchain With Hyperlane - Nam Chu Hoai

foreign [Applause] [Music] how's everybody doing like it's been a long day it's gonna be a long weekend um well I appreciate you taking the time to learn more about hyperlink my name is nam I'm one of the co-founders here at hyperlane and we are doing what we're calling building the interchain highway so first you might ask yourself like what the is The Interchange Highway and what we think of The Interchange highway is basically kind of the situation that we find ourselves today where we have all of these really amazing blockchains right like blockchains are really all about like kind of valuable state that can be like accessed by anybody and Modified by anybody right like the analogy usually it's like in our computers but now we have so many of them that there's a lot of valuable States but they're all isolated um and so those kind of like computers might be might as well be different galaxies and the problem is arises is that the state is fragmented and so when you build an application today right like you have to pick one chain which also means that like you won't be able to access all the state on all the other chains and so developers can only really serve users on that chain they can compose with protocols who are not on that chain and oftentimes people what they do is they end up just a black like you know about sushi right like they just end up deploying contracts on multiple chains but for all intents and purposes those deployments of the contracts are completely independent right basically effectively different applications and so we know that like that's just not going to be tenable right like there's no world in where let's say the internet is like not composable across many different websites and so the question is like what is the end stage and so people have thought about this problem for a while right like we're not the first ones uh there are what we call different eras of interoperability so in 2016 we started with like the cosmosis and polka dots of the world right like that's where they got started and so basically they were able to like derive interoperability protocols that are able to natively verify other chains that are built within the same context so that's where kind of the cosmos app chains kind of um arise right like IBC is able to natively verify the consensus of other chains um via IBC um however 2020 comes around and there's all of these side like alternate l1's popping up and there was no interoperability protocol that existed between all of these other l1s but at the same time there were all these users who had this like kind of goal of like hey there's like a lot of popping up Avalanche popping up so how do I get to use these applications right and so like there's what we call this kind of like makeshift user-facing bridges that came up and are now what we consider bridges for the most part right like it's like end users going to a bridge bring like depositing tokens into the bridge and then getting either a wrap representation on the other side for them then to use and so yeah most Bridge volume is basically through those bridges but we also have seen I think the kind of downside of those bridges because they're oftentimes built an ad hoc way uh there's been a lot of bridge hacks um because there's no kind of native verification that can really happen um and oftentimes like new chains just came come up with like an ad hoc bridge to build because they needed some value to come from ethereum to their chain and so we believe that 22 2022 is the start of like what we call app Centric interoperability and so instead of like an application making the user figure out a way to come to the applications chain we think that applications will incorporate kind of that problem of interoperability into the application itself and so that users are able to use the application from whatever chain they happen to be in so we call those inner chain applications and so to be able to build these internet applications what you need is what we call interchange highway right like this kind of this vision of the inner chain Singularity is like applications that just live on every chain users can use them wherever they happen to be and so important piece for you to realize here is that Hyperlite is not enough itself another blockchain and it doesn't rely on another blockchain to kind of like be solving all of our blockchain problems and instead hyperlane is a network in between blockchains that facilitates state transfers between the blockchains that we have today but especially the blockchains that will come up in the future and so our effort basically relies on us creating this like safe fast and accessible kind of Highway between blockchains and so how does it work um at the kind of service it's pretty simple so we basically have what we call mailbox contracts on every chain and so you as a sender whether you're a smart contract or like an eua you basically call the dispatch function on the mailbox when you call the dispatch function in the mailbox what ends up happening is that the message gets in queued in the Unchained Miracle tree in the mailbox and so then validators can observe that Merkle Tree on that origin chain mailbox create a signature and then on the destination chain the mailbox contract can verify those signatures alongside with a medical proof for that message you can then process the message by calling handle on the recipient of that message and so the API is pretty simple we think it's like this so on the mailbox an orange chain side you call dispatch with the destination chain which is like just an ID for the chain uh the recipient so the address on the recipient on the destination chain and then the message which is just like arbitrary bytes that you can specify and on a destination chain the recipient will be called uh with three parameters the origin chains and where did the message come from the sender who sent the message and then again the message bytes um that were sent and we have a message explorer that can kind of show you the progress of the message as it crosses the chain uh and if I'm bold enough I'll try the live demo right now um I think the internet has been pretty rough but let's see if that works so basically what I will be doing is I'll just go for the quick start tutorial and basically uh using metamask and so first what we'll do is we have to find the mailbox contract on our origin chain so it is a list of them right here you can open them up oops of course I don't think that will work I guess uh let's see that's what happens when you try to do a live demo um we might have to come back to this uh like let me try my phone all right let's give it 30 more seconds and if not I'll just have to skip the demo today oh cool all right yeah so basically on our docs here you could find kind of like all the mailbox contracts and all the different chains so let's say right now let's try to send from a Fuji to Mumbai and so basically what you can see here is we call the dispatch function right the first argument is as I said the domain ideas and so you can find them on the docs as well so the domain ID of Mumbai in this case is 80 80 0001. the recipient address so in this case uh it is bytes32 instead of address because not every chain has just 20 bytes of addresses right like eventually like Cosmos and salon and others actually have 32 bytes for an address and so you if you send it to an evm chain you have the zero pad at 232 bytes uh we have kind of pre-deployed test recipient contracts on every chain but you could also obviously like just enter your own recipient in here right now and as a message body you can again send arbitrary bytes and so we can just like let's say like do hello from if India right and then that's like just uh ETF encoding into a particular string so we'll do this and then we can send the transaction and hopefully if everything goes well we just call metamask right here right we get the transaction uh there you go so in the moment it will be mined right here and as I mentioned you can use the hyperlane Explorer to kind of track the status of your message and so hopefully if you you can see here that we are sending from Fuji to Mumbai right so you can kind of open it here and um yeah so you can have someone see the phases here whether we send a message transaction has to be finalized before validates can attest to uh the validity of the message in the Merkel trade uh and then like once that is once the value is basically signed a uh signed the miracle root the relayer which is permissionless can process the transaction under destination chain and so I think we'll have to wait a couple seconds and in the meantime I'll show you a test recipient contract so this is the contract that we specified here on the sending side right um and so all the contract does let me show you what it does recipient here is like on the handle function right like it receives the origin the sender and the call data and so it will emit a message event here and I will set these two uh these two State variables and so okay cool so at processed we can open the transaction uh we can look at the destination processing if you're on a destination chain and then if we look at the logs we could see the received message that was emitted by the test recipient right and so as you saw there's like a very simple like sending a message across the chains and it's a simple as calling a function call on a smart contract um so one thing we have a notice is that to be able to do this right you need to have a smart contract on Origin chain in the smart content on the destination chain and we were constantly thinking like how can we make the developer experience better because basically the message Api has no concept right of like what the data is that you're sending and how it is structured however oftentimes what you want to do is you want to like be able to make a function call on the destination chain right so let's say you have a Dao let's say you have like a down ethereum um where it lives right like it it wants to own assets on other chains right like you could totally use the message Api to basically deploy a smart contract on both sides and basically relay authenticated calls across but we can just do this for you and so interchange accounts are basically a middleware abstraction that allows senders on An Origin chain to have a proxy account on the destination chain and that proxy account will only ever accept basically function calls that were sent from the origin sender and so that basically allows for what we call like a much like kind of like nicer experience because you basically ABI and call the function call you give that to hyperlane hyperlane will basically like forward the call to that proxy account what we call the ICA and then that proxy account will make the call to the recipient and so kind of the outcome of this is that on the origin chain you make this function call which is very similar right it's like API encode to call as you normally would if it's a single chain context and on the destination chain you actually have to have no contract at all like you're just making a direct function call from the ICA and so we can highlight that as well so again on the page here on the accounts we have the quick start tutorial so all we have to do is we have to go to the uh ICA router which is this address and we basically here have this decade function right again we have to specify the destination domain uh so actually let's do it again to Mumbai uh the target which is again our test recipient and then this is the ABI encoded function call right so in our quick start you will see here that um we're just going to call Fubar with these two arguments and I just like kind of encoded these two arguments in here and that will ultimately generate uh this uh this API encoded function call and so if we once again write this and I do is on metamask we'll have a transaction and just to show you what the uh test recipient this is the Fubar function call that we got called and so let's once again look at our messages refresh he is you got once again sending from Fuji to Mumbai um and then once this is processed in a hot second actually I I'll just shows later because you can imagine what's going to happen like the call will be made and then on here um as you saw like we just emit this receive call event and we like write those two variables that I can show you whenever that's done um all right next one uh so that's if you want to basically write from An Origin to chain to a destination chain but let's say whatever you want to actually do the reverse right so let's say you have a contract on polygon and you really want to access some State on ethereum right for example like the the V3 swap on like uh Eve to usdc right like which is probably the most secure top uh but you're on polygon so what do you do uh once again we've kind of thought about like what it would be a better developer experience and the best thing would be right like if you want polygon can just like Abi Abi encode The View call send it to hyperlane and hyperlane will basically do like the view call on ethereum for you and then call your contract on polygon with the results of that query and so that's what energy inquiries is so the way it works once again is that you basically pass to a query function your ABR encoder function call and then the Callback which is the function on your own contract that should be called hyperlane will relay that message over to the hypercultural destination chain it will make that call as you specified onto the sender and then the result will be put again into a message back to the origin chain and that result will be put into the Callback function as you specified and so again the nice thing is that on the destination chain there's no contract that you have to have to write just on the origin chain you specify destination chain the target you want to make the view call against the query like the view call itself API encoded and obviously the Callback on the sender as well um and so once again let's do a demo which is uh right here uh actually wait it's now right here it is right here so basically the this time is a little different because we have this uh test query Center contract on the origin chain which will do the query right because in this particular case like the way you receive the result is a function call on yourself on the sender and so we've pre-deployed those contracts right here you can see uh the interface of it here if you want to look at the contract real quick um tests test query sender right so basically when you call query address all it will do is we'll call the query router on the hyperlan contract with uh the destination main the API encoder call and then the Callback which is handle query address result right which is this function so basically if you as the developer just have to kind of like make this call and you can expect that the hyperlink contract will call handle a query address results with the actual result that happened on the destination chain and so let's actually do that right so in this case let's say we are sending the girly which is the domain five right here and we uh in this particular like in this quick start example what we're doing is we are um just uh reading the owner State variable of a particular contract so in this case this is just a contract that we have and the owner of that is like one of our keys uh but then the basically like the view call that we're making right is like this owner and so that's ABI encoded it's just this particular byte string and so basically if we do those three things uh pass that to query address when one can once again uh make the query and this is maybe interesting because once the transaction is finalized we can also see that our previous ICA account call um was delivered let's see okay so so we're sending from Fuji to growing right and this is the query the first leg right where we're basically saying like hey what is the owner uh what is the owner address of this particular account and so let's wait until the transaction gets processed on the destination chain and so to be clear what we're doing is right now is this part right like we're sending this this message right now so let's just seeing once that goes through I think early in Mumbai I've been pretty like congested like not congested which is just like not as easy to include transactions uh lately anymore um but so once that goes through there you go right so we took I guess it took only like what 20 30 seconds uh so basically we can see is just open it in a block Explorer uh right like basically like uh return this query so that was this is the address that we were reading this is the result of the address and so this transaction hash right actually ends up sending a message back to Fuji and so if we add this transaction hash to our search you can see it's actually two messages right like one is the one from Fuji to girly and then here's the one from growing back to Fuji and so that already like processed and so here on the Block Explorer uh we are able to see that the query was resolved with uh this data and that's the um nope that is the last address result here right like you can see that this is the address that we got returned um cool all right um so last but not least uh sometimes what you want to do is you don't want to just send messages but you actually want to send value right so the manage API all it does it sends arbitrary bytes but like how do we decide what value is is obviously like a much bigger topic if you're interested come back uh to a booth to talk and talk more about it but one thing I have like that's like a key part here is that like whether you actually sending canonical tokens versus rap tokens right so like right now when you say let's use Wormhole to send usdc from Eve to Solana actually what you end up doing is you're depositing usdc on ethereum and then portal mints like a wrapped usdc version on Solana and there's obviously all kinds of good and bad things about that we believe that there's going to be many different ways of transferring value and so we have what we call the liquid layer API which allows you to use free single interface different value Bridges right and so for example you will be able to use portal but also like circles native usdc Bridge which burns usdc on let's say ethereum and then mince it on Avalanche and so you never have this kind of like wrap token issue and so the API looks very simpler uh it's similar to the master API where you send your specified destination chain a recipient a message and then the three additional arguments are the token that you're trying to bridge an amount and then the string of the bridge itself so like in this case would be either Circle or portal um uh I'm gonna skip the API demo here but like if you're curious uh it is obviously on our uh docs page right here and last person is the thing that I want to kind of like highlight as well is that when I had this uh diagram here it was very simplified right because basically it said like oh the mailbox of Val will verify signatures but one of the key points that I think everyone should take away from this talk is that bridge security is very hard right like every second bridge basically has been hacked and part of the reason why is that uh there's no such thing as like one secure model fits all right like a hacker here if India has a very different security requirements than like let's say unit swap when it wants to like do like governance decisions to cross chains and so we have what we call Sovereign consensus which allows the recipient to specify the security model under which the recipient accepts messages right and so for example in the simple cases if in there you could say like oh like any Valor signing a message it's okay for me to accept a message but if I'm uniswap right I might actually want like higher security uh to accept messages and so basically you can create these things what we call isms interchange security modules which the recipient points to and then basically the hyperlane API will first call the ism with icon is valid uh function call and only if that is true it will actually call handle on the recipient and so that allows uh applications to kind of specify their own security and so like you know in default case right now of hyperlane you have this like validator set that you use but you could imagine isms that have like optimistic modules so you could imagine isms that for a specific like chain pairs actually use like uh ZK Bridge or something and so we think that as a developer you are able to kind of opt in into the same API so it will have different security going forward um all right I think that's it I know we are all running behind so if you have any questions we have a move over there we'll be here all weekend uh we also have bounties uh 10K uh and we're generally just looking for like very creative uses of hyperlane like as we mentioned in the beginning of the talk we believe that the future are interchange applications applications that live on every chain like it just doesn't make sense to me to have an application that only lives on one chain and then all the other users you just like like out of luck like you have to come figure out a way to come to us right like a no world our application successful if they just force users to jump through hoops to use your application um so yeah if you have any more questions please come by uh come by our booth and yeah hope you have a good weekend bye