IBC Roadmap with Susannah Evans of Interchain

Transcript

we're live my guest today is Susanna Evans she's product lead for IBC today we're diving deep into blockchain interoperability we're going to be looking at different Bridge designs and why IBC stands out also looking to understand how IBC Works under the hood looking at the fault isolation mechanisms that makes IBC safe and also looking at the future of the IBC roadmap I'm also dying to find out why she thinks animals should have stronger rights but that the vegans are getting it wrong so before we get started make sure to hit the like button hit the notification Bell And subscribe to get notified When I Grow live every week and remember that none of what we discuss here on the interrupt is

financial advice and if you enjoy this content please consider sticking with us as we're live on fmos Quicksilver very soon very very soon on osmosis just look for the interop in the active validator set my guest Susanna Evans is coming up next right here on the interrupt foreign [Music] hey how's it going hey I'm good how are you thanks for joining me on this uh on

this podcast yeah I'm really glad to be here thanks for inviting me yeah well so I mean I I first you know I first encountered you I think right around nebula's Summit last year uh you were introduced to me by Folks at the ICF and you gave a talk there and then you also gave a talk uh at the um or you're on a panel rather uh at the event that we did Medellin and uh yeah I've been wanting to get you on the podcast for a while because I think like you're one of these people that are you know really important to you know building out the IBC standard but maybe you're not super visible like on social

media like you know you're operating you know in operational sense and but you have a I think a really uh broad overview and understanding of IBC and so uh it made sense for for us to have a chat here at kind of like diving dive deep into that yeah yeah I I I remember these like the especially the pan we also did the panel at nebula that one was really great I remember yeah yeah uh but yeah I guess like I actually have only been working um on IBC since last May um but before that I was uh uh hey Carlos uh yeah but before that I was um working with zero knowledge validator so I was kind of exposed to a cosmos

ecosystem especially because they were running some privacy related events so they're quite engaged with Cosmos and yeah I guess I became Cosmos pills and really I wanted to be more involved and yeah than I uh like applied for this job with the IBC go team um and yeah that's like kind of how I got here so yeah but then I would say I'm a bit more uh under the cover on social media I'm more of a I just look at what's happening I am I'm not a massive participant I've just never really been hugely into social media maybe I should make more of an effort on that part but uh yeah it's uh I'm just in the background Maybe

yeah at least you get some work done right yeah yeah I actually have a response yeah actually when I was doing the research here I I looked I looked you up on LinkedIn and I hadn't realized that you've been working with uh with Anna and her team at the zero knowledge validator and before that you were working at Rolls-Royce like earlier in your career what were you doing at Rolls Royce so um I did an engineering degree um the first few years were General and then I specialized in manufacturing and in my first and second year of University I did some internships at Rolls-Royce um I very much decided I

didn't want to be in this traditional engineering industry it was a kind of an eye-opening experience in a way to be working in such a massive organization but there were just so many things which didn't really appeal to my working style in general um you know things are very very slow um there's a lot more like barriers to getting things done quickly just when you have to coordinate with so many layers and um that kind of thing but it was still like fun I I I was in my first internship I was working um I was working with jet engines and I was doing some like non-destructive

testing of turbine blades which is like the most critical part in the engine because it goes to the highest temperature um so you really need to make sure there's nothing's going to go wrong there and then my second internship I was you need to make sure those gen engines don't explode me there yeah yeah well you know I think a lot of people in crypto are flying quite regularly so uh yeah yeah they're pretty vital for that but um yeah it's it's it's a very heavy industry and I know yeah I was also looking at just how um I was looking at helicopter engines and um how basically looking at incidents of the engines um and like kind of trying to get to the root cause of where these problems came

from uh so pretty interesting some quite uh interesting instant reports that came through on that one which I was like very interested to read uh but yeah it was just not my not my uh long-term aspiration really yeah well I mean uh it's yeah it's cool that you you got to sort of come over to the the side of crypto um and especially working on Cosmos uh I want to get this out of the way because we were talking about it a little bit before the show but you mentioned that you used to be a pretty staunch vegan and that you've now moved away from that and I thought that was really interesting because for a couple of years in my late 20s and like early 30s I was also a pretty uh strict vegan and

I I feel like you know it was a point in my life where I was kind of going through some some changes right some like pretty significant Transitions and um and like looking back on it now I I can see how I I was like perhaps indoctrinated a little bit by like this movement of like these people that I was hanging around with at that time and it's um and that now I've sort of like totally you know put that behind me and like I'm no longer following that diet or you know really um like you know adhering to you know that ideology I I think that like I think

that radical veganism is sort of like a cult actually and uh and then I kind of got pulled into it so I'm curious what you're like what your view is on that if you if you feel that you know at some point you were kind of brought into this thing in similar ways so I think it was um I mean the trigger for me to go from being kind of normal omnivore um was I actually did um I was working in a sandwich factory and I saw um just like the scale of meat going into these sandwiches and it's like I was like okay this is literally one Sandwich Factory and there's like you know thousands of these across the world and that's just sandwiches you know uh so I was like

really that was really eye-opening and then I first just went vegetarian and then I um I didn't I I watched cowspiracy and that really made me feel kind of guilty for not going the full way [Laughter] I was indoctrinated through that but um yeah then I was like okay I feel it was very guilt guilt driven I was like okay I feel like I like I can't really um live with myself not committing to this uh so I was vegan for like three years and I was very like rigid about it and I think uh it became kind of like a part of my identity that I was like you know this vegan person and then I guess

I just did a bit more like introspection and there was some like change in my life circumstances and I realized I was kind of like holding on to this uh perspective as like a part of my identity but I didn't really actually think it was you know my real identity it was just like something which I was being very stubborn about um not like kind of for the sake of it I did believe in the whole ethical um you know Logic for being vegan but it made just normal life a lot more difficult and especially when you're socializing and meeting new people um it's just like kind of annoying and inconvenient for them and I just like realized like this isn't this doesn't

