Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
#10 POT: The Cryptocurrency Podcast - Interchain: Building The Internet of Blockchains
78 Plays2 years ago
Interchain Foundation are pioneering the development of tools and protocols that enable blockchains to communicate and interact with each other. They have been instrumental of the development of the Cosmos.
Managing Director Maria Gomez and IBC Product Lead Susannah Evans explain the bigger vision and inner workings of Interchain.
The need for interoperability has never been more critical. The Interchain Foundation's work, particularly through innovations like the Inter-Blockchain Communication (IBC) protocol and Cosmos SDK, is setting new standards for how decentralized networks can operate in harmony, paving the way for a truly interconnected blockchain ecosystem.
Interchain's believes the future of blockchain technology lies not in a monolithic structure but in a diverse and interconnected network of blockchains. The foundation is providing the tools and protocols necessary for creating a decentralized web of blockchains that can interact without central intermediaries, in a safe and efficient way.
Inter-Blockchain Communication (IBC) Protocol
At the heart of Interchain's toolkit is the IBC protocol, a standard for interoperability that enables secure and reliable communication between different blockchains. By allowing data and assets to be transferred across chains, IBC opens up a world of possibilities for cross-chain applications and services, enhancing liquidity and enabling more complex decentralized applications (DApps) that can leverage the strengths of multiple blockchains.
What makes the IBC protocol unique, is the concept of Light Clients. Unlike bridges, which are known to have been exploited in the past, Light Clients operate by basically copying a very "light" version of Blockchain A's state, on Blockchain B and vice-versa. This means that transactions and data transfers need to be verified on both state machines before they can take place. This is a massive bonus for security as well as scalability.
The IBC protocol works as a mailman. The transport layer is concerned with delivering the post, and the authentication layer makes sure that there is a delivery and return address on the message. The protocol is completely agnostic to the data sent, and it's up to the receiving chain to acknowledge and do something with that data.
There are currently hundreds of interconnected chains on Cosmos, and the more the ecosystem grows, the more desirable the idea of being part of the internet of blockchains becomes.
Cosmos SDK
The Cosmos SDK serves as a foundational framework for building blockchain applications with an emphasis on modularity. This set of tools allows developers to create blockchains tailored to specific use cases by selecting and implementing only the necessary components. The SDK's design principles prioritize flexibility and ease of use, empowering developers to bring their blockchain visions to life with greater efficiency.
Interoperability, Scalability, and Security
Looking to the future, the Interchain Foundation recognizes the evolving challenges and opportunities in the blockchain space. Interoperability remains a key focus, with ongoing efforts to enhance the IBC protocol and expand its adoption across a wider range of blockchains. It's a non-trivial task for a chain to integrate the IBC protocol but the team is hopeful that with increased adoption, new and existing chains will begin participate in the Internet of Blockchains.
This podcast is fueled by Aesir, an Algorithmic cryptocurrency Trading Platform that I helped develop over the last 2 years that offers a unique set of features.
Recommended
Transcript
Introduction and the Need for Interconnected Blockchains
00:00:00
Speaker
TASIS of Cosmos, the inter-channel blockchains was really verified. We have seen all this, we have all these hundreds of blockchains and they are trying to communicate to each other. At the beginning, Bitcoin and Ethereum, they used to think of, we are going to create everything on this blockchain.
00:00:25
Speaker
There is not that need to talk to each other. That Tess's cosmos came and was like, yeah, no, these blockchains, huge blockchains are not going to be just done in Ireland.
Meet the Guests: Maria Gomez and Susana Evans
00:00:44
Speaker
What's up, everyone? Welcome to proof of talk. I'm your host, Andre, and I'm here today with Maria Gomez and Susana Evans, who are the managing director of Interchain and the product lead for the IBC protocol. Thanks a lot, guys, for accepting my invitation. How are you both doing today? Very well, thank you. Thanks to you, Andre, for inviting us.
00:01:06
Speaker
No, it's my pleasure, honestly.
Interchain's Vision and 2024 Goals
00:01:08
Speaker
I think that you have an amazing series of tools that you are currently developing, that you have developed in time to really support with inter-blockchain connectivity.
00:01:21
Speaker
and I think there's gonna be a fascinating discussion. So maybe you wanna start by giving a high level overview of the vision of Interchain and what are some of the key areas that you guys are working on right now and looking forward towards 2024. Yeah, I can go ahead and. Anyone can take it, it's out there, anyone's free to take it.
Components of Interchain: IBC, SDK, and Comet BFT
00:01:48
Speaker
I'm going to take it from a very high level and maybe Susanne can compliment.
00:01:53
Speaker
and especially from the IBC perspective. So the test is with the interchain or the test is the Cosmos test is that there is going to be this world which is full of blockchains and is for the communities to define what is it that they wanna focus on. And so the idea with the tools that we are trying to develop
00:02:20
Speaker
is that people are easier for people to set up a blockchain and adapt that blockchain to their local needs. That's the main high-level testes of the Intrusion. And so part of the Intrusion stack is the IBC.
00:02:42
Speaker
which is the communication protocol between the different blockchains, the SDK, which is that set of tools with different modules that people can go and pick in order to launch their chain, and then we have the consensus engine.
00:03:00
Speaker
which is Comet BFT. Those are the key things that developers need to set up and launch their own chain. And so that on a high level is a cosmos test or the interchain test. And those blockchains are not isolated islands. They talk to each other and that's why the IBC protocol is so key.
How IBC Protocol Enables Blockchain Communication
00:03:23
Speaker
Right, yeah, so you basically have the Cosmos SDK which contains a set of tools to build blockchain specific applications that are compatible across any other blockchain who also uses the tools from the Cosmos SDK. You have the Cosmos Hubs, the ecosystem of interconnected apps and services that grows with every other addition to that base chain. Then there's the IBC protocol which we're gonna go in a bit more detail.
00:03:54
Speaker
And then what I thought it was really interesting that you have your own, you have Comet BFD that you just mentioned, which is the Byzantine fault tolerant system, which effectively for anyone that doesn't know, it's an algorithm that's actually inspired by back in the days of like the Byzantine armies, right? When they were ensuring that the army can continue to march or operate even if not all of the members of the army are still there or some of them, I don't know, deserted or something like that.
00:04:22
Speaker
So your guys basically it means one third of the chain, so long as two thirds of the chain remain intact, the network will continue to have a consensus layer, consensus mechanism that works without being interrupted.
Capabilities of IBC: Messaging and Token Transfers
00:04:37
Speaker
Susana, if you want to go into a little bit about the IBC protocol and talk about how all that works, I think that would be super interesting.
00:04:46
Speaker
Yeah, so kind of as Maria mentioned, you've got loads of different blockchains in the interchange, we call it, I think right now there's over 100. And, you know, kind of as Maria mentioned,
00:05:01
Speaker
Each chain has the ability to choose like what it wants to specialize in, what application it actually wants to have. And then the idea is that change should be able to leverage other applications from other chains and kind of seamlessly send messages, data, tokens between them.
00:05:21
Speaker
and in a truly sovereign world, then we don't want to have to rely on someone else, another blockchain, some kind of intermediary to enable these chains to communicate. So this is why there was a need for this
00:05:38
Speaker
interoperability protocol, which would allow blockchains to communicate on a peer to peer basis. So not adding in any kind of intermediary that verifies something happens on one chain and then lets you do it on the other. Instead, we use something called light clients, which is able to track the state of another chain. And then you just have to
00:06:01
Speaker
update the light client to verify that something happened on one chain and then you can perform an action on another chain.
Cosmos SDK and Comet BFT's Role in Interoperability
00:06:08
Speaker
So the inter-blockchain communication protocol is a generalized protocol which enables this communication between chains and doesn't add in any additional trust assumptions. So you just have to trust the blockchains that you want to send messages to each other and this is kind of a really core part of the protocol.
00:06:28
Speaker
And the protocol is used really extensively in Cosmos, but it's actually a generic protocol that can be extended to other blockchain ecosystems as well. So not just the chains that use Comet, Cosmos SDK, maybe the Cosmos and stuff. It's actually a general protocol.
00:06:50
Speaker
Right. It's also the, is the most popular, right? Interchain protocol on Cosmos, isn't it? It's definitely one of the biggest, if not the biggest one, like the most popular one being used. Yeah. I think because, well, it's, uh, if you're building with the Cosmos SDK and Comet, it's just another module which you enable. So it's like, you've got this really powerful protocol to communicate with other chains. Um,
00:07:18
Speaker
It just makes a lot of sense that you would want to then enable that on your chain. And I mean, the network effect just grows like as more and more chains kind of join the network, it just becomes increasingly desirable for you to want to also be a part of that network.
00:07:34
Speaker
Right. Yeah, that makes perfect sense. Just going back to the idea of light clients and the fact that you don't need a third party to run this thing.
Security: IBC vs Traditional Bridges
00:07:45
Speaker
Basically, you're making bridges. Bridges are known to be relatively unsecure. A lot can happen. They can be vulnerable to attacks. Whereas
00:07:54
Speaker
the light clients are not like bridges at all from my understanding and please correct me if I'm wrong but from my understanding the light clients are like a very light copy of blockchain A on blockchain B and therefore they're kind of aware each chain is kind of aware of the other chain's state and that's how they're able to transact securely without needing a bridge.
00:08:18
Speaker
Yeah. So I think maybe, so bridges definitely is kind of... If I butchered that, let me know. That's actually really, you know, like a great way of explaining it. But I'd say, yeah, when people think of bridges, it's definitely like a loaded term. And I think people think of bridging as kind of these externally verified bridges. So where you do have some maybe like chain in the middle, or you've got some kind of
00:08:48
Speaker
oracle off chain service, which is like saying this thing happened on the other chain rather than it, rather than using like clients. Um, but then when I like, I think bridging is just like one of the use cases of interoperability because bridging is, um, it's just moving tokens between chains. Um, so IBC, uh,
00:09:13
Speaker
It's not a bridge in the sense of these kind of externally verified bridges, but it does enable you to move tokens between chains. So it enables the bridging use case, but it's not like a bridge that we think of bridges, kind of, you know, the bridge hacks and this kind of thing.
00:09:32
Speaker
And yeah, exactly. As you said, like a light client is just a, um, a, a way to track, um, the state of another blockchain. And it's more lightweight than running a full node because with a light client, you don't have to track every single block that you're, that the blockchain is producing. You just need to update the light client with the blocks that you're kind of interested in.
00:09:59
Speaker
So it's like, there might not be an IBC transaction on every single block. So it's like, you don't have to therefore then like follow every single block as you do with a full node. So a lite client is a lot lighter and this is kind of important if you've got it on chain, like kind of state is a kind of more scarce resource. You don't want to just like grow the chain, you know, inevitably, if you're running a full node of every single chain that you want to connect to.
00:10:28
Speaker
It's going to be a lot. So yeah, like clients are just a more succinct way of tracking a counterparty that you want to communicate with.
00:10:37
Speaker
Right. And I think that's a very important distinction to mention that a live client is not a full node, but instead it connects to a full node, right? It gets the data that it needs from a full node and then goes like, okay, this is what we have on this chain. This is how you need to reconcile this data. So you've also mentioned that it offers the obviously the bridging capability, but without the vulnerabilities of an actual, you know, bridge that you manually built between these chains.
00:11:04
Speaker
What are the use cases are there for the IBC protocol?
Beyond Tokens: IBC Use Cases
00:11:11
Speaker
So you could send arbitrary data between two chains. You can create a chain on another account and control it from another chain. This is what we call interchain accounts. You could query the state of another chain
00:11:28
Speaker
uh, kind of an instant query. Um, we also have, um, so we have like application modules and you can build your own application module, but we also have middleware, which means that you can extend existing application modules. So we see some really cool use cases of people will like,
00:11:48
Speaker
use a token transfer, but then they're also using a middleware to then do something with those tokens and maybe send them on to another chain. So for instance, you might send your token to Osmosis, then perform a swap and then send that back. So yeah, it's like any data transfer controlling account from another chain,
00:12:13
Speaker
querying state from another chain. I think there's quite a large possible design space and possibilities of what you want to do. You can make quite extensive cross chain workflows with IBC.
00:12:28
Speaker
Right.
Reliability of IBC's Packet Lifecycle
00:12:29
Speaker
So the way I see people compare the protocol to is like a mail service that's split into two different layers. You have the transport layer and the application layer, and then the transport layer is basically the mailman
00:12:45
Speaker
taking your post, making sure that it's got the stamp, it has the delivery address, it has a return address, and then it just delivers that. It's not really concerned with the format of the data or the shape of what the data is. It just makes sure to deliver it. If the address exists, if it doesn't exist, it just returns it back to sender, which I think is really cool, especially when people are just sending tokens without, you know, that eliminates the risk of sending to an invalid address, doesn't it? Yeah. In a sense.
00:13:14
Speaker
Yeah so it's like I think that the kind of as you mentioned one of the big powers of IBC is that you do have this transport application layer kind of these two abstractions are really well defined and every single application that
00:13:31
Speaker
um, you want to develop and use with IBC is having exactly the same, uh, we call it the packet lifecycle, the way of sending, uh, messages from like source to destination. And then we also send back a confirmation that, uh, this message was received and we will act on it and it was kind of received successfully so that the sender actually knows. Okay. Yeah. Like.
00:13:58
Speaker
what I wanted to do actually happened, which that's actually missing in a lot of interoperability solutions. Most bridges don't have that functionality. You just like send and hope for the best. Yeah, which is wild.
00:14:15
Speaker
Yeah, yeah.
Challenges in Adopting IBC in Non-Cosmos Chains
00:14:17
Speaker
But having this, you know, kind of exact the packet lifecycle being the same for every single application, it means that the role of the relayer is quite like a
00:14:33
Speaker
The relayer doesn't have a responsibility to make sure that like the information being sent in the packets is correct because the information being sent in the packets is actually opaque to the relayer and it's up to the applications to decode the information. So this also makes it kind of like
00:14:52
Speaker
tamper-proof when you're sending the packets between the chains. And it also means that relayers are just responsible for, like, ferrying stuff to and from. They're just responsible for the liveness of the protocol. But it also means that when you plug in, like, new app different applications, you know, there's, like, some consistency in how you're actually going to move things from chain A to chain B.
00:15:23
Speaker
And right and and yeah consistency right is is basically the the the keyword here because it's it's well I mean so many chains have these kind of makeshift bridges right that make it connect to each other in a way and that was I was I was there when all of the hacks in 2021 were happening like another bridge hack the harmony bridge one hack
00:15:46
Speaker
All these like, one day after another, a hundred million dollar hacks were going on in crypto. It was not like another day, another hack. And that was, again, from my understanding, the way the bridge hacks happen is because you're basically, when you're bridging assets, you're effectively saying, okay, this token on this chain gets to this burn address. Once the other chain confirms that that token was burned, it releases it.
00:16:12
Speaker
onto the other chain, but is a way to fold the first chain into thinking that it's burned or transferred that to the appropriate wallet when in fact it was never sent, therefore just minting fresh coin on the other chain without having to confirm what actually happened on the first one. So the protocol, the IBC protocol helps remove that kind of exploit, right?
00:16:39
Speaker
Well, yeah, because I mean, with using Lite clients, you have to prove that something actually happened on the source or destination chain. And if you can't prove that, then you wouldn't be able to earn escrow funds or mint the token to say like,
00:17:01
Speaker
the sending chain actually did send the token to the destination. So yeah, I think like with a lot of the bridge hacks, there were some which were kind of like implementation bugs and then some which were multi-sig exploits. So then people could, you know, literally just say,
00:17:22
Speaker
meant this because I'm signing saying it happened and it's just some random person that's taken over the bridge. So supposedly it's still a bit of a learning curve for the cryptocurrency ecosystem to realize the importance of intercommunication in this aspect. I'm guessing
00:17:45
Speaker
because it's something that requires you to run a live client on your chain, you would need all of the blockchain themselves to kind of adopt the IBC protocol, right? Or build the chain with the protocol in mind. Would you say that it's easier to adopt the IBC protocol for a more mature-ish solution? I think that's kind of one of the challenges we see of IBC is it's
00:18:14
Speaker
non-trivial to have a native integration if you're not a cosmos chain just because there aren't really
00:18:23
Speaker
There's not loads of implementations for different blockchains out there. We do have the IBCRS, which is making strides and will be enabling a few REST-based chains and roll-up frameworks to connect to the network. And there is a Solidity implementation, which
00:18:44
Speaker
some teams have some either fork or variant of it in testnet to underpin a connection to Ethereum. But yeah, it's not a trivial task to have a fully functional implementation of the protocol. And I think like the approach in
00:19:06
Speaker
in Cosmos is you kind of have it, you have IBC enabled as a part of your kind of blockchain protocol, whereas if you look at the kind of interoperability more in Ethereum and EVM chains, often the solutions are deployed as smart contracts. So it's kind of bridging based in the EVM, whereas we're kind of the layer below
00:19:36
Speaker
by just enabling it in your chain code. Right. Yeah, that makes sense. So there's the challenge of adding new non-cosmos chains is still there. But from what I get is you're working to create solutions that allow for that a bit easier in a sense. Does it have to do at all with the code base of the solutions? I think IBC is written in Go, if that's right.
00:20:04
Speaker
Or most of the packages I saw that they're written in Go. Cosmos SDK as well is also written in Go. Are you guys planning to roll out more developer support, different languages to kind of help with that adoption?
Efforts for IBC Compatibility with Other Chains
00:20:18
Speaker
So we work on IBC Go, but there's a REST implementation, which the team at Informal work on. And there is a Solidity implementation, which is
00:20:31
Speaker
kind of at the testnet stage. The IBCRS implementation is also actively being used on testnets and stuff as well. So yeah, there are a few different implementations out there. I think as well, I mean, for us specifically, because IBCGo is the...
00:20:54
Speaker
the call it the reference implementation, it's the, the first implementation of the protocol, and it's the most feature rich, it's just been developed the longest time. So which makes sense naturally that it's got, it's the most up to date with the specification kind of thing. And we're kind of thinking about how can we
00:21:18
Speaker
make the product that we work on usable by non-cosmos SDK chains as well. So we started some exploration into how it might look to integrate with the OP stack. It's still very exploratory work, really, and we will be starting work on a proof of concept in February.
00:21:42
Speaker
But if the approach works, then it would be easier to port IBC code to other frameworks, not just using the Cosmos SDK. But yeah, we'll just have to
00:21:58
Speaker
It's a, you know, it's a non, these are non kind of trivial challenges to try and, uh, make it more affordable. So we'll see, I guess, but yeah, kind of hopeful because, um, you know, as we said, it is the biggest challenge of, if you don't have something, which is, you know, kind of close to plug and play, it does make it harder to use, use the protocol in the first place.
00:22:28
Speaker
Oh yeah, for sure. Um, do you want to go maybe in a bit more detail about the solution that you, you're kind of planning to develop in February? No pressure, if not, it's totally cool. Uh, I'm just asking. Well, so I can go over in a slightly high level. So yeah, sure. The idea, um.
Integrating IBC with OP Stack: A Proof of Concept
00:22:51
Speaker
As I kind of mentioned with like EVM chains or rollups, you could just deploy a solidity smart contracts to enable IBC that way. Um, but in general, there's kind of issues because a lot of these EVM environments are kind of gas constrained. So like running a light client on Ethereum is really expensive.
00:23:18
Speaker
So the idea that we're going to look into a proof of concept for is so with the OP stack specifically you have like OP-GAF which is the Ethereum client and then you have like a sequencer which is basically posting the transactions
00:23:37
Speaker
Um, that, that people are, um, broadcasting sequence there through OP graph and then pacing that the call data and stuff to Ethereum. Um, but our idea is what if you could Mount like another execution engine alongside OP gas and that would be mounting, uh, IBC go.
00:23:59
Speaker
And then if you create an interface between the two execution engines, they could communicate in an async way. So you could have like one, uh, execution engine responsible purely for IBC transactions. And then one, which is like your, your EVM based, uh, engine, you know, that kind of end user will just be doing whatever stuff they're doing on that rollup.
00:24:23
Speaker
Um, so yeah, the proof of concept is examining whether we could actually create like mount two different execution engines in parallel. Uh, so yeah, we'll, I guess we'll, we'll see. I think it's a, it's a cool idea and there's already, um,
00:24:45
Speaker
Yeah, some, some work going on, uh, by other teams to try and have like a OP stack integration, specifically polymer who are taking like a different, a slightly different approach because they're just mounting, um,
00:25:02
Speaker
the Cosmos SDK onto the OP node. So yeah, we're kind of all collaborating, working together on sharing ideas and solutions, but yeah, that's kind of the thing that we're going to try out. But yeah.
00:25:24
Speaker
That sounds super exciting though. It's obviously such a, I hope it works. It sounds like an incredible solution to a real problem.
Driving Adoption of Interchain Technology
00:25:32
Speaker
And I think that's also where community becomes like really, really important, right? Because all of these tools are open sourced, right? So people could, communities could try and find a way to find a solution to that problem. They could just run it, you know, a mock chain locally and figure out a way of
00:25:54
Speaker
of doing it, which is, you know, it's fantastic that it allows for people to kind of come up with solutions if they want to, if they're keen to contribute to that. Yeah. I mean, I think it's.
00:26:06
Speaker
Yeah, the blockchain space is just like evolving really rapidly. And, you know, it's like the way it was two years ago is already quite different to how it is today. And yeah, I think the technology is just the pace of change is quite quick. So yeah, people will just keep innovating.
00:26:31
Speaker
What do you guys think lies ahead in terms of, well, from interoperability to scalability to security? What do you think is on the horizon in the next few years?
00:26:48
Speaker
I can answer. Go ahead.
Future Trends: Interoperability, Privacy, and Scalability
00:26:52
Speaker
I think like zero knowledge proof based technology is going to be really important. For interoperability, you've got kind of the use case of like compressing the proof size. So being able to update a light client in a more
00:27:16
Speaker
in a cheaper way. I also, I really believe in the kind of privacy cases as well. Because, yeah, I think that there's some, clearly, it's good to have this kind of verifiability and the immutability of blockchains. But I think if blockchain technology is going to underpin like a
00:27:43
Speaker
you know, the new financial system, you just couldn't really do it without privacy. So yeah, I really think that's going to be important. So yeah, and I think it seems like
00:28:04
Speaker
There's more teams working on ZK based stuff. And I think the technology just seems to be developing. I'm definitely like far from being an expert on the subject, but it seems like it's moving into more people actually having like tangible applications or like privacy chains. Well, there already are some privacy chains like Zcash and stuff, but new privacy chains and new designs are
00:28:34
Speaker
emerging and they'll be launching on coming years kind of thing. They're rolling out a privacy chain solution. I forget the name, but I'll definitely send your name. I think it's really interesting. So there's a distinction right between privacy from like end to end as in
00:28:56
Speaker
hiding the user or the wallet or hiding the contents that are being transferred through. So from the discussions that I've kind of had recently, it seems like a move towards protecting the actual transaction details. So you're not gonna know if I sent you a certain NFT or a certain amount of tokens or something. You can see the wallets interacting with each other, but you won't be able to see what they're actually transacting.
00:29:23
Speaker
uh which makes things a lot safer and a lot less prone to to exploits because you you know I think that's important yeah I think it's like uh you know on Ethereum it's like MEV is a big problem again not an MEV expert but I think if you you know having private mempools or if you just had private transactions um
00:29:48
Speaker
as a default or use things like threshold decryption, where the transaction is only revealed after consensus has been reached on a given block. Things like that will just already massively reduce, you know, that like loss from MEV. So, and then it's like, you know, people would have more kind of ownership over their specific trading strategies or something and they're not going to get
00:30:19
Speaker
sandwich or whatever things like this. Yeah, I take away the math bots from the decks and suddenly no one's making money in DeFi anymore. Yeah, maybe it's like detrimental consequences then.
00:30:34
Speaker
Yeah, you can't front-run anybody. This is no fun. But yeah, no, that's a super important thing to be solving. And I've seen a couple of projects looking to solve this kind of stuff. I've also seen a move from being an AMM or being a liquidity provider to being more of a trader in DeFi.
00:30:55
Speaker
It just gives you more of the, yeah, it just allows you to do more stuff with your crypto and more, take more control of decision making rather than just providing liquidity, hoping that the pool will remain profitable. Yeah, yeah.
00:31:15
Speaker
But yeah, so in terms of in terms of interchange future in crypto and the crypto industry, what are you guys aiming for in the next in the next few years?
Reflections on Cosmos' Vision and Developer Support
00:31:31
Speaker
What is like the ideal vision for you guys?
00:31:36
Speaker
I think on a very high level, one thing that was very fun to see in the last
00:31:46
Speaker
one or two years, I would say, was these, you know, like the testes of Cosmos, the inter-channel blockchains was like really verified. You know, we have seen all this, we have all these hundreds of blockchains and they are trying to communicate to each other. At the beginning, you know, Bitcoin and Ethereum, they used to think of we are going to create everything on like this blockchain and
00:32:16
Speaker
There is not that need to talk to each other. That TESIS Cosmos came and was like, yeah, no, these blockchains, huge blockchains are not going to be just on island and everything is going to be built in one thing. That TESIS was validated. Cosmos had that vision since back in 2016, 2017.
00:32:41
Speaker
when things were getting some traction. So now what we need and what we really need to focus on is adoption.
00:32:58
Speaker
And for that, we really need to try to extract somehow all the amazing technology that enables all these functionality for blockchains and enable a lot of use cases. But we are still very far from the mass, you know, from like your normal people. And of course we have to work, we have to start somewhere else. And like you have to have that,
00:33:24
Speaker
initial target market and they are, for us, they are developers and they are very savvy on the technology. But maybe not necessarily for us as a foundation, we are funding all this amazing technology or this interchange.
00:33:42
Speaker
stack and IBC and the SDK and command BFT. But maybe we need to start also trying to push for the builders to also pay more attention for adoption and make it easier for people to use the tools they are building.
Making Blockchain User-Friendly
00:34:03
Speaker
And so, yeah, that's one of the important things to tackle, because that will bring adoption. And that will bring adoption. If people are starting to use all these blockchains and all these tools out there, then we're going to have more builders, which are the developers that are going to be using the stack to set up their blockchain and provide a solution for their use cases.
00:34:32
Speaker
So I think that's another thing that we need to talk about. Yeah, and actually I was just talking to the co-founder of Horizon in my last episode. They're building a platform that helps game developers connect to the Web3 layer and then connect to using SDKs. They can connect to Unity or other game engines and pull chain data.
00:35:00
Speaker
from the chain to use it in their games. And I feel like the conclusion tends to be similar across different spaces that you gotta first take care of the developers. You gotta have to give them the tools to build the products that then the people want to use because it's a new technology, because it's still emerging, because there's a lot of, there's still a lot of unknowns, even people that are specialists in the industry still have a lot of unknowns and problems to solve.
00:35:27
Speaker
building for developers effectively means building for the community later down the line. So I think in many ways it's just building for the future, isn't it? Yeah, exactly. And of course we need to focus, right? And like our focus in the case of the Interchain Foundation is the builders and the savvy people make sure that they have the right tools in order to go and create their blockchains. And they are the ones that are more concerned
00:35:57
Speaker
we're talking to the end user. However, I think sometimes we have to, you know, like, the fact that we are focused on something, we, we didn't necessarily that doesn't mean that we need to forget about the other side. And even if
00:36:15
Speaker
I don't see that that's one of our priorities. We need to start talking also with those developers to see how they see adoption. What are the type of use cases that maybe we need to prioritize, for example?
00:36:32
Speaker
and make sure that those developers in that set are like serve. And so they have more time to really think about instead of like solving big tech problems, they like find the time to really like make sure that they can reach the end user and people can use it. People don't need to learn that much about
00:37:02
Speaker
technical side of things in order to be able to use this thing. And we are not there. Even for us, sometimes things are tricky and like go to use. And like we are scared of sending a transaction. It's like, yeah, we started to think about that if we really need adoption, if we really want adoption.
00:37:24
Speaker
Yeah, no, 100%. And that just makes so much sense. You're thinking about if it's still a challenge for people in the space to use some of the technologies, then you know, people that are non-technical, how are they going to go and, you know, navigate the space. I don't think it's that kind of common knowledge, like, hey, this is how email works, or this is how, you know, it's
00:37:44
Speaker
It's not there yet and it's probably not going to be there for a while. And especially with the solution like Interchain connection or things like Cosmos or solutions like Polkadot. This is like really building way into the future. It's an amazing vision that still needs to cement itself. But I think some of the use cases are effectively
00:38:05
Speaker
creating immutable data for, I mean, any kind of organization, right? You could be a hospital, or you could be a hospital wanting to host data on chain and then have a way of communicating with all the other hospitals that all have their own little network that are connected by an interchain solution, right? Or something like that. Exactly. Yes. I think for things like that, it's like you would inevitably need privacy
00:38:34
Speaker
Right. Because like GDPR is already such a massive, especially in, you know, it's obviously a problem. It's like, if you're putting a hospital data on a blockchain, you know, you need to be able to verify that it's going to be private. I doubt you're going to be putting that stuff on like a public blockchain, obviously. No, you probably wouldn't want to do that. But yeah, I think.
Real-World Blockchain Applications
00:39:03
Speaker
It does seem like a lot of those kind of, they use like supply chains or there's some of like real world use cases, like some internet service providing like blockchains, actually creating a real life network. There's the environmental kind of
00:39:26
Speaker
carbon credits tracking stuff. Yeah, I think it's like, people have some kind of signal amplification thing, but then they also have like a node, so it can keep track of like, who connects to your, your, your like, signal provider. I don't know precisely how it works. But but I remember talking to someone who told me about it. And they were saying that
00:39:54
Speaker
a problem with internet in some less developed countries is that people are kind of overcharged because they have discrete blocks of usage rather than actually paying for how much you actually use. So blockchain kind of solves that.
00:40:23
Speaker
problem because you can directly track like how much data did someone actually use when they connected to this node.
00:40:33
Speaker
Right. But do you think is that kind of the best, the best way of providing that service? Or would you just be like a flat fee? Like we most pay for our broadband? Hey, here's the flat fee. I can just watch Netflix all day long if I want. I guess it, I mean, that's like a question about like pricing models generally, right? Should it be paid for what you use or do you just have the unlimited amount? I guess it's like for
00:41:00
Speaker
Like we're in a privileged position where paying like 50 euros or whatever a month is not a big deal. Whereas that's probably not the case. You know, internet access is actually still not like the naught. I think there's something like a billion people who don't even have access to the internet in the world. And yeah, there's still lots of kind of development, you know, to have
00:41:29
Speaker
actually full coverage in the world. Solutions like Starlink could totally help a lot with that. If there was more volume for solutions like Starlink, it's just basically internet via satellite. Apparently it doesn't work well at all in the city because there's just
00:41:49
Speaker
too much noise in terms of like wavelengths and frequencies, but in less populated areas, that is very useful. That could be a solution. Could that be delivered kind of like via a blockchain thing, pay as you go, something potentially, I guess. I don't know. I mean, I don't even know in detail how that application works. I just remember talking to someone and thinking it's like an interesting real world
00:42:17
Speaker
the application of blockchain. There's a few blockchain organizations trying to solve the internet problem, the issues in Africa. I think some of them are trying to do it with like those media balloons.
00:42:35
Speaker
that you put up in the sky and then kind of I think is very similar to what you're saying Susanna I think they're sort of allowing connections based on the amount of usage as a price and you're like running a node effectively kind of pays in a sense for that usage in a way.
00:42:56
Speaker
And it makes it inherently fair because you never pay more than you use. And there's literally no markup. And I think that's where the issue is that we pay whatever it is, 50, 60 dollars a month for internet. But there's a huge markup if you actually consider the network cost, which is probably minimal. Yeah. Yeah. Yeah. I mean, yeah, I've always the internet in Germany is not very good.
00:43:27
Speaker
I wouldn't have thought I thought I thought it'd be one of the one of the best. No, no, I think I think countries like South Korea and Japan are meant to have like
00:43:39
Speaker
some of the best internet connections in the world. Yeah, I think is Japan. Do you guys have any announcements that you want to make any anything in the future for people to look forward to any particular links or anything that you want people to get involved in at all?
IBC's New Feature: Channel Upgradability
00:44:00
Speaker
I can
00:44:02
Speaker
give a brief shout out to our latest release, which will be by the end of the month. Um, so our, our, our latest release will be the 8.1 and, um, the feature that it's Scott in this release is called channel upgrade ability. And this is a way to, um,
00:44:25
Speaker
basically upgrade an existing channel with IVC. And this is really cool because if we think about like technology generally, it's like something that was made two or three years ago. It already kind of becomes outdated as soon as you like, you know, it's like the computer you buy, as soon as you buy it, it's already appreciated in value because it's no longer new.
00:44:54
Speaker
And that's just kind of true for all technology in the world. And so channel upgradability allows you to upgrade the existing functionality of a channel. So a channel is just the, you can think of it as like the path that like data packets are moved from one chain to another along. And this means that you can extend kind of the existing applications that
00:45:25
Speaker
you're using this channel for to send packets between. So for example, if I'm using a channel to send tokens between two chains, I could now upgrade this channel. So I could add middleware on both sides of the channel. So this would basically then enable you to do things like incentivize relayers along this channel.
00:45:52
Speaker
Or you could change the ordering of the channel. So you might have a channel which says, I have to deliver packets in order, so sequentially. And then you might say, OK, actually, I don't need this anymore. I want to change it to be unordered. So packets can be delivered in any order, rather than having to be time-based from when they are created.
00:46:17
Speaker
Or you can just say like you wanted to extend and change an existing application. Now you can do that, um, without losing like all of the, the state you built up from moving like packets along this channel. And this is like really important for tokens because fungibility is just kind of probably the most important thing when you, when you think about interoperability.
00:46:44
Speaker
But so yeah, it's just a way that enables us to kind of keep pace with changes of technology, improve the protocol based on changing user needs.
00:47:00
Speaker
but do this in a way which isn't going to sacrifice all of the fundability of the tokens that you sent along this channel in the past, or just all of the state that you accumulated on this channel.
00:47:15
Speaker
So it's all backwards compatible still. Yeah. Well, the upgrade is not backwards compatible, but it's like you don't have to create a new channel. It's like you can retain the channel of communication, but now you can extend its functionality. Right. And you've mentioned that you can deliver data packets in a sequential order or in any order. What would be the advantages of either and why might you want to do one or the other?
Preventing Censorship Through Channel Ordering
00:47:44
Speaker
So if you had an application where the order of the delivery of the packets was really important, like you wanted to perform actions, but they had to perform in a certain sequence, then you might want an ordered channel. But for token transfers, you don't have an ordered channel. Another kind of, well, maybe this is like
00:48:11
Speaker
This is more of like a future idea, but you could also use channel ordering to prevent like censorship. So if you had some connection between the packets that are being created in this channel and to say, okay, after like so many packets have been delivered, I have to make sure that I've delivered packets from like
00:48:39
Speaker
100 packets earlier. This is kind of a way to prevent people from just censoring and never actually sending certain packets. So there's kind of some ideas and areas to explore if censorship resistance is something that people really want. That's also a possibility with changing the ordering of channels. That's cool.
00:49:05
Speaker
I like that. Well,
Conclusion and Further Resources
00:49:08
Speaker
thanks a lot, guys. This has been a fantastic conversation. Yeah. And if people want to learn more about the Interchain Stack, they can go to interchain.io. Interchain.io to find out more about the Interchain Stack.
00:49:20
Speaker
Awesome. And that's where you're also going to have all the open source repos, right? Like the Interchain, the IBC repo and the Cosmos SDK repo and everything like that. I did have one more question around the language. Is there a particular reason for choosing Go to write some of the packages?
00:49:44
Speaker
I mean, that decision was made way before I was ever involved with the Cosmos ecosystem. But I think I think it's probably picked because it's
00:50:02
Speaker
a relatively easy language to onboard to, but has secure properties, I think, generally. It seems to be a language that people are using, not just within Cosmos, but in the blockchain space generally. I think because there's a general security consideration when you're developing anything in blockchain. So it kind of fits the
00:50:32
Speaker
the bill for being like, sorry, my head is disconnected, I don't know why, for being
00:50:39
Speaker
Yeah, secure, relatively easy to onboard to, good for distributed systems. I guess that's just why it was chosen. But I honestly have no idea what's going on. That's fair. I was just wondering, because sometimes you do have choices like, oh, Polkadot does Rust. And there was another project that did Viper, which is like another, like a Python-like language, which just turned out to have a lot of security issues at some point, which were also, it caused one of the hacks we had earlier last year. So I was just...
00:51:08
Speaker
I was wondering, but yeah, that's all good. Was there anything else, Maria, that you wanted to add? No, nothing else. Okay, well, perfect. Thank you so much for the conversation, guys. This has been a great pleasure to sit down with you and kind of talk about Interchain, future blockchains and everything in between. And I wish you both a very nice day. Thank you. Thanks. It was very nice to meet you. Bye-bye. Nice meeting you too.