Ethan Buchman & Sunny Aggarwal

Cosmos – Launching the Internet of Blockchains

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 we discussed 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
Sponsored by
  • Microsoft Azure: Deploy enterprise-ready consortium blockchain networks that scale in just a few clicks. More at aka.ms/epicenter.
Transcript

Sebastien Couture: We are here today with Ethan Buchman and  Sunny Aggarwal. Ethan is the Co-founder of the Cosmos and Tendermint projects and Sunny is a research scientist at All in Bits which is the parent company of Tendermint, and is also a host here on Epicenter. Hi guys.

Sunny Aggarwal: 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.

Ethan Buchman: Yeah good to be back. Thanks guys.

Brian Fabian Crain: Yeah, so of course we’ve done some podcasts on Cosmos before. We did one with Jae 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 you know, how would you describe Cosmos?

Ethan: Sure. So, I think 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 interchain, right? So the interoperability layer between existing blockchains and the many new blockchains to come and a sort of part of that not only is the goal Cosmos to define these kind of interchain 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 then of course IVC, which is the key kind of interoperability piece that enables these different blockchains to actually communicate with one another.

Sunny: Yeah really, we see it as this third-generation blockchain and I know that term is very clichéd and over used quite a bit, but I think that most of the other things that call themselves third-generation blockchains don’t really quite fit the mantle, they really just seemed to be continuing the second generation. And so what I mean by when I say second generation is it’s this era of blockchains who are trying to do this one chain to rule them all kind of system. So in 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 have their own applications, Bitcoin for money, Namecoin for DNS etc. Ethereum came along and sort of did two main things, 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 CryptoKitty on 0x to buy some dai. 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 spaghetti code C++ very difficult to reason about, the consensus is kind of intermingled with the state machine, intermingled with P2P, especially post SegWit. And so Ethereum solidity, it’s like, you know, solidity is not the nicest language in the world, but it was way easier for people to write applications than forking the Bitcoin code base. But I like this analogy to compare it to the history of human development which is, if in the first generation you can think of that as kingdoms and villages where you have these separate kingdoms and villages that don’t really have the ability to trade or anything. Ethereum kind of created an empire. What empires did through mass political integration, they allowed for mass economic integration, you allowed people from Italy to trade with people in Persia because they were all under a common rule of law and dictator and it led to economic integration but it also came with a lot of drawbacks that love empires namely things like heavy taxation on its citizens, just a lack of social scalability and like governance that manages to take the viewpoints of all of the stakeholders and whatnot. And so, you know in the last hundred years in humanity we had this great thing where what we did was we shifted from 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, 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.

Brian: So the Cosmos white paper was published in 2016 like somewhere in the summer/fall, 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.

Sunny: Buchy can probably answer this a little bit better because you know, he was there around back when it was started. But you know 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 Cosmos has always sort of been the same but sort of our messaging and stuff, and it’s adapted looking at some of the changes in the blockchain space, especially, you know the Tendermint 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 Buchy can answer bit more.

Ethan: 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 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 easy as lowest hanging fruit was okay. We can define token transfers between these chains 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 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. As new cryptography comes out we’re updating, oh this could be used to make IBC more efficient or whatever. So 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 systems and so 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 and so the Cosmos SDK has kind of become a big part of the ecosystem now and you know, there’s a lot of particular details about how that was built and what’s in and what’s not and so on we can talk about that later, but from a high level I think things have stayed quite stable.

Sebastien: Sunny you mentioned this idea of third-generation blockchain and I think it’s safe to put a project like Polka Dot 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 Polka Dot can you describe the fundamental philosophical differences between Cosmos and Polka Dot.

Sunny: Sure so I think I would say one of the main primary philosophical differences between Cosmos and Polka Dot is that Cosmos takes a sovereign by default approach where we assume chains are sovereign, have their own validator sets, have their own security models and allow them to communicate and interoperate with each other and we don’t assume that there’s any one, like they are designed for IBC is designed such that, you know, any two chains could talk to each other. There’s not necessarily any route chain or anything like that. Polka Dot 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 there is this one route relay chain and then all these other chains are going to be just 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 by default people use the relay chain while in Cosmos by default their sovereign, but then the Cosmos hub as well as these other hub systems in the Cosmos interchain, but these chains will offer services such as shared security and whatnot. But these are optional things that chains can opt into while it’s not the default or requirement.