have to be a core element of me it's like I can resonate with the values of veganism but I just thought I'm just going to relax a bit uh yeah it's like yeah so that's my story and now now I don't eat meat but I'll occasionally eat fish and sometimes like cheese and eggs but yeah I I that that all resonates with me very strongly and I I think that there is there's such a huge guilt aspect to that entire movement and and you know also coming out of that I realized that you know the the there are many aspects of what

sort of the you know this this kind of vegan movement that has become an industry uh you know tries to pass off as good uh healthy eating is actually just like horrible eating I mean I remember you know discovering these you know whatever incredible burgers or you know this kind of like you know whatever you know Mash of processed oils and whatever and like every time I eat one I just feel so horrible after I felt so bad for for hours and uh I was like what is this and it's just like a lot of a lot I think a lot of these processed uh sort of vegan uh meat-like products or cheese-like products are

just not good for you and uh and and the thing is like if you if you have a pretty active lifestyle and you're not able to you know properly cook uh every single meal and like really make sure that you're getting uh I mean I'm not like I'm not a nutritionist by any means but like being very careful about cooking just like kind of Whole Foods you easily very quickly get into this uh you know eating this kind of food yeah um and I actually I've actually encountered quite a few vegans that were like quite overweight right I was like how is this possible how is this person like they're just like eating this horrible oily fatty food um but yeah another make this all about uh veganism because people are dropping off the live streams but um

yeah so I wonder if you can give us maybe like a brief history of IBC um if that's something you're you know you're familiar with because I know you've been working on the project for about a year and a half uh you know do you have a sense for where IBC came from and like how those ideas came to be uh and and you know to be implemented and active actively working as they are now so I I just I've been there a part of the IVC team for I think now it's like nine nine or ten months so a bit a bit like under over a year and a half but uh from like what I have heard um there were like um well so we still have like Aditya who

was one of the kind of um early uh contributors to IBC um there was also uh Ethan Frye and Chris goes who were involved there and Federico who co-founded evmos and then also Colin who's also still on our team um they were kind of involved with the the V1 um I think chrisco's was kind of leading the team and then he moved on to uh like Helix and anoma um and yeah Federico also moved on had Ethan uh created cosmosm um but yeah I think they were kind of the

core team then there were lots of other kind of involvement from other teams like I think uh informal did some kind of uh formal verification of the code um I know that like Strangelove were involved in the launch very much of IBC and uh I don't know exactly who was like you know working on it in those early days because this is only kind of what I've heard but then there was the kind of whole uh organizational split and you know people moved entities and stuff um and then Colin and Aditya moved over into interchain which is like where the

team is now and then the team grew um we had uh this Charlie Wilson alley member um and Carlos and Thomas and then some more Engineers joined Damien Kian we have Addie as well uh who's working on the product team with me um so I guess since that very small team the team's now nine people um like it's kind of incredible to think that there are only like you know like kind of single digit numbers of Engineers working on the protocol and it's like when it launched I think it was about over a year and a half ago now um I think it was like September uh

21. it's like around since it's something like that was the not not so sorry it was um because I know that September last year was like the 18 month anniversary so so my maths on the spot's quite terrible um but yeah I I guess I can't give too much context on the history given that I wasn't involved in the early days um but no but I think what what bear is kind of thinking about here and what's interesting is that IBC has only been live for uh I think like about a year and a half you know it was since I mean basically since osmosis launched right is really when IVC kind of took off and it it it's something that we had always

been looking forward to in Cosmos right is like when is IBC gonna go live and when IBC goes live it's gonna be great and like um but when when osmosis uh went live and IBC went live around that same time I think everybody's Minds were kind of blown as just how well this protocol was working and how um how it just dramatically improved the user experience around sending tokens and it's only gotten better since then you know in large part because it's been integrated in all of the cosmos apps so when you're using osmosis for example and you do a withdrawal the IBC transfer happens in the interface and it's just so seamless that

you sign and your tokens end up on the other chain and it just works so well and to the point now where you can use IBC without really using your wallet it's it's all built into applications and I think that's really where the value of icebc really shines is how it just improves user experience uh overall yeah I mean it's like fundamentally the the protocol is an infrastructure product like it's it's kind of designed to be there ultimately in the background like I think the yeah the best experiences like when you use these kind of front-end applications which have all of the kind of uh the details kind of abstracted

away from the user it's like you don't have to be putting in the channel ID um things like this which are a bit complicated if you're doing your IBC transactions manually through like Kepler um so that's why you know uh evmos osmosis kind of axler as well and there's there's loads of other examples as well um who have kind of done this abstraction away for you and make it a really seamless experience but yeah the the core protocol is this infrastructure layer which is designed for people to build on top of and you know do do things on top of IVC at the application layout um and you know have this really secure reliable transport

layer um which is which is a yeah not going to be at risk of uh losing all your funds if you use this or something uh but yeah well we'll talk we'll talk about that about that aspect uh in a little bit later I want to ask you though what is like what's what is your your job essentially like as the product leader of an open source software project um what what are what are the things that you do and yeah because I think when you think about a product lead to most people you think about a software product or like a you know like a a user-facing product whereas the button going to be how is that experience going to be like but when I

when thinking of this open source product uh you're thinking about code and how developers are going to be able to use those code so what is that like and who are the stakeholders that you need to satisfy who are you thinking about when building that product and who are all like you know what are the movie pieces there yeah so like as you said the like with a product owner your like main uh concern is the users and I guess with it being this open source infrastructure product our users are chain developers and people that want to to integrate IBC go into their into their blockchain um so I spend time talking to users um which are developers asking them you

know how they find using IBC go understanding the pain points um and then that just feeds into the work to be done to improve the protocol um if there's things which are like blocking teams from actually um kind of using IBC in the way that they want to so there's like one kind of blocker at the moment um which is like a lack of callbacks from the application modules and this is really important for using IBC or smart contracts um but this was like not kind of an original it wasn't like one of the yeah kind of V1 features or or like an early feature of IBC but

