Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Bonus 1/2: “Epicenter Live” and a Chat with Jae Kwon of Cosmos – Interchain Conversations Berlin

Episode Date: June 21, 2019

This is part one of a two-part bonus series. These sessions were recorded at the first Interchain Conversations conference which took place in Berlin on June 13th and 14th, 2019. The first part of this episode is “Epicenter Live,” a live podcast recorded on stage at the event. It features hosts Meher Roy, Sunny Aggarwal, Brian Fabian Crain, and Sebastien Couture. In this conversation, we discuss the topic of blockchain interoperability. We look at how different projects address interoperability and seek to form a picture of how these projects might interact in a multi-blockchain future. We also discuss how these protocols address application comparability and speculate on how they will remain competitive. The second segment is the opening Q&A between Jae Kwon and Sebastien Couture. Among other things, Sebastien spoke with Jae about the recent Cosmos launch, the Interchain Foundation, and the future of the Tendermint company. Subscribe to Epicenter for new episodes every week.

Hi, welcome to Epicenter. My name is Sebastankujiu. So this week we've got two bonus episodes for you, both of which were recorded at the Interchain Conversations Conference, which took place in Berlin last week on June 13th and 14th. It was organized by the Interchain Foundation in Cosmos, and this is part one of a two-part bonus series. So you'll notice that we haven't done bonus episodes in a really long time.

In fact, the last time we did this was back in 2014. But this is something that you should expect to see more of, and as always, we're happy to hear your feedback. This was a special occasion because for a very brief moment before the event, all five of us, Epistenter hosts were together, and Brian Mayer, Sunny, and I were all at the conference and participated in the hackathon, which took place over the weekend. We got to connect with a lot of you, our listeners, which is always extremely gratifying, and just emerge ourselves in the cosmos ecosystem for a couple of days. It was also special because it was the first time that we saw a big part of the cosmos community come together under one roof. I think people have the sense that it marked the beginning of something significant. And for a lot of people, including myself, it was the first time that we were getting to meet a lot of the folks with whom we talk on Twitter and forums and telegram and just put a face to the Twitter avatar for the username.

So in this episode, you'll hear the first edition of Epicenter Live, which we recorded on, stage at the event. Our discussion was centered around blockchain interoperability and what a multi-blockchain ecosystem could look like in the future. We address topics like application composability and the different approaches between Ethereum, Pocod, and Cosmos. And we talked about things like, you know, how we should expect chains to compete in the future as they potentially become more generalized. And at one point, Mayor goes off on a tangent and makes a great analogy comparing blockchain to evolutionary biology. That thing was great. Anyway, I hope that I hope you'll enjoy it because it was a lot of fun and we definitely plan to do this and hope to do this in the future.

In the second part of the episode, you'll hear my Q&A with Jay Kwan, the founder of Cosmos. So I sat down with Jay at the start of the event for about 30 minutes to kick things off and set the stage for what was about to come over the next few days. I hope you'll enjoy these sessions and be sure to check out part two of this bonus series, which is also available now. So with that, here's Epicenter Live in Berlin. Up next, we have Epicenter doing a live recording of their beautiful podcast. We got Sebastian and we got Brian coming up to the stage next. Here we go. And Sunny.

And Mayher. It's fine. Thank you. Okay. Hello, everyone. Welcome to the very first edition of Epicenter Live. I mean, it's live, it's kind of a lot. I mean, it's live because we're doing in front of you guys.

It's not live streamed or anything like that. But it will be released on the feed in the next couple of days, probably next week. So, you know, we wanted to do this because for the first time in a while, most of us, at least, we're going to be here at the event. Unfortunately, I feel like it could not be here because of other engagements. But this is something that I think we,

we would like to continue doing when we travel to events, so we already have plans to do this perhaps in the next few months. So it's very much experimental. And the way that we'll be doing this is, and we've got a couple of topics here that we want to cover, and we want to leave it open to you guys, also to interact, ask questions, comment. You know, we don't have all the answers or all the knowledge.

A lot of the knowledge is also in this room. So there is a mic going around. So if you have anything to say or anything to comment on during this discussion, just raise your hand, get the mic, and intervene. So for those who don't know Epicenter, Epicenter has been in the space for over five years. Obviously, we're a podcast. And you have four of the hosts here on stage today. So Meher Roy, Sunny Argyal, Brian Fabrian and myself, Sebastian Kuchio, and the fifth host, Friliger Ernst, who couldn't be here. Just before we get started, a couple of disclaimers.

Obviously, as most of you know, a lot of people here on this stage, all of us are atom holders. We also participate in various Cosmos projects or companies related to Cosmos. And Cosmos is also a sponsor of Epicenter. I just wanted to get that out there. If you didn't already know that. So the first topic on, I mean, so the broad topic today is blockchain interoperability. here at the Interchain Conference. And so, you know, the first thing that maybe to get things started off is sort of lay

out the blockchain interrobability landscape. And so, you know, today's event is obviously about Cosmos and the Inchained Foundation, but you know, there are other projects out there. And within these projects, there are questions around how these projects will interact within themselves, but also amongst each other. So starting off, what is to you guys sort of the interoperability landscape look like outside of the projects being discussed here at this conference? Go ahead.

Okay, I mean, so I guess, I mean, the two main interoperability projects that, like, you know, I'm particularly very interested in and I've been like kind of like focused on is, the first is obviously Cosmos, and then the other is interledger. And I think that these are like, you know, kind of these two are like two of the examples on the two different spectrums of interoperability. So Cosmos, we're kind of talking about sidechains kind of stuff where we're, you know, moving assets between blockchains. And then the interledger is kind of in that realm of atomic swaps like protocols where the idea is, you know, we're not trying to move assets between blockchains anymore. We're just trying to, you know, I'm using one block. and you're using another blockchain, we want to send some value back and forth.

Like, you know, I want to pay for, it's really only meant for payments. And so these two products, you know, but it's only meant for payments and it's much more limited in its capabilities, but it has much fewer restrictions, right? Like in Cosmos, you kind of have, we have this assumption that all these chains are going to implement IBC. and if not we need to like hack in IBC using peg zones. While interledger has way fewer requirements on it, and so I gave a talk a couple, and I think they're like both really important

and useful technologies, and I actually gave a talk at the Interledger Summit last month kind of specifically on how these two pieces of things like intermeshed together and why they actually need to coexist to make, I think Interledger's actually a really important part of the cosmos ecosystem. Yeah, I mean, in one way that I think one can also think about the topic is, you know, when Bitcoin came along in 2013 or, you know, back then 2011, 12, but people would talk a

lot about, okay, application you could build on Bitcoin and you had some of these earlier things like collard coins and master coin. And then, of course, you had, with Ethereum, you had this alternative vision in that they say, okay, Bitcoin's too limited, we can have an alternative, this world computer, and in a way there's very clearly a concept of interoperability in Ethereum, right, because it's all in the same machine and contracts and call each other. And, you know, this kind of notion of Internet of value has been around for a long time and kind of used in different contexts, right, whether people have talked about it in the context of Bitcoin or Ethereum or maybe Reparguise. And I think today,

it seems pretty clear that that's not what the world's going to look like, but there's going to be lots and lots of different chains for lots of different purposes, controlled by different people in different places, evolving in different ways. And so then interoperability

becomes something different, right? It becomes about how do all of those chains somehow interoperate and create this internet of blockchains, right? And so I think interoperability today, I think, is about figuring out how can different blockchains interact. And of course, within that, you also still have different visions,

something like polka dot, which seems to be more, to me, like a continuation of the Ethereum vision in that you say, okay, it's still kind of a world computer, at least at the lowest level, and sort of the security and the guarantees,

but then, you know, you can have sort of a sharded version and lots of different ones. And then the more, maybe more radically, decentralized approaches, both interleger and IBC, we kind of count under that, where there's not like an inherent hierarchy

and the concept of what this network topology is going to look like, but it's just about, okay, how can you just different chains communicate with each other? And I think another approach to interoperability, which is kind of the dark horse in the race, is that you see that there are these projects that are trying to build blockchains that can own private data.