Sebastien: Okay. I mean the way I see Polka Dot 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, you know if you’re building a new blockchain and you’re choosing a platform on which you want to build your application, you know 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 people will ask and will require of Cosmos at some point, that the market and the ecosystem will want as a functionality.

Sunny: Yeah, totally. I think that this is what people absolutely want 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 Polka Dot to like the Cosmos Network. Cosmos Hub versus Polka Dot is really a more salient comparison and so  I have a design for the Cosmos Hub shared security system. That’s slightly different than the Polka Dot design. And so, you know, I’ve discussed it with a lot of the Polka Dot dev teams and we’re both aware of each other’s shared security designs and maybe if you want we can go into 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.

Sebastien: And what about Ethereum in that case. 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 described it this blockchain 3.0 space. Can you already discern some of the differences between what the vision is there and the Cosmos vision.

Sunny: Sure. So Ethereum still takes very much a single state machine. Everyone has to use the EVM and really the problem with that is it suffers from a lot of governance issues where people are going to basically have different requirements 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 with hundreds of EIP’s that are open in the EIP repo Ethereum proposals and some of them are contradictory and some people want state rent, some people don’t. Some people want X some people don’t. There’s so many different design requirements. The problem of turing a complete VM is it really forces everyone to 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 UTXO’s, like there’s a reason Bitcoin did that and they’re just way better for parallelization and efficiency, but if you’re building a payment system on top of Ethereum, you are stuck, you have to use their account model and that involves using the sequence numbers and you lose out on a lot of parallelization. And so just like in the world of nation states where splitting it off, it allowed nations to specialize, we also want to allow blockchain to specialize in use cases.

Brian: 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 then announced/ Talk a little bit through the process of getting to launch. Why did it end up taking so much longer and how do you guys feel that launch went?

Ethan: 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, Jack was hosting a live stream and we halted at Block 17 and his face just like all the color drained out of his face. It was 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, you know, we had this decentralized start which was pretty cool, quite a decentralized started actually and then, arguable kind of how you look at what’s happened since then, but I think we’re quite excited about 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 how we got to launch and why it took so long and so on. On the one hand software developers are notorious for poor estimates. So there’s Hofstadter’s law which is like it’ll take longer than you expect even after you take into account 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 they were a few iterations of things where we just threw something away completely and started again. And so for instance that’s kind of the story of the Cosmos SDK which wasn’t part of the white paper it wasn’t really part of 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. It doesn’t lock into any particular serialization algorithm or Merkle tree structure or any of the things like this and you know prior to that we kind of had some kind of a framework it was called Basecoin at the time or for a while, 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 set reset things. We started working on it a new model putting object capability-based security first and really thinking through how much of the Go programming language existing capabilities can be utilized in our security model and how we are 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 with the kind of Ethernet project. That was really a cheap design goal that only really became articulated a little later on in the process that this framework we built, we want it to be extremely general purpose so that you could literally wrap the existing Ethereum state machine with its RLP and it’s Merkle tree and the EVM as is, all the existing clients, not having 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 rebuilding things that we had already built, the staking modules and all this 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 in the fee distribution and all this stuff, 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 on bonding 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 a hundred or a few hundred validators. So getting all that to work and you know, we scrapped our fee distribution twice, we first had a pretty complex one, we scrapped that into a simple one and then we scrapped that and did a different one, now things are a lot more mature and stable and we have nice specifications for a lot of it. But I think to a significant extent we really underestimated the complexity of what we were building, there wasn’t a specification done upfront, 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. And then of course, there are operational constraints, coordination constraints. We have quite a distributed team from San Francisco to Berlin all the way to Asia, you know, San Francisco and Berlin pretty much don’t overlap at any point in business hours. So coordinating it can be very difficult and we launched various programs, we iterated through the test nets and is a lot of kind of operational overhead to that at the game stakes, which we can talk about as well. And so just getting all those things in place and dealing with all the difficulties of remote coordination and so on, so it ended up taking a little bit longer than anticipated. I mean, I joked that we were two months away for 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.

Sunny: I actually have a chart in the office the kind of maps the estimated time to launch and it was sort of hovering around the two months mark for a good eight months.