think little things like that which uh you just find out from speaking to users of oh I actually wanted to do this thing and I can't or actually we were using this and uh it wasn't quite as easy to do this so it wasn't easy to understand this thing or things like that and then that just feeds into prioritization and planning for engineering because there's two parts to this right there's the standard which is a set of rules or I mean it's a protocol right so it's like how software talks to each other and then there's the actual implementation which is kind of the product and that's IVC go yeah you're involved mostly with with the implementation not so much protocol right so like the the protocol The Interchange standards

uh that's what they called say like the the repository is just IBC um yeah it basically defines the uh semantics of uh how an IBC implementation must be to actually be considered an IBC implementation and I guess the beauty of that is that it kind of doesn't matter which uh like programming language you implement ibcn as long as it's adhering to these standards then you should in theory be able to have two instances of IBC communicating with each other if it's all implemented correctly um

and yeah IBC go is just the first implementation of these standards and that's what our team is focused on developing and maintaining yeah yeah which repos do you oversee specifically uh the IBC go so it's Cosmos forward slash IBC go and then the standards kind of feed into work that happens in IBC go as well because like uh new features will be specified and then they'll be implemented in IBC go and then there's I think that there's a couple other implementations this is IBC RS which is like a bit behind IBC go not yet used in

production uh but it's you know kind of catching up and then there's a solidity implementation as well which is also not used in production but it's uh yeah but yeah the implementation yeah it's uh it's it's not like production ready um but yeah for like you know the future of uh IBC in ethereum you would need IBC to be implemented in solidity to work there okay that breaks my entire ma mental model about how this works but we're gonna I'm yeah oh I'll follow up I'm gonna I'm gonna put a pin in that and we'll come back to it later

um so Beyond those nine people that you mentioned there are obviously open source contributors so how many people are we talking about that are contributing to IBC um uh moving IBC go forward yeah so it's also just like important to note that IBC go is just like kind of one part of the whole IBC like ecosystem as I mentioned like there's ibcrs which is IBC invest and I've seen solidity but like a key component of IBC is the relayers which is kind of the often infrastructure to actually move packets

back and forth and enable chains to communicate um you don't just have the protocol alone you also need read this this relayer software and relays to be operating and there's two relayers right now so there's a relayering go which is managed developed by Strangelove there's a relayer in Hermes which is uh managed and developed by informal and then beyond this there's also of IBC applications and middleware um Strange Love does some applications the middleware um informal um is doing rcrs and Hermes and then like lots of like it's a very big ecosystem

that's also um like organizations like polymer who are working and contributing actively to IBC um they contributed some work on multi-hop routing and a local host client and they have their own kind of IBC use case for connecting non-cause machines um to do Cosmos chains as like a router um so it's like there's there's really a very large like number of organizations which are getting involved with IBC related development and different kind of elements of the stack as well and like also you know uh the future to

have more kind of cross-chain smart contracts so like cosmosm is really relevant here um yeah it's uh it's so it also I should have like basically for um IBC to spread Beyond Cosmos you have a big component of like client development um which Strangelove are involved there and also some other teams like composable who uh want to create like a cosmos uh broken art connection and also a connection with net so there's lots of like broader IVC work going on a bit other than just IBC go

wow I didn't realize that so many teams were contributing back to IBC like polymer and and composable and all these other teams so yeah it's it's very cool I mean especially since I know that those teams are focused on bringing IBC outside of the cosmos ecosystem and I think this is one of the really interesting things about IBC is that you know even though today it's mostly used between Cosmos SDK chains there is a real effort to bring IBC outside of the cosmos ecosystem and I think it's it's also real wreck it is recognized outside of the cosmos ecosystem as a a great standard and I think you know given the right implementations and overcoming

some of the challenges of implementing IBC outside of you know fast finality chains um it can be implemented across other other ecosystems as well you know and probably will be so very uh optimistic about that um so what are the key components here so you mentioned like clients uh relayers and channels can you can you describe I mean maybe maybe one way we can do this is like Describe the life of an IBC packet uh you know from chain a to chain B and how it interacts with all of those different components yeah so that's

that's kind of two two kind of just like elements of the IBC protocol you've got the application layer and you've got the transport layer so the application sorry uh Susanna there's this um there's a bit of noise from the wind I wonder if oh yeah okay [Music] um yeah so there's two layers you've got the application layer and the transport layer the application layer you'll have um your specific module like it could be token transfer or it could be crocheting query or interesting accounts and

um this application module will interface with the channels um which is kind of like the top layer of the transport layer and then the transport layer consists of like clients connections and channels so it's like um those are the key components to think about um a light client is just an algorithm to track the consensus state of another chain um and connection is just um the the yeah you have two chains they'll have a connection between them built on a certain like client and then the channel is the kind of application specific conduit um for

for this um like it could be for token transfer you'll have a separate channel for queries you'd have a separate channel for institute accounts um so those are like the main components and so basically they're just two chains that are that have a connection would have different channels for all of those things and and by the way those things are uh our standards in themselves right so moving yeah you know ics20 tokens or moving ICS 721 tokens or doing an interesting query which is itself another standard you need a channel for each of those things yeah exactly um so yeah each each like application

module will claim like their Channel and be attached to that specific Channel and then what's the process of implementing that channel is it do both do both chains have to implement it in their Cosmos SDK software doing upgrade so that's what the channel is established is is there and then how do they initiate the connection so when you have two chains that both have um an implementation of IBC a like client would um spin up sorry a relayer would spin up a light client of that chain and the the other chain would have the like line of the the

counterpathy chain and then these two chains would perform a connection handshake so that's basically to say okay um chain a um is is um running a like client of chain b um and they're like high chain B nice to meet you you seem everything is checking out as expected chain B will then be like hello yes you also look as I expect you to be so now we can have this connection and then if you have a specific application that you want to use so say token transfer then the relayer will spin up a channel as well on top of this client and connection and

