Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Ethan Buchman & Sunny Aggarwal: Cosmos – Launching the Internet of Blockchains

Episode Date: April 3, 2019

The shipping container brought standardization to the way we move goods around the world. Similarly, TCP/IP packets normalized how information transits over computer networks. Today, blockchains remain siloed ecosystems and interoperability is practically non-existent. A new wave of third-generation blockchain protocols aims to change this. In this new paradigm, blockchains communicate natively and value moves seamlessly from one network to another. One of those projects is Cosmos. We’re joined by Ethan Buchman and Sunny Aggarwal of Cosmos. With its recent mainnet launch, we discuss how the network is running and address potential issues relating to governance and centralization of power. Disclaimers: – Cosmos (All in Bits) is a sponsor of the podcast. – Brian is a former employee of Tendermint (All in Bits) and founder of the Cosmos validator Chorus One. – Sunny, is a regular host on Epicenter and founder of the Cosmos validator Sikka. – All participants in this interview are Atom holders. Topics covered in this episode: The Cosmos vision and how it differs from Polkadot and Ethereum 2.0 Building Cosmos and the “Game of Stake” The Cosmos governance process and current proposals Voter participation in the Cosmos governance model The role of validators and the importance of decentralization of power Validator market economics, related inherent issues, and centralization risks The Cosmos SDK and how it differs from Substrate The Cosmos Inter-Blockchain Communication (IBC) Protocol The role of the Interchain Foundation moving forward Episode links: Cosmos website Cosmos SDK websitt Cosmos SDK (GitHub) Cosmos blog Sunny Aggarwal on Twitter Ethan Buchman on Twitter Thank you to our sponsors for their support: Deploy enterprise-ready consortium blockchain networks that scale in just a few clicks. More at aka.ms/epicenter. This episode is hosted by Brian Fabian Crain and Sébastien Couture. Show notes and listening options: epicenter.tv/281

This is Epicenter, Episode 281 with guests, Ethan Buckman, and Sunny Agarwal. This episode of Epicenter is brought to you by Microsoft Azure. Do you have an idea for a blockchain app but are worried about the time and cost it will take to develop? The new Azure blockchain dev kit is a free download that brings together the tools you need to get your first app running in less than 30 minutes. Learn more at aka.m.m.s. slash epicenter. Hi, welcome to Epicenter. My name is Sebastian Kutjo. And my name is Ryan, Robert and Craig.

So today we're going to have Ethan Bachman on and Sunny Agarwal. Ethan is the co-founder of Tenement. He's also a vice president of the Interchain Foundation. And of course, Sonny is a co-host with us at Episner, and he's a research scientist at the Tenement team. Now, quite obviously, there's this sort of tight interconnection between Epicenter and Cosmos. And so we just want to point it out so you guys have the right context. So first of all, Sonny is obviously a co-host of Web Center as well as an employee at Tenement

and he's also running a Cosmos Validator. So please be aware of that. Then when it comes to myself, I used to be an employee at the Tenement company as well. I also hold Adams personally. And I've been building a validator called Course 1 and so working on Cosmos from that perspective. So also take that into account that I'm sort of, you know, on both sides in this, in this instance. Additionally, you know, this validator course, one and building it together with Meher, I mean, he's not hosting this episode, but he's of course also a co-host of Epicenter.

And then Cosmos is also a sponsor. So they're not sponsoring this episode, but they're sponsoring the Epicenter podcast. So we just wanted to point that out. Another thing I would point out is that I also hold Adams. And I've been very, very, closely following the Cosmos project and Course 1, so I have some insights there. And so we should also want to apologize about some of the noise. So there was a little bit of construction going on in Sunny's vicinity, so hopefully we'll get some of that out, but apologies for that background noise. So without a delay, here's an interview with Sunny Agarwal and Ethan Buckman.

So we heard today with Ethan Buckman and Sunny Agarwal. Ethan is the co-founder of the Cosmos and Tenement Projects. And Sonny is a researcher, virtual scientists at All InBits, which is the parent company of Tendermit, and it's also a host here on Epicenter. Hi, guys. Hey, thanks for having us on.

It's exciting to be on wearing the guest hat finally. It's kind of been my dream ever since joining the blockchain space. So happy to finally be here doing it. Yeah, good to be back. Thanks, guys. Yeah, so of course we've done some podcasts on Cosmos before. We did one with Jay about, I guess it's now two years ago. So that was just around the fundraiser.

And we'll link to that. I think that was a great episode. And actually I think still mostly current. But for those who aren't super familiar with Cosmos, let's spend like a few minutes just giving like a high level introduction. So maybe, Ethan, what's the vision of cosmos and, you know, how would you describe cosmos? Sure. So I think the vision of cosmos is kind of analogous to the original vision of the internet in the sense that when the internet started coming around, we already had a large number of, you know,

small networks, and the internet was proposing a way to actually interconnect them all through a common set of protocols like TCP. And so in the same way that the internet, you know, enabled this. interoperability between many existing networks and networks that were still to come, the idea with Cosmos is to be the kind of interchained, right? So the interoperability layer between, you know, existing blockchains and the many new blockchains to come. And as sort of part of that, not only, you know, not only is the goal of Cosmos to define these kind of interchained standards, but also to define, to define more modern and mature approaches to actually building the individual change

themselves. And so that's where things like tendermint, this general purpose consensus engine comes in, things like the Cosmos SDK, which is a framework for building applications on tendermint. And then, of course, IBC, which is the key kind of interoperability piece that enables these different blockchains to actually communicate with one another. Yeah, really it was like meant to like kind of, we see it as just like third generation blockchain. And I know that term is like very cliched and like overused quite a bit. But I think that most of the other things that call themselves third generation blockchains aren't don't really quite fit the mantle. They really just seem to be continuing the second generation.

And so what I mean by when I say second generation is it's this like era of blockchains who are trying to do this like churing complete VM, one chain to rule them all kind of system. So in like the first generation, we had Bitcoin and Namecoin and Saya and all these separate blockchains that were kind of independent and doing their own thing and like had their own applications, Bitcoin for money, Namecoin for money. name coin for DNS, et cetera. Ethereum came along and sort of did two main things, right? The first thing it did was it made it easy for different applications to talk to each other.

So, you know, on Ethereum, I could go and use my, I can use my CryptoKitty on XeroX to buy some dye, right? Like it has this nice composability between different applications on the Ethereum system. And the other thing it did was it made it very easy for developers to write their applications. Right? So back in Generation 1, really, if you wanted to write a blockchain application, your best, easiest way to do so was essentially to fork the Bitcoin code base, which is this like, you know, spaghetti code C++, very difficult to reason about. The consensus is kind of intermingled with the state machine, intermingled with P2P, especially post-Seguit. And so like Ethereum solidity, like, you know, solidity is not the nicest language in the world, but it's definitely, it was, it was, it was, it was, it was, it was, it was, it was, it was. It's way easier for people to write applications than forking the Bitcoin code base. But, you know, and so I, you know, I like this analogy to compare it to like the history of like human development, which is, you know, in the first generation, you can think of that as like kingdoms and like villages where you have like these separate kingdoms and villages that don't really have the ability to like, you know, they can't really trade or anything.

Like some people working on atomic swaps. Ethereum kind of created an empire. What empires did was they, through mass political integration, they allowed for mass economic integration. You allowed people from, like, you know, Italy to trade with people in Persia because they were all under a common rule of law and dictator. And this, you know, it led to economic integration. But it also came with a lot of drawbacks of empires, namely things like, you know, heavy taxation on its use, on its, citizens, just a lack of social scalability and governance that manages to take, like, you know, accept, like, taking the viewpoints of all of the stakeholders and whatnot. And so, you know,

in the last hundred years in humanity, we had this, like, great thing where what we did was we shifted from, like, empires to nation states and city states. We allowed for mass economic integration in today's world with global trade, the internet, free trade zones. but we allowed it to break down into smaller political entities. And that's kind of like the vision of Cosmos as well, is can we have those benefits that that second generation of blockchains did, namely the ease of use and the integration, while still keeping the sovereignty of the first generation of blockchains?

So at what extent do you guys feel that the Cosmos, I mean, originally the Cosmos white paper was published in 2016, like somewhere in the summer, fall, 2016. So it's been quite a while. Has the cosmos vision evolved and changed in that time, or do you guys feel it's largely stayed the same? Bucky can probably answer this a little bit better because he was there back when it was started.

But I've been involved with the project for only about a year and a half now or approaching two years now. But I would say definitely over time, I think the vision of, you know, the vision of cosmos has always sort of been the same, but sort of our messaging and stuff. And kind of it's adapted looking at some of the changes in the blockchain space,