Sebastien: That’s funny.

Ethan: Just one other point I want to make, Zaki gave a talk at the MIT Bitcoin Expo that 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 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 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 and so 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 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 help continue the momentum and despite the fact that the Cosmos Hub hadn’t shipped, we were still shipping lots of releases for Tendermint into the SDK and a lot of people were starting to really see value out of that and you have been running in production for some time. So I don’t want to neglect that.

Sebastien: Yeah, of course and obviously we were all very excited when the launch happened and so, months before launching there was this game of stakes which was sort of 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 Chorus One, I 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 did you learn from this experience that allowed you to launch the network then so successfully, so far flawlessly I guess.

Ethan: Sure. A big part of our understanding of what we were doing is that not only we were building software but we’re 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 different from proof of work system, mining and 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, we were 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 test net community and I think to a significant extent this was really spearheaded by Adrian of Crypterium 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 a self-sustaining community on its own of running testnets, taking the latest release and running it in the wild and eventually by the summer we started doing these decentralized starts, there were a lot of hiccups at first when you’re doing QA on your software with a distributed network of strangers over the Internet. It’s quite an intensive experience. So we got these networks up and running through the testnets 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 are lots of halts. Lots of things went wrong where people would have to 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 testnets, 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 this sense of community, but with respect to game of stakes, so the other piece that we realized was that there were a lot of people participating in these community testnets that were really valuable community members answering lots of questions, doing just outstanding work in contributing to the software and so on, but these people actually didn’t have 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, here was some concern that some of the most competent or experience network operators actually wouldn’t be able to participate at lunch, right? So this is where we kind of cooked up the idea that well, maybe we can build some kind of incentivized test neck competition where the people who are really participating can 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, or some of those validators who received atom recommendations in the Genesis block were validators from Block 1 and have been huge participants in the network since its launch, and so game of stakes was really about making sure that 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 some atoms so that they could participate and that seems to have worked tremendously well, and yeah I would highly recommend that other proof of stake networks that are launching do something like this and 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 the issues, things are going to go wrong and you really need competent network operators that can coordinate to address these kinds of issues.

Brian: So of course we participated in this game stakes and we had like an incredibly also stressful and intense like Christmas because of that because yeah, I mean, 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 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 he halted a bunch of times and then restarted and we had basically over the holidays many others I think fixing these things and improving it and then I think what we saw in the launch is that everything went super smooth. And I think without game of stakes that would not have gone this way. I’m sure lots of validators would have had lots of downtime and in game of stakes we saw lots of downtime with various validators, but then since it launched it hasn’t happened like that.

Sunny: Yeah, totally and the other thing that it also did like you mentioned was a lot of the halts during game of stakes were due to bugs in the software and another thing game of stakes really did was it allowed us to have a good process of testing all sorts of behavior on the state machine and all the validators were trying different functions and doing the fun little stuff on the game and that forced us to test software and things in ways that we weren’t testing it internally ourselves, and so that helped us catch a lot of bugs and it seems that we haven’t had any bugs, knock on wood, 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 idea that somehow it was going to test the economics of proof of stake. And so the idea was like, oh can we fast track the testing of proof of stake by increasing the rewards so the inflation was, I don’t know something absurd like twenty thousand percent or something 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 Buchy said, one of the main things was to get validated to set up their security system properly and I think that saying, oh we’re testing proof of steak actually degraded the improvement of people’s security, so you’ll notice that for example my validator didn’t auto bond any of our tokens, and so we quickly fell out of our stake quickly depleted, that’s because we wanted to practice keeping a cold key and not having a hotkey with an autobond script. And so I think that having that testing a proof of stake kind of actually degraded a little bit from the experience so I think as different projects go on and do more incentivised 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.

Ethan: Yes, that’s a really great point. And I mean partially it showed that we could do these kinds of experiments and they can be successful. But I think to Sunny’s point, they really should clarify what in particular they are testing and not try to conflate too many things at once and, I mean 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 that’s that’s more true than ever today and with game of stakes we got a few things I guess confounded in that of the one hand we’re trying to really improve operator security but on the other we were talking about testing the economics and those two things are a little bit juxtaposed with each other or they’re a little bit intention like Sunny was saying, auto bonding isn’t something you should be doing if you’re building this kind of hyper secure offline key system, whereas it is if you’re just in it for the rewards, right? But I think we’re also seeing that play out on mainnet, if you look at significant amount of the transaction activity is some of the validators just constantly withdrawing their rewards and rebonding it, maybe that’s a problem with the architecture of the system that the rewards aren’t automatically bonded and that stuff 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.