then be able to send packets along this channel so it's very like the relayer has to set up the client connection channel to use that to transmit the packets between the two chains and relayers don't need to be I mean relayers and validators are separate things like a relayer can just be any old you know uh client that is relaying those packets and sending it to the chain to be included uh in a in a transaction correct yeah so relaying is completely permissionless like anyone can in theory relay packets like anyone can see oh

okay this user um wants your token transfer they can see okay token transfer then technically anyone who's running the relay infrastructure can just relay this packet however in practice running a relayer isn't really like a trivial task like you need to be running a full node of the chain of the two chains that you're relaying between and this is so that you can update the like client that's uh checking the consensus state of the of a chain so you need a block header from your full node um and you construct the proof to update the like client um so it's like in theory anyone can do this but in reality it's mostly relayers

doing this because it's not really trivial to be just running full nodes of multiple chains and yeah you mean valid errors are doing this yeah because they they already because they're already running yeah exactly yeah although I'd say like relaying is um like more of a um complicated task than validating I think in reality um I'm not personally a validator but um you know from like my understanding and past experience of validation operations it's kind of like once you have your setup going and everything's running smoothly you know the most intervention you have to do is

like upgrading uh when it's chain upgrade and things like this it's like once you have a stable setup it's like relatively stable and straightforward I think getting a solid relaying setup is a bit more challenging and it's also a bit more active involvement like um yeah it's a bit more of a Challenge and also like one thing of relaying is really I'd have to pay for the transaction fees um on either side chains will reimburse this typically um either with like octane funding delegating to the relay is validator um or such but yeah it's a bit more of a relays really believe in the

entertaining ecosystem at this point um it's still like kind of a problem which should hopefully be be solved soon actually with some work that our team's doing with Channel up readability and then you would be able to add um incentives to existing channels um like really incentives uh to kind of cover these costs we hope to make the kind of relayer um role more sustainable um maybe even desirable if it really works out nicely but yeah right now it's it's the the cost falls on the relay so the relay error just to kind of recap here because I think it's really

interesting how this this really works so the relayer it has a a full node on both or sorry the the relay has a full node on one chain that he is relaying for or on both chains well let's say Adam and osmosis like I'm doing I'm reeling IBC packets uh for osmosis do I also need the full node client for Adam or just osmosis and a light client for the for the for the chain that I'm re that I'm receiving packets from well so technically um so basically in a packet life cycle you have a packet going from chain a to

chain B and then um it will receive the packet and then they send back an acknowledgment to say yes I I received the packet and everything is good on kind of the the happy path of um like it's gone successful so um in theory these two relays don't need to be the same person in practice often chains are running full notes on like um yeah and so they said so they might just be relaying both of these packets but yeah in theory you you only need to be I could just be relaying on osmosis so I'm running everywhere on osmosis and I'm just um like sending packets out from osmosis right so I'm essentially watching for uh

let's say let's come back to this osmosis atom uh scenario I'm relaying packets for osmosis I'm watching the atom chain and I'm watching the osmosis chain but at some point someone sends a transaction saying I want to move my atom to osmosis uh they're initiating that transaction on osmosis uh or no they're initiating that transaction yeah uh where does that information come from like how am I as my as a as a relayer receiving that information is it is it because someone is watching the atom chain and they're sending a transaction on osmosis like that that's the part

that I'm missing here so the application module will emit an event to say this always true on on atom on on the Hub the cosmos Hub so an end user would be like okay I want to send 20 Atom from the herb to osmosis they interact with the application module it will emit an event the relay will see this event then they'll like update the like client and go through the whole uh whole transport layer process and then you can actually send this uh packet but basically they're like looking out for these these like transactions that users are

making and then they'll act act on this so it's uh they're they're watching basically so I need a light as the as the osmosis relayer I need to also have a light a cosmos Hub like clients that I can be watching the cosmos Hub chain so I'm essentially running kind of two pieces of infrastructure I'm running a cosmos full node and an uh sorry a an osmosis full node in a cosmos Hub like client yeah but the like client is like on chain it's like the relay just updates the like client with a new block header if that makes sense so like the light clients are like the on-chain component and the full node is the kind of

off-chain component which relayers are running as part of their like infrastructure setup okay I I understand okay and um when when this happens so that transaction goes through um um what happens when the funds are essentially received when when that token transfer happens how is it that I can't then spend those tokens continue spending those tokens on uh on the cosmos hub and effectively ensuring that there's no double spend between those two chains once they've finally made it on on the

osmosis chain so uh with this case of uh token transfer ics20 um it's using the bank module which will and the ics20 has like a lock and then mint on the other side mechanism so basically your tokens will be locked into the bank module on the Hub and then um they'll be sent over and there's like verification that these tokens actually kind of were minted on the other chain and um if there's like a problem that that the Hub doesn't get confirmation that these tokens were were minted then

kind of like or there was like a problem um then the whole the whole thing will like revert and there'll be like a timeout sent to say okay these tokens never arrived um don't like kind of actually uh mint these tokens on the other chain so it's like there's like verification that the action actually took place in the whole life cycle and um you can't just kind of be minting uh tokens like continuously you have to verify that the user actually like interacted with the application module lock these tokens um to then be minted on the other chain what what prevents so the the way I see

this is let's say you have like to two people uh in like different houses and you know in on one side someone puts something in a box and they're like okay it's in the box and then they're able to provide a proof to the person across the street that they've put that thing in the Box yeah and that allows the person on the other Street to say okay now I'll do an action like I'll I'll take my thing out of the box and give it to the person inside the house yeah but good description but but but but here's the thing once that's done um person in the house across the street

doesn't can't be certain that the person in the initial house doesn't take the thing out of the box afterwards so what prevents basically what prevents the Hub in this case uh from minting those tokens again after some time uh and uh in such a way that the osmosis chain would know that that has happened or if you don't receive the proof that um these tokens were taken out of the box after a certain time period Then the whole thing will time out and you won't then be able to like take the tokens anymore so it's like a time there's a