especially, you know, Cosmos or the Tendament Project kind of started almost simultaneously with Ethereum. And so a lot of the thinking that we've done has kind of shifted as we saw the Ethereum ecosystem develop and see what kind of use cases people were interested in. Yeah, maybe Bucky can answer a bit more. Yeah, I think the high-level vision is very much. still the same. It hasn't really changed from the perspective of, you know, there's going to be many blockchains in the world, and that's right and that's fine. We want these blockchains to have kind of independent state machines that are defined, you know, according to the needs of their

users and their stakeholders. We want them to be relatively sovereign so that they're controlled and governed by their users and their stakeholders, and we want them to all be interoperable, so that there's some standards through which they can still communicate with each other. And in the short term, you know, the kind of easiest lowest hanging fruit was okay. We can define, you know, token transfers between these change. But in the long term, if we define things well enough and, you know, with advances in cryptography and crypto economic design and so on, you know, we could do more general purpose data exchange.

And so that kind of high level vision really hasn't changed at all. I mean, what has changed is the particulars of the implementation detail as the, you know, as the ecosystem of blockchains and blockchain engineering. has evolved and new users are coming in and new applications are being found, you know, all of that is kind of evolving in tandem. You know, as new cryptography comes out, we're updating, oh, you know, this could be used to make IBC more efficient or, you know, whatever. So the high-level vision, I would say, has been relatively the same, and I hope is actually grounded in a kind of timeless approach to building systems. And so, you know, ought to never change to some extent.

But, you know, of course, the particular details of how we go better. I mean, the Cosmos white paper had notion of the Cosmos SDK, for instance, right? And so the Cosmos SDK has kind of become a big part of the ecosystem now. And there's a lot of particular details about how that was built and what's in it and what's not and so on. We can talk about that later. But from a high level, I think things have been quite stable. So, Sonny, you mentioned this idea of third generation blockchain. And I think it's safe to put a project like Pocod in this category as well. And I think also by extension, the vision for Ethereum 2.0 could also fit in this category. Starting with Pocod, can you describe the fundamental philosophical differences between Cosmos and Pocod?

Sure. So I think I would say one of the main primary philosophical differences between Cosmos and Pocod is that Cosmos takes a sovereign first, sovereign by default approach, where we assume, chains are sovereign, have their own validator sets, have their own security models, and allow them to sort of communicate and to operate with each other. And we don't assume that there's any one, like our design for IBC is designed such that, you know, there could be any, any two chains could talk to each other. There's no necessarily any root chain or anything like that. Well, Pocod takes the approach where it like kind of does shared security by default,

and that's kind of what they really focus on, where they kind of say that, like, there is this one root relay chain, and then, you know, all these other chains are going to be just like shared secure, using the validator set of that relay chain. And so, you know, and then they, you know, have the concept of connecting

to other chains, but they, using bridge zones. But that's really not, like, by default, people use the relay chain. Well, in Cosmos, by default, they're sovereign, but then the Cosmos Hub, as well as, you know, there's other hubs and hub systems in the, in the Cosmos Interchain. But these chains will offer services such as, like, shared security and whatnot. But these are, like, optional things that chains can opt into while it's not the, like,

default or requirement. Okay. I mean, the way I see Pocod in that, in that respect is I see it as sort of this validation as a service for blockchain. and Cosmos, at least right now, doesn't have that functionality. Do you think this is something that projects will want? So, for example, if you're building a new blockchain and you're choosing a platform on which you want to build your application,

having that ability and having that functionality and that feature, so bootstrap your application using a shared security model might be attractive to someone or to a project. Do you think that this is something that, you know, people will ask and will require of cosmos at some point that the market and the ecosystem will want as a functionality? Yeah, totally. I think that this is like what people absolutely want this. And this is kind of what the goal of the cosmos hub is in the long term. So I think it's more fair rather than comparing Pocodoc to like the Cosmos Network, Cosmos Interchain idea. Cosmos Hub versus Pocodot is really the like, you know, a more salient comparison. And so

there, and then, you know, the Cosmos Hub has a design for, or I have a design for the Cosmos Hub shared security system that's slightly different than the Pocodot design. And so, you know, I've discussed it with the, with a lot of the Pocodot dev teams. And, you know, we're both aware of each other's shared security designs. And, you know, maybe if you want, we can go into some of that, some of how I plan for the shared security of Cosmos Hub to work. But yeah, so essentially my point is, yes, the shared security is something that will definitely be demanded by a lot of projects. And that is one of the primary services that the Cosmos Hub will provide to the Cosmos Interchain

Network. And what about Ethereum in that case? I mean, I know it's much earlier in terms of the maturity of Ethereum 2.0, but I think that a lot of the fundamentals are there for, you know, leading Ethereum into this, as you describe it, this blockchain 3.0 space. Can you already discern some of the differences between what the vision is there and the cosmos vision? Sure.

So Ethereum still takes very much a, like, you know, a single VM, like single state machine. Everyone has to use the EVM. And, you know, really the problem with that is it suffers from a lot of, like, you know, it's going to suffer from a lot of governance issues where people are going to basically have like different requirements from the from this VM and they're not going to be able to decide who gets what going into that VM. And you know, we already see this where there's like hundreds of EIPs that are open in this in the in the EIP repo, the theorem improvement proposals. And some of them are contradictory and like, you know, some people want state rent. Some people don't. Some people want

X. Some people don't. Like it's like there's so many like different design requirements. man said like the problem of the acturing complete vm is it really forces everyone to like use the average use case you know an example i like to use is if you want to build a payment system you should probably be using utxos like there's a reason bitcoin did that they're just way better for like parallelization and like efficiency but if you're building a payment system on top of ethereum you are stuck you're you have to use their like account model and that increasingly involves using the sequence numbers, and you lose out on a lot of parallelization. And so you don't get that, you know, just like in the world of nation states where like

splitting it off, it allowed nations to specialize. We also want to allow blockchains to specialize in use cases. This episode of Epicenter is brought to you by Microsoft and the Azure blockchain workbench. Getting your blockchain from the whiteboard to production can be a big undertaking. And something as simple as connecting your blockchain to IoT devices or existing ERP systems is a project in itself. Well, the folks at Microsoft had you covered. You already know about the Azure blockchain workbench

and how easy it makes bootstrapping your blockchain network pre-configured with all the cloud services you need for your enterprise app. Their new development kit is the IFTTT for blockchains. Suppose you want to collect data from someone in remote location via SMS and half that data packaged in a transaction for your HyperLedger Fabric blockchain. The development kit allows you to build this integration in just a few steps in a simple drag-and-drop interface. Here's another great example.

Perhaps you're an institution working with Ethereum and rely on CSV files sent by email. One click in the DevKit and you can parse these files and have the data embedded in transactions. Whatever you're working with, the Devkit can read, transform, and act on the data. To learn more and to build your first application in less than 30 minutes, visit AKA.ms.

And be sure to follow them on Twitter at MSFT blockchain. We'd like to thank Microsoft and apps. for their support of Epicenter. So the Cosmos project has been in, you know, in development in some way or another for a long time, right? Tenement, I think, was originally started in 2014. Now, just a few weeks ago, we finally had the launch of the Cosmos Up. So congratulations. Of course, it did take a little bit longer than announced.

Talk a little bit through, you know, kind of the process of getting to launch. Why did it end up taking so much longer? And like, how do you feel, how do you guys feel that launch went? Launch seems to have gone really well. So I don't know if you've watched the video or if you were there at the live stream. That was pretty cool. I mean, there was a moment. I think it was Block 17.

You know, Jack was hosting the live stream and we halted at Block 17 and his face, just like all the color drained out of his face. It's quite a moment. I think at Halloween, someone dressed up as Block 17, just to troll Jack. But it seems the launch went quite well. we had this decentralized start, which was pretty cool. You know, quite a decentralized start, actually. And then, you know, arguable kind of how you look at what's happened since then.

But I think, you know, we're quite excited about, you know, the fact that it's live and it's working. And, you know, there's lots of interesting activity happening and lots of upgrades to come. I think with respect to, you know, how we got to launch and why it took so long and so on. I mean, you know, on the one hand, software developers are notorious for poor estimates. So, you know, there's Hofstadter's law, which is like it'll take longer than you expect, even after you take into account half Hofstadter's law. So you get this kind of recursion, which is great. We definitely felt subject to that.

I think we didn't quite appreciate maybe the complexity of what we were building initially. And a lot of that really only came to the surface as we tried to start building it. And there were a few iterations of things where, you know, we just threw something away completely and started again. And so, for instance, that's kind of, you know, the story of the CosmosS SDK. The Cosmosis SDK wasn't part of the white paper. It wasn't really part of, you know, front and center of anything. But we realized kind of as we were going that, you know, we really do need a mature kind of professional framework for people to build blockchain applications in that is extensible and can cover a wide number of use cases. And it doesn't lock into any particular, you know, serialization algorithm or Oracle tree structure or any of the things like this.

