Hyperlane 🛠 Interchain Accounts with Hyperlane! - Yorke Rhodes

foreign [Applause] [Music] well yeah thanks guys for coming uh we're gonna have a lot of fun uh my name is York from hyperlane uh we're formerly known as Abacus if you heard of the Abacus protocol we rebranded recently um but yeah today we're going to be talking about some developer tools that we expose for you guys to use during the hackathon I know the workshop was labeled with interchain accounts but we also deployed a new middleware today for like interchange queries so we're going to cover both of those hopefully um so yeah first and foremost what is hyperlane in case you guys aren't up to speed hyperlane is a developer platform that enables interchain applications and so what that basically means is there's a smart contract API that's deployed on all of our supported chains and you can use that API to send messages between blockchains so you kind of enable composability between smart contracts which exist on different chains and we have kind of like a novel security model that we do to it that we employ to enable this but I think I want to keep this talk focused on kind of like the developer tooling side of things um as opposed to the security protocol but happy to answer questions there that you guys have at the end so yeah why do we care about interchange applications and why should you be building one uh so today developers that are building dapps are faced with this choice of which chain they want to deploy on when they're going out and you know launching their v0 and I think what developers don't realize a lot of the time is that that choice has uh kind of like a lot of Downstream consequences so we we listed a few here uh developer experience the the tooling that's around a specific chain um might be you know limited to to that Chain's ecosystem um you know each each chain has some idiosyncrasies and uh sometimes the tooling isn't as mature on on newer chains or cheaper chains so you might be like trading that off without realizing and then I think this one's probably the should be the highest on the list user experience uh just generally like when you're choosing which chain you're deploying on really what you're choosing is like who is the user demographic that's actually going to be able to use your application um and you know are they going to be required to bridge to some chain that they're not already on which requires them to go through some like third-party application uh usually taking on a lot of like counterparty Risk we've seen a lot of bridge hacks recently so generally like you don't want to ask users to go through some third-party application um to just to access your app then we have the platform risk so this is kind of like once you've developed a network effect on a specific chain that you've deployed on uh it's very it becomes very hard to migrate that uh application or network effect to a new chain if you decide that the current chain has departed from like some maybe uh you know morals or philosophy that that you want to adhere to maybe it's like some censorship property or something like that uh It generally becomes difficult to migrate you know Network effects Capital Etc [Music] um and yeah this this extends to composability uh if you want to kind of like reach new user demographics which are on uh different chains or maybe like lower fee chains or higher security chains Etc um if your application isn't designed with uh cross chain composability in mind you kind of when you deploy to these new chains you end up with these like new siled instances of your application rather than an application where all of the users of your app are benefiting from kind of like the aggregate Network effects instead you have these kind of like siled networks that um you know in the case of like an amm when unit swap goes and deploys on a new chain it's an entirely new set of liquidity and so you kind of have to rebuild the network effects a lot of times you have to deploy these like artificial injections um in the form of like incentives to get uh bootstrap the utility there initially so yeah there's like all these consequences and what people are doing today to go multi-chain or go cross chain really is not scaling well um they're like like I said deploying these incentive programs um and there's like all this mercenary capital on the ecosystem that's just like chasing these incentives and as soon as the incentives dry up they just leave um and so you know it's not a really sustainable model for scaling to all of these new chain environments however we want our applications to support these new chain environments because like there's all these different you know scalability uh improvements and enhancements being made which make certain user demographics you know more uh likely to use your application so there's like kind of this tension between the proliferation of like these scaling Solutions and new user demographics and being able to like have an application which maintains its Network effects like across all these different chains so this is where hyperlane comes in hyperlane is a network that exists between blockchains so it's not another blockchain um you don't have to choose hyperlain you can just like use hyperlane tooling to deploy everywhere and it eliminates this choice so today we're only on evm chains and so you still get this nice property of like only having to write your application logic once and kind of like deploying it uh everywhere in like a symmetric interface and it's built to be this connective tissue that allows smart contracts to communicate between different chains and so you can have uh like intra app communication um whereby you have a shared State model and some sort of like State synchronization that exposes a user interface on all of these different chains but actually is doing kind of like asynchronous State synchronization on the application side which is like obfuscated away from the user or you can have inter app uh kind of composability so even just like an app that's on chain X and another app that's on chain y they're not natively composable because they're not in the same runtime uh hyperlane like allows you to build you know the aggregator app that makes those two apps composable and yeah like I said you bring your app to users on any chain they don't have to learn a new experience you know they already probably have a wallet that they prefer a certain custody Solution on a certain chain that they're comfortable with you don't want to like enforce all of these additional uh like frictions to your users just to like use your application you know any friction in the initial like onboarding experience is going to massively limit your ability to like scale your audience and and your customer base so um yeah and then get rid of this platform risk so uh this is a little bit out of date but we're going to talk briefly about like the lowest level primitive that hyperlane exposes to you guys which is the messaging API and then we're going to talk about interchange accounts and then um you know I deployed interchange queries today so we're going to talk about that too instead of the other examples here so the messaging API um basically there's kind of two smart contract interfaces which are necessary uh to be implemented when um using hyperlink so on the sending side you have to basically dispatch mail to an outbox on the source chain which specifies the identifier of the destination chain that you want to send the mail to the recipient address on that chain to receive the message and then the message itself and you know you'll you can see here that the message is just arbitrary bytes so we're not enforcing any specific like application message encoding on you really like this is a very low level primitive and and you can do a lot with it um and then on the receiving side um the in order to receive a hyperlane message your contract needs to implement this interface called iMessage recipient and specifically this handle function which takes in An Origin chain identifier the sender address on that chain or from the origin chain and then the message that was passed by the protocol and it's important to note that uh I guess um we need to implement this specific interface because uh other and and actually also Access Control this function to the hyperlane protocol because otherwise anyone could just spoof any sort of like cross chain message by calling your smart contract and like pretending that it's uh coming from some chain when it's actually not and that has you know a bunch of security implications which again I'm like trying to stay away from but happy to answer questions um so yeah it's like slightly annoying that you have to deploy contracts on both sides of the message life cycle like the sending chain and the receiving chain uh because it basically means you have to like manage an application which is deployed like on all these different chains and it like can get kind of complicated again like we've built out a bunch of developer tooling to make that much easier um but I want to talk about uh this concept of interchain accounts um which uh is basically kind of like a middleware implemented on top of the messaging API that like slightly constrains the messaging coding but makes your job as a developer potentially much easier um in terms of like orchestrating and deploying and managing your app across like end chains so the messaging API that we just looked at again like doesn't enforce a specific encoding it could be structured you know arbitrarily you could have like Json in there if you wanted to um and if you want to implement like a application specific feature like you're transferring an asset in like a in like an asset Bridge or you want to do a swap or you know whatever it is you have to implement that as like a specific messaging coding um on top of the messaging API but if we constrain the messaging coding to uh basically uh actions which can represent kind of like all the entire set of actions that can be taken on like a destination chain um and we leverage some properties of the evm mainly like uh the create two op code we can actually like create these accounts on remote chains that are controlled only by a smart contract on the source chain and so this allows you to basically like have a smart contract on chain a that that holds assets on chain b or does like Atomic actions on chain B um and yeah basically the way this works is like there's a interchain account that's deterministically created from the source uh chain contract um and that interchain accounts bytecode basically restricts uh any incoming function calls to the source chain contract so if you want to make one of these like interchain account actions um you basically like relay it through the interchain accounts API from The Source chain contract and then the hyperlane protocol will go and relay that to the destination chain interchain account which will implements this Handler that basically has access control saying you know how we saw the messaging API here basically saying that only this origin chain and this origin sender mainly the inner chain account owner can uh run this function [Music] and so the nice property we get from this API is like uh now you can only Implement hyperlane interfaces on the sending side you don't have to worry about deploying contracts on the receiving side because the hyperlane protocol will go and deploy these inner chain accounts for you automatically whenever you route through this API um so you can basically dispatch like ABI encoded calls to be made from your inner chain account on another chain um and kind of like the middleware wraps up all of the uh you know messaging API uh receiving so an example use case of this type of uh pattern is cross-chain governance so uh you know the way cross-train governance works today typically is like uh voting happens you know usually on one chain like the Hub chain and then there's like some basically like you know either trusted multi-sig or like Oracle solution to take the results of a vote that happens on like a hub chain and actually like propagate or broadcast that result to all the destination chains to like perform the specific like governance proposal that was encoded on the source chain however with interchain accounts if you have a Dao contract that dispatches governance proposals to The Interchange accounts API on the kind of receiving chain side of things you can basically just set the owner of contracts that you want to be controlled by a dow on another chain um to The Interchange account of that Dao and you basically have gotten cross-chain governance for free um so there's like one example um but yeah I think like The Interchange accounts API has I guess like makes it much easier to work with the hyperlane system so I definitely recommend you guys check it out on the docs um and then I also wanted to highlight The Interchange query system which is like super new uh deployed on testnet today um but yeah it feels like another kind of like middleware developer primitive that basically just makes it easier to work with the hyperlane system so um I think you'll you'll notice in the messaging API that um there's no kind of like native callback support so let's say like you wanted to go and dispatch an action to some other chain and get the result of that action and then like return back to your the calling contract and then resume execution it's not super obvious how you would do that with this API maybe you maybe it is obvious to you but we've found that it's like somewhat difficult for people to understand how to implement callbacks um and so we wanted to build out this kind of like interchangequery system that just lets you like read Remote Smart contract State on other blockchains which is like a super simple API you know now that we have basically on any hyperlane supported chain this now becomes accessible to any smart contracts and again the nice property is the receiving contract or the contract which is being queried doesn't need to implement a hyperlane specific interface because we're just dispatching ABI encoded calls to be run against those to be run against contracts on the remote chain so yeah you can basically with this API dispatch a sequence of function calls and provide a set of callback function selectors to actually receive those query results so hopefully you're like familiar with how function selectors work in the evm but um the basic idea here is like you need to provide some way on the source chain to resume execution or kind of like recover the the stack once you receive the message back from the remote chain of like what was the value of the query on that chain and so these function selectors basically say like what functions should I run once my query resolves and I've gotten a return value what functions do I need to run on the source chain to kind of like resolve that value or like consume that value because we don't have an async await syntax in uh solidity or the evm but uh you know something you could build with this interchange query system which like I was toying around with like hacking this weekend is actually like an async08 syntax in solidity that like gets transpiled down to like The Interchange queries API um just as like kind of a fun demonstration that like you can have asynchronous Smart contract runtimes and um it just takes a little work so yeah here's like a quick um or this is just the API so yeah it's kind of similar to The Interchange accounts API um except instead of uh it just being like a sequence of calls you also have to provide the Callback um again this is like compatible with Legacy contracts so you can like make uh let's say you're on polygon you can go and like make smart contract queries against like uniswap V3 you can like go and get price data from ethereum like sorts of things like this aren't possible right now um and this is an example that I just like put together really quickly sorry for the like lack of uh syntax highlighting but um yeah basically like this is an example of querying ens for the owner of an address from a chain which is not ethereum so you can just like take the ens interface you can you know figure out what what label do you want to query on the ens registry in this case um we don't actually have the hyperlink.eth domain maybe we should go buy it but um yeah if you wanted to query the owner and the expiry of uh the owner of that domain you just you know ABI encode calls to the ens registry on ethereum and then you use The Interchange queries API to go and query that in an asynchronous way you'll see that we have the like resolve owner and resolvex pre-selector here so basically these two functions will be run with the return value of what was basically queried on ethereum we're still kind of at least I'm still thinking about like what the the right interface here is this is like a little awkward um to for a way to implement callbacks but um yeah I just wanted to like give a quick example um and yeah you could imagine building some sort of like so this is like this requires someone to do a round trip between chains um and so like let's say my contract queries some uniswap V3 price Oracle let's say it's like usdc and eth uh I want I want to go get that price and then some other contract makes the same query both of those queries are going to do are going to require round trips between the two networks which kind of sucks um so you could another idea for the hackathon is like maybe implementing a caching system uh with this like interchange queries API and ens is like especially amenable to this that's why I picked it as an example because there's this like explicit Unix timestamp expiry attached to every kind of like relevant piece of State on the ens registry so you could like very easily build uh uh kind of like cross chain ens cache contract that like saves um not only saves round trips but actually uh has like Atomic resolution of maybe uh addresses which are like popular queries I mean the same can be said for like other types of interchange queries this was just the example I picked but uh yeah I think we're like at the timestamp so I wanted to give an opportunity to for people to ask questions um that was like probably a lot to to get through um but yeah yes so it will work between Roll-Ups um and what's nice is you don't have to wait the optimistic period right so um we're kind of all these use cases are optimized for like low latency and high security so right now I think we're on optimism arbitrum I'm trying to remember what other roll-up chains were on I think that might be it for now but those are the I guess most in-demand ones um but yeah it's very easy for us to expand to new evm environments so if there's like a specific chain that we're not on um and you can check that in the docs but if there's a specific chain that we're not on we can definitely talk to you about expanding maybe like even tomorrow or something like that um you can that's a great question um so the way our like relayer implementation works is it will only uh include transactions whether they're callbacks or just cross-stream messages in general the transaction will only be included if uh it's expected to not revert and so what that means is like in your callback uh receiver like let's say you know resolve expert or whatever in the implementation of that function you could have a reverting condition which says this much time must have elapsed between when I dispatched the query and when the Callback is being resolved and that's kind of like how you could schedule callbacks um sorry it's a little hard to hear yeah so like what's the security model basically of like energy queries yeah great question so um so hyperlane is like a example of generalized message passing which is a generalization of asset bridging which has been like demonstrated as like super insecure um and like super shitty and like probably shouldn't trust any of these things um so we're kind of like making what we think is like a fairly novel security uh trade-off um we're uh basically establishing a distributed set of proof-of-stake validators that sits between all of these blockchains um they're actually staking on the source chains instead and so instead of kind of like guaranteeing that we can prevent fraud in in kind of like let's say the return value of one of these interchange queries um instead what we can do is we can guarantee that there's an economic cost to fraud a minimum economic cost to committing fraud um associated with a message that is sent outbound from a chain where hyperlane validators are staking and we can do that because if the if those validators sign something which is not committed to by an accumulator that we have in our smart contracts um we can provide a fraud proof which basically slashes them and so we haven't actually defined all of the economics around the system right now we just right now the validator set is permissioned um so to some extent you have to kind of trust the existing operators you can check out our docs and the Discord uh to like both like uh see who the validators are if they're like fairly reputable organizations around the space but also um you know you can talk to them in the Discord um but yeah right now it's a permission set so you do have to kind of like trust uh the I guess Quorum of signers in that set but we're opening hoping and basically the next month or two to transition to this like permissionless proof of stake validator set where instead of this like social trusts or like reputational trust we have uh like full Economic Security model which basically like most of these other Bridge systems have not really implemented effectively um so yeah great question though I mean like that's kind of like the core differentiation of our protocol versus some of the other like generalized message passing protocols out there um is this like Economic Security model that has actual like enforceable slashing conditions and smart contracts so you can like have strong guarantees of what the cost is to commit fraud which is not true of basically like most other security models awesome yeah thanks guys for coming uh I'll be around the venue all weekend so if you have questions or need help with anything um we have a booth upstairs definitely come out