timeout period where you have to have received verification that the transaction has has taken place and if this time period is exceeded without any verification then you like revert the whole the whole process but but I mean you maybe maybe I'm not fully understands but like you could Fork the cosmos SDK and all the modules right uh and and have an IBC go module that is acting normally but in in the code that you've compiled there's a mechanism by which there's

like a new transaction type which is like unlock tokens um without like which is like unlock the tokens and like re-mint them you'd have to be a militant malicious chain for this but it is there a mechanism that prevents that is there like someone who's watching the chain to make sure that the chain is not acting the the initiating chain is not acting maliciously like some sometime later right like yeah I know I understand that what you're asking her though um so like when you update the like client but see the whole point of the like client is to verify that a transaction took place on the

counterparty Chain so it's like this is like involved in the verification that some action actually happened to say okay then do an action on on this other chain so if someone tries to um trick like like basically create this like fake verification that something happened um which didn't actually happen which would then enable me to like mint more tokens or do something like this um there is basically another mechanism of Aurelia where they can submit misbehavior to the like client so another relayer could see okay someone tried to

um update a like client incorrectly so there might be some discrepancy in the consensus State the the validator set so there might be there's like parameters when you update a like client to say the the previous update must have um a certain proportion of the previous validators that signed this consensus state in the next consensus State update so this is like to make sure that someone's not just like Fork the chain created their own validator set and then they're trying to say that these like client updates are are real when it's actually just an entirely new validator set um so that mechanism will ensure that

there's like continuity between the like client updates and they're actually kind of tracking the real consensus state of that chain so you'd need like the validators on um the chain to be colluding basically to submit a false header to like trick the verification um like to say to pretend something happened when it didn't to to kind of get to that situation so it's quite complicated to do this like like client attack like it's it's not really trivial and I think the thing even though you know a lot of these app chains have like a smaller market capitalization and like um ethereum

they're really not incentivized to um to to do like false false uh Litecoin updates or things like this because all of these validators are pretty much not just validating on one change like their reputation and there's lots of other things to consider so you could have social slashing on other chains as well like if they were doing this I mean yeah so it's like this sometimes yeah I think it's it's quite like an elaborate um ploy to do and it's even when like um when and you know like Terror was kind of collapsing and it wouldn't really have taken that much um

like monetary you could you could have kind of bought into tires yeah it was kind of attack but like it didn't happen as well so um I think it's I mean obviously it's impossible to happen but I think it's um this kind of whole mechanism is why like IBC is so secure really I read somewhere that IBC relies on two trust assumptions uh one that [Music] um oh I forgot what it is uh that that users trust the chain with which they're interacting and the other is these fault mechanism these fault isolation mechanisms that prevent the chains from uh executing malicious behavior and the

way I describe ibcd people it's like I I describe it as moving going from one place to another and using a bridge so you could go from New York to New Jersey and and take a bridge to do that if you go to New Jersey what happens to you in New Jersey is your own problem like it's on you for having gone to New Jersey like not not at this on New Jersey or anything but just whatever um I've never been to neither New York or New Jersey so what the do I know yeah basically you cross the bridge and you go to you know let's say like the town right and it's like the good side town the bad side of town and then there's another bridge that takes you to like an equally good side of town like you could take that bridge and go to the

good side of town and what happens to you there is your problem and then like someone else could take a bridge and go to the bad side of town and if something happens to them there that's their problem but at least the bridges are not going to collapse under their feet like there's always a way to be a way to come back as long as you haven't been wrecked when you're in that other side of town you could still take the bridge and come back and also the bridge is not going to collapse under you yeah that's kind of the way I describe IBC to people yeah I mean it's like unless there is um some like Miss like misbehavior I think like like a common misconception is that that we hear is like people think that you can just close a channel you know which is

just like not true the only reason like a channel would close is in like this there's really two two circumstances one is where there is some kind of um misbehavior like you know that there's some discrepancy but then and then the like client will um be frozen so you wouldn't be able to transfer any funds like back and forth with the connection and channel built on top of the slight client then the other case is um for specific Channel types so you have for interesting accounts you have a need to have orders channels at the moment and these don't support timeouts so basically every transaction has to arrive and if a packet like there's

there's some reason why this specific packet um doesn't Reach the the end the end the other chain and it times out then that channel will close but then basically just means that you have to open another Channel um it's like it's yeah I mean it's it's it's uh it's it's been a bit like a bit of a pain point but um those are the two reasons why like the channel would close really and if there's if all the relayers of if all the relayers decide that they go offline then that basically compromises liveness but anybody can become a relayer so at that point anybody else can um so I guess that's maybe one of the

like it doesn't compromise on security but it compromises on liveness because the relayers are not like a decentralized network that like ensures that there's already always a relayer uh available um but anybody could spin up a relayer and uh make it such that the channel would be available again that's right yeah yeah and I mean although it's like not the relayer network is not like necessarily super decentralized um there's always pretty much always coverage and I think the relay Community is really like oh yeah that that positive and nice people and they like actually want to you know if there's like a problem like there's um a buildup of uh packets that

aren't being relayed on a specific Channel people will like clear the channel um that kind of yeah actively trying to make sure things are working well um so yeah it although it's not like yeah exactly a decentralized network but it it work it generally works like pretty well so so we talked about token transfers and I think that's the the use case for IBC that most people have interacted with so far those who have used IBC there are other applications for IBC interchange accounts is one of them it's one that is beginning to come online now um in some cases then interchange

queries also uh there's uh there's I mean I was in the repo and I I was kind of discovering all of these other uh ICS standards so there's ICS 29 which is a standard to incentivize relayers and there's a bunch of other ones but maybe let's focus on interchange accounts and interchange queries and I'm also curious a little bit about this relayer incentivization because as it's from from what I'm understanding like currently relays are doing this uh because you know they're idealistically driven or they may be driven um I mean they may be driven because they also want people to delegate to them but yeah over longer periods in the long term it's likely that the cost of