So there's one project on Tendamid, Oasis, I think, there's Enigma, there's Ren. They're essentially using a bunch of different technologies, but you can have like this crypto network and you can put data on that crypto network and the data is confidential and you can compute using using the confidential data that you have put on the crypto network.

If that sort of thing is possible fundamentally and it can be made secure, then what kind of data would you want to put on such a crypto network? Well, you might want to put your private key on such a crypto network. So if I can have my Bitcoin private key on that crypto network and my atom private key on that crypto network, and some other user, Brian has... as their Bitcoin and Atom private key on that crypto network, and it also gives us maybe some way to interoperate. Because I could buy Brian's Bitcoin while giving up my atom

using a computation on that crypto network, because both of our keys are on that network. So that could be an alternative, but I think it's a dark horse. It may or may not be an important part of the interoperative. part of the interoperability space. So for Brian, you know, Arthur Brightman has this like quip. He says that like, you know, all interoperability projects are just a veiled attempt at domination.

Like even Cosmos said like, oh, you know, this is just like a veiled thing that we're saying, like interoperability when really all we're trying to do is like, you know, to make Cosmos hub the chain. You know, what do you think about that like claim from him? Well, you know, I'm sure different people have different, you know, priority. and you know obviously people in holding atoms have you know some economic interest in Cosmosup becoming significant but I just think the way that IBC that is approached and it doesn't you know it doesn't prioritize Cosmos Hop right there's no particular role in it so I I wouldn't

I would like somewhat disagree I mean there's probably some truth to it as well but I don't know what you think? Yeah, I mean, I kind of agree with you on the, you know, I think the Cosmos design is kind of meant to not do that. And, you know, we've been trying our best to make sure we support multiple hubs right from the get-go. Like, you know, there's already the Iris Hub and we like, you know, encourage more hubs to, like, come in and like try different things, different distributions, different whatnot.

Yeah. And then, you know, I mean, I also I think the entire fact that like, you know, you know, atoms are not making any play for like money or anything. And that right there is kind of like forcing a lot of the value to go to the edges of the Cosmos network, not necessarily on the hub itself. And what about interoperability then now between the different networks that, you know, presumably attempting dominance? So let's assume that, you know, in some years, you know, Cosmos has, you know, several billion dollar market cap.

You've got Pocod also with, you know, important. important dominance in the space and like Ethereum 2.0 and maybe some other projects. You know, at which point do we say, okay, now we need interoperability between those systems? Do we imagine now other blockchains sitting on top of those providing interoperability between them? Or can they be interoperable just between themselves with the protocols that they implement? And sort of using similar types of protocols. Yeah, I mean, basically just need to get them to implement IBC and then, you know, Pocodod will just be a hub in the cosmos network.

Okay. Like, same with Ethereum and whatnot. Like, you know, it's all just part of this Cosmos Interchain. And, yeah. Okay. I mean, like, we are working with some of the ETH 2.0 developers, like, you know, Prismatic Labs and stuff on, like, how we can integrate some of the features of IBC into, like, Ethereum 2.0 and whatnot.

And then, you know, with Pocod, like, you know, it's easy to, you know, we can add an IBC adapter chain, like, as one of the pair chains, can be an adopter, like an IBC adapter for backing to the hub. That brings me to the next point that I wanted to address here is the types of applications that different chains will attract. So if we're looking at, so the Ethereum Space has been, fundraising has been one of the major applications for that platform. We're seeing a lot of defy there.

One of the things I noticed here at this event at least is that there seems to be like a couple of projects that are in like the social good space. So you know we've got like region network there's this cello and we saw a talk from the open money initiative and everything that's going on there and I myself and my friend will be working on a UBI project called Heartbeat. So like do you think that Cosmos maybe is is a platform that will attract a lot of these types of projects or are there you know specific types of applications that you think will sort of nationally come to the Cosmos hub?

I mean, I think I don't know if the cosmos is like particularly, I don't think it has a, you know, particular feature that favor like social change applications, but I think the thing that is unique about cosmos is the sovereignty of chains, right? So I think if you look at something like Binance chain, we can't really imagine that finance would build a decks as a pair chain or on Ethereum 2.0, right, because they would want to full control. So I think just anything that cares about like governance and sovereignty seems like very well suited for building kind of in this cosmos paradigm. No, that might be. I mean, you know, I think for example with the region network guys, like I have one thing, one thing that makes a lot of sense to me there is also the, you know, thinking about governance and who controls

the network and the different stakeholders and stuff like that. And again, and one of the challenges is something like Ethereum or some of these other designs is that, okay, you can have a tap on Ethereum and it has its own governance, but then you always have the underlying governance of the platform, right? So you almost have like these layers of governance systems.

And of course, you can not easily have conflict. As you saw with the DAAR, right, where you had maybe the DAO holders that had one idea and then the Ethereum holders, some of them agreed, some of them didn't, but you clearly had different groups of stakeholders that now conflicts will emerge. And I think having this kind of sovereignty-first approach

just, I don't know, it just feels better to me. Yeah, I mean, and then from the application standpoint, you know, I think smart contracting platforms are great. Like, as long as they're used for exactly what they sound like, which is smart contracting, right? That's why I think ICOs and fundraisers took off on Ethereum, and they're the perfect use case, because there's something that are pretty short-term use

and need high levels of customizability, right? Like no ICO design was exactly the same. And so that short-term use and high customizability is what smart contracts are meant for. But then when you're trying to do much more high-level applications, like, you know, much more advanced applications, like, you know, I think like a Dex platform or prediction market platform,

I think that's when you start to want more application-specific state machines that you have much more control over, much more efficient than running on the EVM, for example. Oh, and also, you know, I was at the scaling Ethereum workshop last week in Toronto, and no, there was this joke going on, like, you know, basically, trying with the plasma group people, and basically the idea, you know, they were proposing, like, you know what, let's just throw out ETH 2.0, and let's just take all of the data

availability work that we've been putting into ETH2.0 and apply it to plasma. and we're going to call it sharded plasma. And basically, you know, the thing with plasma is that, like, you know, it's somewhat limited in its capabilities. The plasma group has done this, like, generalized plasma concept that they've, you know, worked on quite a bit. And so, you know, they've definitely expanded the scope of plasma well beyond what it was, like a year ago.

Like, you know, it's not just the plasma plasma cash thing with UTXOs. You could do much more things. But it's still limited. Basically, you know, it's limited to things that you know that every piece of state has direct ownership at any given time. But, you know, I think 90% of defy use cases fall under this scenario. And so, like, you know, I was attacked with Ben from Plasma Group. And, you know, we were just like, yeah, you know, let's just like focus on that for E2.0. And then someone else asked like, oh, what about like the few applications that don't need that?

They're like, oh, just throw them in Cosmos. So, you know, I think that's actually a reasonable, like, design pattern. Like things that need that can work in this plasma. So essentially, like, you know, my entire pitch has been that, like, you know, all of these different hubs need to find specializations, right? And I think Ethereum act as a perfect plasma-based hub. Like, you know, its focus should be on, like, being the root chain for different plasma constructions.

Do we want to talk about composability a little bit and the differences between... Well, I think it's like composability on... There's composability on different levels, right? So composability within a chain like Ethereum and Cosmos and sort of differences there. But then also composability, I guess, in the future, between different chains themselves. So, like, between Cosmos and Ethereum and, like, how value and information could transit between those two systems. So maybe starting off with the differences, you addressed this a bit at the beginning, but between Ethereum and Cosmos and the truth.

tradeoffs that Cosmos has made on composability. Yeah, I mean, I think the biggest thing is just the fact that you have to deal with, like, I mean, so even on Ethereum, you know, how they solve the composability issue was they basically created an ERC repo and people like, you know, propose ERCs there. So, for example, you know, the most popular example of a composability design for Ethereum is the ERC20 standard, right? By creating the standard, we basically say, okay, now because all the tokens follow this standard, you know, now I can actually integrate it with both Uniswap and ZeroX, and you get that composability in the ecosystem.

