IBC Protocol Workshop: Interchain Accounts & Relayers

[00:00:00]all right um good morning everyone here live in uh in south korea and uh good morning afternoon or evening to everyone uh watching on the live stream or uh watching the live stream after um today i'm going to give a workshop on ibc how to get started with it but first a little bit about myself i am thomas de geaser i work as an ibc devils at interchain gmbh started doing that in february this year so only like six months so pretty new to the ecosystem but very excited about interoperability in ibc and hopefully i can share some of that excitement with you today uh so before we start the workshop let's uh look at the goals of the workshop um so what we'll be doing uh today is first and foremost get a high level understanding of ibc to make sure that you can go and visit the docs yourself and know where to go and how to read them and follow and understand them then we also have the demo itself from the workshop i already sent the people who are here a link we'll see the link in a minute for those watching via the live stream so for the workshop if you feel comfortable following along with the commands that's perfectly fine if you're not and you don't want to multitask you can just follow along with me uh the most important thing is that you follow and understand what i'm doing rather than simply like copy pasting the commands uh so that you can do it uh on your own yourself later another important point that i want to mention is that in the cosmos ecosystem like development is always ongoing so i think it's kind of important that you learn to manage different versions of the software and in this particular case on the ipc demo uh the relayer software and this is particularly important because right now we're actually at a time when both uh major relays the goal angry layer and the hermes relayer are going to have a new major release soon v2 for the golang relayer v1 for the hermes relayer so the the versions that are specified in the demo you can use them and then everything should work fine but feel free if you revisit the demo at a later time to try it out with your own version that is the latest at this time and i think it's also important to like look at what we're not going to do in this workshop um ibc uh is you know the inter blockchain protocol so you need two blockchains uh running to to work with ibc but it's out of the scope of this workshop to really look at how you build uh your own chains or your modules we're not going to look too deeply at the code um and also custom configuration of your chain configs and the genesis files this is not something that we'll handle in this demo you can of course always like visit the docs or look at other workshops or the documentation all right so hopefully i will get your attention after this talk and if you want to go further along the path of developing in cosmos with ibc or with the cosmos sdk or with tendermint i want to promote a little bit the interchain academy in the chain developer academy that is so this is essentially a program that we started in collaboration with b9 labs that wants to train uh it is 5 000 developers in the next three years and this is free of cost so this is a program that is self-paced six weeks and the intention is to train web 2 developers into web3 developers or blockchain developers because we believe you know we need a lot of people to join us to to make sure that we um you know get the cosmos ecosystem uh flourishing so there are some uh next cohorts starting in december and september and december um so what you will be doing there is you will be building with the cosmos sdk you will also learn about ignite cli you will learn about cosm.js to build your interfaces you will learn how to run a validator node and finally you will also learn to run a relayer that enables ibc and the idea is that if you follow this program and you finish it you might get a better chance of getting hired at one of the core contributors in cosmos so actually the content that you have in the industry developer academy is exactly the same as the one that you will have in the cosmos developer portal so you can follow that with the link that is over there it's tutorials.cosmos.network so once again we have all of the content that is there on the sdk ignite cli ibc and cosm.js we have some tutorials there blog post and it's continuously in development an important point is that probably if you're new to cosmos and you're new to developing with the cosmos stack you might first want to go to the cosmos developer portal and this will make you ready to then go into the github repos and into the documentation on your own all right so now about ibc i think it's always important when you start learning about something new that you understand why you're doing it and so ibc as you can see is the interchange universal general purpose interoperability protocol and when you think about why do i use ibc i think it kind of like splits into two parts the first one is why do we want to use interoperability in the first place and i think it's pretty clear at the state of blockchain industry right now that we won't have like one chain to rule them all and that interoperability is is actually quite important um a little anecdote for myself i wanted to get into blockchain development since a long time already i think 2017-2018 and i didn't have any development experience back then so i was really like looking at all the different languages all the different ecosystems and i found it quite hard to pick my particular ecosystem because i thought like back then there was no interoperability or at least less i mean cosmos was there but mainnet hadn't been launched and so a choice for one particular ecosystem would be like quite a big choice in in terms of energy and investment and i think interoperability really helps the developers here because if you build an application you know that through interoperability this application might be uh spreading out to all of the other ecosystems and uh yeah your application might be used to the full extent and the second thing is why would we pick ibc over competitors competitors for example being simple um token bridges that use some multi-stake well it's because ibc is secure it works with a light client um mechanism that we'll look into a little bit more detail later so basically we don't need to trust the the middleman which in this case is the real layer so we have two blockchains and in between we have the relayer we don't actually have to trust the relay anyone can spin it up and we're actually going to do this in this workshop and we don't have to trust a relayer to make sure that um yeah our assets are secure and so this is the permissionless aspect and third ibc also supports generalized message passing so it's not just that we're able to send tokens from one chain to another it's really that we can send any packet of arbitrary data over the relayer from chain a to chain b all right so this is a diagram about the cosmos stack maybe many of you are already familiar with it but still it's good to have a resume um so we have the cosmos sdk tendermint consensus core and ibc so tendermint consensus is at the bottom so it takes care of the consensus and networking layer then we have the cosmos sdk which is the application building uh layer and then we have ibc uh that takes care of interoperability so right now in ibc i think this may be already a little bit outdated 45 chains are connected and some additional data and even though ibc originated from the cosmos stack it's important to realize that it's not like limited to the cosmos ecosystem so we really have the aim of expanding ibc really to pretty much any chain that is out there and some of the projects that you see there composable finance has been working on bringing ibc to base chains so in the polkadot ecosystem and this is all almost finished and then we also have the near blockchain which they are building a bridge towards all right so a first slide of ibc i think you can you can look at the diagram first so there we have our two blockchains chain a on the left chain b on the right we have multiple relays in between so the relayers are the parties that are responsible for transferring the packets over to the other chain and like we mentioned this is permissionless everyone can simply spin up a re-layer so this is why we have the multiple relayers to really make sure that you understand that it's not just you know one or two relayers pretty much anyone can do this and so also in the diagram we see the light client that is over there but this we will look at in more detail and what we also see is that we have kind of the split between the ibc tau or transportation layer and tao stands for transportation authentication and ordering and so what this does is this is the layer the core layer that is responsible for simply making sure that packets can be transported authenticated and ordered if necessary from one chain to the next and then on top of that we have the application layer and this is really the layer that makes sure that we can encode decode and interpret the packets that are being sent so for the transport layer the packet data is pretty much opaque we don't need to know what is in the packet we just make sure that it gets sent and then the application layer takes care of the packet data uh this is uh i guess the diagram uh that if you understand it you probably understand ibc on a high level uh don't be afraid of it we're gonna go through um i'm not sure if you can see my mouse here but basically the the top part of this diagram is the application layer and most of you will probably be building ibc applications so this top part is actually the one that you'll be mostly concerned with so there we have for example a user that initiates some kind of transaction on an application then it will interact with ibc and here we see the clients connections and the channels we'll look in into that in more detail we also have some proofs standardized keypads and i think here it's very small but we also have the relayer and basically uh when we have the ibc gorilla repo which is the reference implementation of ibc that our team at interchain maintains pretty much we take care of all of this so the clients connection the channels and everything around it which is the transport layer as i said and then it's up to other developers to develop some applications even though the ibc go repo also contains some applications two of which we will see in the workshop later all right so as i mentioned we kind of have like three main layers of abstraction inside the ibc protocol and i'm actually going to go from the bottom up to the top first we have clients so clients track the consensus state of counterparty chains so we can imagine that if we have two blockchains and we want them to communicate we need to make sure that you know they understand how to interpret uh the state of the other blockchain so that they can really know that a packet was indeed sent and this is what the clients or the lite client is responsible of so essentially when we send a packet on one chain we will send or submit a commitment proof and this will be recorded into the state then a relayer will construct the packets and add a proof that this was submitted into state and then submit this on the receiving chain which can then verify it using the the lite client of chain a that they have stored on uh unchain on chain b and important to realize here is also that um we have a different light clients per consensus type so like i said in the light client uh tracks the consensus state of the counterparty chains so it's kind of logical that if you have a different type of consensus that you need a different type of light client and so for a long time ibc was in fact limited to cosmos chains and more particularly to tendermint um consensus type chains but now with the work that composable has been doing we can also go for example to substrate and hopefully many more will follow sorry then on top of clients we have connections so connections uh essentially you know establish the connection between two blockchains once we have the clients set up and what happens in connections is basically kind of a double identity verification so you must imagine when two blockchains want to connect with each other that they kind of have a picture of the blockchain that they want to connect to and the other blockchain also have has a picture of the blockchain that they expect to connect to and so what happens in the connection handshake because both channels and connections will be set up by handshakes what happens in the handshake is basically we're going to look okay are you who you say you are so is the blockchain that wants to connect to me uh effectively the blockchain that they pretend to be and is the picture that they have of me really me all right so it's kind of a double identifier verification and if that checks out we set up the connection and then we can have the last layer of abstraction which is channels and channels also gets set up with a with a handshake and channels actually um identify in combination with the port they identify the application so for example if we have a fungible token transfer over ibc this could be a transfer slash channel zero which is the channel uh transfer here would be the the port name so sometimes this is kind of misunderstood people think a port should be like a number like uh 8080 like we have in in traditional web development but uh in in cosmos development and ibc uh it designates like the application um so for example transfer uh or for contracts uh with cosmosm this would be the contract address and then here we have the the base dna an important point is of course the relay operators because if we have two blockchains but no relay operators then ultimately we cannot do communication we've mentioned already a few times that reeling is permissionless it's potentially incentivized we are actually close to releasing the final version of ibc v4 which will include femaleware so femaleware is an on-chain protocol that allows users to add fees to directly incentivize the relayers it could be either the end user or chains could decide to do this themselves of course up until now relayers also got incentivized for the work that they do but this was happening in a hybrid of ways and if you um click through uh this medium blog post uh it's called reeling relaying the message a deep dive into ibc reeling operations we go into a little bit more detail on what really is how you start it and the different ways that real layers get rewarded and then this is going to be important for today so there's different implementations of relayer software you can use any one of them and actually in this workshop we will be using two different ones so we have hermes which is written in rust and developed by informal systems and then we have the gory layer which is obviously written in go which is developed by uh strange love ventures um security is an important um value of ibc so it's good to look at the like main two security principles that we have uh the first is we need to trust the chains that we connect with so this is uh different than for example a bridge that has a multisig so a limited amount of parties that we trust to verify the transactions in ibc we don't have that we have the the lights client implementation and ultimately in ibc we assume that the chains that we interact with are trusted and if that is the case then ibc will not falter and the second one is fault isolation so if anything were to happen either through some kind of error or misbehavior of any party if that were to happen ibc and actually cosmos as a whole has the idea of fault isolation so that anything happens to for example one particular chain if you have an interoperable ecosystem it's quite important that you can isolate defaults and make sure that not the entire interchange will be affected so for developers and people who want to build a chain with ibc this is also kind of important so what is needed to connect your chain with ibc so first of all you need to have a chain this is obvious but still if you don't have a chain so first you can build it for example with the cosmos sdk or even with substrate now that substrate can also be connected via ibc the second thing you need is core ibc which is a transport layer as you see below in ibc ibc go that is we have the um we have this out of the box the transportation layer and then we need um a light client on our own chain that is able to track the state of the counterparty and we also need to make sure that the counterparty that we want to connect to also has a light client available that under understands the consensus of our chain and so in the best case scenario for example when you're using cosmos sdk and this has a tendermint consensus this will be already out of the box if you have another type of consensus or another type of application framework then cosmos sdk that you're using it could involve a little bit more development work and then there's also like an asterisk which means that they're also like solo machine which is as the name implies uh just one machine that we can also interact with ibc and this happens instead of a light client we have there uh some simple key verification method that enables you to interact with with ibc all right so let's take a closer look at an ibc packet lifecycle so this is the example of ics-20 which is fungible token transfer over ibc so on the left we have [Music] our tokens that are being locked up on chain a by a user because they want to send over tokens to chain b in the middle we see that after they have been locked up this packet is indeed being sent and as i mentioned before on the chain b what will happen then is the line client verification algorithm will check if indeed we did this locking up of the tokens on chain a and if we have verified that this is indeed the case we can then mint ibc vouchers representing the the tokens of chain a on chain b and this is another way of looking at this so once again we have the user here this is a more generalized packet flow by the way so we can do this for tokens but we can just as easily follow this for a regular packet that has any uh kind of data so we have a user that wants to send over a packet we go to app a app a gives a send packet command to core ibc um then we have the relayer who is going to query and see that the send packet has been submitted so along with the proof they submit a receive packet on the counterparty chain when we have the on receive packets some logic can be executed and we will also have an acknowledgement that is being written and then the acknowledgement will follow the opposite way back to the source chain so that source chain also knows that the packet has been received on the destination chain all right and after this we can for the first time go to the demo so the link is right here all right uh i hope everyone can see this um so in the demo um we have the overview um here setup is the installation so i already sent you guys who are live here in korea the instructions to install so this is both the hermes and golang relayer also the repo itself you can clone [Music] but first before we start let's look at what we're actually going to do in in this demo so in this demo we're going to use two ibc applications so remember i said we have the transportation layer which is already finished and then we have application layers um and the ibc go repo also includes uh already ics 20 which is token transfer and also chain accounts and so today what we're going to do is we're going to have two chains uh one chain is going to be hack adam the other chain is going to be soul because of interchange accounts we have we will see this later controller and hosts host and so soul will be the host and hack adam will be the controller and the first thing we're going to do in the first part is we are going to send over some tokens from the hack from the soul chain to the hack atom chain and then in the second part when we have interchain accounts we will delegate some stake from the hack atom uh chain um to the to the soul chain without actually doing this on the soul chain so we're gonna do this from another chain which is the functionality of end chin accounts but that second part will be later so the first part of the of the demo will be to send over some tokens from the sole chain to the hack atom chain i have my terminals set up here it's a little bit difficult with the mic but let's see so first off what we can do i'm gonna drop the mic for a bit so um yeah you can first check if the binaries for hermes and the golang wheel layer are installed by simply using the the version command this should probably be fine then the next step what we're going to do is we're going to bootstrap two chains and start them in the background so if we go for example to the to the repo of the code we see that we have a make file which has all of the different commands when you scroll all the way to the bottom those are the commands that we'll mostly be using in the demo so here you see init that has the killdef which basically makes sure there's no chains running in the background which can mess up with our with our program and we're going to install the binaries so let's go over and do this so here we have make in it this will take a little while to set everything up so here we can see it's installing the binary the binary here will be icad and you can see that a lot of things have been happening to get a little bit of a better overview we're going to take a quick look at the init command so this is below network here it is so basically here we have a number of variables so we have mnemonics for some accounts so we have a demo wallet we have some validators that we're going to set up we also have some accounts for our relayers uh all the different ports but like i said we're not going to go too much into detail that's out of the scope of of this presentation but as you can see what we do here is we remove previous data we initialize the chains adding genesis accounts creating and collecting genesis transactions to make sure that our validators that we will need have some stake delegated to it to them and then we're just going to make sure that all of the um defaults in the configs are being changed and that we have everything set up to to have our particular setup here on the bottom this is also important this will be for interchange accounts but we'll come back to that later and then the start command or the start script rather is uh simply starting our binaries and as we see that everything has worked out here we can now trust that we have two chains running in the background and we can go on to the to the next step um so here this is just like to see the situation that we had before make init so basically we had the code and our repo ready uh but the chains were not built this is why they have like the the dotted lines um after we had this command make inits finished we now have the chains that are ready but to use ibc we still need to make sure that we have our connections well actually our clients connections and our channels set up but before that we will also make sure that our relayers are configured and so we have both commands now uh in this uh demo we'll be using both three layers so uh we'll be using both of those commands if you prefer one relay over another then you could decide for example to use only hermes an important addition to that is that right now in the version that we're using version 2 the release candidate 3 interchange account support was not yet added in the go golang relayer but i think the version that was released yesterday the release candidate 4 should include it but i haven't been able to test it yet all right so this initialization of the hermes relayer essentially what it's doing as you can see it is um setting up keys so just that we have um uh keys set up for our relayer accounts so if we need to submit messages with our relayer that they have an account that is also funded [Music] we can also take a look here in the in the repo below network network is actually the only folder that we will be using often in in the demo so if we look at hermes we see here that we have the config the tumble and essentially for all relayers what is important is that we set up the the config for hermes for example what you can do is you can go to the hermes website and on the hermes website you will find some information on the installation uh if you had some some issues of installing and then also we have the configuration and an example configuration file which has also a lot of comments on what the different parameters are but so for hermes it's important that you copy paste this file and make sure that if we have our chains here below this is the most important thing and that we have everything that is correctly filled in so here we see that our chain id is hack atom for one chain uh sole for the other chain and then some other ones that are important are the rpc and grpc ports and also the websocket and some other parameters key name for example is also important this is the key that we just set up in the make init hermes relayer script and this is what we do for hermes and then we have a similar thing for the golang relayer uh and actually in this script for the goal angry layer let's look at it for a second should be this one here we will actually have the commands relay config in it and essentially what that does is it creates the configuration file for you if you haven't got one yet so the default folder is in your home directory with dot relayer but here actually we are using a custom home folder so oftentimes when you are developing yourself you may want to choose this option just so you don't clutter your main configuration file especially if you're testing locally like we are doing now in the demo it could be very useful to have a custom configuration file and then use your main configuration file if you're really on mainnet um and as you can see we have initializing adding configurations for both the chains and some paths um and then restoring accounts again is making sure that we have um our relay our accounts uh funded and uh with the keys attached all right so then we can go back to the demo repo and look at the next step um so as you can see here the next step is to create a connection between both chains so this is the ibc part and we're also going to create a channel that is for ics 20 transfers and so when we have one of those two commands it's important that you don't do both uh because then we will have two separate connections and two separate ics 20 channels and so for this um demo we're going to use the go language layer for the first part so we're going to execute this command so we have make setup a golang relayer and so this is going to go through the the steps so here we see for example already a client created so it's going to click create some uh ibc lite clients on the chain so we have clients created what else can we see the next thing when we have our clients created is the connections so they are on top of the clients connections they have a handshake and let's see if we can find some information um something to note here is that um this could be a little confusing that you have a lot of errors but that doesn't necessarily mean that there are in fact errors sometimes it's just that we are querying for packets for example and that it's not finding packets just because there aren't any so don't be fooled by that actually what we can do is when you have this setup so the script has finished and now we can actually check if we have the the required connections and channel um so by the way i have a tab here for relayer i also have two tabs um for the controller chain and for the host chain so controller chain is hack atom uh host chain is soul and a separate terminal tab for uh the relayer and so this will be like very important is that when you have the binary that you can use the help function and actually when you go and look at the repo for the golang relayer um here it is you will see that they have um some documentation but they do say that you know it's probably better to look directly at the at the help and then you will see the available commands so we have something to to set up the config which we already did chains path keys but we can also query so what we're trying to do right now is we're trying to query for the connection and the channels to see if they have been correctly set up so there we see that for example um we have um relay query clients but clients created this we got so let's try connections and so i'm first going to try it like this but this is going to give a mistake and the reason why is because um we have chosen a custom home directory for our configure configuration file so this we already we also need to give into the command line and if you have a jq installed this is a tool that will output the information in json format which is a little bit nicer to read let's see looks like we still oh yeah we forgot the chain all right so it's important that you also tell on which chain you want to look for connections we can do this on on both chains i've now done it for hack atom and here we see indeed that we have connection id connection zero so in fact our connection has been established um some more information you see here is that our connection builds on top of a client so we can see the client so it's going to be a tendermint client and it's id 0 we have some version information the state so our connection handshake is essentially going to finish with both connection ends in the open states and then we have some information about the counterparty and then we're going to do a similar thing but this time for channels to see if our channel has been correctly set up and there we see that we also have a channel so here we see some information it's an uh an order channel so token transfer channels are unordered um channel is open uh port id is transfer so we're working with ics 20 token transfers okay so that looks good to go when we go back to the repo then we can start the fundable token transfer part and first thing that we're going to do here this is just to make our lives a little bit easier these are two commands that are going to export some environment variables these are the demo wallets so on each chain we're going to have a demo wallet that has some funds attached to it that we can use all right and it's important if you do this that you pretty much do it in each of the different tabs now for me this should already be fine because i did this in the preparation but let's just do it again just to be sure there we go and then we can go to the first transaction so now we have set up the client connection and the channel for transfer we can go ahead and take a look at the actual command so here we see we have the binary tx ibc transfer transfer a lot of transfers but the way that you would go about it if you are unsure what the command is you could so you could go and check also with the help commands and then for example you will see a transaction and basically do uh the the different steps until you find this command let's copy it and actually we want to um send some tokens from the host chains from soul to hack atom so this is this terminal command it's actually not really necessary to have the correct tab because ultimately here we have uh the node which we are specifying right so even if we were to submit this command in the different tab it would still work but i think it's just like easier to follow if you do it in the correct tab so now we're going to send this command where we are sending i think it's 11 000 stake which we're sending from the demo wallet 2 on the on the soul chain to the demo wallet one on the uh hack item chain all right and actually i noticed that i forgot to spin up my relayer which obviously we need to do um oh and by the way i see that i didn't add this in the in the repo so this is something we should do oh and actually i started the hermes relay i meant to start the golang wheeler but both will work all right so here we see that some packet has been sent i think the the timeout is set at one minute so we were just in time uh to make sure that there was no timeout and now we can check if we have received our funds by using this command so this is just a query to see if what funds are available in the demo wallets this is on the controller chain and here we see that we have 11 000 and what we see here is actually not the stake so we sent 11 000 stake from the host chain um but what we see here is like i said it's an ibc voucher and this is a representation of the 11 000 stake but on chain soul and because this is obviously not super easy to to read we also have a command that allows you to have this hash and actually reverse it and give you the the regular output so this is the command d numtrace and we can do this on the hack atom chain so uh query ibc transfer ddom trace and then you just submit the hash so ibc here is just a prepend to clarify to people that this is an ibc asset and if we put enter then we see that we have the base neenum which was the stake that was used on the host chain on the soul chain and then we have some path information like we said this has the port which is transfer and then the channel zero and basically this uniquely identifies because our channel goes from the soul chain uh to the to the hack atom chain so this uniquely identifies the ibc assets all right so now we have um some assets on the on the controller chain from the host chain and this will set us up for um we can probably kill this for a minute and this will set us up for the second part which is uh enter chain accounts but first we'll go back to the presentation for that all right so token transfers we have now seen in action and seen that it works and token transfer is an important first step but of course like we mentioned in in the introduction with ibc we can send arbitrary data so we don't just want to send some tokens we also want some more customizable application logic and so you could do this in two different ways at the time so we have interchange accounts and custom ibc applications and we're kind of going to take a look at what the difference is between both and why you would use one or maybe the other so let's start off with custom ibc applications so essentially this is a module an ibc module that you build from scratch yourself so in the documentation we could take a look at this so we here we have the ibc go documentation here applications this will basically go over all the the different things that you have to do to build an ibc application module uh so we have to implement ibc module interface um so this will have some channel opening handshake callbacks channel closing handshake callbacks packet callbacks it will bind to ports like the transports that we saw with um token transfer adding keeper methods and so on so basically this should give you an overview of all the things that you need to implement to have an ibc module and then of course what you will need to do is add your specific application logic so this is basically like a completely customizable way of developing application modules so here we see that we have a module that we build we can send pretty much you know any data that we want then goes to the corresponding module on the counterparty and what we see here on top is that we have ica sx for example token transfer was ics 20 so the number actually defines a particular application now the thing is when we develop these applications like it takes a lot of development effort also it will take some time for it to get standardized for example recently we had the ics 721 which implements the spec and the implementation of interchain nfts but this you know takes some time to develop and you know if you want a lot of customizability in the application logic this may be the way to go but if what you need is something else you could also use in the chain accounts so what interchange accounts allows you is basically to use functionality on the the host chain so here this is chain b to be used by a module or an account on chain a which is the controller chain so i like to think of it as pretty much an api so for example say that we are developers on chain a and we are developing some type of module and during this module during our execution of the logic we would need some functionality that is present not on our chain but on chain b for example so what we can use in the chain accounts for is basically to have a programmatic way to use this functionality on chain b without leaving the environment of our own chain a so to make this a little bit more clear we're going to take a look at the architecture so once again the different namings like it's important to get some familiarity with that so we have the host chain which is um the chain that will host the interchain account and then we have the controller chain so the controller chain is the um the chain that will trigger the actions to be executed on the host chain once again you can think of it like an api um and then these two things we'll take a closer look at in the next picture but what is important to notice is that as a chain you could choose to implement both host and controller functionality or you could simply choose to implement one of each right so you have the choice in that and actually what we've seen up until today is that most chains have or a lot of chains actually have had this host functionality included but not yet controller functionality and we'll take a look at why this is so here we see another diagram so again on the left we have the controller chain on the right we have the host chain so what is happening this is for actually already an execution of a transaction first thing actually uh is that we need to register this enter chain account so when we see the two main functionalities of in the chain accounts this is register in the chain account and then we can send a transaction but the important thing here is that on the controller chain um ics 27 the module that is present in ibc go implements this and this actually works as middleware but this has to have an authentication module that basically has to be built by customly by developers and that's why we think that you know up until now there's not so much adoption of controller chain because chains will have to figure out how to build the authentication module and again we have uh in our docs like step-by-step guides on how to do it but still it takes a little bit more time but basically when we have uh this we can wrap the middleware around and then we can go to the other chain where we will um yeah route um the the transactions to be executed to the interchange account and the interchange account which is just actually a regular account can submit the transaction on the host chain something important to notice here and maybe this will be easier with this is that the original intention of interchange accounts was not to make sure that just any account on chain a could control an account on chain b right um this is actually possible and in the demo this is exactly what we're going to do but this was not the intended use case of entertain accounts more so it was the intention to have a chain itself or a module on this chain control an interchain account on another chain and so again to use it as an api but still there's a few different ways to do it and we can take a look at this so first and foremost the most simple is just single user uh every single user has one separate interchange account this is what we're gonna do in uh in the demo and what is actually easy about this is that when we have this module with the two different functionalities register in the chain account and send dx in this case you simply make sure that your authentication module exposes these two methods directly to the end user via this command line interface and so a small variation on this is if the interchange account is actually a contract smart contract account for example in kosum wasm and then we have like um the more like intended use cases of interchange accounts which uh we call a few to one so this is for example um a dao or a group the groups and golf interface of the cosmos sdk o46 will make this a lot easier so we're already working to make sure that we can use this easier interface but we'll basically allow a group of users um to control an interchain account on another chain and then we have the last one which is many to one so basically this is what we said before that we have a module that we're building and our users can interact with the module on our chain and if necessary our chain can trigger an interchange account transaction on the on another chain but as we said here we're investigating if we can kind of have for each of these templates if we can have some kind of a standard controller which would actually limit the amount of development work that developers have to do to create their own custom authentication modules and if we manage to do that then um yeah probably it we will have a lot more um in chain account functionality uh out there in the wild and i think i also believe that this is one of the challenges in the juno track which is basically to make sure that um a cosmosome contract which would be a module on the chain is able to be like a standard for in the chain accounts functionality all right and this sets us up for the second part of the demo so let's let's go back so um first before we start a little uh summary of what we did so the first thing we did we transferred some tokens from uh the soul chain to the hack atom chain and right now i'm going to use um the naming's controller and host so sol is our host and hack adam is the controller and like we said what we wanted to do is that we want to do some transaction that will delegate some stake um to the the host um or to a validator rather on the host chain without leaving the interface of the controller chain so specifically for interchain accounts we have this situation so our demo repo which is actually a fork of the interchain accounts demo so you can check this out as well it's actually pretty similar i just changed some names and here actually um the go language layer doesn't really work yet so it's better to like use the hack item demo repo um where were we yes right here uh so essentially um this implements also the authentication module and if you take a look at the code um if you are familiar with cosmos sdk development our modules are in the x folder and here enter tx is essentially the authentication module that we built for the demo repo but once again this is the quite simple implementation where we just expose the methods to the end user via the cli all right so this is what i forgot the first time so let's do this immediately we're going to start the hermes relayer all right so our really is set up so when we think of ibc what do we already have we had our our clients set up uh we had our connection set up we also had a channel but that was an ics 20 channel so remember i said that for each application we need a different channel so we don't really have a channel yet but for interchange accounts it's a little bit different because each interchange account that we create on the host chain will actually require a separate channel that's actually one of the reasons that initially we didn't think it would be a good idea to give each every single user on the controller chain uh a separate interchain account on the host chain because that could lead to like a lot of channels which could be an issue for relayers but hasn't been like tried maybe it's not that big of an issue but the important thing to realize is that first we need to register our interchange accounts and this will be with this command so this is section registering in the chain account [Music] and registering the interchange account is something that we want to do on the controller chain so essentially what we want to do is we want to stay on the controller chain so let's go over copy the command and let's take a quick look so we see inter tx which is our authentication module this is what we're going to interact with we have the register command and then we have the the different flags that we have to to fill in you can take a look at that in more detail later but let's see so we have submitted this transaction and then we see when we go to the relay tab that a lot of things are happening and let's take a look so we see channel handstape handshake step completed um and indeed this has been performed on the connection zero which is exactly what we want and here we can see for example um that the port is ica controller and then we have the address of the industry account so in ics 20 for token transfer we basically have a symmetrical situation where the port will be the same transfer on each of the counterparties for interchange accounts a little bit different so for interchange accounts we have ica controller dash and then the interchange account address as the port id on the controller chain and then on the host chain we have the port ica host without any uh added information all right um so let's go back so we have now uh hopefully created um interchain account we're going to see by querying so back on the controller chain we're going to query in the chain accounts so this is just a regular query that looks um at the interchange accounts that are present and then we see indeed here in chain account address which is this one so that should work and now ultimately our end goal is to use this in the chain account to submit a staking delegation transaction but of course this is going to cost some some funds some gas um and this is actually the next step that we need to do is essentially to fund the interchange account and then we can go ahead and send our transaction this step is just to make our lives a little bit easier and we're going to export the ica account address so let's just do this in the two terminal tabs just for safety all right so we've done this as i said next step is funding the interchange account wallet we can just check so if we check on the host chain which is where the interchange account is located oops we're going to check for the balance of the interchange account address this should be zero because we just created it and in fact we see that there is no balance yet and then we have two ways of uh funding this in the chain account one way which is just a regular bank sends on the host chain this is what the original in the chain accounts demo uses but i thought it would be more interesting to use actually in the chain token transfers so essentially what we're trying to do here is for example if you had the the native token of the host chain already available on the controller chain so for example this could be that you go to osmosis and you make a swap and you actually have the native uh token from the from the soul chain without actually ever interacting with the soul chain um and you have this um we could take another look at the balance um let's see if we have one here i think it was this one so again just a little reminder the balance of our demo wallet on the controller chain is uh essentially these 11 000 and the ibc voucher uh and what we're going to do next is we're just going to send a part of that to the interchange account address via an ics 20 transaction and then we can use our funded in the chain accounts um all right here we were so this is our command for the ibc transfer um again we are on the controller chain so ibc transfer uh transfer transfer channel zero we have the uh in the chain account address that is the recipient and we're going to send over 9 000 of our 11 000 funds and then we just have the the regular flags let's take a look if our relay is running and yes it is so if we perform this we can take a look yeah something seems to be happening always takes a while but it doesn't actually take that long so we should be fine and if we check now again for the balance of the interchange account address it should be funded and indeed it is and we see that um we have our original denum back which is just a native stake and we have nine thousand of this so okay this is now our situation so we have the controller chain uh host chain we have our interchange account that has some funds attached to it and the next step is going to be that we want to stake some of these funds to one particular validator and this is the the next part so here we see that um we can send in the chain accounts transactions using the enter tx which is our authentication module and then submits um and yeah we have the the example of a staking delegation so this command first is uh just to find a validator address on chain on the host chain on soul chain so here we have the validated address and then this is actually the interchange account transaction and so basically what we submit here as you can see is the transaction data so this is what is going to be inside the packet and then on the host chain this packet is going to be decoded and we can simply submit this transaction on the host chain so let's copy this and let's go to the terminal again so again still on the controller chain haven't left this interface and we can submit this let's check again relay is still running so that's fine and let's submit this we see that something is happening all right so this should have worked and now we should have uh some stake delegated to this particular validator and um by the way there's also an alternative way to do this if you don't want to add this to the command line interface we can also have a path to a json file that essentially includes the the same information yeah it tells us to wait until the relayer has relayed the packets and then we can check with the quarry of the staking delegations for the validated address so this is going to be on the host chain oh and by the way i should mention that we staked 3000 steak and here we see this so um this uh huge amount of steak is essentially created in the genesis transaction and then here we see the 3000 which we have just delegated ourselves all right um so yeah this is the end situation where we effectively delegated some stake from the controller chain without leaving this interface uh to the host chain so let's do a little recap of what we did until now so we first sent over some tokens from the sole chain to the hack item chain basically this is a step we do in the demo but ideally the scenario is that you don't actually have to interact with the host chain you simply interact with the controller chain which is what we did so again if you want interchain accounts first you need uh to register your in the chain account and then you can use the transactions those are basically the two functionalities and the next thing that we will have in the demo is a timeout scenario but let's first go back to the presentation and talk a little bit about this so remember that early in the presentation i gave you this packet flow for the happy case but of course not all cases are happy and sometimes we have something that happens and here we see that the relayer for some reason or another maybe they were online maybe something else happened but for some reason they did not pick up the packets and so when we don't pick up the packets obviously we don't want our packets especially when there are funds attached to it we don't want our tokens for example to be locked up indefinitely so that's why we have some kind of a timeout functionality and what we see here is the query non-receipt so the cool thing about ibc is that we cannot simply query to see if we had a receipt of our packet of our token but we can also query for non-receipts so if the timeout period has passed we can use this query non-receipt and if that comes out positively and we can submit on the source chain a timeout packet command or message and then yeah some application logic can be used to revert the original sent packet logic that was executed so for example when we have token transfer that would just mean that the lock tokens are being unescrowed again and you can use them again maybe like send another transaction or you know just keep them on your account on the source chain but yeah this is basically the timeout functionality and something that is important to notice to note for interchange accounts in specifically is that interchain accounts have ordered channels and the case is in an order channel if we have a timeout basically that means that you know a packet got lost and because we have ordered channels and every packet needs to arrive in order this will lead to problems and this is why in order channels if we have a timeout the channel is closed automatically and so this is another situation that we're going to look at in the demo so here we are so we are going to test the timeout scenario so this will require some um coordination on our part because as of right now my relayer is still running so to make sure that we can test this timeout functionality it's important that we shut off the relayer for a bit so now essentially we don't have another relay running so if i were to send the packet this packet will not be picked up uh and the um channel that we have created will be closing uh so here it says first step stop the hermes relayer as we did we should wait for approximately one minute because the timeout period has been set to one minute here oh yeah and in the first step it also said to send another staking delegation transaction so let's do this this is this command again so back on the controller chain so we we said 3000 that's not enough delegation we actually wanted to make it six thousand so we're going to try this but obviously our real air is not running so it cannot be picked up let's see let's wait one minute and so while we're waiting i'm already going to go through the the next steps the next steps after we've waited enough more than one minute is to start up the relayer again and when we see this we will observe that the relayer is taking care of the unrelated packets so when you start up the hermes relay it will look if there's any unrelated packets that it needs to take care of it's not just going to start listening to packets but forget about those that it didn't pick up all right so i think that should be fine let's wait 30 more seconds and the next things that we're going to do is we're going to check if indeed our channel state has uh gone to closed as you can see here so obviously if our if our program works correctly or if the ibc protocol works correctly this is an order channel with interchain accounts and so it should be closed all right i think we waited long enough so here we go let's start up the rear again and here we go so yeah you'll have to like learn a little bit how to read these uh debugging tools but here we see or the logging tools rather here we see they extracted a timeout packet event so indeed uh when starting up the real error it looked for the packets saw that uh the timeout period had passed and um yeah they uh they submitted a timeout to the original chain all right and so the next step as we said was to check if our channels had been closed now remember at first we did this actually with the relay software but we can also just do this with the chain binary so let's check it first on the controller chain so we're going to query the ibc channel channels and let's take a look so we have our channel id channel zero remember we also made a interchange token transfer channel so this is actually the channel zero this should still be open um so even if we had sent uh another token transfer transaction this channel would not have closed because token transfer channels are unordered so it doesn't really matter if you know there's a timeout from a packet you know everything can still go on so this was our channel zero and then we should also have a channel one ah there it is it's on top the channel one and this one uh says indeed that it is closed all right so the ibc protocol did it did his job and uh yeah we're also going to look on the counterparty chain there we go so here we see same thing channel id channel one uh is closed and channel zero should still be open there we go all right but of course you know if your channel has been closed that doesn't mean that you can't use in the chain accounts transactions anymore so next step would just be to register another in the chain accounts so again on the controller chain we have this commands enter tx register and we're simply going to create a new interchange account which will use a new channel all right um yeah so the relayer was still running and so if we go back to the previous command so again we're going to query the channels so now we see we have channel zero we have channel one the ordering is a bit off and then we have this new channel channel two which is our um here we go port id is ica controller and then the interchain accounts address and then we see counterparty ic hosts so this is clearly i see host ica controller and then the address whereas as i said before for channel zero token transfer is just port id transfer and counterparty port id is also transfer all right and i think yeah we're not going to send another transaction but actually we could just to check if everything goes as planned right so now we do have our relay running and we're going to try again to send an additional 3000 delegation to our validator all right seems to have picked up the packet um and then we can check again the staking delegations and now we have six thousand all right so this worked uh and i think that's it for the um demo i think we still have some time so uh what i'm gonna do is i'm going to um maybe take a look at the um hermes um help command so yeah essentially i was explaining that it's probably a good idea to play a little bit with these commands use the help so for example say i want to create something i can do hermes create and then help say we want to create a new connection all right and so there we then see hermes create connection we have some options and we need to make sure that we uh have as a argument the chain a id and the chain b id and so for each of the different things you will find some some explanation here and all of the arguments all the flags that you need or that are optional so essentially this is what you could be doing some other sources maybe to go through okay this was the demo so again the documentation from ibc so if you want to write your own custom ipc applications this is where you go first you have an overview let's see if this loads yes there we go so this is a high level overview essentially what we did today um so we have applications as i said middleware so this could also be an important thing if we have um some functionality that doesn't really go in ibc core we could use this as middleware and basically reuse it for different applications so we could actually build an entire middleware stack i don't think the picture has been added but i should like have it here um yeah so basically what we see here is that we have the base application and then we can have middleware one middleware two but essentially we can keep on stacking the middleware and uh creates um yeah functionality that way and so here we have then on top core ibc and so um for example the messages packet and right hack are going from base application to core ibc and when we have uh handshake um setups acts and timeouts the communication actually goes from core ibc through all of the middleware to the base application and so what you can see here is that the order matters so if you have a particular order on one chain for example make sure that the order is the same on the counterparty chain all right what else do we have upgrades so this is also an important aspect so because we have the entire ecosystem on the interchain which all have ibc if we want to upgrade both our chain or the ibc version like this is not something that you can just do because you know we have uh our light clients that are um yeah depending on the information that you you have and so if you perform an upgrade you might want to [Music] plan this and make sure that the relayers can send the appropriate messages to make this a coordinated upgrade so that we can keep our light cleanse and basically can keep the channels functioning we also have governance proposals so for example if a light client could get frozen this could be because you know there was some misbehavior or it could be because there was not enough activity so basically the light client that we have on chain uh for um another chain it needs to be updated with some information and so if there's not a lot of activity between a channel between two chains um we don't really get that update client information and so usually what relayers do is they make sure that periodically even if there is no activity they're going to send an update client message just so that everything keeps running we also have a trusting period and if it so happens for any reason that the wheeler is not updating the client for longer than the trusting period the lite client could get frozen and then we have governance proposals to unfreeze the light clients relayer doesn't really have that much information it's actually better to go to the hermes documentation or to the github repo of the golang relayer um then we also have a section for the uh ibc application modules uh interchain accounts ib interchange transfer token transfer we have female ware this is the a new thing so we haven't seen a lot of implementation with that but you could go ahead and familiarize yourself with it and then also migrations for going to a different ibc version and then we also have the cosmos developer portal which we talked about already so there you have some tutorials some articles but mainly we here have the cosmos academy so if we take a look all right so here we see a general introduction to cosmos main concepts uh running your own cosmos chain so i think um here basically yeah you work with ignite cli and you're basically going to create your own chain um the example that is here being used is a checkers blockchain so you can play the game of checkers but host it on on the blockchain and then here if you're only interested in ibc we have also a section on ibc so we have the the overview general introduction to ibc what is it and then we have the different aspects or the different abstraction layers of the transport layer so we have clients connections channels again also some applications so fungible token transfer indoor chain accounts relaying so if you need some more background information on relaying you can also find it here so first we have some general information then the gory layer maybe if you go to this today like i said in the introduction there have been some upgrades for the gory layers so and also actually for the hermes relay so we're going to have to review this information yeah in general the information also about the config file and what you need to add is there and then last we we have some ibc tooling so map of zones is an interesting one basically you have this nice overview here of all the the chains that are being connected which is kind of nice um the next one is mint scan so we have min scan also now with the nice visualization of all of the chains that are connected and all of the ibc transactions that are happening so yeah min scan map of zones are good sources to find some information about ibc in particular but also about regular transactions and then we also have iob scan iob scan is still in development but it has a improves quite a bit already and so this is one that is really like focused also on ibc um i do see that this link is not working we should look into that um so that's the ibc information in the cosmos academy uh like i mentioned before um the same topics will be in the in the chain developer academy if you uh wish to apply to that there's still time to apply for the september cohort so this is the hermes documentation which we already went through um this is the hack item path all right and then a few more words on uh what to do next so as i already mentioned uh if you're interested to learn further about ibc or the bigger cosmos stack go to the cosmos developer portal maybe sign up for the interchange developer academy basically the the advantage of the in the chain developer academy is that you are guided and you also have like some exams some quizzes so if you need some accountability to um yeah for your learning then this might be a good option um you do need like some time i think it's like 10 hours per week for six weeks long that we ask for people to to spend on this another thing that you could be doing based on the demo of today is to build some custom authentication modules so what it could be it could be either the standards based on um based on these templates so for either of these sections is something you could be doing you could build your custom ibc application so again in the documentation you should find all of the necessary steps and then you can add your custom logic also two other things in the chain security will be really really nice and there's actually a workshop today i'm not sure if it's still at 2pm could be a bit later but it's by then from informal also in the chain cosmos and contracts i think also the next talk next workshop will be about ibc contracts and there's still a lot to do in the cosmos ecosystem so yeah i think if you want to develop that you'll have no shortage of of tracks to go and um i think that's the end of the presentation um yeah there's some time for questions uh first and foremost uh thank you for your attention uh and yeah good luck in the in the hackathon and hope you build great things thank you [Applause] are there any questions yes sorry yes i i do think there's some ideas um for some pruning later but um i don't think we we do that right now someone else yes um middleware is more on the application level yeah so so essentially this is also maybe interesting on in middleware we could also like manipulate for example the the packet data so some examples that have been talked about are like you know some filtering um maybe like manipulating the packet data in middleware is a little less interesting but yeah like i said you know if you have an application for it there's a lot of freedom to to use it whichever way you want yeah you had another question um so even in on order channels we have like a sequence number but it means that the sequence numbers don't have to like arrive in sequence so there's still a sequence one number i'm not actually sure what it's being used for um but yeah in order channels it's basically the packets have to arrive in a certain order and if that's not the case then we time out the channel there's also work on partially ordered channels but that will probably be for q4 of this year or later sure feel free so i just want to answer that little more i'm giving the next talk and it's very good question um sorry unordered unordered channels are basically like udp the packets arrive and you only guarantee timeout or arrival order channels are like tcp or guaranteed in order right that's really the kind of equivalent there the one key point this is um in an unordered channel any packet could time out right so pack you could get you do five packets number one is relay the number four the number two and then a five and three never deliver they're timed out then six comes later doesn't matter with a timed of you don't have any guarantees if you send multiple packets at once if you have an order channel you guaranteed you send one two three one two three will arrive if there's any of them times out the channel gets closed it's actually pretty strict meaning it's impossible for relayer to trick you and okay i'll just like drop one of those packets and run the other ones so you have guaranteed you can send three or four packages in a row you guarantee them arrive in that same order and it's very important for that it's a little more fragile it's very very strict thank you any more questions all right if not i just want to say that i'll be here the rest of the day so if you're interested in following the interoperability track um feel free to reach out to me and uh we'll look at your question uh even if it's about the documentation or about a specific workshop and once again thank you everyone and uh yeah have a great rest of the day thank you