**A** (0:14):
This episode of Epicenter is brought to.
**B** (0:16):
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 Ms. Epicenter.
**A** (0:38):
Hi, welcome to Epicenter. My name is Sebastian Couture.
**C** (0:41):
And my name is Ran Rabbenkray. So today we're gonna have Ethan Bachman on and son Yagarwal. Ethan is the co founder of Tenement. He's also a vice president of the Interchain foundation. And of course Sunny is co host with us at Epicenter 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 co host of EP center as well as an employee at Tendermint and he's also running a Cosmos validator. So please be aware of that. Then when it comes to myself, I obviously I used to be an employee at the Tenement company as well. I also hold Atoms 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 correspondent 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.
**A** (2:01):
Another thing I would point out is that I also hold atoms and I've been very closely following the Cosmos project and Corus one. So I have some insights there and so should also want to apologize about some of the noise. So there was a little bit of concern construction going on in Sunny's vicinity. So hopefully we'll get some of that out. But apologies for that background noise. So without further delay, here's our interview with Sunny Aggarwal and Ethan Buckman. So we're here today with Ethan Buchman and Sunny Agrawal. Ethan is the co founder of the Cosmos and Tendermint projects and Sunny is research scientist at All In Bits, which is the parent company of Tendermint and is also a host here on Epicenter. Hi, guys.
**D** (2:48):
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.
**E** (3:00):
Yeah, good to be back. Thanks, guys.
**C** (3:03):
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 a few minutes just giving a high level introduction. So maybe, Ethan, what's the vision of Cosmos and how would you describe Cosmos?
**E** (3:38):
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 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 enabled this interoperability between many existing networks and networks that were still to come, the idea with Cosmos is to be the kind of interchange, so the interoperability layer between existing blockchains and the many new blockchains to come. And as sort of part of that, not only is the goal of Cosmos to define these kind of interchange standards, but also to define more modern and mature approaches to actually building the individual chains 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, and then of course ibc, which is the key kind of interoperability piece that enables these different blockchains to actually communicate with one another.
**D** (4:42):
Yeah, really, it was like, meant to like, kind of. We see it as this 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 to 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 Turing complete VM1 chain to rule them all kind of system. So in like the first generation we had Bitcoin and Namecoin and SIA 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 DNS, etc. 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 0x to buy some dai, 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 one, 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 plus plus, very difficult to reason about. The consensus is kind of intermingled with the state machine, intermingled with P2P, especially post segwit. And so like Ethereum solidity, it's like, you know, solidity is not the nicest language in the world, but it's definitely, it was, it was, it's way easier for people to write applications than, than forking the Bitcoin code base. But you know, and so I, I, you know, I like this like analogy to compare it to like the history of like human development which is, you know, if 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 user, on its citizens, just a lack of social scalability and like 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 don't have, 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.
**C** (8:12):
So to 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?
**D** (8:32):
Bucky can probably answer this a little bit better because you know, he was there around back when it was started. But you know, from, from the, I've been involved with the project in only for, only about a year and a half now or close 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, it's adapted. Looking at some of the changes in the blockchain space, especially, you know, Cosmos or the Tendermint project kind of started almost simultaneously with Ethereum and so on. 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.
**E** (9:16):
Yeah, I think, 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, that's right, and that's fine. We want these blockchains to have kind of independent state machines that are defined 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, the kind of easiest, lowest hanging fruit was, okay, we could define token transfers between these change. But in the long term, if we define things well enough and with advances in cryptography and crypto economic design and so on, you know, we could do more general purpose data exchange. And so that, that kind of high level vision really hasn't, hasn't changed at all. I mean what, what has changed is the particulars of the implementation detail as the, you know, as, 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, has been relatively the same and I hope is actually grounded in a kind of timeless approach to building, 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 about it. I mean, the Cosmos white paper had no 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, have stayed quite stable.
**A** (11:09):
So Sunny, you mentioned this idea of third generation blockchain and I think it's safe to put a project like Polkadot 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 Polkadot, can you describe the fundamental philosophical differences between Cosmos and Polkadot?
**D** (11:36):
Sure. So I think, I would say one of the main primary philosophical differences between Cosmos and Polkadot 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 interoperate 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. We, well, Polkadot takes the approach where it kind of does shared security by default and that's kind of what they really focus on, where they kind of say that there is this one root relay chain and then all these other chains are going to be just like shared secure using the validator set of that relay chain. And then they have the concept of connecting to other chains, but using bridge zones. But, but that's really not like by default people use the relay chain while 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 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.
**A** (13:07):
Okay. I mean, the way I see Polkadot in that respect is I see it as sort of this validation as a service for blockchains. 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 to 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 people will ask and will require of Cosmos at some point the market and the ecosystem will want as a functionality?
**D** (14:00):
Yeah, totally. I think that this is like 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 Polkadot to the Cosmos Network, Cosmos interchain idea, Cosmos Hub versus Polkadot is really a more salient comparison. And then 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 Polkadot design. And so I've discussed it with a lot of the Polkadot dev teams and we're both aware of each other's shared security designs. And maybe if you want, we could 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 project and that is one of the primary services that the Cosmos Hub will provide to the Cosmos interchain network.
**A** (15:02):
And what about Ethereum then, 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 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?
**D** (15:23):
Sure. So Ethereum still takes very much a single vm, like single state machine. Everyone has to use the evm. And really the problem with that is it suffers from a lot of, it's going to suffer from a lot of governance issues where people are going to basically have 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 we already see this where there's hundreds of EIPs that are open in the EIP repo the Ethereum improvement proposals and some of them are contradictory and some people want state ren some people don't, some people want X, some people don't. There's so many different design requirements. The problem with during 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 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.
**B** (16:59):
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 have you covered. You already know about the Azure Blockchain workbench and how easy it makes bootstrapping your blockchain network preconfigured 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 a remote location via SMS and have 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. Epicenter and be sure to follow them on Twitter SFTBlockchain. We'd like to thank Microsoft and Azure for their support of Epicenter.
**C** (18:16):
So the Cosmos project has been in development in some way or another for a long time. Tendermint, I think, was originally started in 2014. Now, just a few weeks ago, we finally had the launch of the Cosmos Hub. So congratulations. Of course, it did take a little bit longer than announced. Like, 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?
**E** (18:48):
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. 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. Quite a decentralized start, actually. And then arguable how you look at what's happened since then. But I think we're quite excited about the fact that it's live and it's working and 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. 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, 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 Cosmos SDK. The Cosmos SDK wasn't part of the white paper. It wasn't really part front and center of anything. But we realized, kind of as we were going, that 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 doesn't lock into any Particular serialization algorithm or Merkle Tree structure or any of the things like this. And prior to that we kind of had some kind of a framework, it was called basecoin at the time for a while and that was working. We had testnets with that running and staking and IBC even before the fundraiser in 2017. But the kind of design process for the Cosmos SDK kind of reset things and we started working on a new model 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 Ethernet 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, 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, the most complicated kind of proof of stake state machine in existence today, especially with regards to 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 many thousands, if not hundreds of thousands or millions of delegators across maybe 100 or a few hundred validators. So getting all that to work and you know, we, we scrapped our fee distribution twice. You know, we, we first had a, a pretty complex one. We scrapped that and did a simple one, and then we scrapped that and did a, you know, a different one. But now, you know, things are a lot more mature and stable and we have nice specifications for a lot of it. But I, 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 really only evolved over the course of 2018. Right. And then of course there operational constraints, coordination constraints. We have quite a distributed team from San Francisco to Berlin, all the way to Asia at points. San Francisco and Berlin pretty much don't overlap at any point in business hours. So coordinating it can be very difficult. We launched various programs, we iterated through the test nets and there's a lot of kind of operational overhead to that into game 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.
**D** (23:50):
So I actually have a chart in the Berkeley office that kind of match this, like estimated time to launch. And they're just sort of hovering around two months mark for a good eight months.
**A** (24:01):
That's funny.
**E** (24:02):
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 we didn't launch the Cosmos Hub until. I shouldn't say we. The Cosmos Hub didn't launch until a couple weeks ago, 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 for instance, the IRIS Net launched, I think a month or two before the Cosmos Hub did, and tendermint has been used in production for quite some time now. This approach of doing everything in a quite modular fashion and trying to make the pieces as useful as possible in the interim, I think really helped build the community and develop the ecosystem and the expertise around it. And until we got to the point of actually launching this mainnet Cosmos Hub. And so I think that was really valuable for us and kind of helped continue the momentum. And despite the fact that the Cosmos Hub hadn't shipped, 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 have been running in production for some time. So I don't want to neglect that.
**A** (25:17):
Yeah, of course, obviously we're all very excited when the launch happened. And so months before launching there was this game of stakes which was sort of like, I guess like a glorified test net where things were happening kind of in production. And 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 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 what you learned from this experience that allowed you to launch the network then so successfully and so far? Flawlessly, I guess.
**E** (26:11):
Sure. So 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 proof of stake 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, 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, how mature they were going to be. And so we started to put some real effort into building the validator community and the TestNet community. And I think to a significant extent this was really spearheaded by Adrian of Cryptium, who was working with us at the time. He really got the ball rolling on this, which was really nice. And it picked up far beyond him very quickly and really became like a self sustaining community on its own of kind of running testnets, 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 bugs and failures. There were lots of halts, lots of things went wrong where people would have to restart the whole network and do that in a decentralized way. 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 in learning how to operate and building this sense of community. But with respect to Game Mistakes, the other piece 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, didn't have any atoms. You know, they didn't participate in the fundraiser in any, you know, at all. Maybe they didn't even know about Cosmos at the time. And so, you know, 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, some of the most competent or experienced network operators actually wouldn't be able to participate at launch. Right. And so this is where we kind of cooked up the idea that, well, maybe we can build some kind of incentivized testnet competition where the people who are really participating and really demonstrate their competence can actually be rewarded with some atoms in the Genesis block, a recommendation for atoms in the Genesis block. And so that if the network starts with that recommendation, they'll be there on day one and they'll be able to start to participate. And that was extremely well received. We had a lot of support for that. A lot of people participated in the game of stakes. And some of those people who, you know, or some of those validators who received, you know, Atom recommendations in the Genesis block, you know, were 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 testnet program and weren't going to be able to participate at launch, would actually 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 stake 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 address these kinds of issues.
**C** (30:10):
And so yeah, just briefly weighing in here because now of course one had. So we participated of course in this game mistakes and we had an incredibly also stressful and intense Christmas because of that. Because I think we had participated in these testnets for quite a while before but 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 a major issue. So then having building up systems to have automated phone calls and on call schedule and all of that stuff. And initially it started just before Christmas and then it halted a bunch of times and then restarted. 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, of validators we've 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.
**D** (31:18):
Yeah, totally. And the other thing that it also did, like you mentioned was a lot of the halts in the during game mistakes were due to like bugs in the software. And so another thing game mistakes really did was it allowed us to have a good process of like test testing all sorts of behavior on the state machine and all the validators were trying like different functions and like doing like 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 it, we have like we said we haven't had any bugs knock on wood like yet on mainnet. The other thing that gamer 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% 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, 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 pitch that we're saying, oh, we're testing proof of stake actually degraded the improving of people's security. So because you'll notice that for example, my validator Sitka, 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 hotkey with an auto bond script. And so I think that like, you know, having that like testing or 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 testnets like this, I think these are some of the things that they should be thinking about really focusing on the security of the validators.
**E** (33:28):
Yeah, that's a really great point. And I mean partially to show that we can do these kinds of experiments and they can be successful. But I think to Sonny's point, they really should clarify what in particular they are testing and not try to conflate too many things at once. Part of the excitement that I always had around the blockchain space was that we can really start to test 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 mistakes, we kind of got a few things, I guess, confounded in that. On 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 Sunny was saying, you know, auto, 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 Mainnet and if you look at significant amount of the transaction activity is some of the validators just like constantly withdrawing their rewards and rebonding. Maybe that's a problem with the architecture of the system, that the rewards aren't automatically bonded and 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.
**D** (34:48):
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 like 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 Cosmos hub is.
**C** (35:07):
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, Tezos 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?
**D** (35:43):
Sure. So the on chain governance process of Cosmos is a little bit complex and it's like not, it's, 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 Tezos or Polkadot kind of say. So in Tezos and Polkadot like you know, they have like a sort of 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, coin holders 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 the 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 all 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, the Ethereum for example has the carbon vote but it's not this like official thing. It like the UX 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 be 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 it 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 or 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 coin holders is not actually is not. This is really less of a governance and it's more of just a coordination system of when to update 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 miners 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 you know, 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 ca, 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's relative, the Cosmos Hubs relatively conservative governance system.
**C** (39:53):
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. 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?
**D** (40:22):
Yeah. So 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 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 activating transfers is ready. But the way that that second governance proposal was kind of framed, it was framed in a, in a, 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 in bits 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 no that actually for, 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 Tendermint the company could like do anything they want and like we could, we could change the state machine to like do you know, do anything we want, 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 set good precedent that the community was like wary and skeptical of us. And so now in the past few days that 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.
**C** (42:20):
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 vote 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, we'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?
**E** (43:09):
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 guarantee, I mean it's kind of double edged on the, on the voter turnout question because on the one hand by having the automated, 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 stakeholders 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, it really depends on, it depends on who the delegators are and what, what they care about and you know, how technical they are and how, 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 encourage the community to be such that such retail investors aren't really the primary holders of atoms. 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 of this technology and the network. And 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 validator. Right. So building businesses and, you know, putting up zones and all this kind of other stuff on top of Cosmos. But so I think there is, 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 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, if from a certain other analysis or perspective, it might make sense for those things to be the same.
**D** (45:44):
It doesn't even necessarily have to be to another validator. It could be just to another user account as well.
**E** (45:48):
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 that makes sense and that kind of works and let it evolve from there according to the stakeholders and the users of the network. So it'll be very interesting to see how the governance really evolves from here.
**A** (46:16):
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 some sort 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 and encouraging participation. Now it might be that you have all these functionalities and these features that allow you to delegate, et cetera, but that in reality, maybe two big whales are. Only two big whales are actually coming in and making decisions on important proposals to the network. And if at some point 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 that could potentially pose a risk to a lot of users. One idea that 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, never surpassed 50%, and in recent elections we've seen even less than that?
**E** (48:05):
This is a really hard question, and I don't know that any of us are going to be able to give 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. You know, 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, you know, and part, again, part of the vision of Cosmos was really this sovereignty and this, you know, 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 larger meta perspective of giving people the tools to run blockchains and to engage with them and govern them, I think that will hold a lot of promise in this question about how do we build actually engaged communities and stakeholders that participate. But I think it's also still an open question for us as civilizations and societies how we build these kinds of institutions where there is democratic engagement, 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 of 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 as like, or some of these blockchain networks as 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 the closer that the actual state machine of the blockchain is to the particular stakeholder, the more likely they're going to pay attention and they are going to vote. And so this kind of thinking, I think, has been paramount in our design decisions to encourage this proliferation to not have the kind of shared security by default, but to have 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 and so that they will turn up. And I think asking the question of 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, 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.
**D** (50:54):
Also a couple of weeks like earlier on in like the Cosmos Hub development process, we actually had it so that if you like, you know, if a validator doesn't vote, they actually got slashed. But then 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 blockchains 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, 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 sub keys which will allow you to like basically designate one key as like 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 and 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 already support governance. And so once we have these sub keys, you can keep those keys on your phone and be able to vote. You know, we'll make it like fun. Like, you know, when you see another Cosmos holder, atom holder, be like, hey, have you voted on the proposal yet? And like, you know, you know, we got to encourage people to be part of it and make it easier and more secure for people to do it as well.
**C** (53:00):
So we've spoken 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.
**E** (53:16):
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, and getting the engagement. There kind of holds for the larger space of mechanism design and you know, all the kind of 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 humans, 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, it might not really, might not really take shape the way you expect. And 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 and think, thinking about blockchain design and so on. So anyways, from the perspective of validators, I mean, I see, I would, I'm very interested in. This is a much, this is a long term perspective. So I'll just give it to you like that. I'm, 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 not, sorry, not a red herring. It's the elephant in the room. Get my analogies, my idioms mixed up. The elephant in the room when we talk about decentralization is that 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, validator, like proof of 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, in a data center. It was actually I found this quite touching the other day I was, 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? I thought that was, 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, you know, sovereign, independent blockch that are all kind of interoperating kind of takes a, to a significant extent like a geographical orientation so that, you know, certain zones actually are based locally, geographically and you know, traditionally that's how, 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, you know, reset the Internet infrastructure on top of that kind of thing with validators. Now in the short term, what's the role of the validator? You know, 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 valid, 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, doesn't just offload everything to some other, you know, tech provider. And I think those are interesting questions and challenges for us to address over the coming years, decades.
**C** (57:43):
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 the decentralization. And of course we do have, let's say, for example, polychain. So there are some of these funds with massive positions. There's an expectation that exchange is going to come in and in some other systems they've also, like in eos for example, I think they've accumulated massive power. Coinbase custody is they're going to launch a validator soon. So how do you first of all think about, like, what's the 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?
**E** (58:29):
Good. Tough question. I don't know. You know, very early on in the development of tendermint, I think at least a couple researchers were driven to the brink of insanity by virtue of the fact that Tendermint, under the formal analysis, collapses to just two dudes, right? One with 99% of the stake and one with 1% of the stake. And I have, I have seen mines in the throes of this kind of analysis and it's, it's. 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, 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 protocol, I think, you know, these are difficult. There's a lot of discussion around them about what you can do there to really, 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 don't, you know, so, 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, any one solution or the other. I'm interested in seeing kind of what the will 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. But I will say, I 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 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 I would take some amount of pride in that initially.
**D** (1:01:02):
One solution that I will vouch for is 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 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 even if a validator tries to split into many smaller validators and they all double sign or fault together, they get slashed even more than if they didn't split. And so you can design incentives where it's like encourages validators from an economically rational standpoint to help decentralize the network and not put everything under into centralized systems.
**A** (1:01:50):
So going further on this topic, this is something that's come up recently and something that we felt it would be good to address, especially specifically because we're talking to you, Sunny, is this position of adopting low commissions as a validator. So your validator has adopted this policy of 0% 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. And I think two or three of those were around this topic. And so in a sort of capitalistic paradigm, one would think that everybody would try to bring their fees as low as possible. And then the bigger validators, 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 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, I think, people and validators specifically not to adopt this sort of policy or this sort of 0% commission. So how do you respond to that and why did you do this and what's the reasoning behind it and how do you address that in the context of decentralization? And also as a Tendermint employee, I feel that you have a particularly vested interest in Tendermint succeeding. So how do you respond to all this?
**D** (1:03:39):
So Sitka is the name of the validator that's run by myself and Dave Oja, who's another Tendermint 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 that a lot of the validators 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 both sides to start moving towards each other, so we meet somewhere in the middle. And so I think Sika has been doing this very well, where by using the zero percent, we've already forced a number of validators to reduce their commission. Very few validators have reduced it to zero percent, 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, say 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 through Dawn 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 are 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.
**C** (1:06:30):
Yeah, so I mean this is I think very interesting discussion and obviously I've been involved in discussion quite a bit. I personally find the argument super questionable that you're making. Like for example if you look at some math here, let's say the Cosmos, the Atom 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 validators it means 5 million revenues across all of the validators for paying for the entire infrastructure. So 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.
**D** (1:07:11):
And then if you have 5% be 50 million, not 5 million, no, 5% of a billion is 50 million now.
**C** (1:07:19):
But you have, 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 delegated 5% commission would be 5 million. Split across 100 validator would be 50,000. Now of course you don't have a uniform distribution of the stake, right. So basically would mean that like you would not be able to have more than 5, 10 validators that maybe could be like financially sustainable. So I think it's. Now from your guys 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. And I personally think, and now this is a little bit strange because I'm also the interviewer 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.
**D** (1:08:17):
Okay, I think that, you know, like I said, I have no intention of keeping it at 0%. And also, well, that's even more messed.
**C** (1:08:27):
Up just to do it 0%, not tell anybody and then later like hike up the price. I mean, I think they told people.
**E** (1:08:35):
That it was just going to be a month, right?
**D** (1:08:36):
Yeah, yeah. And I told people that if I, 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, like this is like taking a very short term view of the network. Keep in mind atom 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, the fees will be enough to like pay, pay for the services that you guys are providing.
**C** (1:09:48):
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 move. So you know, we're running pretty late already, but let's move briefly to the, you know, Cosmos SD and ibc, especially Cosmos SDK, which I think is a key part of the Cosmos project and the kind of value proposition. So Bucky, do you mind running through what's the division of Cosmos SDK into utility a bit?
**E** (1:10:16):
Sure. I think maybe to really understand that from a lower level, if you're already familiar with Tendermint, it helps. Just talk briefly about the Tendermint abci. So Tendermint was designed in such a way to abstract the state machine from the replication. 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 call 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 tremendous flexibility there and I think that's been part of why Tendermint core the software has been so widely adopted. But when you're building directly over abci, it's quite a low level interface. 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 in 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. The Cosmos SDK was really designed as a framework for building applications in go on top of tendermint. 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 is 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, you know, the key design principles of the Cosmos SDK of object based capability security come in. Where, you know, the idea is that things are only going to get access to the store if they're given, you know, 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 you can, you know, it doesn't force a particular serialization algorithm, it doesn't force a particular Merkle 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 as the Cosmos 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 certain kinds of signatures and nonces and fee collection and all this kind of stuff which, you know, 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 the same structure for what transactions are like and how they're serialized and so on. But that, and so that, 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, 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 can as well. So again, the SDK is really this kind of general framework for building cryptocurrency style state 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.
**C** (1:14:55):
Cool. Now, one question that people often have is the difference between Substrate, which is a kind of similar framework developed by the Parity team, and Cosmos SDK. What do you think are the main.
**D** (1:15:08):
Differences Here I haven't gotten too much time to play around with 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 Golang. And you know, we have another framework that was also built by some engineers who used to be at all in bits and now have spun off into their own company called nomic, called lotion JS, 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 Bucky mentioned like a while back ago that we had an old version of SDKV1 and we kind of scrapped it and started writing SDKV2. Well, one of our ex engineers 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 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 do design along with ease of use and ease of access to developers. Like you know, I learned go in like two days. It's really easy programming language to pick up 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.
**C** (1:17:28):
Yeah, so that does bring us to the next topic that 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 the current status on IBC and what does the IBC roadmap look like?
**E** (1:17:46):
So I mean, there had been past specifications of IBC and past kind of prototype implementations that were running on testnets 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, what are the requirements to satisfy these particular needs and so on. And so you can follow all this work in a GitHub repository. It's GitHub.com cosmos ICS that stands for interchange standards, so Cosmos ICS and you'll see there 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 IVC layered stack. Right. And so activity there is really starting to ramp up. We're also hosting 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 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, you know, is working on implementation in Rust, Alden Bits is working on one in Go, you know, we're trying to work with the agoric team on one in JavaScript and also the Gnomic team who has pieces of it already in JavaScript. And so, you know, we're really trying to make that, 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 Interchange vision. And so if people want to follow that again, GitHub.com cosmosics if you're interested in the bi weekly 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 and should be able to join publicly. And so that's moving along and hopefully we hope to have MVP at least of the spec 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 ship something to the Cosmos Hub, you know, this year. You know, beyond that, more 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.
**A** (1:20:42):
So why should someone choose to build their DAPP or their application on Cosmos rather than Ethereum?
**E** (1:20:51):
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, you know, 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, you know, 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.
**A** (1:21:37):
So you mentioned the interest gen foundation, and so this is the foundation that led the fundraiser. Can you talk about the role of the foundation moving forward with regards to the Cosmos and Tendermint and all these different projects and organizations gravitating around Cosmos?
**E** (1:21:56):
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 bits, but it also includes a number of other entities we're 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 Interchain 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 years to really grow the ecosystem and in the short term to see kind of the immediate needs be developed. So IBC for sure, certain other application frameworks, bridges, things like a bridge to the Ethereum network, things like Ethermint, which are 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, on some R and 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, you know, we're looking to hire Rust developers for that. We're also building up 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 lower, lowest layer and kind of working our way up to help, you know, 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 we'll 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 in the long term for the foundation. I think we'd like to figure out what sustainability really looks like for a nonprofit. I think that's something that hasn't really been, hasn't really been addressed in this space. You know, a lot of people, a lot of foundations are sitting on 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, kind of a naive view and kind of the thinking that got us into peak oil crisis and stuff like that is 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, probably the better. So we're starting to think about what that looks like, but we don't really know yet. So, you know, if we're eager to hear what people think and, 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, 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, and developing things on it and so on.
**C** (1:25:32):
Yeah. Cool. Well, thanks so much, guys, for coming on. It was great diving into Cosmos. I'm sure this is going to be something to revisit and lots, lots more to discuss, especially as actually interoperability is going to start to happen. Right. And we'll actually start to have multiple interconnected blockchains and a whole new world of what blockchains look like and blockchain networks look like. I think we're starting to emerge. So thanks so much for coming on. It was a pleasure.
**D** (1:26:03):
Thanks for having us.
**E** (1:26:04):
Thanks for having us.
**B** (1:26:07):
We release new episodes of Epicenter every week. Click here to subscribe for hundreds of insightful interviews with some of the leading minds in blockchain and crypto.
**A** (1:26:15):
You can also listen to the audio.
**B** (1:26:17):
Version of the podcast on itunes, Spotify, Stitcher, and other podcast apps. Click here for a full list of.
**A** (1:26:23):
Places where you can listen. Thanks for watching Epicenter, and we hope you'll join us for our next episode.