And so we're kind of starting to do that now with Cosmos in the ICS repo. So it stands for interchained standards. And so kind of, you know, we're putting into there a lot of these different kind of standards for how we expect to deal with different things. So, you know, the first, obvious, the first one is going to be like token transfers between chains. But then, you know, we'll start to add stuff like NFTs and Oracle data and like, you know, identity information. And, you know, it'll just get more and more different types of standards being added into there. And then part of what makes the compostability in Ethereum a little bit easier is that they all use a common VM, right?

It's all, you know, everything is using solidity. And so representing these interfaces and, like, translating them is only, you know, you're translated from the spec in the ERC repo to solidity. While in Cosmos, we have to translate it from, you know, you know, the spec in the ICS repo. We have to translate it to, you know, an SDK module. We have to translate it to an agoric system. We have to translate it to, like, you know, an Etherment system. We have to translate it to, like, you know, whatever new VMs come into the ecosystem.

And so that process is definitely going to be more complex. And maybe, you know, one of the ways that, for example, because in Ethereum there's only that one VM, what happens is people do the interface in the ERC repo. So the ERC 20 standard, all it defines is the names of the functions. And then the real implementation is basically always like, oh, you look at what's the standard in the Open Zeppelin repo, right? And that's like, okay, that's what the definition is.

of ERC20 is now. But we don't really have that. And so now basically our specs have to be more explicit on what the functionality of these different ICSs are. Anything that? Yeah, I mean, of course, also another thing that's just added complexity is that, you know, let's say if you look at Cosmos and you want to build some application

that spans multiple blockins, now you have to worry about, you know, the different validator sets and what if one of them fails, or if you have multiple hops. And so the security just becomes much more complicated, and the kind of game theoretic attacks and all of that stuff. So obviously, Ethereum is nice in that way, and that you kind of don't have to worry about any of this.

But yeah, that's just a trade-off. And I guess let's see how it all turns out. Yeah, but like maybe in Ethereum 2.0, some of the game theoretic vulnerabilities will resurface in a different way. But yeah, I guess, I guess like cosmos is, composability is going to be high, is going to be more challenging in cosmos because of the reason the Suni mentioned. So if you have something like KYC data or you have NFT data,

now you have a sending chain that's sending some NFT and a receiving chain, And both of these chains, ultimately they are getting like this stream of bytes, and now they have to interpret these bytes to mean NFT. And they have to agree on the interpretation of how these bytes translate into an NFT, how a stream of bytes translates into a token, how a stream of bytes maybe translates into a withdrawal message for a validator. So these agreements will need to happen, and different chains will need to like subscribe to these standard ways of translating bytes

into these higher level financial objects. I think that's going to be one of the big tasks that emerges out of IBC. Another challenge is the synchronicity as well, because in the Ethereum, the nice thing is that, since everything is perfectly synchronous, an event that happens in one contract can immediately call something another contract

and can force it to do something. the classic example, you know, essentially, you know, I mean, something I've been chatting, I've tried with the agoric people about, is that, like, look, in the system right now, you can take a CDP maybe and move it to another chain, and if you want to liquidate it, that's probably possible. But what if we get into the, but in Maker, what you also need is, you know, there needs to be mass liquidation events as well, because if the price of the collateral goes down, it needs to send out a message to all of the CDPs that are everywhere and say, oh, you need to liquidate right now,

or at least you've got to re-up the CDP or it's going to be liquidated. And so, like, you know, it's just a much more complex design pattern when you have to start to do these kind of things across these many chains, across these asynchronous environments. Yeah, but I think one really interesting power

that I find really interesting about the Cosmos SDK is that applications in the course, Cosmos SDK are autonomous in a way that Ethereum smart contracts are not. So in an Ethereum smart contract, a smart contract has some state, it is storing a bunch of things. And any time you want to change it, an external user needs to trigger this transaction, and the transaction will hit, and then there'll be a change. But the interesting thing about Cosmos change is all of these applications, can write application logic which is,

oh, every hundredth block, like make this particular change to something. So I'll give you an example. So imagine that there's a zone, right? And that zone owns some address on the cosmos hub. So it's like this whole zone, this whole network that's owning like this address on the cosmos and this zone owns atoms on the cosmos hub.

So like the region zone owns, let's say, 100,000 atoms on the cosmos hub and delegates to Sertes 1. Now, what is possible in the Cosmos SDK is for the region zone to have logic that every 1,000 blocks of the region zone, it will try to withdraw its rewards on the Cosmos hub automatically. and basically every thousand blocks the region network will generate like this IBC packet will flow to the hub and that IBC packet contains the instruction for withdrawing the rewards made by delegating to Sirtas 1 and it like faithfully executes this every 1000 blocks without any external user of the region network time to trigger this withdrawal right so this this like this like this like this This region application is autonomous, right?

It can do that autonomously. This kind of thing is really hard to do in Netherium. But if one chain can do something like periodically autonomously, all of these chains can do that. So you can have some kind of logic that is autonomous across multiple chains. Like this chain does this, and then five blocks later the other chain does something, and then 50 blocks later this third chain does something,

and these three chains, keep dancing continuously and then some kind of higher level functionality is achieved in this particular way. So I think this is kind of different kind of composition that we might see in the cosmos-based internet of blockchains. And yesterday I was talking to somebody from PolkaDot and it's possible that PolkaDot will also have something something similar on their side. And I wonder what this is going to enable. So the way I tend to think of it is Ethereum has smart contracts,

but at Cosmos SDK, we have decentralized bots. We have these decentralized bots that can run periodically and do something more than smart contracts. It's just not like... Cosmos SDK is not like translation of just smart contracts. It's smart contracts. smart contracts, smart contract like things, but also decentralized bots. I find that really interesting.

I think we're going to have to spend a bit more time on this, how do we preserve neutrality as podcaster's topic at the end? Yeah. Oh, I just want to say, like, you know, while you were just talking about that, and like that and the thing I mentioned about the, like, Ethereum sharded plasma idea, something in my head just clicked for me. So this idea that, you know, the claim was that the sharded plasma, design allows you, basically, you know, anything that, you know, all state is owned by someone,

you know, that can all go onto plasma. And it's for everything else that, you know, let's throw it on Cosmos. You know, one of the common bitcoins arguments against Ethereum is that smart contracts are useless because almost every useful smart contract or like DAP requires some level of Oracle data, right? And, you know, and so you're, so let's say, you know, your dye on Ethereum is not secured by Ethereum because it's actually secured by the MKR holders, right? Because the security, even though Ethereum security might be high, if the MKR security is lower, then, you know, that's what it's actually secured by. Or let's say Auger, for example, right? It's not actually secured by Ethereum. It's security is the minimum, which is the rep holders, right?

And so I think Cosmos just says, okay, let's just make that explicit and say, okay, if the security is lower bounded by the Oracle providers, let's us make those Oracle providers also be the validators of a sovereign chain. And I think that probably fits. I haven't thought of this enough because I just thought of it just now, but I think everything that can't go on plasma essentially might need some sort of Oracle service to make it work, because they're the ones who are collectively holding the shared state. And so that might need to go onto a Cosmos chain, because then you just have those validators act as the oracles for the system. And of course, like, this is not a property of cosmos, SDK,

or, like, Polkarat substrate. But it's just like a weird feature I feel of proof of stake. That in proof of work, when you have a minor, there is no public-ki-associated with a minor, right? So the entire Bitcoin protocol as a whole can't own Ether. Because who would be the signatory for the Ether owned by the Bitcoin Protocol? But it just feels very interesting and fascinating that in proof of stake, that's not the case. So when you have these 100 hub validators and you identify them with these people,

them with these public keys, these 100 hub validators could collectively own, you know, tokens like Terra SDR on the Terra network. So the atom, like the Cosmos Hub protocol can own Terra. Cosmos Hub protocol will be able to own like Kawa USD. Cosmos Hub protocol will be able to own some Derrishap protocol will be able to own some Derr innovative assets and like Cosmos Hub governance will be able to exercise control over these assets. And I feel like that's such a magical new capability added to crypto protocols just because these are proof of stake. Do you think we'll start seeing hostile takeovers of chains between chains?