Sunny: 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 of stakes that only made shut sense in short-term games not in a long-term game like the real Cosmos Hub is.

Brian: Well, let’s move to the topic of governance because that’s another thing that, since the network’s launch you still can’t transfer tokens, but there is activity around governance and one of the things that’s interesting is in the last years people often talk about on chain governance, but there was always talk about Tezos or  also DFINITY or these other projects, Cosmos would never be mentioned. But of course there is onchain governance, it’s being used today. So do you mind describing what does the on chain governance process look like in Cosmos and how does it differ from other on chain governance processes?

Sunny: Sure. So the untrained governance process of Cosmos is a little bit complex and I’d say it’s somewhere in the middle ground between the more social consensus style system of Bitcoin and Ethereum, and the more complete hardcore fully on chain governance that Tezos or Polka Dot kind of say, so in Tezos and Polka Dot, they have 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 my issue with this is I think it leaves out a lot of the stakeholders. So your 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 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 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. Ethereum for example has the carbon vote but it’s not this official thing, the UX around it is not that great, and so it leads to extremely low voter turnout. And so the idea is that by 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 softer upgrade proposal. So the text proposal is really what I’ve been talking about where it’s this signal so 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 softer upgrade proposal. This is where the question we’re asking to coin holders 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 a segment activation in Bitcoin, that whole not 80 percent threshold that they had, I don’t think 80 percent of miners wanted SegWit. The question really was do you think that SegWit was accepted by social consensus and 80 percent of the miners voted yes on that question. And so that’s really what the software upgrade proposal is, we’re telling the voters here that you’re not supposed to be saying oh 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 chain, which there’s some things high level code changes and so 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 the miners can just straight up chain themselves. For example, the gas limit or block size in Ethereum. And so that’s why we have these parameter change of proposal where it’s like some things that maybe just for the situation of simplicity and efficiency, we’ll say okay well 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 in the software proposal, this two-round system is really going to be the crux of Cosmos has vote the Cosmos Hub’s relatively conservative governance system.

Brian: So we’ve had two governance proposals so far, one was about changing some parameter about how inflation in the block reward is calculated and the other one is around enabling transfers. What are the insights or maybe some lessons that you guys see so far in terms of how the governance system is functioning, is it living up to expectations. Do you guys feel like some things have come up that surprise you?

Sunny: Yeah, so, the first one was about this thing that it is relatively unpretentious and it seems to be passing quite well. The second one was about the famous activating of transfers. So, as Buchy mentioned we launched the Cosmos Hub without the ability to transfer tokens and we kind of said it will be up to the community to decide when they think that activated transfers is ready. But the way that that second governance proposal was framed, it was framed in a in a sub optimal way where it basically said, do you want to activate transfers and if so we’ll all run the code that is signed by All in Bits or Tendermint the company and basically essentially Tendermint the company said it was based off of the signatures of three key base accounts, which I think included Buchy, Jae 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 and that actually for a little bit a lot of people have voted yes, and then some people start to think about it a bit more and they’re like, wait a second, that means that Tendermint the company could do anything they want and could change the state machine to do you know do anything or send all money to us and obviously I work for Tendermint the company and I don’t think we’re malicious. But I think it’s set good precedent that the community was weary and skeptical of us. And so now in the past few days 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 to round commit system that we just talked about.

Brian: So one of the interesting things in the Cosmos voting system is that, let’s say I’m a delegator and I’m delegating to validator A, then 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 power balance between validators and delegators? So I mean in many voting systems launching government’s 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.