And prior to that, we kind of had, you know, we had some kind of a framework. It was called Basecoin at the time for a while. You know, and that was working. We had test nets with that running and staking and, you know, IBC even before the fundraiser in 2017. But the kind of design process for the Cosmos SDK kind of reset things, right? And we started working on a new model and putting, you know, object capability-based security first and really thinking through, you know, how much of the Go programming language existing capabilities can we utilize in our security model and, you know, how are we going to get the right abstractions and how are we going to be

able to build systems as diverse as the Cosmos Hub on the one hand and, you know, the Ethereum State Machine on the other, right, with the kind of Etherment project. And that was really a chief design goal that only really became articulated a little later on in the process that this framework we build, we want it to be extremely general purpose so that you could literally wrap the existing Ethereum State machine with its RLP and its Merkle tree and the EVM as is, all the existing clients, you know, not have to change them at all and use the same framework to build that as you would use to build the cosmos hub, right? And so that required a lot of design work and a lot of kind of resetting and, you know, rebuilding things that we had already built in terms of staking

modules and all this, now back on top of this new framework. And so, you know, that kind of delayed things. And then as we were really drilling into the staking model and the fee distribution and all this stuff, you know, there's a lot of complexity in there. And it's extremely advanced. And I think as far as I know, you know, the most complicated kind of a proof of stake, state machine in existence today, especially with regards to, you know, the delegation and the unbonding periods and supporting redelegation, which has its own set of subtleties and nuances. And through all of that, having fee distribution to potentially, you know, many thousands, if not hundreds of thousands or millions of delegators across, you know, maybe 100 or a few hundred validators. So getting all that to work and, you know, we scrapped our fee distribution twice. you know, we first had a pretty complex one, and we scrapped that and did a simple one, and then we scrapped that and did a, you know, a different one.

And now, you know, things are a lot more mature and stable, and we have nice specifications for a lot of it. But, you know, I think to a significant extent, we really underestimated the complexity of what we were building. There wasn't enough specification done up front. You know, there weren't enough people really thinking about the problems and the implementation details and all that. It really only evolved over the course of 2018, right?

And then, of course, there are, you know, operational constraints, coordination constraints. We have quite a distributed team from San Francisco to Berlin all the way to Asia at points. You know, San Francisco and Berlin pretty much don't overlap at any point in business hours. So, you know, coordinating, it can be very difficult. And, you know, we launched various programs. We iterated through the test nets. And there's a lot of kind of operational overhead to that and to gain mistakes, which we can talk about as well. And so just like getting all those things in place and, you know, dealing with all the difficulties of remote.

coordination and so on, you know, so it ended up taking a little bit longer than anticipated. I mean, I joke that, you know, it was like we were two months away for like, you know, 15 months or something. And then there was a period where we were like a month away for a couple months. And then we were a couple weeks away for a few weeks. And, you know, then it happened. So I actually have a chart in the Berkeley office to kind of match this, like estimated time to to launch.

And they're just sort of hovering around a two months mark for like a good, like, eight months. that's funny. Just the one other point I want to make, and Zaki gave a talk at the MIT Bitcoin Expo that kind of really harped on this approach we took, which I thought was actually really valuable and really interesting. And I think distinguishes us from a lot of other

projects, which is that, you know, we didn't launch the Cosmos Hub until, I shouldn't say we, the Cosmos Hub didn't launch until a couple weeks ago, right? But all that time, there were a large number of projects building on top of the software we had been developing, some of them even running in production,

And, you know, for instance, the IrisNet launched, you know, I think a month or two before the Cosmos Hub did. And, you know, tendermint has been used in production for, you know, quite some time now. And so this approach of, like, doing everything in a quite modular fashion and trying to make the pieces as useful as possible in the interim, I think really helped kind of build the community and develop the ecosystem and the expertise around it until we got to the point of, you know, actually launching this main net Cosmos Hub. And so I think that was really valuable for us and kind of helped continue the momentum. And, you know, despite the fact that the Cosmos Hub hadn't shipped, you know, we were still shipping lots of releases for tendermint and for the SDK. And a lot of people were starting to really see value out of that. And, you know, have been running in production for some time.

So, you know, I don't want to neglect that. Yeah, of course. And, you know, obviously we're all very excited when the launch happened. And so, you know, months before launching, there was this game. of stakes which was sort of like a I guess like a glorified test net where things were happening kind of in production and being being sort of like a close observer of cosmos and a close observer of course one I sort of got to see what was happening here and thought it was interesting that this approach was actually quite interesting and that you know maybe it should be adopted

also by other blockchain networks that would launch in the future. Can you talk about why you did this? What was the goal here? And like what do you learn from this experience that allowed you to launch the network then so successfully and like so far flawlessly, I guess? Sure. I mean, so a big part, a big part of our understanding of what we were doing is that not only we were building software, but we were also building a community of network operators.

And when you're talking about peristake systems, the kind of expertise required in a network operator is very, very different from, you know, a proof of work system, mining, and, you know, the kind of full nodes that are running there, especially because you have this private key online and you're also concerned with hiding your IP, so you have a more complicated kind of infrastructural operational setup and so on. And so early, I think in 2018, you know, we were a little bit confused, or sorry, a little bit concerned about how mature the actual validator community was going to be, by the time launch, which was two months away for how mature they were going to be. And so, you know, we started to put some real effort into building the validator community

and the Tessnet community. And I think, you know, to a significant extent, this was really inspirated by Adrian of Cryptium, who was working with us at the time. He really kind of got the ball rolling on this, which was really nice. And it, you know, it picked up kind of far beyond him very quickly and really became like a self-sustaining community on its own of kind of running test nets, taking the latest release and, you know, running it in the wild. And eventually by the summer, we started doing these, like, decentralized starts. You know, there were a lot of hiccups at first when you're, when you're, like, you know, doing QA on your software with a distributed network of strangers over the internet.

It's quite an intensive experience. But so we got these networks up and running through the test nets. And through that kind of built a community of operators that really understood how to run the software, how to deal with, with bugs and failures. there were lots of halts, lots of things went wrong where people would have to kind of restart the whole network and do that in a decentralized way. And so the community really got a lot of practice doing that through the series of test nets, which I think was incredibly valuable, both for us and for getting feedback and so on, but also for them and learning how to operate and kind of building this sense of community. But with respect to game mistakes, I mean, so the other piece that we were, that we realized was that there were a lot of people participating in these community test nets that were really valuable community members answering lots of questions. like doing just outstanding work in contributing to the software and so on.

But these people actually didn't have any atoms. They didn't participate in the fundraiser at all. Maybe they didn't even know about Cosmos at the time. And so given that the plan for the Cosmos Hub was that it was going to launch without the ability to transfer the atoms, there was some concern that some of the most competent or experienced network operators actually wouldn't be able to participate at launch. And so this is where we kind of cooked up the idea that, well, maybe we can build some kind of a incentivized test net competition where the people who are really participating and

really demonstrate their competence can actually, you know, be rewarded with some Adams in the Genesis block, a recommendation for Adams in the Genesis block. And so that if the network starts with that recommendation, you know, they'll be there on day one and they'll be able to start to participate. And that was extremely well received. We had, you know, a lot of support for that. A lot of people participated in the game mistakes. And some of those people who, you know, or some of those validators who received, you know,

Adam recommendations in the Genesis block, you know, we're validators on, you know, from block one and have been, you know, huge, again, huge participants in the network since its launch. And so game mistakes was really about making sure that, you know, those people who had put so much time and effort and energy into our test net program and weren't going to be able to participate at launch would actually have, have some atoms so that they could participate. And that seems to have worked tremendously well. And yeah, I would highly recommend that additional, that other, you know, proof of state networks that are launching, do something like this and, you know, make. sure they're building up this kind of community of network operators because at the end of the day, running these networks is really probably about half as much as about having competent operators that really understand what they're doing as it is about as it is about the software because the software is going to have bugs, it's going to have issues, things are going to go wrong and you really need, you know, competent network operators that can coordinate to to address these kinds of issues. And so, yeah. Yeah. Yeah. I mean, just briefly, uh, weighing in here because, you know, and now, of course, one had, so we, we participate in.

of course in this game mistakes. And we had like an incredibly also stressful and intense like Christmas because of that. Because I mean, I think, you know, we had participated in these test nets for quite a while before. But, you know, then it would be like, okay, something happens. It goes down. It wasn't really so consequential. But then all of a sudden it was like, okay, no, this is like a major issue. So then having, you know, building up systems to have, you know, automated phone calls and like on-call schedule and all like all of that stuff.