Or maybe a new job type which is like mergers and acquisitions banker for chains? Or Cosmos Hub can short itself. Ah, yes. I mean, so we did this epicenter episode a couple months ago now with Mark and Coppelman and Matanfield about the DX Dow. And, you know, in that thing, he made this interesting pitch or, you know, statement, which is I think also the title of our epicenter episode, which was, you know, this will be the biggest organization. Not biggest. Not biggest. Most important organization in the world. It's the biggest.

Okay. this will be the biggest organization in the world in 10 years. I think there was like 1% chance or something. Let's just put the context here for the statement. But yeah, you know, I think, and basically, you know, his claim was that this DX Dow is starting off by running this, you know, providing governance for the Dutch X exchange that they built. But then over time, you know, it's going to become the operator, you know, hopefully more and more defy systems as they get built.

they'll say to the DX Dow, oh, we want you to govern this thing as well. I think fundamentally all proof of stake validator sets are just DAOs, right? But the difference between the Cosmos Hub validated set and the DX Dow is I think the Cosmos Hub validated set is a way more competent Dow. Not that the DX Dow isn't competent, but they haven't really done anything yet. Meanwhile, the Cosmos Hub validated set has successfully launched a billion dollar network. They're able to run high security infrastructure. And so I think that, you know, go listen to that entire epicenter episode

and every spot that they say DX Dow, just replace it with Cosmos Hub. Yeah. And then like Zaki's idea takes this one level ahead, right? Like these validators, they naturally have this taking pool address. And so these validators and these delegators, you're also making them into DAOs naturally, right?

Because it's like sub-DAOs. Sub-DAO's, right? There's the main cosmos hub DAO. Sika-Dao is essentially a sub-DAO of the cosmos hub-DOW. And we are like child-dows, right? Like this, there's implicitly there's a Sertes DAO, implicitly there's a DOCIA DAO, implicitly there's a KORUSDAO. It just exists, it will be like put into code and it will have this taking pool address, and it'll be able to own assets on other chains. And then you'll find applications and these dows will like

branch off. These are the seedlings that are already there. They are going to branch off and their trees are going to erupt from these these collections that have already begun. And it's going to be like it's such a beautiful design, right? Like it's like Dow's all the way down, no? Down, down. I wanted to move on to another topic which is something that you mentioned last night we were preparing for this I really sort of started latching onto the idea of Cosmos at at DefCon in Cancun when you gave the talk where you to describe the vision for Cosmos and where zones would be limited in functionality

and that like all the benefits that has in terms of security etc but you mentioned yesterday that it's possible that zones start sort of generalizing and progressively move towards like V-M-I-ization I would say you know how do you how do you see this sort of this idea that like zones should be either specific or tend towards generalization and do you think that will happen I'm not really sure like you know one of the big questions that we're constantly having is like how much stuff should go on the Cosmos Hub, right? Like, we have one of the interns at Tendermintraint right now,

he's working on implementing a uniswap module in the Cosmos SDK. And so the question is, like, you know, should we put a Uniswop module on the Cosmos SDK? Like, you know, it's kind of like quite a departure from, like, you know, if the Cosmos Hub is supposed to be very simplistic in, like, the state machine, you know, we should not put it there, right? But at the same time, there's so many assets, that's, you know, I consider the Crossus Hub as like this crossroad for the, like, all these

trading routes going between it. And it's nice to have a little, you know, side of the road marketplace there where, like, you know, it's not going to be a full-fledged, like order book decks or something. But, you know, Uniswap is a very nice, lightweight system. And so if people are quickly going through this Cosas Hub, you know, might as well stop at the, it's like Uniswap is kind of like the airport, like currency booth where, you know, you're probably not getting the best prices. But, you know, it's good for, like, those quick trades that you need to.

to do. And so, you know, do we put that in the hub or not? And it's like kind of, I actually, you know, I don't know the answer to this. Like what goes in the hub, what doesn't? Or, you know, just in general, any zone, right? Like, how do they decide what, what, you know, how much to expand and what the, you know, tradeoff between like generalization. And maybe at some point we just start generalizing so much, it just turns into, you know, everyone's just running an EVM again, or hopefully not the EVM because, but, you know, hopefully a better VM. and everyone just started running that, I don't know. So in biology there is this idea of convergent evolution.

So if you look at the tree of life, all life can be put into a tree. And there are like sub-branches of the tree of life. So like, you know, like vertebrates, all of us, lizards, we are all vertebrates. We have one branch of tree of life. Cephalopods, like squid, just. Jellyfish, they are another branch of life. Arthropoda, insects, they are a third branch of life. There are many branches of life.

The interesting thing is, all of these branches of life have evolved the eye independently of each other. Like, eyes have evolved in the vertebrate branch. We have eyes. Eyes have evolved in the insect, like Arthropoda branch, like they have compound eyes with a different design, and they have evolved independently. evolved independently in the cephalopods.

Eyes have evolved eight times, which means there is something that is special about the eye, the notion, the concept of an eye itself, that life ends up evolving the eye. Same with wings, like wings have evolved like four or five times. Reptiles have evolved wings, mammals have evolved wings, like dinosaurs evolved wings and became birds. Bugs. Even bugs.

Even bugs. Insects have evolved wings. So the question here is somewhat like, is Vitalik's idea of this general purpose VM that's like doing the smart contract computation? Is it like the eye? No matter what point you start with, you're going to end up at it. I actually think that's true. Because if I think of the Sikka Dao or the Khoris Tao, let's say.

Now, Sikka Dao is going to have, I don't know, 20,000 people that are the members of the Dao. Now, at some level, you don't want the evolution of the Dao to be constrained by the Sika team. You want the ability for, if some member of this Tao has an intelligent idea, you want to give this member the ability to permissionlessly build their thing and be able to central to this, be able to... signal to the central Sikka team that, hey, this is an interesting thing to do with the Sikka DAO. And like, how do you give that capability? I think you give that capability by having something like a VM that somehow attached to your main DAO logic.

So I feel like these VMs might be this point of convergent evolution. Like, no matter where you start with, you will end up feeling the need for it. Maybe it's like, you know, I mean, kind of, here's an example, right? We want all these staking derivatives on the Cosmos Hub, but it's like, you know, you know, we can trade those stigerners, but wouldn't it be nice if we can actually put like a VM on there so, you know, maybe you can create like tronches of the, like, for like different staked atoms and, you know, you can do all sorts of crazy stuff. And for that, you kind of maybe need a VN.

So maybe, you know, if it does turn into a thing where everything needs a VM at some point, What may be the end result of the Cosmosis SDK is it's just a way, you know, I'll use the EVM as an example, you know, it's just a way for you to launch. You know, everything turned into Etherment, but the purpose of the Cosmosis SDK is to make custom pre-compiles for your personal Etherment, right? Everything has an EVM and people are using the EVM, but like, you know, the problem is the EVM is not great for building these large things. So, you know, maybe I'll have my staking logic as a Cosmosis SDK module that you'll call from the EVM as a pre-compile. and all you're like, you know, whatever your project is, maybe that core logic will be pre-compiles as SDK modules. And I don't know.

That seems plausible. I mean, kind of on that, the unit with the Uniswop example, right? So, yeah, you could put the Uniswold thing on the Cosmos Hub, which makes sense in some way. But also, if you think now all of these different chains connected to the Cosmos Hub and deriding IBC packets through, I mean, with the scalability challenges of blockchain and the benefit of having like kind of

higher performance purpose-specific blockchains, it kind of makes sense to have it, you know, just for routing. But at the same time, you don't, let's say the cosmos there's a few things that are essential. Maybe it's like bridging to Ethereum, bridging to Bitcoin, having the uniswob thing, maybe a bunch of other stuff. Like you don't want to have, you know,

five different staking, with their own communities and their own, like that just gets too confusing, right? If I am now to route through a transaction from the Bitcoin to the cosmos hub and then do the univ swap and go somewhere else, and I have to worry about, you know, four different staking tokens and their own communities, right?

