IBC Beyond Token Transfers

**A** (0:00): Foreign. Today we'll be talking about IBC beyond token transfers. And what does this, what I mean by this is like, you know, everyone else in the crypto ecosystem is thinking about bridging right now, but like we've been doing that for like five years now, right? We, we, we've had token transfers working three years ago. That's the easy stuff. We're working on what can we do beyond token transfers and going to explore what some of those protocols look like today. But if you've ever watched any of my Cosmos talks, you know, I like to start in one place every single time. Which is what is Cosmos? It is the Internet of blockchains. It is fundamentally inspired by the design of the Internet, right? And so when you look at Internet architecture, you have this like, you know, this OSI model of like the different layers of the Internet. Personally, I actually like the TCPIP model, like a four layer model better. It's a little bit, you know, the lines get blurred. I think in the OSI model, I think the four layer model is actually a little bit simpler to understand. And so in IBC there's a lot of like really good analogies to this like layered stack model. And you can actually see it if you go to the Cosmo IBC repo. You can see all these like ICS Interchange standard specs. They kind of are split in this way. You have core stuff, you have client stuff, you have apps, you have relayers. Relayers are kind of like the data link method when it comes to ibc. And there's a lot of like analogy. So like, what does this look like, right? In the Internet you have these link layer protocols like Ethernet, WI Fi. There's a lot, there's a lot, lot, many more. But like the biggest ones are these. Obviously there's different types of WI FI standards as well. And you get a similar thing happening in ibc, right? You have like, you know, today the most popular link layer method is IBC Go, which is used primarily between the Cosmos SDK blockchains. But there's a lot more being built right now, right? You have like IBC Rust being used by like Anoma and Penumbra and other teams. You have Polymer obviously building, building new IBC clients to like Ethereum. You have composable building them to like things like Substrate. You have other teams like Electron Data Chain also doing stuff. Axel are kind of acting like a translation. Like the GMP is in this like weird blurry line that kind of straddles IBC versus a separate protocol you also have, similarly in the Internet, you have these transport layers, you have tcp, UDP are the two most known ones. You have some old legacy ones that have been basically deprecated like Apple Talk. And then there's also ones coming around like quic and you know, it's the newest one because it actually has a logo. And then similarly in ibc you also have these multiple transport layer protocols. You have. How we talk about channel ordering, the three main ones right now is you can have ordered channels, unordered channels, and ordered channels with timeouts. So we'll get back to some new types of channel systems that we're working on. And then finally, I think what's most interesting is on top of the Internet stack, you have all of these application layer protocols that do different things. You have SMTP for web, you have WebRTC for video streaming, SSH, FTP for file transfer, DNS for naming. And obviously the one probably people are most familiar with is HTTP, which is a web standard, right? And the web sort of acted as this like generalized standard that you can build a lot of other stuff on top of as well. So that'll come back important in a little bit. Same thing in, you know, in. So in IBC we've seen the rapid development of a lot of these new application layer standards. Obviously the first one is like, you know, your token transfers, the first one that went live, everyone, everyone's probably used it. You have ICS721 though, which is like, how do we send NFTs across chains? The game of NFTs thing just ended and you know, got a lot of traction of people like being using, testing IBCs over, sorry, NFTs over IBC. You have interchain accounts, interchain queries. You have IBC middleware, you have FEE middleware, you even have custom application specific IBC protocols. So the Band team made a custom IBC protocol just to broadcast their Oracle data over ibc. And then you have cross chain validation, which is used in things like ICS on the Cosmos Hub. So what I'm gonna talk about here is some of the stuff that the Osmosis team has been working on, on like some of these new IBC standards and how we're making use of them in our product. So I'll start with the most basic one, or not the basic one, but like, you know, the one people that probably have probably actually used in production at this point. Interchain accounts and interchain queries. So interchain accounts was basically this idea that Josh from the Osmosis team came up with like three years ago, which is the idea of how do you have, can you have an account on one chain make transactions on the other. And after this original blog post went up, you know, it took a while of iteration to actually get it live. But now we actually have like working products that you that make take advantage of this. You have like Stride that uses interchange accounts to do staking on other chains. And, and so now recently there have been a lot of new products basically making use of interchain accounts on osmosis. So we just had Valentin talk about like Quasar, right? Quasar is making heavy use of, you know, they are a effectively like an osmosis ecosystem product right now, but like existing on its own chain and using interchain accounts to LP in osmosis liquidity pools as part of their product. They also have to create interchange queries as well, which is sort of the other half of it. You know, you can pull data, you know, you can read data from another blockchain into a smart contract, right. And so you know, osmosis, we're making use of these interchange queries. We just built this TWOP based interchange query where you know, you can query osmosis TWOP data onto other chains, use it as Oracle pricing. We have this fee abstraction thing that I'll get into in a little bit. And then we're also making use of interchain accounts. One of the things that we're working on right now is this thing called pass through governance. So basically, you know, this is something that we kind of have been working on in collaboration with the Mars team. But like what it is is you can use interchange accounts to participate in other people's governance. So the osmosis, let's say the osmosis community pool holds a lot of Mars, right? You know, there's going to be probably going to be some sort of proposed token swap with the Mars protocol at some point. And the osmosis community pool can foreseeably be owning a significant chunk of the Mars token supply. And what we want to be able to do is if you own 5% of like Osmos and you vote, you should be able to vote with 5 proportional 5% of osmosis community pools as Mars tokens. So this is like one of the things that we're trying to do right now. And the osmosis community pool owns currently significant chunks of Axel Stars region. And so we always talk about this idea of like oh, token swaps will align these communities but Right now they're just sitting in our community pools, not actually being used through this pass through governance, we'll actually be able to have daos be participating in the governance of other daos. The other. So these are sort of like these interesting accounts and interesting queries are very like high application layer stuff. One thing that like a lot of the stuff that we work on is a lot of middleware stuff. So middleware isn't really a technical term. There's not a lot in like the OSI model, but there's this like good definition I like from this like workshop back in 2000 where it's like, oh, it's the services found above the export layer, but before below the application environment or it, you know, it's the dash in client server, it's the two peer to peer, right. And so you know, you think of like technically all of these protocols, like ssl, Tor, cloud, like cloudflare, load balancing stuff, these are technically application layer protocols, but you can, I like to think of them in like a slightly middle stack, middleware level stack. And so what we sort of helped design was this like IBC middleware protocol, which is a standard that makes it very easy to, for people to write custom IBC middleware. And as part of this we've been, you know, we built this one called IBC rate limiting, right? So what this does is it says, you know, we can cap how much of token can be moved off of the osmosis chain in a specific period of time. So let's say we say oh, only 40% of USDC on osmosis can be moved off off of osmosis in a 24 hour period. Right. So what we can do is like okay, you do your normal token transfers, it works great. But once it hits this rate limit as this IBC middleware, it will automatically stop it, it'll be put waiting period. This allows the chain to react in case there's a bug or some hack or something that's causing this massive outflow. Rate limits are how we like to make fun of them in tradfi. But this is actually one of the best security systems you can have. It's like all, you know, if something seems abnormal, pause the system, let human intervention decide if what when to unpause it. Another middleware stack we built, sort of an important One is called ICS20 metadata. And what this kind of is, is we've basically hacked ICS20 which was meant to be the token transfer protocol, into being a more generalized IBC protocol. And so basically Like I said HTTP, this very generalized protocol that lets you build all sorts of applications on top of it rather than application specific IBC protocols. And what we did was we effectively added this memo field to the ICS 20 token transfer and now we can put custom. As long as you can build handlers that can read this memo field, you can basically use ICS 20 packet data to do all sorts of like higher level IBC protocols on top of this. And you know, you get people are often like, oh, when should you use interchain accounts versus ICS 20 metadata? My take is you should use interchain accounts when you need to do stateful actions on the other side. If you are staking on the other side or you are lping on the other side those you need a permanent account on the other side to do that accounting. But if you're doing stuff like cross chain swaps, you don't need an account on the other side. It is a transient action. So that's when this kind of stuff is more useful. So as part of ICS20 metadata, one of the protocols we built along with the Strangelove team is called packet forwarding middleware. Basically it's token forwarding. You know, in IBC today, you know, you can send USDC from Axlar to Juno, you can send that us more USDC from Axelar to Osmosis. But if you try to send that same USDC from Osmosis directly to Juno, this is like no, no, right. Because that USDC is no longer fungible with the USDC that came directly from Axlar. In IBC network we've basically standardized on direct path. So how do we solve this? Normally what would have to happen is the user would have to do a transaction of sending it back to Axelar, then another transaction of sending it to Juno. What we've done is we basically made a way for you to encode that entire path in a single transaction. So you just make a single IBC transaction on Osmosis and it will do the whole multi hop transaction for you and you'll just show up with tokens on Juno without ever needing to make a transaction. Or on Axelar, we've done the same thing with cross chain swap. So along with token transfers you can also do swaps over ibc. So let's say you have atoms on the Cosmos hub, you can make a transaction that basically in the memo field basically says send the atom to the Cosmos Hub to Osmosis, swap the atom to Juno, send the Juno to Juno and it will execute the Entire transaction in a single click. See, I'm not even touching the clicker. It's all happening in one smooth transaction. Same thing where you could also do it for tokens on the same chain, right? We also have it working with CW20 tokens. So you could say, hey, I want to send Juno to Osmosis, swap it to Wind Tokens and send it back to Juno, right? It'll all happen in a single smooth transaction. And when you combine this with. With packet forwarding middle where you can even do stuff where let's say you have Atom on Juno. The problem is you can't send that directly to Osmosis yet, right? Because you need to first send it to the Cosmos Hub. Well, you can Design a single IBC ICS20 packet that basically does five actions all in a single packet. Send the Atom to the Cosmos Hub, then send that to Osmosis, swap it to usdc, send it to Axelar, send it back to Juno. You can do the that entire thing in one transaction. This is really cool, but is it just an idea? No, it exists. This is a demo from. It should be on testnet, but the relayers were kind of shitty on testnet. So this is running on mainnet right now. But basically, this is an example of. This is a product we're building called Cosmos Swap, where what you can do is basically this is all on Juno chain right now. And you can swap Juno for. For Osmosis. And you can go up to the top, right? You can see where it is in the process. I did speed it up 3x just to make it faster, but it takes roughly about 15 to 20 seconds right now for a swap to happen, because it's basically making transactions on multiple chains at the same time. But yeah, now I have OSMO on the Juno chain without ever making a transaction on the Osmosis chain myself. And so as part of Cosmos Swap, we're sort of like building cosmoswap is gonna be the multi chain Dex throughout Cosmos, right? You're gonna have cosmoswap on Juno, you'll have cosmoswap on Neutron, but all executing against Osmosis's far deeper liquidity than any native Dex on any of these chains. A lot of other people are also working on integrations with like Cosmos Swap style stuff, right? You have the Square team, which is like plugging this not just between Cosmos chains, but now we can have this come over gm. You can trigger cosmoswap via GMP as well. So now you can swap Avax for ETH without ever having an OSMOSIS account. The Cato team is making it so you can just with fiat buy any token on Osmosis and send it to so you can buy Juno on the Juno chain. What it'll do is it'll bridge the USDC via Axelar, swap it on Osmosis for Juno and then send the Juno to to the Juno chain. And we're also working on integrating this into a number of wallets such as Trust Wallet. So you have built in swaps into the wallet. So if anyone's building a wallet and wants to integrate cosmoswap, come reach out to us on top of that. But this is all based off of. Sorry, what was it? This is all for the user side, right? We also have the system for. So CosmWASM contracts can also also integrate CosmosWAP as well. So we have a contract that you can deploy on stargaze. Imagine what you wanted to do was make the transaction of you have USDC sitting on stargaze, but the bad kid that you want to buy is price in Starz. You can put this as an entire single transaction where what it will do is it will send the USDC to Osmosis, swap to Stars, send it back to Stargaze, but then also trigger a callback on the stargaze chain which, which buys the bad kid that you want as well. So you can, you know, don't need a native dex on all of these chains. You can still like if you're building a contract CosmosM product on any of these chains, you can integrate with cosmoswap just like you would any native dex on these chains as well. Finally, one of the weird things that you'll notice is if you are doing the cosmwasm side, you need to know the routing table for the entire IBC network, right? Where if you wanted to swap Atom on Juno, now the Juno contract needs to know like, oh, what is the channel between the Cosmos hub and osmosis? This means that every chain needs to maintain a routing table. So what we've done right now is we are maintaining a IBC routing table on the Osmosis chain and we are going to build a system that can propagate this to all the other chains. But what you can do for now is you can actually send tokens to the osmosis chain and Osmosis will use its routing table to completely unwind everything. So what will happen is you first send the atoms from Juno to Osmosis. Osmosis will use its routing table to unwind it, sending it back to Juno and they execute the entire swap for you. This is a little bit of a hack, but it's really cool because there's always been this issue around. Oh, people often end up with assets that like, are not, you know, not coming via the right channels. Well, all you have to do is just send it to Osmosis and we'll do the entire unwinding for you. Yes. Are you rebuilding kind of a BGP routing system in this sense? Kind of, yeah. Yeah. Right now we have like a multisig controlling the routing table that. So basically our team built the Cosmos chain registry. And for anyone who's not aware, it's a GitHub repo that maintains a list of all the IBC channels between Cosmos chains. And so we're basically mirroring, just taking all the data from that GitHub repo and putting it in a WASM contract on chain. Yeah, we want to sort of like evolve that multisig into making it a little bit more of, you know. Yeah, yeah. And like eventually get rid of the GitHub repo and actually have the on chain one be the source of truth. Okay, so now that we have this cross chain swaps, one of the really cool things we can do. Well, one of the things we do today on osmosis is you can pay transaction fees in any token you want. Right. So if you come to Osmosis, you know, you don't have to pay your transaction fees in osmo. You can change the fee to be in any token that's in your wallet. Right. You can pay in Juno, you can pay in usdc. One of the, you know, my personal favorite features of osmosis. And so what we're doing is we're building this new module called fee abstraction that can be imported into any Cosmos chain that will allow people to pay with any fee token they want on any of these chains, basically using a combination of our TWOP queries. And then what will happen? So this, the TWOP queries is what allows other chains to know how to price the fee tokens that they get in other chains. So stargaze could receive fees in Stars, obviously, but they can start receiving fees in usdc, in osmo, in Bitcoin. Right. Like, and they can accumulate all these fees, but then at whatever schedule they want. It could be auto scheduled or someone can just poke it, but it will go ahead and cross chain swap them all to Osmosis, turn it back into their native token, send it back to their chain and then distribute it to fees. So basically what's Nice here is you're giving your users the UX of being able to pay fees in any token you want, but all the transaction fees on your chain are still being turned into buy pressure for your token on osmosis. Completely shifting gears from defi for a second. Another protocol that we've also been building is called the interchain name service. Right. We've been working on this in collaboration with a couple other teams and the idea here is this is meant to really be like a interchain native name service, right? So what happens here is you own the name on one chain, but when you register your. So let's say Cika, right? Sika runs validators on multiple chains and it doesn't have the same address on multiple chains. Right? Like we, we have different multisigs for our validator on Akash as we do. Well we don't run on osmosis, but we have different ones for Akash as we do on the Cosmos Hub. Well, what you can do is, what you do is we can set our Sika Osmo resolution on the osmosis chain, but over IBC we can set our CICA Akash resolution to a completely different address. And then what will happen is we when you start making transactions, the goal is that you'll be able to put so notice that this is a osmosis Kepler screen, but I'll be able to put a transaction that's meant to go to Sika Akash and what will happen is it kind of works a little bit like DNS, right, where it'll just say, oh, I don't know who Cicada Akash is, right? The osmosis chain doesn't know that, but it knows, oh, this is to Akash address. I'm just going to send this to the Akash network chain and then the Akash network chain, once receiving it will be able to resolve who Sika Akash is and send the money to the right people. So this basically is the design for how you can actually have a name service that works for contracts over defi. Like I said, mesh security. I promise I won't talk about it. So really cool stuff. You can go watch my talk at from East Denver Shared Security Summit about it. But all I can say, very complicated IBC protocol, but we're excited to be building it. We've also been working on so far I've been talking about application layer protocols. We've also been working on some stuff a little bit lower in the stack as well. So going down one level from the application Layer we have what's called the presentation layer, right. So I'll say the stuff from here on out is a little. All the stuff I've been talking about so far has been stuff that we're like in active development of or at least in like the, you know, prototyping stage of here. These are more theoretical ideas, but one of the things on the presentation layer, you know, this is what handles encryption compression, all sorts of other things. People are probably familiar with our like threshold decryption work that we've been doing, we've been working on, but we also have this idea called onion wrapped threshold encryption where what happens is imagine. So going back to that example I said of you want to do this cross chain, like, you know, send USDC to Osmosis, swap to stars, send to stars, back buy an nft. You'll notice there's actually multiple points of mev, like front running happening here, right? If someone can see the transaction coming and saying that, oh, we know you're about to buy stars, they can front run you there also, they could see that, oh, you're trying to buy this nft, they can front run you at that point as well. So with onion wrap threshold encryption, what you do is you can basically design a IBC transaction that only peels back the layers of encryption as they're needed. So the first step is I send USDC to Osmosis. It will do that. Then once that IBC packet hits the chain, then the validators are able to decrypt the hidden part and see, oh, okay. The next step is swap the USDC to Stars. Okay, cool. And then it'll be like, oh, send the stars to stargaze. Once it hits the stargaze chain, it'll be able to decrypt the next step which is, oh, buy this bad kid's nft. So you're basically getting the threshold encryption level privacy that we've been building for Osmosis. But you'll get this over IBC as well for these cross chain interactions as well. Going down one more layer of the stack, this is going down to the transport layer. So you know, like I mentioned in today, we have ordered channels and unordered channels. We propose this idea called partially ordered channels. And how it works is IBC packets have a what we call a priority tier. And what happens is you have to flush everything from a specific priority tier before you can go on to the next priority tier. So most transactions will probably just be in the current priority tier. Right. So you know, you have all these IBC packets, they're all in priority tier one. You can, you know, transmit them completely out of order however you want. You can do that middle one, great. But if there's a new transaction that comes in with priority tier number two, you can't execute priority that transaction because you have to first flush out everything at priority tier number one. So only once everything in priority tier number one is done, then does priority tier two pop to the top of the stack and the same, you know, you can have multiple priority tiers in a single system and then you can have, like, you know, queued up pools later on. Basically you're getting, like, using a single ordering type. This partially ordered system you could effectively accomplish, depending on your application's need, you can accomplish either a fully ordered channel or a unordered channel or some weird combination using a single order type. So I think, you know, this is really cool, but it has a really cool use case that I really like, which I call let's finish flushing these packets out called interchange sanctions. So interchange sanctions is our method of how we do censorship, resistance in the interchain. So imagine Amelia is trying to post a transaction to Osmosis, but her transaction is not being received, right? It's not being processed. She's being censored for whatever reason. Well, what she can do is she can post her transaction as a priority transaction on a different chain like Axelar, and then bump up the priority level. So let's say the current priority level is number two. She can be part of priority number two, but then she can make it as part of that. She can say, oh, I'm bumping the priority level on this channel to number three. So all new packets that come in have to be priority level three. And, and what that effectively does is it blocks any future IBC on Axel between Axelar and Osmosis. Until Amelia's transaction is processed on Osmosis, she can do the same thing on other chains, right? She can post it on Juno or. What did I have here? Juno, yeah, you can post on Juno as well. And what's effectively happening is if any chain is censoring anyone by using this, like, method, you can effectively. All the other chains in Cosmos are sanctioning, refusing to make further IBC transactions with that chain until they process the transaction. Once that happens, then, you know, you can send that proof of processing there and it will unblock those channels. I don't think I have enough time for some of the other stuff I was working on. So, you know, I'll just skip through this thank you.