Ethan: Yeah, I think potentially. This is all a massive experiment so we don’t really know how many of these things are going to shake out. The nice thing though is that having this kind of automated governance for delegators, basically 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 validator, we basically guarantee 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 delegator are paying attention is another question and I think it really depends on who the delegators are and what they care about and how technical they are and how how much they understand state of the network, right? So to the extent that they’re just retail consumers that are looking for some kind of passive return, then they’re not going to care and at least in theory they’re not going to know enough to pay attention. Now, I think we’ve kind of hoped and try 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 active stakeholders. 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, so building businesses and you know putting up zones and all this kind of other stuff on top of Cosmos, so I think there is there is some risk. A lot of it remains to be seen how this is going to work out. Again, it’s a big experiment. I mean there have been discussions about potentially changing that governance 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 which could potentially separate 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 from a certain other analysis or perspective it might make sense for those things to be the same.

Sunny: It doesn’t even necessarily have to be to another validator. It could be just to another user account as well.

Ethan: 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, 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 the stakeholders and the users of the network. So it’ll be very interesting to see how the governance really evolves from here.

Sebastien: 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 betterment in 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 etc but that in reality, maybe 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, one idea could be that potentially 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 has 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 be incentivized to vote etc. How do you think that we can actively make blockchains a of more democratic system where there is actually participation and we don’t fall into the same sort of system that we have now were most elections never for the past fifty percent and in recent elections we’ve seen even less than that.

Ethan: This is a really hard question and I don’t know that any of us are going to be able to give real confident 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 in 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 buying and all this stuff is quite difficult. And so I think again part of the vision of Cosmos was really the 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 whether they’re talking in 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 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 is 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 we don’t really have that at a large scale in our politics. There are certain other cooperative corporations try to do this a little bit more actively where the members kind of have to vote and that’s kind of the whole point being part of a cooperative. You’re supposed to vote on the thing right? And so you can think of some of these blockchain networks as digital cooperatives in a sense, but 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 simply don’t care enough about the outcome that they’re going to vote then they’re not going to vote. 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 the 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 so that they will turn on 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. So kind of a long-winded way of saying it really depends and we don’t know.

Sunny: Also, earlier on in the Cosmos Hub development process we actually had it so that if a validator doesn’t vote they actually got slashed, but then the emergent behavior that ended up happening is everyone to started writing scripts that would auto vote abstain. And  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 this whole community blockchains idea will hopefully do that. The reason maybe people don’t want to vote on a lot of the Ethereum stuff is that it’s just such a big system that you don’t care about everything that’s going on, but if it’s like a more specialized application or a part of your community chain or something, maybe that will lead to more engagement and then from a technical standpoint there’s also some certain stuff that I’ve been working on to make it easier to 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 basically designate one key as four different functionalities 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 move your tokens to someone else. So it’s okay that may be you have your main key on your ledger in cold storage but your governance key, you can keep it on your phone and there’s already a bunch of great mobile wallets, like Rainbow Wallet and Cosmos Station that already support governance. And so once we have these subkeys, you can keep those keys on your phone and be able to vote, we’ll make it like fun. So when you see how the Cosmos atom holder you’d be like hey, have you voted on the proposal yet? We have to encourage people to be part of it and make it easier and more secure for people to do it as well.

Brian: 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 function they serve in the network.

Ethan: Sorry. I just want to make a point about about the last discussion which I think is that this point is about 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. It holds for the larger space of mechanism design and all the kind of things were working on. We tend to take very technically oriented and mechanism oriented approaches to the design of these systems, and I think to a significant extent, somewhere along the line neglect the fact that the whole point of this thing is to coordinate real wet messy humans, and I think the human elements are really what this all about and if we don’t tend to the psychological and sociological aspects of that no matter how perfect your mechanism is on paper, it might not really take shape the way you expect. I was at the Radical Exchange conference last week with my girlfriend who is much more in the social side of things and how to make technology more human and she was basically just trolling me the whole time we were there and just chirping about, all these people are so mechanism oriented, where’s the humanity and all this and so I try to channel her as much as possible when thinking about blockchain design and so on. So anyways from the perspective of validators, and 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 the elephant in the room. When we talk about decentralization that is the physical infrastructure right? Because we’re doing really great things on decentralizing file sharing and consensus and all these great software and overlay stuff, but when it comes to the physical infrastructure, we’ve hardly even begun. I mean there’s a few mesh net projects and so on but what I really see in the long term, the validators as being the seeds for real decentralization of the internet infrastructure and I think proof of stake validators might be the first application where people are going back to data centers, like everything moved to the cloud and 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 in a data center. Actually I found this quite touching the other day, I was talking to Zaki  he travels quite a bit and he said something about when you’re going to go home. And he was like, where’s home? He was like, oh home is where the validator is, right? I thought that was a that was a really interesting take on the meaning and importance of validators in the long term as seeds of the physical internet infrastructure for these new kinds of digitally cooperative communities. And so maybe that’s not a satisfying answer about what the role of the validator is in the short term, but at least 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 there is vision for sovereign independent blockchains that are all interoperating, takes to a significant extent a geographical orientation so that certain zones are based locally geographically and traditionally that’s how sharding is done on the traditional internet with 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. So I’m hoping that we can reset the internet infrastructure on top of that kind of thing with validators. In the short term was the role of the validator is very different so primarily to operate the network and to host it and to start to offer services around it and to attract delegators and upgrade it, make it actually useful for a larger number of stakeholders. But I think to ask about the role of the validator, just the validators on the Cosmos Hub, misses the point of the larger vision of the Cosmos Network and the Cosmos interchain, the validators are really part and parcel of the stakeholders of the independent communities that we expect to run the many millions of blockchains. And so 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 offload everything to some other tech provider and I think those are interesting questions and challenges for us to address over the coming years and decades.