So like that doesn't feel natural. So I think it feels natural to have, you know, split that up over multiple chains, but probably have the same staking. have the same staking token for that. The shared security design. Yeah, something, I mean, you know. Interchange collateralization.

Yeah, I think the shared security thing kind of goes into a bunch of different directions. I think there's one which would be that. Like, you're trying to basically use a bunch of functionality. And it just be done by one stakeholder group. And you don't want to have to reason about like multiple staking tokens and economic incentives and all of that, right?

Well, the reason, what I'm more worried about is the latencies of IBC. So let's say I'm going from zone A to zone B, I want zone B token. I don't want to go to the hub, then to the uniswap zone, then back to the hub, and then to zone B. It's the latency of IBC that I'm worried about here. Sure, yeah, that will be a trade-off, right? Like the latency of IBC versus the scalability of these chains. Yeah.

I mean, that's my biggest thing where I think Interledger comes into play, where I think Interledger helps solve a lot of latency issues with IBC. Yeah, I tend to think that generalization would tend towards some form of centralization, or like some network effects around networks. And we sort of saw this with Ethereum, right? Where like Ethereum captured the majority of the smart contract community and smart contract development.

I think if there are 10, 20, 30 zones that end up having like a general purpose, smart contract language or VM, a lot of those will probably end up not mattering very much, and you'll have one dominant one. Of course, unless this starts becoming part of the Cosmos Hub at that point, then all these other zones stop mattering. But it kind of echoes the point that Jay made yesterday

in the Q&A, which is like you want to have systems that enable people to easily leave and exit towards something else, if they feel that it no longer supports sort of their threshold for how centralized something is. In Sika Dow, I added the rage quit option from the Mollok Dow. So, you know, if you want, you get really mad at the Sika Dow, you can burn your Sika Dow tokens and receive the proportional share of the assets of the Dow with some penalty, like a rage quit penalty.

So, you know, I think we should be actively making sure we build in exit, like, you know, be thinking about exit options when we build these systems. There's so many other things that we had planned to cover here. So there's one more thing. before we sort of turn to the audience. And again, if you have questions at any point, you can just raise your hand. And gentlemen here with the mic, we'll give you the mic.

So with regards to Zones starting to now build and we'll soon be launching on the hub, as validators, and I'm asking this specific to you guys, because you're all validators, how do you see that sort of competing landscape playing out? Because zones will start competing for your attention and your validating power. I mean, we saw this a little bit at the dinner

that you guys had. There were people there and like, you know, I'm here trying to meet validators and pitch them on my idea. How would you evaluate those projects and make decisions about which zones you want to support? Is this something you've thought about? Yeah, I mean, I think we had the validator panel yesterday,

and I think Hendrik made the point, which I think is perfectly correct, that it's almost like an investment decision, whether or not one directly invests money, one certainly invests a lot of time and resources. And I think with all of these projects, you know, it's going to take a long time for them to succeed, you know, and to build them out and functionality to be there

and people start using it and transaction fees to come in. And maybe there's some token, but, you know, right now there's maybe no liquidity or value, some kind. clear, right? So you always have to take some kind of like bet on the future of that project. And so, yeah, then of course you have to look at exactly the same thing that probably investor would look at, okay, does this vision make sense? Is the team good? Are they serious about it? Will they work on it for a long time? Do they have the resources to build it? So I think

there's all of those things. There's obviously also the question of just how hard is it to you run that network and then certainly if people build on calls on SCK that makes it easier so you know fix yeah so I mean there's a there's a technical side and then there's the business side right if you onboard a new network I mean the business side is very clear right you'll have to go and market to this community and it's gonna cost you effort and And maybe that's the larger cost. On the technical side, last year, when building the validator,

I almost had a crisis of confidence. I was like the validator is a damn commodity. All of these networks, the validators are just going to be the same. And we're going to just keep on replicating this thing. And because it's all the same, this is going to be a commodity. I had a crisis of faiths like that. And the interesting thing is this year, every network is subtly different technically.

So Cosmos have, okay, you know how the validators on Cosmosa work. On Terra, we are validators on Terra. On Terra we are building a price oracle. We have to invest effort into building this price oracle and securing this price oracle. Because for the stable coin, they need prices and we have supplying the prices, the Terra network. the Terra network. I hear like on the Kawa network, we are going to need to do parameter setting,

and this parameter setting is going to be complex. So we only need to develop an algorithm to help the network set these parameters. That's custom effort. Another network we're working with Solana. Solana is an oddball altogether. RHS are too slow for Solana. They need GPUs to do signature verification.

signature verification. There's no point building our high availability solution in Solana because that network wants to run so fast that a higher value solution will not work. There's a ton of custom effort for Solana. So while I initially felt all of these the technical costs for onboarding new networks were going to be very low, in practice it's not behaving like that at least this year. Now maybe the future is that we'll build a bunch of 25 tools, price oracle, this, this, that, that, that, that. And then the next network you throw at us, will be able to use that tool, and then the onboarding cost will fall.

Or maybe it never falls. Maybe every new network is its own beast, and it will need this custom thing, and there's always going to be technical onboarding cost. But there's definitely a business onboarding cost. There might be always a high technical onboarding cost. And if both exist together, then you have to be very picky with the networks you onboard. Yeah.

So now we've got 10 minutes left. Oh, no. Yeah. I want to ask a question from the audience about onboarding cost. So I guess I don't understand for, in the technical, I kind of get that. But in terms of the business onboarding cost, let's say, some random project comes up to you and let's say they're running everything pretty standard Cosmosis SDK so the technical onboarding Cosmovement is not that much.

For the business one, let's say you don't really care to advertise or get engaged with their community. You have a reputation from your Cosmos hub validation that you validate correctly, run the code correctly. You look at their code, maybe you audit it or maybe you just run it in a VM. I mean, AWS doesn't audit all the code that runs on their system. So I'm wondering, like, if you don't really care about, like, kind of getting deeply involved in a certain community, like, what, I mean, you know, what are the onboarding costs, really, in terms of, like, the business onboarding costs that you discussed? I mean, I guess the point is that you can't, I think you do, I mean, I think that what Brian's

point was that you should, you know, have some care of, like, getting involved with the community, or, you know, you at least have to have some level of faith in the project, because what you are investing is your time and you know you know trade your money for your time for more time always right and so you know the investment of time that we're putting and what my hear said like you know every system usually designing it requires like a time investment because they're all slightly different and so you know I think the community of a project is something that you should you know be deeply involved with or at least familiar with when you're making a decision about because that's probably one of the biggest factors of the success of the project and you shouldn't be

validating on it if you don't at least have some belief in the success of the project. Yeah, and also to your question, I mean, at least in the kind of cosmos-staking design, and you know, maybe there will be different, I mean, I'm sure there would be different design. Like Polka-Dol, for example, has kind of a different designer. But in the cosmos design, you have this connection between staking and governance, right? So if you, as a valid, you have this, like, significantly responsibility to be engaged in the governance and follow it and things like that. So if you're going to validate on some chain that, like, okay, maybe it's easy to sort of have it run and sign a thing, but, like, you don't really know or care about the community or what it's worked.

I mean, I don't think it's going to be good for these networks, right? Like, I think they will struggle because they'll have, like, basically stakeholders who don't care or not engaged. And then if something goes wrong, right, it's still your responsibility, right? Like, you, maybe that works fine as long as everything works fine. but at some point it's not going to work fine anymore, and then you have to deal with it, right? Because you can't just... I think that would be your responsibility.

So I think there is that cost. Yes, so you'd say validators are more responsible for the blockchain, is much more responsible than somebody like AWS is for applications running on their system. Yeah, certainly, right? I mean, AWS is not going to make any decision about the future of your application, right? But validators...

Yeah, again, at least in the cosmos, do. I mean, if you had some sort of different staking design where maybe have, like in PolkaDot, right, this kind of governance council and they make the decisions and that's a different group of stakeholders and you literally just are responsible for like running the code and, you know, then maybe it's different, right? Like maybe it doesn't have to be like that for all of the chains. Also, I mean, AWS doesn't hold equity in the companies that use AWS while Cosmos validators have some sort of stake in the networks that they're validating. Well, I mean, if you don't, it's very hard to get delegation on those chains.