running a relayer would become pivotive if validator rewards go down or you know whatever in some future that we might need to incentivize them um curious to understand how that works as well so maybe let's uh focus on the two that most people have been most familiar with and that's interesting accounts and interesting queries How do they uh function with the IBC standard because just just to kind of point out here IBC is just a pipe it it can take any sort of packet the ics20 is one type of packet that it can it can it can send but interchange accounts and interchange queries and all these other standards

are just leveraging this pipe uh to to initiate a transaction or something yeah yeah I think that's quite like a nice way of thinking about it it's like the the application module basically defines um all of the data which would need to go in a packet for this specific uh application but like to the relays I mean the packets are just bytes it's just like data that's being passed between the two chains like they aren't really concerned with you know exactly what the what's required for this application module they're just kind of like furrying stuff back and forth and and yeah the the packet um semantics for an ics20 transfer is going

to be different as for an interesting accounts packet or like an interesting queries packet um but then yeah ics20 was just like the first use case that everyone wanted as he said like kind of took off when osmosis launched which was like you know the interchange decks people wanted to move the atom to osmosis and you know there were other chains live as well um but yeah so interchange accounts is kind of like a general message passing protocol it enables you to perform an action on another chain from like uh the control attain is how you define it so you have a control chain you have a host chain

the controller chain would create an instant account on the host chain and then they can send messages to that account and that account will then perform actions with how I would describe it then uh interesting queries is uh there's actually two different implementations for Instagram queries one is for kind of client based queries so it's actually just using um using using a light client and a full node and you're basically just querying some information on another chain but you don't have to do uh the full packet round trip

but then this is limited to very specific um queries like uh it's it's like the yeah the functionality is basically like limited but then for this other query approach it requires a packet round trip so uh you like package the query that you want to perform in a packet you then send it to you have a chain the the chain will then kind of retrieve all the data needed to fulfill this query and send it back so there's like two different approaches but it's the benefit of the client approach is that you don't have to have the other chain implement this application module to be able to query that chain

um so with like these more advanced applications we've seen um the client queries and interesting accounts being used in production uh with these liquid staking protocols so stride and Quicksilver are the users of insurance queries and machine accounts right now um they have a setup where they created a Entertainer so so okay liquid staking is a basic let's take a step back liquid seeking is you know um having a derivative representation of your staked asset which you can then use in D5 and the way that these protocols work is someone would say Okay I want to

have the staked atom token so they'd like deposit some some atom into stride and then once every like Epoch or n and blocks they basically send over Atom from from their stride chain to uh The Hub if we're dealing with State atom so the interesting account on uh on on the Hub and then they'll send a message to the instant account to stake the atom um and then that's kind of like how they're dealing with uh you deposit your um your tokens into stride and then you receive this derivative that was taking

taken back um so for the user it's like you just deposit your atom but under the hood the atoms being sent um to the hub being staked um all through Instagram accounts and they use queries to um look at like staked balances and stuff things like this I think they're also using queries for kind of costing governance applications uh but yeah that's kind of what what's being used for right now um what's so what I see here is so people think of IBC and they think of token transfers as that being IBC but

what's clear what's becoming clear is that IBC is kind of like PCP where it's just well like TCP it's just the token uh the the packet transfer protocol and then ics20 ICS 721 all of these other uh standards leverage IBC so they're sort of at a higher layer in the stack and they are akin to http FTP SMTP packets for transferring certain types of information and it's almost a misnomer to to say I'm doing an IVC transfer it's like you're doing a you're doing a token transfer over IEC or you're doing an interchange accounts

query over IBC or an innocent query or whatever right over IBC so yeah I I just yeah it just became clear to me that like those are two separate things and they should be treated separately yeah it's like what the user is like interacting with is the application like the kind of application layer and then the application layer is underpinned by this transport layer like all the kind of kind of complicated it's handling all the logic of being able to actually pass this packet back and forth and verify that this packet was you know it's it's from like a real transaction it's not

like some um you know someone's trying to submit a fake transaction to make more tokens or something like this all of this is is happening in the the transport layer kind of under the hood but the user is just kind of only really concerned with the specific application that they want to use so yeah and tell me about this uh incentivized real error standard it's ics029 what's the status on that and what does it aim to do yeah so this has kind of come out of a big kind of uh discussion around how yeah being a relayer is not like

it's not really like a money maker right now you know it's a bit of a it's a bit of a public good at this point um and we basically wanted a way to be able to have an end user like contributing to the cost of relay relaying um so this middleware would basically wrap a a channel and it would allow a user to attach an additional fee with their packet so it would be the like send packet the acknowledgment and the the timeout so there's three packets that could be incentivized and the Relay can a user could specify

um the additional fee for each of these packets or if it's kind of like abstracted away from user like um you know as they're saying like osmosis evermos have these applications um where you're just using IBC under the hood but you're kind of abstracted away from having to pick which channel and connection you're going to be using um they could just have a field which is like kind of tip and then they could distribute that um to the relayer like amongst these three packets in like a proportion they wanted to but yeah the idea was to make something which is kind of relatively neutral we would Envision that it would be more on the end user to

pay for this uh this service and because there was you know there were kind of some other discussions of how relays could benefit from like um I don't know potentially kind of like a eip1559 kind of um taking a proportion of like fees something like this or whether you have some kind of like block space market and really is have some kind of it it was I mean all of these ideas were kind of possible but we wanted to just have something that was like relatively straightforward and simple and see whether um yeah whether whether this would kind of

contribute to solving the problem and then if things should should become should like should there be a need for more um Advanced like Theory reimbursement mechanism further down the line then it can be Revisited but the so the one like big caveat on the female wire is that the problem is you need um both both sides of a channel to have this middleware added so this meant that once you've um once you already have an established Channel you can't retroactively add this to your existing Channel however we are going to be working on the future Channel upgradability