Brian: So one of the interesting questions around validators that’s also already come up in the 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 change is going to come in and in some other systems like EOS for example, I think they’ve accumulated massive power, Coinbase custody, they’re going to launch about it soon, so first of all 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?

Ethan: Good tough question. I don’t 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, one with 99% of the stake and one with 1% of the Stake, and I have seen mines 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 atom holders will will cherish and value decentralization. And if they don’t I suspect that there will be some that do and ultimately create forks alternative global hubs where things are a bit more decentralized. Now, there probably are things that can be done in protocol. I think these are difficult and 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 it’s been underestimated,the cost of having like independent validator IDs. And so 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 the validator up into multiple keys. And if they’re being public with both and they’re publicly civil in some sense. So I think things like that could be experimented with, 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 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 this which is the difference between a service hosted by a single entity and a service hosted by 4 or 7, 11, whatever it is, even a small number is very significant and very different than what we’ve ever had before 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 it’s very significant and we shouldn’t underestimate the value of even that small level of decentralization. Of course, hopefully will 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.

Sunny: One solution that I will vouch for is how to help push more decentralization is this one that Dan Robinson and I and Vitalik have been talking about for a while and 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 that there’s ways you can design it such that even if validator tries to split into many smaller validators and they all double sign or fall together, they get like slashed even more than if they didn’t split and so you can design incentives where it encourages validators from economically rational standpoint to help decentralize the network and not put everything into a centralized system.

Sebastien: So going further on this topic. This is something that’s come up recently and something that we felt would be a good good to address 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 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 around this topic and so in a sort of capitalistic paradigm one would think that everybody who tries to bring their fees as low as possible and and then the bigger validators ones with the most economic means could out compete the rest of the rest of the market to effectively lead us to a situation where potential is 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 valid or specifically not to adopt this sort of this sort of policy of the zero percent 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 tenements exceeding so, how do you respond to all this like?

Sunny: So Sikka, the name of the validator that’s run by myself and Dave who is another Tendermint employee, we basically decided to start with zero percent commission and for the short-term, so when we announced that we said we’re doing zero percent commission for at least one month and our goal was to help. I think 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, we saw some validators up at 15% while I agree zero percent is too low. And so the idea was, we want both sides to start moving towards each other till we meet somewhere in the middle. And so I think Sikka has been doing this very well where by before 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, 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 will start to increase our commission there. And then two other things that are kind of relevant here is why are we able to do the zero percent commission, a lot of people have been criticizing us that we’re price gouging. We have like zero VC funding or anything. Literally what we have is our validator is running out of the UC Berkeley Data Center through Dawn song fkjsdhfjksdhfjkhd 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 I fundamentally don’t see this as any different than the miners who decide to mine out of Iceland using their free geothermal electricity. You’re going to have to expect that the validation market will become competitive and people who can find the most efficient ways of extracting resources will succeed there. And finally the last thing is we’re also taking a much longer term view of the Cosmos Network where the Cosmos Hub is not the only change in the system. We’re charging 0% on the Cosmos Hub to earn delegation and reputation and some name branding and then, 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 zero percent commission there. We’re going to be charging a nonzero commission rate there and we’re going to hopefully use our brand that we’ve been building as competent high-functioning valid is on the Cosmos Hub to earn more delegation on the Iris hub.