And also, if you want to get delegation, that's another reason you have to be active in those communities. I'd like to open it up now to like sort of general questions, about anything we've discussed here, if you have any questions about the podcast or do you want to ask us specifically? Go ahead. It's been pretty obvious these days that a lot of projects are on the lookout for validators. So I wanted to hear your opinion about the exact time when they picture the vesting schedules. How do you feel about vesting schedules? Like, they're really struggling to keep validators involved for long periods.

So how do you see that for newly spun up zones or hubs? You mean if they have some sort of vesting for like investors or for like, tokens that validators earn through operating the network? Yeah, yeah, yeah. I haven't actually seen that, I think. There's obviously the thing about, like, yeah, you're investing, or, you know,

somebody is doing some token sale, and now, of course, there are various projects trying to do sort of validator-specific token sales, which I think makes, you know, it makes sense. Of course, it can be a challenge, right? Because many validators are not funds, or most validators are not funds.

So they don't necessarily have the resources to buy tokens. But yeah, then obviously, I think the idea of giving, let's say, some discounted price, but there's some lock-up and things like that. I think that makes perfect sense. And in generally, having investing on token sales, I'm all in favor of it.

Do you think validators are going to inevitably have to become funds? For sure, we have a partnership with the crypto, and that's kind of how we make that work. Yeah. Well, on some level, yeah, I do think they naturally evolve into

fund-like structures. Because even if, you know, like, let's say you're running a validator in Cosmos, then you have some atoms and revenues. Now, probably you're going to have to, like, liquidate you know, some percentage, you know, maybe a lot to cover your cost. But, you know, if you have any kind of profit, then, you know, these will be in tokens. And then maybe you have a bunch of other tokens and other chains. So you started having to manage these different positions, right? So that

becomes a factor of figuring out, like, when you liquidate what. And then, you know, quite naturally, you would build up some sort of balance sheet of tokens. And then, of course, at some point, maybe not now, but maybe in two or three years, if this succeeds, and if these companies succeeds, they probably would be in a position to invest in and participate in these kind of funding rounds.

And so I do think it kind of naturally goes in that direction. Cool. Yeah, cool. The idea, you talked this morning about, like, you know, the concept of the validator being, like, somehow, like, either a Dow or a fund, so you're kind of like switching different ideas. And I'm thinking about, like, what do you guys think about, like, second-level governance, kind of like the proposals, you know, with this concept of having the address for the validator that Zaki, that really kind of like, change mixed up a lot of things so what about like some like sort of like sub-level of governance is something useful not useful good not good what you guys think yeah I didn't the delegators being able to vote oh did yeah like a way that validators can

like do proposals and you know with with bonded proposal not just like two things but just like I put my my skin in the game of what I'm saying, what I'm proposing, and I'm against slashed. The same concept. You think this can be also apply to the second level, like, sub? Right. So that's one thing on the costals hub, though, really quick. Like, you know, it's not just validators that can make proposals and vote and deposit.

All delegators and all staked atom holders can, you know, participate in governance. And, you know, any delegator currently validators inherit the vote of their delegators. but delegators can always override their validators. But on the matters of, like, we're, like, the concept of having, like, the single address for the old, the old delegators kind of, like, creates, like, not tribalism, because that's a bad word, but kind of, like, creates, like, a community, which is the opposite.

Yeah. Now, do you think that there will be space also to give a voice, actual voice to that community? That's my thought. Yeah. I mean, I think for chorus one, when we created our, interesting thing is like last year, back in April, we created a Slack which is chorus one community

because we thought these delegators, they are a community. Not many people came, right? And then created a telegram channel. What do you name it? We named it chorus one community. And then now we have like 250 people on that telegram channel and they are posting. Now we are going to get an address.

I think it's only logical that there is some way for these delegates to signal to us what they want out of the validator. I don't know what they'll signal about maybe in the beginning. I think like

the use case doesn't exist right now. Like what do the delegators exactly signal us about? But I think something will emerge where it will make a lot of sense to further deepen this community. Yeah, I mean, I think that if you look at the way that proposals get submitted now, like a lot of, there's this, and this was mentioned yesterday,

like discussions happen in a lot of different places, like on forums, on telegram, etc. And then like the final decision and the final signaling ends up being the proposal. Like there could be, I think, different layers of granularity there where you can have some form of automated or like organized, orchestrated signaling. where like if you're, you know, if you're going to post like a draft or like a pre-draft or a proposal, you can already kind of post it and start getting people to,

in a more tangible way and like with some form of stake, like signal their... Yeah. So, you know, of all of the podcasts that we've done, I think the one that always remains in my mind the most is the one we did with CZ about Binance. And the thing that stands out to me there

is really that you have this enormous blurring between the customer and the company, right? It's sort of kind of all the same a little bit. And I think that's just enormously powerful. And so even though maybe it's not like a sort of dull in the sense that we think about it, traditionally in the blockchain space, right? That it's like all on chain and smart contracts and stuff.

You can think of Binance a little bit like a doll. And I think why did it grow in this meteoric way and become so hyper-successful so quickly? It's because of that, in my view at least. That's a huge factor to it. I think all successful organizations in the future will look like that, or the most successful ones will. And so I think that absolutely ties into that.

So totally, I think all of the customers, delegates are like community. and I think the more that one can sort of give them deeper stake in involvement, the better. And we've spent a lot of time thinking about how to do that. It's like the biggest obstacle is always legal issues. So that's the sort of challenge for exactly how to make it happen. But I think we very much want to go as much as we can in this direction. and I think that's the inevitable future of organizations in general. Also, so this is kind of one of the things I'm trying to do with the Sika Dow

is that I'm not committing that like, oh, I will vote exactly the way that the Dow says, but any decisions I will kind of use the Dow as an advisory thing at the very least where it says that like, okay, here's a way for you to signal what you think, and obviously take that into heavy consideration. Final question, perhaps? That was the last one. Okay. Well, thank you for taking part in our very first life podcast.

And so this will go out on our feed next week. So if you're not yet a subscriber to the Epicenter Podcast, please go to Epicenter.tv slash subscribe. You can also find us on iTunes or anywhere you get your podcasts. Thank you. Thanks, Josh. Ladies and gentlemen, Epicenter, Epicenter. Check out the podcast.

Talk about the podcast, listen to the podcast. But go eat some food. We got lunch outside. Oh, one other thing. I do have a little side podcast I also run called Conspiratus. So check that out as well. Conspiratus. I'd like to welcome our first conversation between Jay Kwan, CEO of Olmbit

and president of the Interchain Foundation and Sebastian Couture from Epicenter. Thank you for inviting me to this event. I mean, I feel really kind of privileged to be here on the first session with you, Jay. Thanks for helping us. And yeah, likewise, thank you for, thank you everyone for coming here. I know it was pretty crazy weather last night. Yeah. So our time is limited.

We've got 25 minutes. So we're going to try to cover as much as possible. I will be, I don't know if we'll have time for audience questions, but if you do have questions, if you go to my Twitter feed, you'll see a pinned tweet up there and just reply to that tweet, and I'll get the questions here, so that way we can sort of move along as fast as possible. So, you know, starting off with the cosmos launch.

We launched a couple months ago. Things have gone relatively smoothly. You know, validators are up and running. There's been no major bugs except for, like, one that was found and fixed pretty rapidly. Governance has been very interesting to watch as well. what has surprised you the most since the launch what have you found the most interesting to see

and what has sort of, you know, went against your intuitions with regard to the launch? Okay, good question. Is that what I sound like, really? Weird. So, yeah, launch has gone really well. I think there were many cases,

many instances where things could have gone, not as well as it could have. So like before launch, there was a bug that may have caused a chain halt. So far we haven't seen a chain hall. So I think a lot of it was, well, we're lucky to not have had major issues so far. I think the biggest thing would have been,

