Cosmos ❤️ Interledger

**A** (00:05): Hey, guys. Thanks for coming. My name is Sunny Aggarwal. I'm a core developer and researcher at Cosmos. I'm also an advisor to Kava Labs. So, you know, I've been following the Intelledger project for quite a while as well, and so I'll be talking a little bit today about so Cosmos. You know, we're pretty well known as, like, an interoperability project, but it's a very different type of interoperability than what Intelligger is doing. And a lot of people like to compare them and, like, you know, and so I'll kind of go into, like, what IBC is and how it works and how it differs from Interledger Protocol. By the way, IBC stands for Inter Blockchain Communication, and then also talk about some very cool user experiences that can come about when you combine the two protocols. And I think they have a lot of really cool synergies there. Sure, most of you already know this, but, you know, I'll quickly walk through what ILP is, but basically how it works. You know, I'm focusing on this just from an interoperability standpoint. Like, I understand ILP has a lot of other use cases around payments and all sorts of different things, but really I'm gonna focus on the interoperability side of ilp. So, you know, you have a user who has coins on blockchain A, and they have like, a token or a coin or something, they want bcoin on blockchain B. And so there'll be, like, some sort of connector here. I put Strada Labs logo there. What they'll do is they'll go ahead and set up a system where they'll send a coin to Strada, and Strada will get it, and they'll send a coin back to the user on blockchain B, and they'll send them a B token. And so that's pretty simplistic way of thinking about it, but they can just keep doing this, and they'll do it as a streaming system where you'll slowly do a few coins and then you'll get the total amount across. This is cool. And I think it has a lot of use cases, but it's fundamentally limited to. You'll notice no coins are actually moving across chains. It's really like, all the value that was on one chain is staying on one chain, and all the value that was on another chain was staying on the other chain. And it's just really like, you know, shifting distribution. Like, it's basically the user and STRADA are just Changing out distribution between them. The goal here is, what we're trying to do is can we actually move assets between blockchains? So I have a token that was sitting on blockchain A, and I want to move a token across some sort of bridge to blockchain B. And I want to be able to use my A token on blockchain B because maybe there's some functionality there that I really want to use. So, for example, you know, I have BTC on the bitcoin blockchain. I want to move BTC onto the Ethereum blockchain so I can use it in smart contracts on Ethereum, or I can use it to, you know, collateralize a CDP or all sorts of different things where you actually need the asset itself on the other chain. So, you know, how you can think about it is ILP is about value transfer. The idea is, you know, you as a user are just trying to send yourself value across chain. So you're sending yourself, you have $5 worth of BTC. I'll use dollars as cause that's the unit, global unit of account. For Now, I have $5 of BTC on the bitcoin blockchain and. And I want to send myself $5 worth of ETH. And that's what I use ILP for. IBC, on the other hand, is more about asset transfer. I'm trying to send myself 5 BTC. I want that BTC asset on the other chain. This talk is not really too much to go into the technicals of how IBC works. We have a lot more talks that will go way more deeper into that. But I'll just give a brief overview. Basically, the goal here is literally just to make chain A and chain B be light clients of each other. They have on chain light clients of each other doing SPV proofs of the other chain. And so basically, you know, this involves sort of two things. You need to first prove that a header is in the other chain, and then you need to prove that some particular packet is somewhere in the state of the other chain. The idea is that IBC is really just supposed to be this like, generalized protocol. It's like, you know, this idea of like, like spv, like sidechains is not new. That's literally what this idea is. The idea here is just, can we create some sort of standards around how chains should talk to each other and like, standardize the packet format, Come up with a way for them to like, do a handshake with each other, to like, say, oh, this is my consensus protocol? Oh, this is your consensus protocol. Cool. This is the Merkle tree I'm using, or accumulator I'm using. This is the hash function I'm using. And it's basically a way of getting, getting them to be able to connect to each other and basically understand how to understand the likeline proofs of the other chain. And so, you know, you'll have these two main pieces, which is like one is proving the consensus, proving that a header would have consensus on it. So in this example, like this is kind of showing with tendermint consensus, you know, it makes sure it has two thirds of the voting power. And then the next step is you prove that some packet was in the state somewhere of blockchain B. As you'll notice, that value could have actually been anything. Like, you know, it just happens to be send 99 stake to Bob, but it could have been really anything. And so what I kind of said earlier about it being asset transfer is kind of not exactly true. It's actually more about being state transfer and you, you know, just proving something about the state of one blockchain to another blockchain. And so when you're talking about state transfer, you could do like all sorts of stateful stuff. Like, you know, the simplest use case is for sending tokens or like no non fungible assets. I hate the term non fungible tokens. It makes no sense to me. Non fungible assets. Or you could send stuff like capabilities, sort of like if you look at the agoric model of how you can transfer capabilities across chains, you could do stuff like metadata of different things like identity maybe, or whatever you want. One of the ones we're especially interested in at Cosmos is like sending validator set changes. So if the validator set of one chain changes, it should be able to send that information to another chain and let them know that, hey, my validator set has changed somehow. And also if there's any Byzantine faults on this chain, it can also send that to the other chain and let it know and you can do stuff with that, which I'll go into some of the things you could do with that. We'll focus mostly on the token transfer and non fungible asset transfer for now. You'll take a token on chain A and you'll lock it in somewhere in chain A. And when you lock it, it'll put a receipt somewhere in the state of chain A saying that these tokens have been locked and the locker intends it to be sent to this recipient. And so this packet will go ahead and get Sent to chain B, like I said, it contains the proof of the packet in some Merkle tree in a header that is somewhere in the consensus of chain A and chain B will mint it. A claim. It's essentially an underlying claim to the tokens that are locked on chain A. And you know, for most use cases these underlying claims because they're one to one redeemable with the asset that's locked on A can essentially be treated as being fungible with a minus some level of security. Like you know, when you using assets on the tokens directly on chain A, you, you're trusting the consensus of chain A. Now you're trusting the consensus of chain A and chain B. So there is a little bit of extra risk you're taking on but you know that for the most part they should be largely fungible. When you get into more complex sort of assets you're moving across then you, you know, for example a cryptokitty, right? Or you know, you can move a cryptokitty and you can create a claim for a cryptokitty on the other side, but you can't breed a claim of a cryptokitty, right that you have. You need these access actual cryptokitty to breed it. And so you know, it does kind of this kind of the basic token transfer and non fungible asset transfer falls apart there. And that's where you start to need more complex things like Agorax Captp and stuff. IBC is designed such that any two chains should be able to create a connection to any other chain. But you know, just like in the Internet you have ISPs or in the airline system you have like hub airports. You'll naturally end up having some chains that are basically specially designed to talk to other to just try to connect to as many other chains as possible. And these are called hub chains in our, in our lingo. But the idea is like there's no central chain here. You can have multiple different hubs that are, you know, connecting to each other kind of like, you know, BGP or whatnot. And then we already have two chain, two hub chains in the Cosmos Network. There's one called the Cosmos Hub and there's another one called iris. So we're already kind of following this process. And so I'll just walk through a really quick like user story of why, like what is an example of something you could do when you have cross asset, cross chain asset transfer that you couldn't maybe do with like plain ILP with cross chain value transfer. So you know, let's say here's this like, you know, Cosmos Network, couple of chains here you got bitcoin on the bitcoin blockchain and you know, you want to use it to go gamble on the funfair blockchain, right? You play some, I don't know, lottery games or something there. So you can go ahead and use your token, you know, you can move your BTC there and you know, let's say, I don't know, you want a lot of btc, great, because you're really good at gambling. But you know, this is tainted now. Everyone knows that you like won this money by like gambling or whatnot, right? So what you can do now is, you know, maybe you want to send these assets to a like, you know, the zcash chain, for example. And you know, you can use the zcash chain as like a mixer of sorts and you know, send it through there. And now look, you got clean bitcoin again on the other side and great, you know, now you got this clean bitcoin. You know, one of your friends like made a bet with you. Like, you know, you're really into cryptokitties and so he's like, oh, I bet you you can't buy breed a orange cryptokitty within six months. And so you're like, all right, cool. But you know, the problem is that like, you know, the, you know, six months is a long time frame for a bet. Like, you know, BTC is super volatile, you know, so what you want to do is maybe, you know, send it over to the Binance Dex and you know, swap it for some stable DAI token Cosmos. A lot of what we're focusing on is we really have this vision of application specific blockchains which where we think that like large scale applications should be like deployed on their own chain. But you know, that doesn't mean that smart contracting isn't useful. Like smart contracting is useful for the use cases it's meant for which is like short term things that need high levels of customizability. ICOs are honestly a great use case for smart contracts because that's exactly what they are. High customizability, short term things. And so, you know, if you want to make a bet, you can move it to like the Ethereum chain or we have a chain called Ethermint which takes the EVM and puts it on a tendermint consensus. Yeah. So you can go ahead, you know, move your tokens to the Ethereum chain and go ahead, your friend will also put down the same amount of DAI and you guys can Lock it together into a smart contract and then you know, six months pass and you know, you can take your orange cryptokitty and you know, you can send it as, you know, you, you know, one of the things you can't do with ILP really is move non fungible assets across chain. And so here you can actually move like proof of the claim of an orange cryptokitty to that chain and prove it to the smart contract, allowing you to win the bet and when your friends die. So this is a toy example, but here's kind of a hodgepodge of things that you could do that only work when you have stateful transfers and communication between chains. And so IBC and ILP have, I think they both have their special use cases ibc, like I said, really well designed for stateful transfers and you know, non fungible assets. You get this whole thing of like, you know, you can do all this like shared security stuff which I'll get into in a minute. In a bit. You can also, you know, I kind of got, when I got into Cosmos I was quite a bit of a bitcoin maximalist and I was just like, oh, I want bitcoin to be the currency for use in many chains. And so, you know, the idea was you can do that with Cosmos where like BTC can flow out of the bitcoin blockchain and into all of these other blockchains and be used as the primary asset in lots of different blockchains. Where ILP is useful, it has its benefits as well. I think if someone's doing payments across chains, I think ILP is way more useful. I want to receive ETH and you want to pay in btc. ILP is probably the best way to do it. It's useful for simple exchange and trading. I personally would not use it for high actual legitimate trading because you need some sort of order book and stuff. There's. But for simple exchange it makes sense and I think one of the nice things, it has less assumptions than ibc. So here in ibc, every chain that wants to be part of this has to natively implement this IBC protocol. And so we're kind of in the process of creating, we have a working group right now who's working on this IBC spec and trying to make it very cross compatible. We have so far right now it's us, the Agoric team, Loom Network, Prismatic Labs, who's one of the Eth 2.0 developers. So if anyone's interested in joining this IBC working group and making sure. IBC works with more and more different types of chains. Let us know. And then one of the things I think really the bigger one is faster value transfer. I think the UX on ILP is way better. Like if I'm trying to send coins, if I want to quickly move between chain to chain, IBC requires doing these hops, which actually I'll let the diagram show it. So basically, I guess almost a year ago now, there was an Intelledger hacker weekend or something at this house somewhere in East Bay. Scott from Kava asked me, oh, what are some cool ideas when you start to combine IBC and ilp? And that kind of got me thinking of a couple of different things. And so I started thinking about that. And so here's a couple of things of what are some cool things that come out when you actually combine these two protocols together. So one I think is definitely, I think ILP definitely massively improves the Cosmos ux, the Interchange ux. And what I mean by that is so, you know, just a reminder what ILP is useful for is really useful for doing this like, you know, swap thing. What IBC would do is, you know, I take my BTC that's on the Bitcoin chain and I could, you know, do an IBC transfer to the Cosmos to like hub one. I have the BTC there and then I have to do another IBC transfer to Hub2 and another IBC transfer to, you know, the final chain that I'm trying to get to. And you know, IBC is a, you know, I'd call it a relatively heavy protocol. In my head I like to think of ILP as this very lightweight UX thing. While IBC is relatively heavy, like depending on what your. For token transfers, depending on what kind of security you want, you usually have it do like a send a receipt and then another receipt. And so, you know, this every IBC transfer could takes maybe like two blocks on each chain. And so let's say each of these chains have like three to five second block times, right? That it will still take. Each IBC transferred will take like a good like 10, 15 seconds, right? And so, you know, doing this entire process of getting across to the other side, you know, realistically we can imagine it'll probably take at least 30 seconds. So here's my proposal for how I think ILP can massively help the Cosmos ecosystem. For this example, I have a Cosmos validator company called Sika and I wanted to start running ILP connectors soon. So I'll just use my company as an example here, where what I could do is, as a, as a company who's focused on this and specialized at this, I can take a bunch of my BTC on the Bitcoin blockchain and IBC it over to the chain and just spread it everywhere to all these different zones everywhere I want to send them. I'm holding onto some BTC on all of these different zones. Then a user comes along and what they want to do is if they want to go from this, this is a chain over here. They want to go to the chain over there. They have the option of one way they could do it is they could do an IBC transfer, which is really slow and not fun, in my opinion, from a user standpoint, when you add ILP in, what they could do is, like I said, all these users are Bitcoin maximalists. Everything else is a shitcoin. They want to use BTC as their currency on every chain, and so they want BTC on that other chain. But now what they could do is they can do an ILP transfer, send that to Sitka, Sitka can send the user the coins, and then they could keep doing it as much as needed and get all the coins that they need. But look, now Sitka is in a problem where, oh, if anyone else wants to transfer more coins to that chain, because maybe that chain is really popular for some reason right now, maybe there's an ICO going on that chain and everyone needs to rush coins into there. Sitka being a company who's specially designed for this, we can use ibc. And like, you know, because the UX problem isn't an issue for us, we're a company designed to do this. So we can use IBC to go ahead and, you know, rebalance our portfolio and just keep allowing this cyclical pattern to work where the companies will use IBC to rebalance their portfolios and users will use ILP to actually do the transfer between the same asset but on different chains. So that's, you know, one of the use cases, I think, that has this cool synergy there. Another one that I thought of as well that night was this is kind of, I guess, I don't know if it's too much of IBC iop, but it more has to do with payment channels. And I think you can probably abstract it to work with IOP in general, but this idea of paying transaction fees on other chains, when I'm explaining stuff to people, I always use these diagrams. So solid line circle means a blockchain and a Dashed line circle means a validator set and an arrow means what? This validator set is validating this blockchain. So traditionally we always think of blockchains in this sense, where there's a blockchain and there's some validator set that exists on that blockchain and it's validating the chain that it's on. But you can get into more complex things where you can have shared security style stuff where a single validator set could be validating separate chains. For example, you could have like a subset of a larger validator set validating another chain. You could even have like, you know, the validator set could be staked on one chain and it could be validating something on a completely different chain. You know, a lot of the plasma constructions are like this. A lot of the people who are using the Cosmos SDK, our software, are actually staking, doing their staking mechanism on Mainnet Ethereum, but then they're validating a chain somewhere else. **B** (19:10): Yeah, so spatial containment in this diagram clearly doesn't mean who validates what, because otherwise the smaller dash thing would be inside the other one. **A** (19:19): Yeah, the arrow means validates. **B** (19:21): Okay, and what does spatial containment mean? **A** (19:23): That's where the validator set exists, like it was formed there. **B** (19:28): So what do you mean by where? **A** (19:31): In the state machine of chain A. Okay, yeah, so this is where IBC is useful because what you can do is, let's say this is done by, let's say this validator set in the state machine of chain A is done by proof of stake and someone new wants to join that validator set. What you can do is send an IBC proof to chain B saying that, hey, look, someone new has joined the set. And look, you have to join, you know, you have to start adding, add them to the validator set there. And you can also do it for fraud proof. So let's say someone, a validator commits some sort of fault on that chain. You can submit a fraud proof over IBC to this state machine of chain A. And then the state machine of chain A could slash the validators in the state machine of chain A. So this is another use case of IBC where you can do this kind of thing. So where does ILP come in here then? So, you know, let's imagine that this big chain is the Cosmos Hub, which is this chain that, you know, we just launched two weeks ago. And you know, this works in any situation where there's any, where the validator set of chain B is somehow represented on chain A. So it doesn't matter whether it's any. It could be this situation, it could be this situation, this situation, or any other way, as long as somehow there's a representation of that guy's validator set on this chain. So how it would work is you could, as a user, you could go ahead and take your BTC and put it on a payment channel with the validator set of chain A, a one way unidirectional payment channel with them. And then what you can do is, you know, this is, you know, the, the keeping track of channel payment channel one. And you could do a signed channel update of channel one saying send 0.1 BTC to that validator set. And then when you want to include a transaction on chain B, you create your transaction for chain B. And you know, when you normally create a transaction on a chain, what you'd say is, you know, send the, from the data, it could be like 2 or how much you're sending some signature, but you always include some sort of transaction fee. And so normally what you do is you just say 0.1 BTC. And what it, what that chain tries to do is it looks in your account on chain B in the state machine of chain B and it tries to pull coins from your account. And if your account balance on chain B is not enough to pay the fee, it rejects the transaction. What you can do here instead is in the fee field of that transaction, you can go ahead and put the signed channel update as the fee on that transaction. And so here you could go ahead and put that transaction in chain B. And because it's a signed payment channel update, those validators are guaranteed to get those coins. But now, you know, there's another issue what happened. If it's a signed channel update, they could just never actually include your transaction. Just use, you know, 0.1 BTC is quite a bit of money. They could just use that money to, you know, they could just close the channel and never actually include your transaction in, in chain B. So what you do here is let's imagine that there's two transactions or whatever another one happened. So they're trying to close on channel B. So they're trying to create a system where the signed channel update that they're trying to close using is the one where it's channel update number two. But as you can see, transaction number two never actually made it into chain B. And they're trying to basically illegally close this channel. Well, the thing is, how we can prevent them from doing this is, is to close the channel. They also need to include an IBC proof proving that that transaction actually made it into chain B. And so this prevents them from ever closing a channel update for a transaction they never actually included into the chain. And so, you know, this is more like payment channels and IBC interaction. But I'm sure there's a way to abstract the payment channels here to work with ILP in general. I just don't know too much about the technicals of ILP to think about that. Too much. But yeah, and so, you know, that transaction can then go in and they can go ahead and close the channel and get the btc, the validator sec and get the BTC that they deserve. Yeah, that's it. Thank you so much. I hope that was interesting. Cool. Any questions at all about. **C** (23:54): Yeah, you mentioned that you were working on a spec that explains what a blockchain has to support in order to be part of using ibc. Can you say like a blockchain that has a scripting language like Ethereum? What features does that scripting language need to have roughly in order to implement this without native support? **A** (24:12): Okay, yeah, so I mean, as long as it can. So one thing to know about how IBC works is it's just a base layer protocol like tcpip. It's just proving state to another chain. And then on top of that you need higher level protocols such as on top you have HTTP, smtp, whatnot. Here you need, there'd be a protocol for token transfers and that describes what the packet format should look like as well as how it's expected to handle it and so on. And then on IBC itself on the TCPIP side, they're like, there's different. So we call these interchange standards ICSs. And so there's a repo of all these interchange standards where basically when you do this connection between initial handshake between two blockchains, they'll basically tell each other that, hey, these are the different protocols that I know, I know how to. You're using Tendermint consensus and I'm using Casper or something. Right. I know how to understand Tendermint. And so that could have been written in a smart contract on my system or could have been written in native code on my system. You know, that's not there. But. And so if I'm trying to connect to something that like, you know, proof of work and I can say like, I don't know, I don't have a handler to deal with proof of work. So this IBC connection won't work and so that kind of goes back into one of the things about what I was saying about hub blockchains. Right. The idea of hubs is that they're going to be specialized blockchains who are just designed to like, know as many interchange standards as possible. So that way it helps that connection problem. Yep. **B** (25:50): So relating exactly to what you just said about the hubs at the higher level abstraction, where computation in one zone is sending a message to computation in another zone, is there any semantic significance of the hub or to the computation in the zones? Are the hubs just routing fabric and they're just logically significant speaking end to end, zone to zone? Using the Internet analogy, at a very low level abstraction, a routing node is a machine and there's message from machine to machine. And then TCP is you make an end to end connection and you don't care what the routing is through the machines. If computation in, let's say the zone on the left, lower left, is sending a message through IBC to computation in the zone on the upper left, it's only going through one hub, where it's sending it to the zone on the upper right, then it's going through two hubs. **A** (26:53): Yes. **B** (26:54): Does the computation care how the message gets from one zone to another and which hubs are involved? Is there any risk that's specific to the hub, any semantics that are specific to the hub, or can you just sort of drop it from attention the way people using TCP usually drop attention to the router? **A** (27:16): I think we often try to overfit things through Internet analogies. But, you know, maybe this is a little bit more like the link layer where, you know, for now IBC is really just focusing on pairwise connection and it's not, you know. Yeah. And so any sort of thing that you want to execute, maybe a contract. So for now, if you wanted to do the like going back to the whole claims thing. Right. So what you'd really be doing is let's say you want to do another hop transfer. What you'd really be doing is locking those claims on chain B and issuing a claim on the claim to the underlying asset. Okay. **B** (27:50): So the hub also has the full zone functionality. **A** (27:54): Yes. **B** (27:55): And contracts are, are running on the hub. **A** (27:57): Yes. **B** (27:57): In the same way that they run on any other zone. **A** (27:59): Yes. **B** (28:00): Okay. **A** (28:00): Yep. And then when you want to do, for example, contract calls, let's say, for example, an EVM contract call. Right. And you want it to go to another chain, that's not your direct connection, that all has to be done in the Higher. That all has to be specified in the higher level ics like whatever, however you do it, some sort of like it has to say that, oh, this is only able to be. This packet is intended for this chain. And then. Yeah, yep. **C** (28:31): So what do you see as the. How long some of these contracts may last? Because to Stefan's point, if standards or the language for the blockchain changes because of updates or security fixes and all that, does that invalidate anything that's already been put in place in some of these contracts that may be waiting? **A** (28:58): Right, so this is why. So that's why, for example, the token transfer protocol, right, it should be designed in a relatively abstract way where it's just saying that it's not saying that it doesn't know whether the asset that its token is trying to transfer is an ERC20 token or if it's a, a ripple synthetic asset or if it's a. It doesn't know the specific what type of token it is. And so then it's kind of up to the chain to like choose to handle it however it wants. And so if it needs to tweak how it handles it. Right, let's say we decide that Instead of using ERC20 tokens, everyone decided to start using ERC223 tokens. Right. You know, that should, you should try to design the icss in abstract enough ways where it can be still be continuous when you have those slight modifications. Now if you're doing massive changes that completely invalidate like the ICS themselves, then yes, then you kind of need some level of governance systems on the chains that you're talking to so that they can also adapt to how to handle it. Yeah. Can you do IBC locking up of. **C** (30:11): Coins on the bit Bitcoin blockchain right. **A** (30:13): Now or do Bitcoin need to add a feature to support that? Bitcoin is a hard one, mostly because two reasons. One, it doesn't have finality or cryptographic finality. But that's not the worst issue. We can resolve that. The biggest issue we already have an implementation, we call these things peg zones for chains that don't natively implement IBC but are high, high value enough will like, you know, the Cosmos Hub will basically hack, you know, those that validator set would be willing to hack in like dealing with those chains. So you know, the ones that we're working on are mostly the Bitcoin peg zone and the Ethereum peg zone. The Kava team is working on a ripple peg zone right now. And so For Bitcoin it's kind of extra annoying because the multi sig support on Ripple on Bitcoin is not that great where it's kind of capped at roughly eight signers and you can't even give them weights. So on Ripple I know it's also capped at 8, but it's like at least you can assign weights to the validators, which is nice. And you can do kind of recursive multisig. You can have like a multi sig. Be a participant in a multi sig. In Bitcoin you can't do that, which is kind of really annoying. And so for that we're kind of currently the two options are we wait for Schnorr signatures to be implemented in Bitcoin, which I think has a reasonable time horizon. Like, you know, I think Dan has a bet with some with Lalou from Lightning Labs that it'll be done by the end of 2019. What was the bet? Okay, 2020. **B** (31:49): Or. **A** (31:50): We're also starting to do some research into like more MPC solutions that we can do. Ecdsa. Mpc. Yeah. **C** (31:57): For some historical context, I was trying to work on getting Chinor into bitcoin back in 2011. **A** (32:02): Okay. Yeah. I think Dan has decided that it's not going to be implemented though. Yeah. Is it then like it's really. It's the multi signature that's the core component that we needed. The multi signature is annoying and also the lack of. It's not easy to. So the way to. And I know in the Ripple one it's possible and in Ethereum it's especially easy but like changing the signers of a multisig, currently you have to. In Bitcoin you'd have to send the utx, all of them to a brand new address, which is also extra annoying. So the Bitcoin peg zone is like, you know, way more kind of. We haven't actually started implementation of that. There's another company in the Cosmos ecosystem called Nomic, created by a couple of our tendermint's ex engineers actually. But they've actually started work on an implementation of that. But we are currently focused mostly on the Ethereum peg zone to start and then I'm working with the Kava team to help them with their Ripple peg zone. Yeah. Can you expand more on the propagation of risk in both ILP and ibc? So my understanding is with ILP you're only vulnerable to your direct connections and the path of the length of the path that you choose doesn't matter what's the case in ibc. Yeah. So let's say. Yeah, so like I said, as you. So I'll focus on the asset transfer case. The farther you go, you have to trust every chain along the way. And it also is path dependent. So in this example we don't have any cycles, but if you had a cycle, let's say there was an IBC connection from Bitcoin to this zone. Right. So a token that goes from bitcoin to the hub directly and then to this zone is different than one that goes from here directly to here. And so the way that we've implemented it, it will be implemented in IBC is you have these like every time. Because keep in mind you're not actually transferring the asset, you're transferring claims to an asset. Right. And so for the claims we would. This is kind of in the ics, but it could be namespace accordingly. So what you'd have then on this zone you'd have hub one Bitcoin btc, while one that went directly would be Bitcoin btc. And so as you go farther along, it prepends every chain by the chain ID that came along. Yeah, yeah. **C** (34:35): How do you think about fungibility then? Because if I, if I, let's say I'm on one zone, let's say there are multiple paths between Bitcoin and that zone. Can I treat those bitcoins interchangeably or how would a UX for that? **A** (34:45): Maybe. Yeah, it definitely depends on the use case really what you're trusting then. Right. Is the security of the chains on your path. Right. And so if they're both relatively high, highly secure, they'll be mostly fungible with each other. Right. But if there's like some chain that I just, you know, I can, I can run a one validator blockchain that I'm just spun up myself and call that a chain and IBC connected. Right. That tokens that go along that path are kind of probably not that secure. Right. And so it's really up to, I think it really depends on the UI or the application. Right. Some applications maybe want, you know, strict fungibility, while some are okay with like slight looser fungibility. Yeah. And then that's also kind of why we expect a hub and spoke architecture, but on a single hub, a multi hub and spoke architecture to emerge. So that way the number of paths gets is very low and it's focused mostly on the paths that are usually in there are like very high secure chains like the Cosmos Hub. Yep. **B** (35:51): My apologies if this is the same Question. I don't know if it is this path dependence that you talked about. So let's say that computation within the zone on the lower left, that one entity in that zone holds BTC to that zone one stone and the other one holds it through a different path. Or in general that there's just two different paths. It doesn't matter in what way they're different. But both paths are ultimately claims against the same root. **A** (36:27): Yes. **B** (36:28): Now, if the clearing mechanisms understand that, then to an entity holding one currency, spending from the other currency is really just spending two different pegging routes against the same route. **A** (36:49): Well, the problem is you have to trust the consensus of each individual route. **B** (36:53): So let's say that the entity holding one coin trusts the consensus path to the route. The entity holding the other coin trusts the consensus path to the route. If the first wants to spend logical bt, you know, logical bitcoin to the second, that you would ideally like that to turn into a transaction at the root, moving bitcoin from one claimed pool to the other claim pool. **A** (37:31): Oh, you're saying. Yeah, I mean, I think that could be an interesting version of the token transfer protocol where you'd have to basically send. You don't want to do the burning. But what you can do is if you can prove that you can create a circuit there and then you can tell every chain along here, like, hey, wait, can you. We're changing the path of this claim. But like, yeah, that seems possible. I can imagine that happening. It'll be like, I think there'll be a lot of back and forth and receipts to do that, but at least the coins never. The assets can stay on the chain that you're trying to use them. Yep. That seems like quite a good use. **C** (38:11): Case for inter ledger. **A** (38:13): Yes. **C** (38:14): A layer above this to constantly normalize parts. **A** (38:20): Yeah, exactly. I think, like, for example, let's say so, I mean, what Mark was talking about was converting an asset. But let's say we're on one chain and we just want to swap the path. Like, you know, that's another great use of Interledger, where I like the path that your BTC is and you like the path that mine is on, then we can just swap that easily. Yep. Cool. All right, cool. Thank you, guys. Thank you.