Brian: Yeah, so I mean this is I think a very interesting discussion. And obviously I’ve been involved in the discussion quite a bit. I personally find the argument super questionable that you’re making, 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 for the stage of the project, but maybe it will be there. If you have 5% commission across all validators, it means five million revenues across all of the validators for paying different the entire infrastructures. If you have a hundred validators that’s on average 50 thousand dollars per validator. It’s not even one job, like not speaking of running the infrastructure.

Sunny: Wouldn’t five percent be 50 million not 5 million.

Brian: No

Sunny: 5% of the billion is 50 million.

Brian: No but you have a billion right? And then you have let’s say roughly 10 percent inflation per year would be a hundred million revenues paid to all the delegators, five percent commission would be five million split across a hundred validators would be 50,000. Now, of course, you don’t have a uniform distribution of the stake, so basically would mean that you would not be able to have more than 5 or 10 validators that maybe could be financially sustainable. So I think from you 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 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 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 it’s so messed up.

Sunny: Hmm. Okay. I think that, like I said, I have no intention of keeping it at zero percent and also….

Brian: That’s even more messed up, to do it has zero percent, not tell anybody and then later hike up the price.

Ethan: They told people that it was just gonna be a month, right?

Sunny: Yeah, and I told people that whenever we raise the prices we are going to give at least one unbonding periods worth of notice. So the people 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 hundred percent 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 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 people were doing this in the early days of Bitcoin, people were mining off of the faith that 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 at some point the usage of the system, the fees will be enough to pay for their services that you guys are providing.

Brian: Okay. Well, I think this is a discussion that is probably best continued in some other context as well. So let’s move on, we’re running pretty late already. But let’s move briefly to the Cosmos SDK and IVC, especially Cosmos SDK, which I think is the key part of the Cosmos project into kind of the value proposition. So Buchy do you mind running through what’s the division of Cosmos SDK?

Ethan: Sure. I think maybe to really understand that from a lower level, if you’re already familiar with Tendermint helps to 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 and you have the replication piece, which is all 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, to architect it however you like, it runs in a separate process on the same machine on a different machine it 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 a 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 and all this stuff and what we realized was that we had built a few different applications and go to test this out that there are a lot of common elements there that all these applications share 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, so for building state machines on top of Tendermint. And the way it’s structured it kind of comes in these layers and so the lowest layer, it’s called base app, it’s really a thin wrapper around the ABCI that gives you this kind of, very flexible approach to how you should think about the state that you’re storing in your state machine and how transactions 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 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 Merkle tree, doesn’t force 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. And then from there’s this next layer which is the actual, well a lot of people know the Cosmos SDK which are all the kind of pieces of 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 the Cosmos Hub was ultimately built on, and a lot of other things that maybe 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. So that’s a lot of the pieces that you would need to actually build a cryptocurrency or a cryptocurrency system. Then on top of that there’s the next layer which are the actual module and that’s where all the really custom logic for executing your transaction comes in. So after you’ve done all the authentication stuff and make sure 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 for the Cosmos Hub, there’s a certain set of modules that define the governance of the Cosmos Hub and the proof of stake and the slashing, the fee distribution and so on, but if you’re building another 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 what you want to inherit and how much flexibility you want to retain.

Brian: Cool. Now one question that people often have is, 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 main differences here?

Sunny: I haven’t had too much time to play around Substrate yet. I’ve poked around it a little bit and it seems that a lot of the design ideas are actually generally very similar, they’re using a similar idea of modules and 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 if you want to build your state machine you have to do it in Rust, while the Cosmos SDK is and Golang and 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 namik called lotion JS, which is a JavaScript based SDK essentially, and so essentially the idea is that we want this diversity in frameworks. In fact, there’s actually now the fourth one called Weave which as Buchy mentioned a while back, that we had an old version of SDK V-1 and we scrapped it and started writing SDK V-2. Well, one of our ex engineers is actually really like SDK V-1 and he actually  went ahead and kept maintaining it and turned it into its own standalone SDK called Weave 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 use whichever one they feel most comfortable with and it’s really going to mostly come down in my opinion to the programming language. 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 nice little middle balance between security, especially with our object capability system that we design, along with ease of use and ease of access to developers. I learnt Go in two days, it’s a really easy programming language to pick up if you have like basic programming experience. And so the real goal would be as we want to implement IBC in all of these different frameworks. So right now we’re working on it in SDK, but we’re going to have implementations in all of these different frameworks.