And, you know, initially it started just before Christmas, and then it halted a bunch of times, and then restarted. And then so we had basically, over the holidays, a lot of, like many others, I think, like fixing these things and improving it. And then I think what we saw, right, in the launch is that everything went super smooth. And I think that was without game mistakes, that would not have gone this way. I'm sure lots of validators would have had lots of downtime. And in game mistakes, we saw lots of downtime of various validators. But then since it launched, that hasn't happened like that. Yeah, totally. And the other thing that it also did, like you mentioned, was a lot of the halts in the, uh, during game mistakes were due to like bugs in the software. And so what the other thing game mistakes really did was it allowed us to have a good process of like testing, uh, all sorts of behavior on the state machine and all the validators were trying like different functions and like doing the fun little stuff on the game. And that forced us to like test software and things that like in ways that, you know, we weren't testing it internally ourselves. And,

So that helped us catch a lot of bugs. And, you know, it seems that thanks to that, we, we have, like we said, we haven't had any bugs knock on wood, like yet on mainnet. The other thing that Game of Stakes also tried to do, which I'll actually argue that I don't think it did very well, was we also had this, we also had this idea that somehow it was going to test the economics of proof of stake. And so what we, and the idea was like, oh, can we like, fast-track the testing of proof of stake by like increasing the rewards like so the inflation was like

I don't know something absurd like 20,000 percent or something over the over the course of two months and we thought oh that would somehow simulate running proof of stake for years and I don't know. You know like I said like Bucky said like one of the main things was to get validators to test to set up their security system properly and I think that that like pits are we're saying oh we're testing proof of stake actually degraded the improvement of people's security. So you'll notice that, for example, my validator Cicca, we didn't auto bond any of our tokens. Like we were not, and so we quickly fell out of like, you know, our stake quickly depleted. But that's because we didn't want to practice, like, we wanted to practice keeping a cold

key and not having a hot key with an auto bond script. And so I think that like, you know, having that like testing a proof of stake kind of actually degraded a little bit from the experience. So that, you know, I think as different projects go on and do more like incentivized test nets like this, I think these are some of the things that they should be thinking about, really focusing on the security of the validators. Yeah, that's a really great point. And I mean, partially it showed that, you know, we can do these kinds of experiments and

they can be successful. But I think, you know, to Sandy's point, they really should clarify what in particular they are testing and not try to conflate too many things at once. and you know I mean part of the excitement you know that I always had around the blockchain space was that we can really start to test you know economic mechanisms and things in the wild in ways that we probably couldn't before and you know that's that's more true than ever today and yeah with game of stakes we kind of got a few things I guess confounded in that in the one hand we're trying to really improve operator security but on the other you know we were talking about testing the economics and those two things are a little bit juxtaposed with each other they're a little bit intention like some of the other. I was saying, you know, auto bonding isn't something you should be doing if you're building this kind of, you know, hyper-secure offline key system, whereas it is if you're just in it for the rewards, right? So, but I think we're also seeing that play out on main net.

I mean, if you look at significant amount of the transaction activity is some of the validators just like constantly withdrawing their rewards and rebonding. You know, maybe that's a problem with the architecture of the system, that the rewards aren't automatically bonded and, you know, that stuff that could be addressed in the future. but I think this point about picking what you're testing and what you're experimenting with is important. The economics of a short-term game are just so different than the economics

of a long-term repeated game. And I think that was sort of the main problem. And we saw certain attacks that were tried on game mistakes that only made sense in short-term games, not in a long-term game like the real Cosmosub is. Well, let's move to the topic of governance, right? Because that's another thing that, you know, since the networks launched, like you still can't transfer tokens,

but there is like activity around governance. And one of the things that's interesting is in the last years, people often talked about on-chain governance, but they would always talk about, you know, tasers or DFINITY or like these other projects. Cosmos would never be mentioned. But of course, there is on-chain governance and it's being used today.

So do you guys mind describing, what does the on-chain governance process look like in Cosmos? And, you know, how does it differ from other on-chain governance processes. Sure. So the on-chain governance process of Cosmos is a little bit complex. And it's like not, I'd say it's somewhere in the middle ground between like the more social consensus style system of Bitcoin and Ethereum and the more like complete hardcore,

fully on-chain governance that like Tesos or Pocod kind of say. So in Tesos and Pocod, like, you know, they have like a sort of coin holder voting where the more coins you have, the more votes you get. And that has the ability to automatically change the software. And, you know, my issue with this is I think it leaves out a lot of the stakeholders. So, you know, coinholders are an important stakeholder in the governance process, but they're not the only one. There are other important stakeholders that you need to gauge the opinion of, such as, you

know, maybe businesses who are depending on the system, users, core developers. There's a lot of people who you need to gauge them. a social consensus of. And that's kind of like, you know, always been the premise of Bitcoin and Ethereum and whatnot that you need to gauge everyone's consensus. But the problem that Bitcoin and Ethereum face is that they don't have an outlet for coin holders to signal their views. And so this is kind of problematic as well, where, like, you know, Ethereum, for example,

has the carbon vote, but it's not this, like, official thing. Like, the U.X around it is not that great. And it's like, so it leads to extremely low voter turnout. And so the idea is that by like making it beat like the on-chain governance or on-chain signaling be like an official part of the core protocol, the idea is that hopefully we can get more voter turnout and so we can get the coin holders views as an input into the social consensus. And so if you look at the governance system of Cosmos, there's three types of proposals. There's text proposal, parameter change proposal, and software upgrade proposal. So the text proposal is really what I've been talking about where it's this signal. So it's like, you know, we ask the coin holders, hey, do you want this feature?

What do you think about this idea? And the coin holders can do their signaling. Then there's a second round, which is sort of like the software upgrade proposals. This is where the question we're asking to coinholders is not actually, this is really less of a governance. and it's more of just a coordination system of when to upgrade. And so what we're asking people is not, do you want this change? It's do you think social consensus has agreed to this change? So, for example, if you look at Segwit activation in Bitcoin, right, that whole 80% threshold

that they had, I don't think 80% of minors wanted Segwit. The question really was, do you think that Segwit was accepted by social consensus? And 80% of the miners voted yes on that. question and so that's really what the software upgrade proposal is we're telling the we're telling the voters here that you're not you're not supposed to be saying what you want you're supposed to be just providing an oracle to social consensus and saying has social consensus agreed to run this and if so let's coordinate on a block height and a code hash to upgrade to and then finally

there's that middle type of proposal which is the parameter change where there's some things like you know high level code changes and stuff. We want to go through this very slow and drawn-out process, be somewhat conservative like Bitcoin. But even on Ethereum, there are certain things that like the miners can just straight up change themselves, for example, the gas limit or block size in Ethereum. And so that's why we have these parameter change proposals where it's like some things that maybe just for the case for the situation of simplicity and efficiency, we'll say, okay, we'll let the coin holders just automatically upgrade that themselves. But the things that are going to be in that

camp are probably going to be somewhat limited. So really, the text proposals and the software proposal, this two-round system is really going to be the crux of Cosmos' relative, the Cosmos hubs, relatively conservative governance system. So we've had two governance proposals so far, right? One was about changing some parameter about how inflation and the block rewards calculated. And the other one is around enabling transfers, you know. what are the insights or maybe lessons that you guys see so far in terms of how the

governance system is functioning? Is it kind of living up to expectations? Do you guys feel like some things have come up that surprised you? Yeah. So, you know, the second proposal that was made on the Cosmos Hub, the first one was about this like thing that it was relatively uncontentious and it seems to be passing quite well. The second one was about the famous activating of transfers. So, you know, as Bucky mentioned, we launched the Cosmos Hub without the ability to run without the ability to transfer tokens.

And we kind of said it'll be up to the community to decide when they think that activated transfers is ready. But the way that that second governance proposal was kind of framed, it was framed in a suboptimal way where it basically said, do you want to activate transfers? And if so, we'll all run the code that is signed by AIB, All InB, or Tendermint the Company. And basically, essentially, like, you know, Tendermint the company, essentially they said, like, it was based off of the signatures of three Keybase accounts, which I think included Bucky, Jay, and Jack,

who is the project manager for the SDK. If it has the signature of these three people, then we'll go ahead and run that code. But that's, and, you know, that actually, for a little bit, a lot of people voted yes. And then some people started to think about it a bit more. And they're like, wait a second. That means that like, Tenderman the company could like do anything they want.