um hopefully kicking that off within the next next few weeks and which would allow you to add this middleware to existing channels and this is really important because especially for so you can transfer you've basically got this kind of whole fungibility problem where if you Tran if you transferred tokens from a different Channel it wouldn't be fungible with um another Channel even if it's like between um the same two chains and built on the same connection if that makes sense so there's like not token fungibility between channels and that's like an intentional design of IBC it's like part of the security guarantees um

but this is then like has kind of the knock-on effect of well if I've been transferring my tokens down this Channel and this is like the canonical Channel between uh these two chains you don't want to open a brand new channel um which would have humidifier enabled you want to retain the fungibility and all of the past state within this channel that you've kind of accumulated so yeah that's why we then need to enable channels to kind of renegotiate um the connection the connection handshake that they're built on and um so the question there's a question here in the audience that uh this is a regular uh listener of the channel and

he says why aren't validator node operators just forced to be relayers because they're already making money from the protocol why isn't it just part of the deal of being a validator that you would also be a relayer so you know is there uh something there that's prohibitive from a cost perspective or maybe it's uh is it like a game theory thing where validators in being being forced to be relayers it could be compromising to the network what's the rationale here so I think like just the kind of inherent nature of like blockchains uh you and especially like delegated proof of State you can't really Force validate us to do anything right it's because token holders

um have delegated enough tokens to these validators for them to be in their active set where they're getting involved with the chain consensus um and I mean often with chains you'll have foundations who will delegate to validators on their chain and they'll have like a list of criteria to say okay we will delegate to validators who are doing XYZ which is beneficial to our chain so often uh like foundations will have within their policy to say okay we're gonna delegate to validators that are also running relay infrastructure but yeah as we touched on earlier it's like more difficult to run relay infrastructure than being a validator so

yeah it's I think it's also like as you said some some validators are kind of using it as like a selling point for why you should choose to to delegate to them as well um but yeah it's kind of like there's like a problem with decentralization rate you can't really force uh you can't really Force anyone to do anything uh so I want to come back to uh what I've kind of pinned there for for later which was this I IBC solidity implementation so it is my understanding that IBC works when chains have uh faster instant finality because they're able to send this message and

have a sure that chain B knows that chain a is not going to have a reorg and essentially that this this transaction will be final so that once chain B takes an action it has a high level of certainty that chain a won't revert or reorg with ethereum consensus the assumptions around finality are different liveness assumptions are it has higher liveness but lower finality guarantees where there can be reorgs and that is inherent to the fact that ethereum has essentially an unlimited number of valid errors and tendermint has a set number

of validators and that has an impact on finality uh not to get into consensus Theory here but that's the kind of the gist of it um when when people are trying to build IBC implementations for other chains this needs to be taken into account I'm curious what are the um what are the what's in the works to have IBC uh work with ethereum and What mechanisms would be in place to make up for this uh this difference in finality between consensus and I guess it also applies to other chains that have different

finality mechanisms or guarantees yeah so I guess like to take a step back to make it a bit more general just for any two chains to have an IBC connection you need an IBC implementation in line with the specification on both chains so if you want the cosmos ethereum connection you have IBC go on the cosmos chain and then on the ethereum side you'd have IBC solidity and then you also need relayer infrastructure that's operational between both teams and you need a like client of uh the the two chains that you want to track so on Cosmos you have an

ethereum like client and then on um ethereum you have the like tenement like client um which would be common BFD yeah yeah we'll call it VIP sorry sorry guys yeah yeah comment the Ft um and as as you mentioned uh ethereum has this like two slot finality so uh basically you can't guarantee that a transaction will be in the um like canonical Fork of ethereum until two more blocks uh down the line have been uh submitted to the chain

so for like the the constraint here is on the like client updates like you can't use the like client update until you are certain that that transaction is actually going to be in the chain so that's why for a ethereum connection between Cosmos and ethereum you'd have to wait until you're kind of two blocks um two blocks in the future or like you could think like the the block the like client update has to wait two blocks or you can only update the like client with block headers that have happened kind of two blocks in the past it's like kind of slightly different approaches um if you wanted to like update the uh

like client and wait wait two blocks there is like a parameter which isn't really used called The Connection delay period which is to say I would have to wait a certain period of time before I can actually use this like client update for any um IBC transaction or you could just set it up so that actually I'm only allowed to take um block headers from like two blocks in the past to ensure that you've got like finality at the point that you want to um do your IBC transaction but that's just kind of like one um one problem with um I'm still here my videos I'm sorry yeah I was like uh do I keep going or

um yeah so that's kind of like one but the other elements is like um the signing the signature scheme that's used on ethereum makes it like really quite expensive to be running a like client on ethereum um so I think they use this Ed is it two five five so I can't remember the numbers they basically use a different signing scheme to as is used with Cosmos um chains um and this means that you have to um validate loads of signatures in a really inefficient way for like clients which makes it really computationally expensive to actually do this like client update which would underpin

connection and so that's like another big barrier to actually having this direct connection see it's not just like the latency but it's also the cost um and I I think I mean my my perspective is um I think ideally um ethereum should be supporting some kind of like signature pre-compiled to make it less computationally expensive or um actually like having an EIP submitted which supports a different signing scheme if they really want to have kind of like client base interoperability um

which I and I know that as well like the kind of finality question I think on the roadmap for ethereum there is like a long time goal to have um like single slot finality and I think realistically once those things are achieved it would be more realistic but however there are also other kind of work around Solutions so there's like the ZK like clients which people have been looking into which reduce this uh this kind of computational cost and polymer also have like another kind of solution where they're trying to move this computation off the ethereum chain um but still allow you to like tap into

the like IBC semantics um so I think my view is like a direct IBC connection although it would be amazing is just probably not super practical right now um I think in the future it will be but then I also think there's going to be kind of these other of a Solutions which would work around this and make it more feasible um yeah but yeah I mean it would be great if we had single like if ethereum so I didn't know about this two slot finality um what is the delay essentially like if you're if you know if we were to implement IBC now with like this two slot finality what's the longest it would take for a like client to be able to verify the transaction is final on