say, if something were bad into crypto layer, then, you know, you can't recover from that easily. But that hasn't happened. So thank God. I think the latest issue that we discovered with the unbonding issue was it was kind of a good issue to have had because it was just on the threshold of like bug severity where it's almost really bad but it's not so like we even had a debate internally about whether it was how much of a very bad. of an emergency was, you know? Would people start massively unbonding as soon as they figured out that they could? Or, but what we found was that it wasn't even really exploited much, right?

So it was good for us to have had that experience so that the next time, when there is something maybe more severe, we know how to respond better. So it helped us flex our, you know, response issue, muscles. but we should still have more conversations around, like, what happens when you find, like, a bug that is so severe, you can't, you don't even want to share it with the validators, right? So that was the conversation we had internally. I think it's a conversation we should have now

before the next issue happens. Because on the one hand, you might think of either Tendermint, Inc., the for-profit, or the Interchange Foundation as being the one that dictates and you know that everyone should be able to trust but the the intent behind the chain and all these entities is to do the opposite you know to make sure that everything is decentralized that we aren't owners of the network so how do we get there in a responsible way and I'm sure we'll learn a lot of lessons along the way but yeah otherwise things it looks like things are going well see

that kind of brings me to my next question which is moving forward you know what do you see as the role for AIB all in bits tendermate ink with regards to the foundation and you could just describe sort of what you see there as the role of this to your organization is going forward yeah great question I think there are there are three entities here because there's there's the tendermint, Inc. It's actually called All in Bits Inc. It's the Delaware Sea Corp. There's the Interchange Foundation, which is based in Switzerland. It conducted the fundraiser. It also owns and manages like the trademarks and some of the IP, but it has the most funds right now to be used for developing this ecosystem and its network. It has a mandate. So like unlike a for-profit like Tendermit Inc. or All in Bits Inc. The Swiss Foundation needs to operate under its state of mission,

which is to develop the Cosmos Network and decentralized protocols. But still, like, the intent behind even the foundation is, like I was saying earlier, not to dictate the network, but rather just to be a participant of it. It has the funds, and it needs to use the funds to enable the network, but the intent was for it to be kind of this beneficial participant, just like any other participant. So who's the third entity? The third being the stakeholders themselves, right? So the blockchain, through its governance mechanism and implied and explicit social contracts,

it should be able to govern itself and make decisions on its own. It should be aware that it is autonomous and it has the ability to do so. I mean, we've been going through several governance contracts already, so I think we all know what that's like. And it's the nature of the experiment to create a sovereignty, to create a network with participants that's not based on a legal entity, but it's based on communication and transparency and various crypto-economic mechanisms.

Yeah, the whole experiment and the point is for it to govern itself. So don't let the ICF or AIB or myself or anyone dictate what the hub should do. It's really, it's the token holders and it's the mechanisms, but it's all of us that make the chain what it is. So will AIB now shift its focus to that the hub is launched? There's still a lot of engineering, like a lot of the engineering machinery machinery, no, I mean like the engineers and the people and the talent is still, it's an ICF as well, but it's also an AIB, the company. AIB is trying to become a software company. and we have largely two product lines that we're developing now on top of everything else we're doing.

So there's the infrastructure. We're developing IBC. We're continuing to develop tendermint. We've been developing DESDK and we'll continue to do that. But all of that may evolve in the future. So that's the infrastructure layer. But on top, we also want to participate in developing applications that use to use to, the network.

You can think of it as like infrastructure versus applications. Maybe you can think of it as a pendulum where, you know, for a while we've been developing infrastructure. But really, in order for this infrastructure to prove itself, there needs to be applications. And there are applications that are being built. But we think that it's such a large, like, opportunity space that we should be building apps as well.

So what kind of applications are you most looking forward to? What's the... one of the projects or areas that you would really like to see develop because a blockchain is nothing without the applications that are built on. Yeah, yeah. We're exploring that still now, so we're not really sure 100%. But the way we're thinking about it largely, there's two prongs to this.

One is we want something that can generate revenue in the short and long term. So we want to develop a line of business. It's probably going to be to finance. space. So like, you know, like one obvious use case might be a Dax. So we're exploring that now, but we're also exploring other opportunities. And then

on the other hand, you have non-financial applications. I think there's a ton of applications that don't involve tokens that can benefit from the infrastructure and I think they can benefit each other when done well.

So we'll try both of those lines. Yeah. So that's the AIB. The ICA. So it has a mandate to help enable the network. And so there's just a lot of funding activity that needs to be coordinated. But more on that later. So moving on now to the ecosystem.

Yesterday I was upstairs at Full Note and going around talking to people in the Cosmos ecosystem and asking the community, what are the things I should be asking you today? And so these are some of the questions that were brought up one of the things that is on many people's minds is potential centralization in the validator set. Could you give us your thoughts on this issue? Is this something you're worried about?

The potential for centralization. Sorry. The potential centralization in validation. Basically, validators going towards a race to the bottom and a lot of the smaller validators being pushed out. I think I'm not too concerned about it yet. I think in the long run it may. Who knows what's going to happen in the long run? I think anything can happen.

Eventually, I have this working hypothesis that's sort of vague, but the idea is that anything that even starts off decentralized, if it's sufficiently economically complex, it'll eventually centralize. And I think that's true for any system, no matter how you try to design it so that it stays decentralized. Eventually, it'll figure out a way to become consumed by itself. So in that sense, I'm not saying, oh, the cosmos hub is flawed or that blockchain won't work, but rather I think that highlights the importance of the need to create open source code and protocols and standards

so that once something does become centralized, people have the opportunity to exit or to use alternatives. And ideally, everything is still interoperable along the way so that the transition is smooth. But, yeah, if and when the Cosmos hub validators prove themselves to be centralized, and you should be able to tell based on the network pattern of their signatures as well as how they vote,

where they stand on issues. and if you feel that it's not sufficiently decentralized and it's thinking, then we should be moving away from the hub and using perhaps another hub, right? So I think in the long run, we'll see cycles perhaps where maybe something gets too centralized and then people decide to fork it out and move on. Yeah, I think we'll see generational creative destruction this way for sure, but in the short term, in the next 10 years, I'm not really sure how it will shake out.

We should strive to stay decentralized, and we'll see. Let's keep an eye on it. Is that part, do you think, of the foundation's mandate to promote the Cosmos Hub and decentralization in the Cosmos Hub, or are you a proponent of a multi-hub ecosystem

where hubs are competing against each other? I do believe that we should be building toward a multi-hub system, as in something that makes it easier for people to exit to work on other hubs and for economic activity to start coalescing around other hubs, such that there is this freedom of motion and therefore this competition

which allows and enforces the decentralization of the hub itself. Because it's kind of like I remember Web 2.0, like, Drew Paul and all these things. Like, yes, a lot of the selling points of those open source projects was that there was no lock-in, right? And I think just I had a conversation at one point with one of the founders, and they were explaining how, you know, that was an important pitch because sometimes you do get locked.

into software, even if it is open source, they can design in such a way that you're logged into that ecosystem. But when you make it clear that it's open source, that there isn't lock in and that you can transition easily out to any other platform, it gives you the comfort

to stay and use that platform. And it also incentivizes the creators and the maintainers of that platform to do the right thing so it doesn't turn into the centralized thing that starts exploiting the users. So I think that's what we should do. Another topic that came up was the question of shared security

and Cosmos' uniqueness in bootstrapping networks. So a zone, if you compare it to other blockchain networks out there and the way you build applications, a zone has to bootstrap their own valid ERISA set, has to bootstrap the security model. and potentially even raise funds to distribute a token. In regards to bootstrapping the network and the work that a zone has to do to do that,

do you see that as a challenge for Cosmos in the face of other blockchain networks out there where you have shared security and it's really just about building your applications and deploying it to the network? Yeah, I do see that as a problem now that we will be solved. initially with like simple replicated shared security over IBC and and then like