And like we could change the state machine to like, do, you know, do anything we want. A lot of send all money to us. And, you know, obviously I work for Tendermint the company. And I hope I don't think we're malicious. But like, I think it's that good precedent that the community was like wary and skeptical of us. And so now in the past few days that the, the vote on that proposal has quickly shifted to no, and that proposal will probably be rejected. And there are people in the process of writing a new proposal for enabling transfers that

follows this more two-round commit system that we just talked about. So one of the interesting things in the Cosmos voting system is that, you know, let's say I'm a delegator and I'm delegating to, you know, validator A, then if I don't vote, if I don't vote myself on a proposal, I basically wrote in the same way that validator A votes, but I have the ability to say, oh, I'm going to vote myself and then differ from the way my validator votes. How do you guys think about that in terms of the sort of power balance between validators and delegators? I mean, in many voting systems, on-chain governance voting systems, you've seen very low participation from token holders.

So let's say we're going to see similarly very low participation here. Do you see a risk that validators will have too much power in this? Yeah, I think potentially. I think, you know, first of all, this is all a massive experiment. So we don't really know how any of these things are going to shake out. The nice thing, though, is that having this kind of automated governance for delegators, basically, you know, it does help, I mean, it's kind of double-edged on the voter turnout question, because on the one hand, by having the automated voting kind of follow your delegate,

follow your validator, you know, we basically guarantee that as long as the validators are voting, which they ought to be, then all of the stake is kind of coming with them, which leads to high turnout numbers. Now, whether or not the individual delegators are kind of paying attention is kind of another question. And I think it really depends on who the delegators are and what they care about and, you know, how technical they are and how much they kind of understand the state of the network, right? So to the extent that they're just, you know, retail consumers that are looking for some kind of passive return, you know, then they're not going to care. And at least in theory, right, they're not going to know enough to pay attention.

Now, I think we've kind of hoped and tried to, you know, encourage the community to be such that such retail investors aren't. really the primary holders of atoms. You know, the other parts of the Cosmos Network will be for them. The hope is that really the people that hold atoms are people that are quite interested and involved in the maturation, the maturation of this technology and the network. And, you know, they're building businesses around it and on it and so on. And so want to see that even if they're not a validator themselves, that the network is evolving in a direction that makes sense for them as kind of active stakeholders, right?

But the extent to which they'll be active really depends on the extent to which there is opportunities for them to be active outside of just being a validated, right? So building businesses and putting up zones and all this kind of other stuff on top of cosmos. So I think there is some risk. A lot of it remains to be seen. How this is going to work out, you know, again, it's a big experiment. I mean, there have been discussions about potentially changing that governance. So, you know, so that maybe when you delegate, you also have to pick. which validators votes you'll follow rather than automatically following the validator you delegated to.

So that could kind of make things a little bit more flexible and which could potentially separate the, you know, the decision between who you want your stake to be tied to and who you want your vote to be tied to, which could be very different. But I think, you know, from a certain other analysis or perspective, it might make sense for those things to be the same. It doesn't even necessarily have to be to another validate. It could be just to another user account as well. Could be to another user. Right, right, right. So kind of make it more of a liquid democracy kind of approach. Yeah, so there's a lot of opportunity and flexibility there.

I think what we've started with is just kind of, you know, again, from the perspective of actually shipping the thing and having it not be too complicated from the get-go. You know, the idea was, well, let's ship the kind of simplest thing that makes sense and that kind of works and let it evolve from there according to, you know, the stakeholders and the users of the network. So it'll be very interesting to see how the governance really evolves from here. I think that this flexibility is desirable and perhaps necessary. And I think that having something more akin to a liquid democracy is an improvement or something of betterment in terms of what our actual current political systems look like. But I think the challenge remains, regardless of this sort of flexibility, is participation in encouraging participation.

Now, it might be that you have all these functional. and these features that allow you to delegate, et cetera, but that in reality, you know, maybe two big whales are only act, only two big whales are actually coming in and making decisions on on important proposals to the network. And if at some point, you know, there are billions of dollars in value and user applications and investment funds and insurance companies and banks and what have you building on tendermint, then, you know, that could potentially pose a risk to a lot of users. You know, one idea that, you know, we were discussing before the show, Brian and I, and one idea could be potentially that delegators would need to actively delegate their vote with validators,

but that those validators votes in a pool would only count if a sufficient threshold had been reached. So effectively, validators would sort of have to campaign on behalf of their delegators in order for votes to go through. and so therefore you might have a situation where people will be incentivized to vote, et cetera. How do you think that we can actively make blockchains a sort of more democratic system where there is actually participation and we don't fall into the same sort of system that we have now where most elections, I think, you know, like never surpass 50%. And in recent elections we've seen like, you know, even less than that.

This is a really hard question. And I don't know that any of us are going to be able to give like real competent answers. I think to some extent we're exploring extremely uncertain and unknown territory. What I would say is that it really depends on the stakeholders and the community engagement and how much people care about the system and want to participate. And to some extent it will also depend on the incentives, but building the incentives around governance in a way that doesn't just promote vote buying and all this stuff is quite difficult.

And so I think, again, part of the vision of Cosmos was really this, sovereignty and this proliferation of blockchains and that any group of stakeholders that wanted to put up a chain would have the tools to do so and to do so in a way that was at some level interoperable with everything else right so you know whether they're talking to the cosmos hub or not it kind of doesn't matter and so from this from this larger you know meta perspective of giving people the tools to run blockchains and to engage with them and govern them I think that that will hold a lot of promise in this question about you know how do we build actually engaged communities and and you know so

stakeholders that participate. But I think it, you know, it is also still an open question for us as, you know, civilizations and societies, how we build these kinds of institutions where there is kind of democratic engagement and participation. And, you know, we don't really have that at a large scale in our, I think, in our, in our politics, there are certain other, you know, like cooperative corporations, try to do this a little bit more actively where, you know, the members kind of have to vote. And that's kind of the whole point being part of a cooperative is you're supposed to vote on

the thing, right? And so you can think of some of these digital networks is like, or some of these blockchain networks is like digital cooperatives in a sense, but, you know, it's very experimental. And so I think it really comes down to what is the value to the stakeholder that they're getting out of this and how much do they care? And if they don't, if they simply don't care enough about the outcome that they're going to vote, then they're not going to vote, right? And so, you know, the closer that the actual state machine of the blockchain is to the particular stakeholder, the more likely they're going to pay attention. they are going to vote. And so, you know, this kind of thinking, I think, has been paramount in our design decisions to, you know, encourage its proliferation, to not have the kind of shared security by default, but to have, you know, more of an interoperability by default

and sovereignty by default to really enable the state machine to really be as close as possible to the stakeholders so that they will care, so that they will turn up. And I think asking the question of, you know, how do we get all of the atom holders to vote on things on the Cosmos Hub or how do we get all the Bitcoin holders to vote on things on Bitcoin, you know, it's a little bit of a misnomer because of how distant the state machine of those networks is from the stakeholder, right? And yeah, so kind of a long-winded way of saying, you know, it really depends and we don't know. Also, a couple of weeks, like earlier on in like the Cosmosub development process, we actually had it so that if you like, you know, if a validator doesn't vote, they actually got stuck. But then what, you know, the emergent behavior that ended up happening is everyone just started writing scripts that would auto vote abstain. And, you know, I think what that made

us realize was trying to force behavior, especially when it comes to voting and stuff, is not effective. And really what we need to do is inspire and encourage people to vote. And I think that that is like, you know, this whole community blockchain's idea is kind of will hopefully do that. where like, you know, the reason maybe people don't want to vote on a lot of the Ethereum stuff is that it's like, you know, it's just such a big system that like you don't care about everything that's going on, right? But like if it's like a more specialized application or part of your community chain or something, you know, maybe that will lead to more engagement. And then from a technical standpoint, there's also like, you know, some certain stuff that I've been working on to make it easier for people to vote. So for example, right now, you need a vote using your key that also, you know, has. all your atoms on it and maybe you want to be keeping that in cold storage.

I'm working on a proposal called subkeys, which will allow you to like basically designate one key as like a for different functionality. So you could, and one of the things you could do is you could say this key has only the ability to vote in governance. And it can't like move your tokens to someone else. So it's okay that maybe that you have your main key on your ledger in cold

storage, but like your governance key, you can keep it on your phone. And there's like already a bunch of. great mobile wallets like rainbow wallet and Cosmo Station that all you support governance. And so once we have these subkeys, you can keep those keys on your phone and be able to vote, you know, go make it like fun. Like, you know, when you've seen other cosmos holder, Adam Holder, you'd be like, hey, have you voted on the proposal yet? And like, you know,