Brian: Yeah, so that does bring us to the next topic that maybe you can briefly cover. I know it’s in it’s very beginning but Buchy I know there’s some work starting around IBC. So what’s the current status on IBC? And like what does the IBC roadmap look like?

Ethan: So I mean there have been past specifications of IBC and past kind of prototype implementations that were running on test nets 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 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 the in a GitHub repository. It’s github.com/Cosmos/ics, that stands for interchain standards, so Cosmos/ICS, and you’ll see there are large number of issues, they’re each numbered like ICS number 3 number 4 etc, and each of these kind of corresponds to a different component of the IBC layered stack. And and so activity there is really starting to ramp up. We’re also hosting a biweekly 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 specification that really focuses on some of the key data types, but also 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 right out the bat to implement it in three different languages in Go and Rust and in JavaScript and to have those implementations actually pursued by three distinct teams. And so The Interchange Foundation is working on implementation and Rust, and All the Bits is working on one in Go, we’re trying to work with the gorik team on one in JavaScript and also the nomic team who has pieces already in JavaScript, and so we’re really trying to make sure that we don’t over fit the design of IBC to a particular state machine or to 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 in this larger Cosmos interchain vision. And so if people want to follow that on github.com, if you’re interested in the bi-weekly call, I actually don’t know the best way to find it but you should be able to find it from the repo which you would be able to join publicly. And so that’s moving along and 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 shift something to the Cosmos Hub this year, beyond that more refined timelines are really hard to give. Obviously we want it as soon as possible because that’s 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 very clear and is amenable to implementation in multiple languages.

Sebastien: So why should someone choose to build their dap or their application on Cosmos rather than Ethereum?

Ethan: 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 wins of the Ethereum governance and to Ethreum’s fee system and mechanism and proof-of-work mining and all this stuff, then you should develop on Ethereum. If you want independent sovereignty and if you want to use a mature programming language that you’ve been building in for a decade and has matured debugging tools and testing and all this stuff than Cosmos is probably right for you.

Sebastien: So you mentioned the Interchain 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 Cosmos and Tendermint and all these different projects and organizations gravitating around Cosmos.

Ethan: Yes, so the foundation was set up in early 2017. It did this fundraiser. It has been the primary source of funds for many of the folks involved in developing key elements of the Cosmos Hub and pieces of the Cosmos Network. I think now that a number of organizations are standing on their own two feet in the sense that they’ve managed to raise venture capital investment, so that includes All on Bits but it also includes a number of other entities, are starting to see staking companies, raise VC money and so on, a lot more attention to starting to turn to 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, you can find it on the website interchain.io, you can apply for funds. So we’re looking to 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 grow the ecosystem and see in the short term to see the immediate needs to be developed. So IBC for sure, certain other application frameworks, bridges, things like 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, certain wallets and block explorers and so on, so really growing the set of applications and frameworks and developer tools and all this for building out the Cosmos ecosystem. The foundation is all starting to focus on some RND as well, a little internally so, as I mentioned the foundation’s going to take on the implementing IBC in Rust to complement AIB doing it in Go, and others in JavaScript and hopefully others in other languages too. And so, you know 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 lowest layer and kind of working our way up to help, to 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 block chains 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. 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 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 a kind of a naive view and kind of the thinking that got us into 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 we’re eager to hear what people think and and we’re building out there and hopefully there’ll be a lot more save from the foundation in the short term, but really the focus is on funding, building out the community and really having strong independent members of the larger Cosmos ecosystem that can really take responsibility for operating the network and developing things on it and so on.

Brian: 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 more to discuss, especially as actually interoperability is going to start to happen and will actually start to have multiple interconnected blockchains and a whole new world of what blockchains look like and what blockchain networks look like  starting to emerge. So thanks so much for coming on.

Ethan: It was a pleasure. Thanks for having us.

Sunny: Thanks for having us.