different experiments on top so like thank you some some projects like Pocod I don't know what Pocod is trying to build for nowadays but at least in the white paper they described a pretty specific way of sharding right I think Pocod also calls it shared security but yeah But when we say share security, sometimes it's different depending on who's saying it and what. But the idea with the Cosmos Hub initially was just to be minimally defined so that you can add, you can do different kinds of experimentations and let different security models kind of evolve. Okay, so in the first phase, there will be multiple blockchains with their own validators set,

completely independent, and that's where we are today. So we see that a lot of projects want to recruit validators to join their network to help bootstrap their ecosystem, which is, I think, fantastic. So going back to one of the questions that was surprising, it's kind of surprising how quickly that's happening. Yeah. But as soon as we have IBC and replicated shared security, and what I mean by that is, like, you have a validator set here,

and through IBC to other zones, you can, We can just copy the mutations of the validator set to all of the replica chains. Pretty simple model. And then if you do anything wrong anywhere, you can submit the evidence onto the hub or the center chain, the master chain, I call it master slave replicas.

And so that way you can keep all the economic, like maybe like the staking token distribution system and fees and all that all in one place. And wherever you do wrong, you get slashed everywhere. And so that means for each staking token, well, it means that for all of these, the stake has gone up. So arguably, and I think this is correct, the security of the whole overall system goes up

because you have so much more. Because there's more potential for earning transaction fees in the system, the amount of security also goes up as well. But there are other models of shared security, like the Pocodot model maybe, where you don't have to be a validator validating on all the... In replicated share security, all the validators have to validate it on all of the zones

that we're talking about, the main one as well as the... But in Pocod, at least in the original white paper, you kind of are shuffled around, right? So I think there are different models. And even when shuffling, like there's different ways you can shuffle, you know, different ways you can create subsets. Maybe some blockchains require larger validator sets than others. Maybe there are regional considerations like continental considerations to consider as well. So I think there's going to be a lot of different models on top.

But they can largely all kind of work with the cosmos subspeck that we're developing. So no matter what replicated or our shares. security system we have, they should probably all just work fine. And the Cosmos Hub doesn't have to be aware of the different mechanisms it has because it's just using the same protocol of like-clined SPV where it's, yeah. Okay. So a follow-up question to that, and you know, you mentioned the Cosmos hub spec, in SDK, and of course there's also tendermint. Do you think that the foundation should play a in coordinating software updates so that you know we don't arrive into a situation where there are breaking changes that don't allow for backwards compatibility and

large parts of the network or some big applications on the network can no longer operate can you can you can you yeah so you know if if a zone is built using the SDK and using a specific feature set on the SDK and they have they have updated to the most recent version of the SDK. And at some point, All in Bits decides to release a new version of the SDK or even Tendermack Core that would break functionality with the rest of the network.

How do you think that the ecosystem as a whole needs to coordinate around updating their software regularly enough so that we don't get to a point where whole applications are no longer compatible? So I think we should be designing IBC so that you don't have to coordinate the upgrade of zones on like all simultaneously. I can imagine there being potentially few upgrades in the future, even after we have IBC coin transfers up where we want the network to upgrade simultaneously for some new feature perhaps. Ideally, it'll be like a rolling update, so it'll stay backwards compatible for as long as possible. So in that sense, I think the cosmos hub should be very forward-thinking, long-term thinking,

and try to stay backwards compatible. But there's just like a lot of considerations here. There's like client software to consider, like client protocols to consider, like maybe. And also there's U.S. as well. So yeah, for the validators, the various validators or the users, like for key management, for example, like the tooling might change. So for all of these, I think initially we should probably take it, take a minimal list approach and see how things kind of develop and where the problems arise and then try to address them as it comes up. I think the ICF can play a role in providing a forum for these discussions to happen. I don't think the ICF should be playing a role where he's trying to help coordinate the upgrade across all the zones.

You know, I don't think the ICF or AIV should do that. Maybe they can be involved in vetting proposals. And, yeah, so maybe, like, for example, in the Cosmos Hub, we might see a proposal that describes what the upgrade proposal process should be. and then maybe the ICF or Tenement Inc. can be involved in vetting it and maybe they can kind of publicly state their opinion on it as well. But ultimately, it should be the validators that are deciding on the process. Okay. So regarding IBC, you can give us a brief roadmap there and maybe some indication as to when

the Ethereum Bridge would be ready. Okay. When, yeah. I'm not doing it. Yeah, I think... Let's just say on the IBC then. What's the status of the IBC protocol? Here's the tattoo I got.

And I think you were going to ask about this anyways. I'll just say, there's one more tattoo I need to get on my head. My only out is that I haven't said when I would get it, so I'll get it eventually. But, yeah, it'll be somewhere over here. So we're trying to get IBC out as soon as possible, and one of the things that we're going to have soon is software, or at least API, so that you can develop your application and IBC, even before IBC is complete, so those APIs will be available soon.

Recently, there was some spec changes and some merging that happened with the Agorix IBC-like system. And so there's more work being done in the spec as we speak. In terms of when it'll be available, like, yeah, I won't say when. But we do want to make sure that the APIs are available. for developing as soon as possible. And we have weekly calls, so please join us if you're interested in tracking the status of it. And also in October, in San Francisco,

there will be a hackathon where we want people to be able to use those IBC APIs for application development. So there's a date, but no promises. So my final question, I want to come back to the foundation and AIB, your president of the foundation and CEO of AIB. Do you see a conflict there perhaps moving forward and you have any plans there to review maybe your involvement in either or of those organizations? Yeah, that's an interesting question. there is a conflict of interest

as in I mean I don't think that's bad per se but it's important to be transparent about it there's a conflict of interest in the sense that AIB wants to be this for-profit software company and the ICF is supposed to be in spirit non-profit so it's actually not a nonprofit technically but whatever

in demand date in the spirit, it's pretty clearly a nonprofit organization. I don't think, but in practice, I don't think this poses a problem because, at least from my shoes yet, as in AIB is not, like AIB as in Tendermint Inc. is capitalized. It has enough atoms to sustain itself. So there's no, like, immediate need to, to exploit this relationship.

Any, you know, there's pretty clear, like, development that needs to happen from the ICF side that AIB is doing, but largely it's just, we're just charging the ICF with software contracts at cost, so there's no profit there. And in terms of how I believe the ICF should be deploying its funds, I really want to make sure that it's enabling decentralization, that it's helping many companies in this ecosystem, so like a lot of the companies that are involved here,

including validators, including, you know, all the projects that are part of this ecosystem, such as like explorers and client software. I want to make sure that the ICF is growing this whole ecosystem and the Cosmos Network is the collection of entities that are individuals and legal entities, including AIB, but it must involve many organizations, including all the validators and everyone here.

And that's what I want to see happen. I think focusing on that and focusing on the expansion of this ecosystem, as well as building bridges, so IBC and bridges to Bitcoin and Ethereum, and finding a position in the whole crypto ecosystem, such that it becomes the solution for interchain token transaction. transfers will be, you know, it's all we need to do in terms of from the ICS point of view and from AIB's point of view, at least in the short term. In the long run, AIB has, you know, like I was saying, we want to develop particular applications, but these applications are not core, they're not like infrastructural things.

They're just additional applications on top of the ecosystem that are among many other applications that people are building. So I don't see in the long run or even a short run right now a conflict in practice that makes it difficult for me personally. I think there's journal optics involved, so maybe people will look at what the company is doing and what the ICF is doing, and maybe they'll feel that things are unfair,

but I think it is my job to prove. and be transparent so that people know that there's a it's that the ICF is is working in accordance with its mandate so yeah I want to make sure that's happening um that's I've answered your question yeah thank you thanks again thank you thank you for joining us on this week's episode we release new episodes every week you can find and subscribe to the show on iTunes Spotify YouTube SoundCloud or wherever you listen to podcasts and if you have a google home or a advice, you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter.tv slash subscribe for a full list of places where you can watch and listen.

And while you're there, be sure to sign up for the newsletter, so you get new episodes in your inbox as they're released. If you want to interact with us, guests or other podcast listeners, you can follow us on Twitter. And please leave us a review on iTunes. It helps people find the show, and we're always happy to read them. So thanks so much, and we look forward to being back next week.