we have to encourage people to be part of it and make it easier and more secure for people to do it as well. So we spoke a bit about validators. And of course, that does tie into governance as well. So what do you guys see as the role of validators in the long run and the kind of the function they serve in the network? Sorry, I just wanted to make a point about the last discussion, which I think is that this point is about kind of voter turnout and engagement and that it's maybe the wrong question and it's more about building systems that people care about and getting the engagement there

kind of holds for the larger space of mechanism design and all the kind of things. things we're working on. We always, we tend to take very, you know, technically oriented and mechanism oriented approaches to the design of these systems. And I think to a significant extent, you know, somewhere along the line, neglect the fact that the whole point of this thing is to coordinate, you know, real, wet, messy humans. And that the human elements are really what this is all about. And, you know, if we don't tend to the psychological and sociological aspects of that, no matter how perfect your mechanism is on paper, you know,

it might not really, might not really take shape the way you expect. You know, I was at the Radical Exchange conference last week with my girlfriend, who is much more in the kind of social side of things and, you know, how to make technology more human side. And she was basically just trolling me the whole time we were there

and just chirping about, you know, all these people are so like mechanism oriented, like where's the humanity and all this? And so, you know, I try to channel her as much as possible in thinking about blockchain design and so on. So anyways, from the perspective of validators, I mean, I see, I'm very interested, and this is a much, this is a long-term perspective, so I'll just give it to you like that.

I'm looking for radical decentralization of the physical infrastructure of the internet, because right now it's kind of a red herring, or it's kind of the, sorry, not a red herring, it's the elephant in the room. Get my analogy, my idioms mixed up. The elephant in the room, when we talk about decentralization is the physical infrastructure, right because we have made almost no progress you know we're doing really great things on decentralizing file sharing and consensus and you know all these all these great software and overlay stuff but when it comes to the physical infrastructure you know we've hardly even begun i mean there's a few mesh net projects and so on but so what i really see in the long term the validators as being the seeds for real

decentralization of the of the internet infrastructure and i think you know validators like proof stake validators might be the first application where people are going back to data centers, right? Like everything moved to the cloud and it's like, finally we've created an application that is encouraging people to actually leave the cloud and actually set up real physical infrastructure close to them, you know, in a data center. It was actually, I found this quite touching the other day. I was talking to Zaki. You know, Zaki travels quite a bit. And he was, you know, he said something about like where home is, like, when are you going to go home. He was like, where's home? He was like, oh, home is where the validator is, right?

And I thought that was kind of really, really interesting take on the meaning and importance of validators in the long term as like seeds of the physical infrastructure, the physical internet infrastructure for these new kinds of digitally cooperative communities. And so, you know, maybe that's not a satisfying answer about what the role of the validator is in the short term, but at least, you know, that's what I'm kind of hoping for in the long term, that they really start to seed physical infrastructure in local communities in that. You know, this vision. for sovereign, independent blockchains that are all kind of interoperating kind of takes a, to a significant extent, like a geographical orientation so that certain zones actually

are based locally, geographically. And traditionally, that's how sharding is done on the traditional internet, right? With, you know, the huge volumes of Google or whatever get cached in local data centers to serve those populations more efficiently than having to always go to California to get the data. And so I'm hoping that we can reset the internet infrastructure on top of that kind of thing with validators. Now, in the short term, was the role of the validator. It's very different. It's obviously primarily to operate the network and to host it and to start to offer services around it and to attract delegators and, you know,

upgrade it and make it actually useful for a larger number of stakeholders. But I think to ask about the role of the validator, you know, just the validators on the Cosmos hub, you know, kind of misses the point of the larger vision of the Cosmos network and the Cosmos Interchange. of, you know, the validators are really part and parcel. They're like the stakeholders of the independent communities that we expect to run the many millions of blockchains. And so, you know, part of that is going to be educational. How are these communities actually going to have the technical expertise to actually do this

in a way that just doesn't, you know, it doesn't just offload everything to some other, you know, tech provider? And I think those are, you know, interesting questions and challenges for us to address over the coming, you know, years, decades. So one of the interesting questions around validators that's also already come up in the, you know, two and a half weeks that it's running is around, you know, the decentralization. And of course, we do have, let's say, for example, polychain, right, there's like a huge, so there are some of these funds with, like, massive positions.

There's an expectation that, like, exchange is going to come in and, you know, in some other systems, they've also, like in EOS, for example, I think they've accumulated massive power. Coinbase custody is now, you know, they're going to launch a validator soon. So how do you first of all think about, like, what's a role? of decentralization in the cosmos hub, is there some kind of metric to measure it? And yeah, how do you see this playing out? Good, tough question. I don't know. Very early on in the development of tenement, I think at least a couple researchers were driven to the brink of insanity by virtue of the fact that, you know, tendermint under the, you know, formal analysis collapses to just two dudes,

right? One with 99% of the stake and one with one percent of the stake. And I have seen minds in the throes of this kind of analysis. And I don't encourage you to go there. But, yeah, it's a hard question. And I don't know the answer. I mean, hopefully the community of stakeholders and, you know, atom holders will cherish and value decentralization. And if they don't, I suspect that there will be some that do

and ultimately, you know, create forks or alternative global hubs where things are a bit more decentralized. Now, there probably are things that can be done in pro-execriles. protocol. I think, you know, these are difficult. There's a lot of discussion around them about what you can do there to really push for it. You're always at risk of, I think to some extent maybe, you know, it's been underestimated the cost of having like independent validator IDs. And so, you know, we could, you could propose things like a cap on how much could be bonded for a particular validator and that would force people with large positions to split their

validator up into multiple keys. And if they're being public with both, then they're publicly, you know, civil in some sense. So I think things like that could be experimented with. I don't know, you know, I'm certainly not going to necessarily vouch for any one solution or the other. I'm interested in seeing kind of what the wheel of the stakeholders really is and the people that have atoms and distributed. And we certainly won't know what it's going to look like until transfers are enabled.

And, you know, a much larger group of interested parties can kind of get involved in this. But it's definitely a threat and it's definitely a little risky. will say this, which is the difference between a service hosted by a single entity and a service hosted by four or seven, you know, 11, whatever it is, even a small number is very significant and very different than what we've ever had before, right? And so even just this moderate amount of decentralization in the short term over some number of entities, especially if they're geographically distributed in different jurisdictions, I think is very significant. And we shouldn't, we shouldn't underestimate the value of even that small level of decentralization.

Of course, hopefully we'll push for much, much more of it over the long term, but it's already extremely experimental and quite unprecedented. And so, you know, I would take some amount of pride in that initially. One solution that I will vouch for is, you know, for how to help push more decentralization. Is this one that Dan Robinson and I and Vitalik have been talking about for a while, a bunch of other people as well, called partial slashing, which is the idea that a, the, the The larger a validator is that faults, the more they get slashed. And then you also take into account there's ways you can design it such that like even

if a validator tries to split into many smaller validators and they all double sign or fault together, they get like slashed even more than if they didn't split. And so you can design incentives where it's like encourages validators like from an economically rational standpoint to help decentralize the network and not put everything. under, you know, into centralized systems. So going further on this topic, this is something that's come up recently and something that we felt it would be a good, good to address specifically because, you know, we're talking to you, Sennie, is, you know, this position of adopting low commissions as a validator.

So your validator has adopted this policy of zero percent commission, and there's been some amount of uproar on social media and on Reddit. In fact, we posted a Reddit post before this episode asking people to ask questions. I think two or three of those were, you know, around this topic. And so in a sort of capitalistic paradigm, one would think that, you know, everybody would tries to bring their fees as low as possible. And then the bigger validers, the ones with the most economic means could out competition the rest of the market or out compete the rest of the market to effectively, you know, lead us to a situation where potentially there's a lot less decentralization and maybe there is just one or two validators. Now, of course, as a decentralized system,

we want to encourage, you know, I think people and validers specifically not to adopt this sort of this sort of policy or this sort of like, you know, zero percent commission. So, we're how do you how do you respond to that and like why did you do this and what's what's the reasoning behind it and you know how do you address that in the context of decentralization and also as a tenderment employee uh i feel that you have a particularly you know bested interest in tenderness succeeding so how do you respond to all this like yeah so sicka we is the name of the validator that's run by myself and dave ojo who's another uh 10ement employee.

We basically decided to start with 0% commission and for the short term, right? Like, so when we, when we announced it, we said we're doing 0% commission for at least one month. And our goal was to help, you know, I think what we saw a lot of commission rates at a lot of the validative set was too high. And I don't think it needs to be that high. Like we saw some validators up at 15%. While I agree, 0% is too low. And so the idea was we want to, you know, both sides to start moving towards each other so we meet somewhere in the middle.

