Abacus 🛠 How to use Interchain Accounts with Abacus - Yorke Rhodes

[Applause] [Music] welcome everybody we have york here from abacus who will give you a workshop on how to use interchange accounts and if you have any questions in the meantime feel free to pop them in the chat and we can take them towards the end your color let you take the stage well yeah thanks so much um welcome everyone to the abacus workshop uh we're currently going through a rebrand right now to hyper lane um so apologies for any uh future confusion there but yeah i'm excited to jump into it interchain accounts is kind of a new uh i guess revelation and innovation that we uh are just about to deploy to mainnet um and i kind of wanted to give you guys a sneak peek at what's gonna be possible so yeah let's dive in so just as a quick overview hyperlane is a developer platform that enables developers to build inter chain applications so specifically there's a smart contract api that lets you send messages between blockchains and we're specifically optimizing for low latency applications that require kind of high high guarantees on distributed security um so this is kind of like where we might be different from some of the other inner chain messaging platforms that you may have heard of so why should you care about these types of tools in general um there's kind of a lot of different dimensions of the motivation for why we're building hyperland but um generally the choice of blockchain that a developer has to make when they're first kind of just bootstrapping their their application and just kind of like trying to get pmf they they actually there's all these unforeseen consequences of which blockchain they choose to deploy to which may kind of play out on a longer time horizon and so they they end up getting a few different uh consequences of this decision that that really is not uh always made with uh with you know uh recognition of the consequences so one example is the developer experience different blockchain ecosystems have different degrees of tooling maturity and you know block explorers indexing services basically any any sort of tool that you would want you know node providers as a developer these might be kind of to varying degrees of sufficiency on different blockchains um you know you also have to think about the impact on your user experience when you're picking a specific blockchain different blockchains tend to be designed for different user demographics and you know there's there are different degrees of accessibility on different chains so some chains might might have you know social login support whereas some might require you to have some some esoteric curve supported on your wallet or maybe you have to run a node yourself as a user to even participate and use applications that are deployed on that blockchain there's also this what we what we call platform risk which is basically the inability for application developers to uh i guess isolate themselves from the uh from basically the decision makers at the blockchain layer so um you know if the community around a specific blockchain decides to do some some controversial fork that the application isn't necessarily aligned with there's really no recourse and you know security of the application is really beholden to the underlying platform and then finally um the actual kind of long tail value of applications that are deployed to a single blockchain are limited by the network effects which exists within that blockchain um and so if there's some you know new synergistic application which maybe uh your users and your application would benefit from being composable with on another blockchain you can't actually uh tap into that and grow grow your network um you're kind of limited by whatever whatever local network effects are available and so recently we've seen a lot of kind of application developers deciding to go cross chain and this is an attempt to solve some of this problem of you know the aforementioned consequences of being in a being deployed on a single chain um but the way this happens uh kind of operationally today is you know uniswap dao votes where where they wanted to play a new application to reach a certain user demographic but um these new deployments exist as kind of individual islands of state and so this actually doesn't solve the network effects that are are limited by a single chain context kind of directly it does it does allow a brand and an application to exist on multiple blockchains kind of for for brand recognition and marketing purposes but the actual utility derived from each one of those application deployments is not composable between between each other and so users on you know the ethereum deployment of uniswap are not benefiting from the network effects of users on on other chains so you know these are the types of problems that we're hoping to address with hyperlink so hyperlane is a network that exists between blockchains um rather than being a new blockchain no we're not trying to make the decision harder and we're actually trying to eliminate this choice for developers of which blockchain they they want to have you know fealty to you can kind of think of it as like having a blockchain agnosticism as an application developer um and we do this while still allowing you to only write your contracts once and you can choose kind of however you decide strategically to expand which chains you want to be on there's kind of no there's no consequences of the initial set of chains that you decide to deploy to and so yeah hyperline is this protocol this connective tissue that exists between contracts on different chains and you can have your application basically communicate with itself across different chains you can have your application interact with remote applications that's what we're going to be focused on today with this concept of inner chain accounts basically allowing your application to have this sort of like sovereign composability with applications that exist on remote blockchains and you can you know meet users where they are so rather than asking users to come and come to your chain where you deployed or maybe have to do some complicated process of bridging tokens and um you know understanding a new wallet experience etc you can bring the familiar experience of a single chain application to your users and to your developers while making it accessible to all of these different blockchain demographics um and and like i said you reduce this platform risk uh of depending on a single chain or a single chains kind of like you know long-term vision for for where they want to go and what types of apps they want to support so as a quick overview of what we're going to discuss today i'm going to introduce the messaging api which is this like on-chain api that is currently live on i think eight evm main net chains um so you guys can go and use that today um and then we're gonna hop into this concept of interchange accounts which i'm super excited about and then some examples of how to leverage entertain accounts so yeah so the messaging api of hyperlink super simple there's two endpoints you can send messages to other chains by calling the dispatch function on our outbox smart contract so the analogy we use here is is kind of like uh you know sending sending messages in the mail um you know you put an envelope in a mailbox and someone has to take it out at the destination and so we have this concept of the outbox where you can dispatch mail and then we have a inbox where recipients can kind of like handle inbound mail so for sending messages you use this dispatch endpoint on our outbox smart contract all the addresses um that are kind of implicit in this presentation can be seen on our docs but yeah you have to specify basically the destination chain that you want the mail to go to um the recipient address of the contract on that chain that you want to receive your message and then the message content itself and so really there's nothing prescriptive here about what types of data you can pass in the message content however the recipient address that you're dispatching mail to must actually implement a a specific interface and have this um this kind of compliant api so when you're receiving message a smart contract that wants to receive messages through this messaging api must implement this interface imessage recipient and have this handle function which um basically gets called by the inbox contract when mail is kind of received from the hyperlane network and the interface for this function is defined as the origin chain where the message came from the sender address that dispatched this mail on the origin chain so in this case the sender would be whatever message.sender is calling outbox.dispatch and then again this kind of like arbitrary message content and so you know with this system this simple kind of uh you know channel based communication protocol where you can send and receive messages between any two abacus uh hyperline chains uh you can create application inner chain applications and so that's ultimately what we're trying to allow you to do here um it is you know worth noting that with this api you must have contracts on both sides of the communication so both sending and receiving sides that are aware of the hyperlane api and in this case on the receiving side what you need is you need a contract which implements the specific handle api and so we developed this this thing called the router pattern which kind of allows you to write a symmetric uh a symmetric basically like inherit from an abstraction called the router contract that allows you to basically write these like symmetric applications where there's no distinction between the logic on any chain but that these routers will accept uh or basically send and receive messages between each other um and you deploy a single router on all of the chains and then you can you know leverage these channels all of the pairwise channels between all the chains and i think so far we've been we've been leveraging this router pattern internally but it's fairly complicated so i don't want to dive into it right now but kind of the high level analogy is you know it's called it's called a router because in traditional networking you have this concept of like routing tables and routing policies that routers use to forward internet traffic they use some understanding of the network topology to route messages to certain api ip addresses on the internet and this is the same concept of like the hyperlink routers you can route messages to certain contracts on remote chains based on an understanding of the network topology and the application topology so an application can exist across n chains and depending on the user intent or or the action that the user is performing you can actually route them to specific chains um depending on kind of like whatever routing policy you define um and so one one example of uh i guess a use case of this that i'm excited about is like uh this concept of a gas price or or basically like uh gas minimization routing policy that allows you as an application developer to route computation um that needs to happen in your smart contracts to whatever the cheapest chain is at the current block height and so you know this theoretically would allow you to provide a better user experience for users because you could you know optimize for fees while not requiring your users to actually you know move their keys or their assets to different chains all this can be exposed from from a single chain interface and have kind of these messages that are passed between chains unbeknownst to the user so anyway that kind of sums up uh the messaging api piece i wanted to cover this is kind of the core primitive of interfacing with hyperlink um but today i wanted to talk about interchange accounts which kind of actually eliminate the need for you as an application developer to deploy contracts or rather for contracts to be hyper lane aware on both the sending and receiving side um so like i like i mentioned before this this messaging api doesn't define what data you can pass or how it's structured it's just raw bytes and so you can kind of have whatever messaging coding you would like to see if you want to implement kind of application specific features on top of this api this messaging api you need to write specific messaging codings for those application specific actions interactions so you would need to have you know some way to encode a token transfer or a swap or someone staking on a on a remote chain etc so these are all kind of like application specific uh uh i guess like um consumers of the api that you would need to implement um and so this concept of inner chain accounts subverts this uh idea of like application specific uh encoding and receiving um by just leveraging the existing api encoding in the evm and you know at a high level like this concept allows smart contracts like i said to to control accounts on other blockchains in a way that minimizes security so the two features of this system are being able to deterministically create an inner chain account um so what this means is you know a contract on chain a can deterministically create an account on chain b and uh users or contracts on chain a and chain b can have kind of predictable knowledge of where the contract on chain a's in your chain account um would be um or what address it is basically to kind of let uh use in in application logic right so if you want to if you want to have logic which says i want to allow this remote contract to have this permission whether it's you know an owner or a mentor or some concept like that you need to know where that inner chain account will exist so this is this idea of like deterministically creating an account and then subsequently allowing the uh controlling account on the source chain to relay a transaction to the internet chain account that gets submitted and executed on the target blockchain anatomically so the kind of main difference between this api that um that we're working on right now we're working on deploying probably will be done in the next week or so is that you don't have to deploy receiving contracts on every chain and this is um i think a much simpler and much lower lift wave for us to kind of get backwards compatibility with existing smart contract systems because using just a specific like abi encoding that exists in the evm everywhere on all these different chains um you can use this like interchain account api to dispatch a call to a recipient contract that doesn't need to be aware of the hyperlane api or messaging api and we'll just treat this inner chain account that gets created on the destination chain like any other address like any other local contract or any other local eoa and and this is possible through basically like some create two magic i don't want to like get too much into the implementation details because i don't have much time but yeah we're kind of like encouraging people in this hackathon to try and use this new api again um we're we're still in the process of deploying it on midnight i think we already have kind of some some pieces that you can start with if you just want to test test locally but yeah we we basically love to see participants of the hackathon use this new api because we think it might be it might be easier so yeah i wanted to quickly go over a example of how we think entertain accounts could be useful so like i said um we think i guess we have the hypothesis that the interchange accounts will give us uh improved backwards compatibility with existing contracts and the reason for that is like we said receiving contracts don't need to be hyper lane aware so what that means is a hyperlane aware contract can use interchange accounts to communicate with any contract on any blockchain without that contract knowing that the communication is coming from a remote blockchain um and i think this is like pretty powerful so in the example of cross-chain governance you could a mat i assume you know a lot of you guys are probably familiar with daos and how dao governance works basically like to summarize there is you know i guess most styles use token voting to basically decide on what transactions a dow contract should execute if if the vote reaches a sufficient like forum of voters and um you know today these calls are limited to the local blockchains where that dow is deployed and so if the dao wants to like perform cross-chain actions they need to you know basically oracle eyes some mechanism for um relaying the contents of like a decision that was made by a dao to other chains and this is actually how um i think uh ave governance works now for example there's like this oracle system which which isn't really i think it's in my opinion not aligned with um some of the rest of the ethos of the ave project but um they they could instead use a system like this to to relay decisions by just passing the uh calls from the governance proposal as these cross-chain calls through an inner chain account so the dao could could basically have an interchange account on all of these remote chains and any child contracts or sub-dows or um you know whatever consumers of let's say the ave dao can now just transfer ownership to these dao interchain accounts and basically give give power to this like remote tao over over all of the like owner authorized actions on their contract um and so we can now create these sort of like cross-chain permissions and authorization relationships in a way which is not doesn't need to be application specific so that that's pretty cool i think we're running up on time so i will kind of just leave some time for questions and then uh maybe we can talk a little bit further about uh additional ideas for the hackathon if if there's time um so yeah if i don't know if there was anything in the chat looks like there was one what are the ica function um yeah so like i said we're still actively working on deploying this so the uh i guess the interface is still slightly in flux but let me pull up the code for you just to kind of illustrate cool so um yeah basically the functions on the inner chain account contract will be this ability to dispatch api encoded calls which is uh i guess these things um to a recipient contract um so concretely like if you wanted to let's say perform a uniswap v3 swap on a remote chain the recipient address would be that pool contract and then the data that you pass would be the abi encoded call um that you have to make to that contract and then the hyperlane uh interchange accounts yeah exactly like a multi-call that's exactly right um so i think probably like we we've basically just prototyped this through so far but yeah that's exactly right you'll you'll basically have like a multi-call interface um that you can just pass api encoded calls cross chain um there's also like i said there's kind of deterministic uh i wish i had a more um a more stable interface for you but i don't want just basically everything all this code you're looking at right now you know treat with a grain of salt but um yeah you'll be able to basically like compute the address of an interchange account for a contract that exists on a remote chain even before they've ever like even before they've necessarily made a a transaction through their inner chain account um which is pretty cool and that that's possible through create two so basically the create to address of these interchange accounts is salted by the uh by the origin chain and the sender on that chain so each kind of chain and contract has uh interchange accounts consistent interchange account addresses across all of the remote chains um and you can imagine even like creating a cross chain wallet that leverages this um if you wanted to kind of like route user actions through a single smart contract um you could have like natively cross-chain account abstraction that sort of thing but yeah great questions uh if there's not anything more i think i have to seed the floor but yeah thank you guys so much for the time um and would love for you to hop into our discord we're also hiring if uh you are looking for a job shameless plug and yeah reach out an email if you have any further questions like i said the docs are options.network and you should have all the links there it's a great respect session and yeah feel free to follow up over discord it's a sponsor dash abacus and you'll find york there thanks a lot everyone