ethereum I think it's something it would be something around like 14 minutes or something I think uh yeah an Epoch on a ethereum is somewhere between five and seven minutes right uh and then if you're using like a ZK like client approach you've got the time to construct the proof but I think that's kind of um the the longer the longer time in this whole process is going to be waiting for those those two blocks interesting are you familiar with uh some of this gay stuff like like polymer and um some some other project I've seen is called LaGrange they're doing like this

generalized proof Network like I mean it's just pretty looks pretty interesting actually I've not heard of LaGrange I I knew polymer like polymer are like contributors IVC like they contributed uh multi-hops back and they did some work on a local Hertz client as well um they just generally working on cool IVC stuff as well and they have the yeah their product vision of having um a polymer kind of chain as a router which would connect non um non-like Native the IBC chains so like non-cosmos chains to all all of the cosmos IBC connected chains

like an interoperability Hub kind of thing um I guess kind of like axillar but really based on IBC rather than um like the threshold signing scheme that they have yeah well uh yeah I'd love to do one with polymer as well um they're yeah they're very they're very heads down building though I feel like yeah I'm very very excited about what they're doing yeah um I mean that team's great like um they're both great there's Peter as well they're they're all yeah I think yeah it's a headstone building very clever guys

um I'm also excited to see how how everything they're working on yeah comes to fruition so before we wrap up here um what's next for IBC uh maybe on the protocol level you know I will the does the protocol need to evolve me if it's just message passing and most of what's kind of you know evolving uh and providing new use cases is the stuff that we're sending through it right like these ICS standards does IBC itself uh have a road map right in terms of improving I don't know this message passing and what are the things in terms of applications that you're most interested uh or most

excited about so yeah there's there's much more to be done on the protocol it's definitely not finished I mean in like the next few months I mentioned Channel upgradability which basically allows you to update the application module which is um has claimed a Channel or ad middleware to both ends of Channel whilst retaining all of the existing state really important particular fungibility and then this means that you could add femaleware for existing channels so it's exciting to see what's going to happen there then there's new kind of Channel orderings um so for I mentioned with interesting accounts there's a requirement to have ordered channels um which would close on a timeout

um as this is a pain point it would be really interesting to look into order channels which allow a timeout um also on the protocol like one problem like links to token fungibility is if you want to send your token from chain a to chain B and then to chain C and it wouldn't be fungible with a token that's gone from chain a to chain c um so basically this would be if like a user wants to send their token from chain B to chain C after coming from chain a you would kind of automatically root it back to a into C so that you retain fungibility so it's kind of like a would be like a ux Improvement big

issue right if we could yeah I've encountered myself and yeah some work around for that would be really cool yeah yeah so that that's like uh on our on our Horizon as well so just the problems here just to maybe clarify the problem is if you move say um atoms from osmosis or two osmosis and then to Juno and then you go back into Adam from Juno you essentially have IBC ics20 atom on the cosmos Hub you're not going to go back to Adam you have to unwind that transaction in order to come back and so this would if that effectively on go back through Adam and

move those tokens uh into whatever other chain back to the to the cosmos Hub rather than you know going from Juno would come back through osmosis yeah but the idea would be that you you'd never get to the point where you've got this atom uh that's gone it's ics20 yeah it's like you'd only ever have like one hop tokens because every IBC tokens it's called an IBC denomination and it has a record of the the channels that this token has traveled through it's kind of part of the security guarantees of IBC um but yeah this can cause like ux problems like when you try and if I have

my Atom from the herb sent to osmosis and then it's like actually I now need this atom on Umi to to do some you know whatever uh lending kind of stuff or you know this is another I want to send it to injective um then you know it's it's like feminine you see you're just like okay I want to go here now but you actually have to think actually if I want to be able to use the applications on on Umi or injective my token needs to be fungible with all of the other tokens there um so you need to like unwind it um so having this kind of done automatically in the background would be um pretty pretty big win there and

there's also kind of other new channel types so for queries um right now both designs are like kind of um request and receive but I think having a subscribe and publicized model would be it's like something which seems to have a lot of interest and a new channel type could enable this so kind of having like a broadcast channel type where it's like people would say I want to listen to what's coming out of this Channel and then it's kind of like push push push data from this channel uh to whoever's like subscribing so yeah and uh I think I think that I'm really

excited about which is like um we're like actually doing some work to like enable this this workflow better is for more kind of uh like cosmosm composability and having more cross-ching contracts um the like initial protocol was designed without like a callback from the application modules so if if I'm not a person calling an application that's not right now an automated way to know that like your your your your cross chain transfer has completed unless you did like an on-chain query

okay well I think your internet we've we have a lot of technical difficulties here um with my camera and uh and uh her internet um so hopefully gets resolved here in a second hi yeah sorry no no worries oh yeah I just yeah my my internet just went a bit about that

um no it sounds like it sounds like there's a lot of really cool things coming down the pike and um really excited to see like all the applications and the application space that this opens up and I think that in many ways it's just the beginning it feels like IBC has a protocol is about to get a whole lot better with you know wider adoption of IE of interesting accounts water or adoption of interesting queries and the cool things that people are going to do with that this transaction and winding uh problem that is only going to make IVC better and the user experience of IBC will be a whole lot better and we haven't even talked about like stuff like interchange security which is actually also a part

of IBC yeah also known as CVV apparently which is the technical standard prostate invalidation so um yeah I think we might have to do another episode at some point uh to get an update on all this stuff but yeah thanks so much for coming on it's been really interesting and I've learned so much but I've see how it works and now I have even better conviction that it's you know one of the one of the most important standards uh in The Interchange and certainly one that I think um is expanding outside of what we typically know as you know the interchange or the customer secret system so it's it's really satisfying to see that actually coming to fruition so thanks so much yeah thanks so much

for coming on and to our listeners uh thanks for tuning in thanks for watching uh the podcast if you enjoy this content please consider subscribing you can also follow me on Twitter I'm set 3.0 and you could also stake with interop just look for interop in the active outer set thanks so much for watching I'll see you next week