And so I think Sica has been doing this very well where by using this 0% we've already forced a number of validators to reduce their commission. Very few validators have reduced it to 0%, which was never our intention. Our intention was just to force people to reduce it downwards and towards something that we see is more reasonable. And I don't know what the number we see as reasonable is yet. Like, you know, I don't think it should be too much higher than 5% in my opinion. But, you know, that was kind of the goal there. And we'll start to increase our validator, our commission rate there. And then two other things that are kind of relevant here is why are we able to do this 0% commission?

A lot of people have been criticizing us that we're like price gouging or like, you know, we have access to sane in the mind. So like VC capital or something. Like that's how we're doing. We have like zero VC funding or anything. Literally what we have is our validator is running out of the UC Berkeley data center, which, you know, through Don Song, who works on Oasis Lab, she was my advisor at UC Berkeley, and so she got us into the UC Berkeley data center, and we're running our validator out of that, which is why we're able to run our highly secure validator for very low cost. And, you know, I fundamentally don't see this as any different than the miners who decide to mine out of Iceland using their free geothermal electricity, right? You're going to have to expect that the validation market will become, like, competitive and people who can find the most efficient ways of, like, extracting resources will succeed there. And finally, the last thing is, you know, we're also taking a much more longer-term view of the Cosmos network, where the Cosmos Hub is not the only chain in the system.

We're charging 0% on the Cosmos Hub to earn delegation and reputation and like, you know, some name, name branding. And then, you know, within this or next week, we're going to start running a validator for the Iris Hub. And we're not going to be charging 0% commission there. We're going to be charging a commission rate there, a non-zero commission rate there. And we're going to hopefully use our brand that we've been building as like competent, high functioning validators on the Cosmos Hub to earn more delegation on the Iris Hub. Yeah. So, I mean, this is, I think, very interesting discussion. And obviously, I've been involved in the discussion quite a bit. I personally find the arguments super questionable that you're making. Like, for example, if you look at some math here, let's say the cosmos, the added market cap is a billion, which is a lot, right, for the stage of the project. But, you know, maybe it will be there. If you have 5% commission across all the others, it means 5 million revenues across, across all of the validators for paying deep for the entire infrastructure. If you have 100 validators, that's on average $50,000 per validator.

It's not even one job, right? Like, not speaking of running the infrastructure. And then if you have like... Would it be 50 million, not 5 million? No. 5% of a billion is 50 million. No, but you have a billion, right? And then you have, like, let's say roughly 10% inflation per year would be 100 million

revenues paid to all the delegator. 5% commission would be 5 million. split across 100 validator, it would be 50,000. Now, of course, you don't have a uniform distribution of the stake, right? So it basically would mean that, like, you would not be able to have more than 5, 10 validators that maybe could be like financial sustainable. So I think it's now from your guy's perspective, I can totally see the argument. I think it's sort of economically rational, but I think it's extremely negative for the,

for the cosmos ecosystem. I personally think, and now this is a little bit strange because I'm also the interview here, I also think it's totally irresponsible to do it, especially getting like paid by all in bits at the same time as a salary and then doing this by competing with everyone building a network, I think so mess up. Hmm. Okay. I think that, you know, like I said, I have no intention of keeping it at 0%.

And also, that's even more messed up. To do it 0% or tell anybody and then later, like, high up the price. I mean, I think they told people that it was just going to be a month, right? Yeah, and I told people that whenever we raise the prices, we are going to give at least one unbonding period's worth of notice. So people will have three weeks, and if they don't like our announced pricing commission rate increase, they can instantly redelegate away and be out of us completely 100% before we ever increase our prices. And then also, using the numbers you said,

this is like taking a very short-term view of the network. Keep in mind, Adam Inflation is not even meant to be a reward for the validators. It really was designed to be a system just to punish people for not staking. The real long-term reward in the Cosmos Hub system is going to be the fees that you earn from the system. And yes, I understand that right now, the fees are essentially negligible because the system is brand new. But like, you know, people were doing this in the early days of Bitcoin. People were mining off of the faith that, like, these things will one day be valuable. And this is kind of what we're asking the validators to do as well.

Have some faith in the system and believe that, like, you know, at some point, the usage of the system and the fees will be enough to, like, pay for the services that you guys are providing. Okay. Well, I think this is a discussion that, you know, is probably best continued in some other contexts as well. But so let's, let's move, so, you know, we're running pretty late already, but let's move briefly to the, you know, Cosmos SDK and IBC, especially Cosmos SDK, which, you know, I think is, you know, it's a key part of the Cosmos project into kind of the value proposition. So, Bucky, do you mind going through, like, what's the vision of Cosmos SDK into utility of it? Sure. I think maybe to really understand that, you know, from a lower level, if you're already familiar where Tenderman, it helps. just talk briefly about the tenement ABCI. So, you know, tenement was designed in such a way to abstract the state machine from the replication engine.

So when we talk about blockchains as replicated state machines, you have a state machine, you have the replication piece, which is all the, you know, the peer-to-peer, the consensus, etc. And so what we did was we invented this interface that we called the ABCI, the application blockchain interface, that abstracts away all the concerns of the state machine from the underlying replication engine. And that enables you to build your state machine in any programming language you want, to use existing code, you know, to architect it, however you like. It runs in a separate process on the same machine, on a different machine, kind of doesn't matter. So there's, you know, tremendous flexibility there.

And I think that's been part of why Tendermint, core, the software, has been so, you know, so widely adopted. But when you're building directly over ABCI, it's quite a low-level interface, right? And so there are a lot of concerns that you have to kind of keep in mind and take care of things like concurrency and state management and the structure of your modules and all this stuff. And what we realized is we had built a few different applications and Go to kind of test this out, that there were a lot of common elements there that all these applications shared.

And so what we did was we created another layer of abstraction to really simplify all those concerns so that you could now build more directly just the key pieces of your state machine without having to think about any of this ABCI stuff. And so the Cosmos SDK was really designed, as a framework for building applications in Go on top of tendermint, right? So for building state machines on top of tendermint.

And the way it's structured, it kind of comes in these layers, right? And so the lowest layer, it's called Base App, is a very, it's really a thin wrapper around the ABCI that gives you this kind of, you know, very flexible approach to how you should think about the state that you're storing in your state machine and, you know, how transactions are going to, are going to, access that state or manipulate that state. And this is where the key design principles of the

Cosmos SDK, of object-based capability security come in, where the idea is that things are only going to get access to the store if they're given an explicit capability that enables them to access the store. And so kind of the whole model of the base app is designed like that, but the base app is still flexible enough that it doesn't force a particular serialization algorithm, it doesn't force a particular Merkel tree doesn't force, you know, any notion of coins or anything like this. It's very, very general purpose building a state machine on top of the ABCI using this object capabilities-based approach to accessing your state, right? And then from there, there's this next layer, which is, you know, the actual, what a lot of

people know is the CosmosS SDK, which are all the kind of pieces of like the coins and the anti-handler and this particular way of structuring transactions and having, you know, certain kinds of signatures and nonces and fee collection and all this kind of stuff, which the Cosmos Hub was ultimately built on, right? And a lot of other things that, you know, maybe they won't look the same as the Cosmos Hub, but they'll still use a lot of this same structure for what transactions are like and how they're serialized and so on. But the end of it, so that's, that's kind of the, a lot of the pieces that you would need to actually build, you know, a cryptocurrency or a cryptocurrency system. And then on top of that, then there's the next layer, which are the actual

the modules, right? And that's where all the really custom logic for executing your transaction comes in. So after you've done, you know, all the authentication stuff, you make sure, you know, people have enough to pay their balance and they sign their signatures and so on, then you want to actually get into the meat of your application logic, and that's where the modules come in. And so, you know, for the Cosmos Hub, there's a certain set of modules that are, you know, that define the governance of the Cosmos Hub and the proof of stake and the slashing and the fee distribution and so on. But if you're building another, you know, a different kind of application, you could choose a different set of modules.

So you can still inherit everything underneath, so the same kind of transaction format and all this kind of stuff, but you can start to define more specifically the messages, the message structure, and the kinds of state transitions that are involved in your application, and so on. And to the extent you want to use the same governance or the same proof of stake module, you can.

To the extent you want to change those, you know, you can as well. So again, the SDK is really this kind of general framework for building cryptocurrency style, machines on top of tendermint where there are multiple layers at which you could enter, depending on kind of what you want to inherit and how much flexibility you want to retain. Cool. Now, one question that people often have is, you know, the difference between substrate, which is a kind of similar framework developed by the parody team and Cosmos SDK. What do you think are the look at the main differences here?

I haven't gotten too much time to play around the substrate yet. I've poked around it a little bit. And, you know, it seems that, you know, a lot of the design ideas are actually generally very similar. Like, they're using a similar idea of modules and, like, different transaction types and stuff. And really, at the end of the day, I think it's really just going to come down to people's preferences for programming language, where substrate is written in rust. And, you know, if you want to build your state machine, you have to do it in Rust while the Cosmos SDK is in GoLing. And, you know, we have another framework that was also built by some engineers who used to be at All InBits and now have spun off into their own company called Nomic called LotionJS, which is a JavaScript-based SDK, essentially. And so essentially, you know, the idea is that we want this, like, diversity in frameworks. In fact, there's actually now the fourth one called Weave, which is, uh, Bucky mentioned like a while back ago that, like, you know, we had an old version of SDK,

V1 and we kind of scrapped it and started writing SDKV2. Well, one of our ex-engineer has actually really, really liked SDKV1, and he actually kind of went ahead and kept maintaining it and kind of turned it into its own standalone SDK called Weave now. And so, you know, the idea is that we want all these different frameworks in the Cosmos ecosystem, whether it's the Cosmos SDK, Weave, lotion, substrate, and give developers the opportunity to like use whichever one they feel most comfortable. with and it's really going to mostly come down in my opinion to the programming

language I think that you know in my personal opinion I think Rust is a little bit too esoteric for most developers while JavaScript is maybe a little bit too loose and I think go hits this like nice little middle balance between like you know security especially with our object capability system that we design along with ease of use and ease of access to developers like you know I learned go in like two days it's it's really easy programming language to pick up as if you have like basic programming experience. And so and you know the real goal would be is we want to implement IBC in all of these different frameworks. So right now we're working on it

in SDK, but you know, we're going to have it implementations in all of these different frameworks. Yeah. So that that does bring us to the next topic that, you know, maybe you can briefly cover. I know it's in its very beginning, but Bucky, I know there's some work starting around IBC. So what's, you know, what's the current status on IBC? and like what does the IBC roadmap look like? So, I mean, there had been past specifications of IBC and past kind of prototype implementations that were running on testaments and so on.

What's happening now is we're kind of taking a step back from all of that and trying to really split the IBC spec apart into all of its constituent pieces and really for each piece define, you know, what it is, what are the properties at this layer, you know, what are the requirements to satisfy, you know, these particular needs and so on. And so you can follow all this work in a GitHub repository.

It's GitHub.com slash cosmos slash ICS. That stands for interchange standards. So Cosmos slash ICS. And you'll see there, you know, a large number of issues. They're each numbered like ICS number three, number four, et cetera. And each of these kind of corresponds to a different component of the IBC layered stack, right? And so activity there is really starting to ramp up. we're also hosting a bi-weekly meeting with a larger group of members from the community who are interested in participating in the IBC discussion.

What we'd really like to ensure is that, you know, IBC is defined in a very general purpose way and has a, you know, a specification that really focuses on, you know, some of the key data types, but also kind of the properties and the requirements of the protocol, so that it becomes very easy to implement it in many different languages. And we have intention, at least, you know, right out the bat to implement it in three different languages and Go and Rust and in JavaScript and to have those implementations actually pursued by three distinct teams. And so we're working, you know, both the Interchange Foundation is working on implementation in Rust. All the Bids is working on one in Go. You know, we're trying to work with the Agoric team on one in JavaScript and also the NOMIC team who has pieces of it already in JavaScript. And so, you know, we're really trying to make sure that we don't. say overfit the design of IBC to a particular state machine or to you know particular needs and that it really stays generic enough to suit the needs of a

large number of stakeholders who are looking to have their state machines interoperate you know in this larger cosmos interchained vision and so if people want to follow that again github.com slash cosmos slash ICS if you're interested in in the biweekly call I actually don't know the best way to find it but it is all you should be able to find it from the repo it should be able to join publicly. And so that's moving along. And hopefully, you know, we hope to have MVP, at least of the spec, you know, in the next few weeks. Of course, I'm going to start making estimates. So you shouldn't listen to my estimates because they're almost certainly wrong.

But, you know, hopefully IBC will be in a place where we could actually shit something to the Cosmos Hub, you know, this year. You know, beyond that, more refined timelines are really hard to give. Obviously, we want it as soon as possible because that's, you know, really what's necessary to realize the cosmos vision, but we want to do it right. We want to make sure the specification is written quite formally and is very clear and is amenable to implementation in multiple languages. So why should someone choose to build their DAP or their application on Cosmos rather than Ethereum?

Well, potentially a lot of reasons. So if you want direct interoperability with the rest of the Ethereum ecosystem, then obviously you should build on Ethereum. If you want to subject yourself to immense development pain in using solidity and debugging your solidity contracts and so on, you should develop on Ethereum. If you want to subject yourself to the whims of the Ethereum governance and to Ethereum's fee system and mechanism and, you know, proof of work mining and all this stuff, then you should develop on Ethereum.

If you want kind of independent sovereignty and if you want to use a mature programming language that you've been building in for a decade and has mature debugging tools and testing and all this stuff, then Cosmos is probably right for you. So you mentioned the Interest and Foundation, and so this is the foundation that, like the fundraiser, do you talk about the role of the foundation moving forward with regards to Cosmos and tendermint and like all these different projects and organizations gravitating around Cosmos?

Yeah, so, you know, the, foundation was set up in early 2017. It did this fundraiser. It has been the primary source of funds for, you know, many of the folks kind of involved in developing, you know, key elements of the Cosmos Hub and pieces of the Cosmos Network. I think now that a number of organizations are kind of standing on their own two feet in the sense that they've managed to raise venture capital investment, so that includes all in bits, but it also includes a number of other entities are starting to see staking companies, you know, raise VC money and so on, a lot more attention is starting to turn to, you know, building up the Interchain Foundation

and building up teams there and ramping up the granting program and so on. So right now, really the focus there is on this granting program, so you can find it on the website, interchane.io. You can apply for funds. So we're looking to, you know, in the short term really deploy capital, deploy funds from our treasury, which has been, I think, reasonably well managed over the last couple of years to really, you know, grow the ecosystem and see, in the short term, to see kind of the immediate needs be developed. So, you know, IBC for sure, certain other application frameworks, bridges, things like, you know, a bridge to the Ethereum network, things like Etherment, which are, you know, the Ethereum state machine running on top

of tendermint in a way that's compatible with the Cosmos network, you know, certain certain wallets and block explorers and so on. So really kind of growing the set of applications and frameworks and developer tools and all this for building, for building, you know, out the cosmos ecosystem. The foundation is also starting to focus on some R&D as well, kind of a little internally. So, you know, as I mentioned, the foundation is going to take on the implementing IBC in Rust to kind of complement AIB doing it in Go and others in JavaScript and hopefully others in other languages too. and so we're looking at higher rust developers for that.

We're also building out the research team there, and so we're starting to focus in really on formal verification of hopefully all of the protocols in the stack, but really I think starting from tendermint, starting from the lowest layer and kind of working our way up and to help really ensure the correctness of the software and to enhance our ability to test it and really build confidence in the software,

both for the Cosmos Hub, but also for all the many other blockchains that will be building on tendermint and then hopefully we'll be able to turn our attention to actual protocols in the state machine in the way staking works and governance and so on and try to move the bar on formally verifying things there. You know, in the long term for the foundation, I think we'd like to figure out what sustainability really looks like for a non-profit.

I think that's something that hasn't really been addressed in this space. You know, a lot of foundations are sitting on, you know, a huge stock of capital and feel like their only job is to appreciate the value of the assets they sit on. I think that's maybe a little bit of, you know, kind of a naive view and kind of the thinking that got us into, you know, peak oil crisis and stuff like that. It's like, oh, we have all this stock. Now we can just spend it. It's like, no, we kind of need to figure out sustainability.

And the sooner we do it, probably the better. So we're starting to think about what that looks like. But we don't really know yet. So, you know, we're eager to hear what people think. And, you know, we're building out there. and hopefully there'll be a lot more to say from the foundation in the short term. But really the focus is on funding, you know, building out the community and having, you know, really having strong, independent members of the larger Cosmos ecosystem that can

really take responsibility for, you know, operating the network and developing things on it and so on. Yeah, cool. Well, thanks so much, guys, for coming on. It was great, you know, diving into Cosmos. I'm sure this is going to be something to revisit and lots, lots more to do. discuss, especially as actually interoperability is going to, you know, start to happen, right? And we'll actually start to have, you know, multiple interconnected blockchains and a whole new

world of, you know, what blockchains look like and blockchain networks look like, I think will start to emerge. So thanks so much for coming on. It was a pleasure. Thanks for having us. Thanks for having us. 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. on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts. And if you have a Google Home or Alexa device, 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. Thanks so much, and we look forward to being back next week.