Intro to the Cosmos Network

**A** (0:05): Hey, guys, My name is Sunny. For those who don't know me, I'm a researcher at Cosmos Tendermint. I was also one of the co founders of Blockchain at Berkeley about three or four years ago. Now let's go ahead and get started and talk a little bit about what is Cosmos. The tagline I gave this talk was many chains, many tokens, one ecosystem. And hopefully I'll explain what that means. So before we start talking about blockchains, let's just talk a little bit about, like, the evolution of, like, human coordination. So I would, I assert that, you know, the first stage was we had these, like, ideas of villages and kingdoms where, you know, they were relatively isolated. You don't have much like, economic integration. You know, you basically only really trade with your, like, neighbors, and that's about it. And, you know, because of that, like, they just weren't able to scale very high. And so, you know, I assert that, like, you know, historically what we see is that economic growth comes from increased economic connectivity. So as you're able to trade with more people, you get, you know, you get more and more. And so I think the second stage of civilization was this was empires, where basically we realized that, okay, how do we get people in Greece to trade with people in Persia, right? It's like how we do it is by having like, you know, everything under a common set of laws and rules where every, you know, common ruler, so, you know, you have standards, you have, you know, if they don't want to trade, well, you know, you put a gun, you march your army on them and force them to trade with you. And so this is kind of like what we did. And I'm sure I don't have to explain to you guys what the downfalls of empires are, like the moral hazards and whatnot. So the third step was what we have today, which is nation states and city states. We kind of have a combination of them in the world, like nation states, countries like Germany, France, we have city states, countries like Singapore, Monaco, et cetera. And I actually think we're seeing a shift towards more and more city states. We see this in like, you know, for example, Catalonia trying to secede away from Spain, which I consider that sort of a city state. And so essentially I see, I think what the greatest innovation of humanity in the last hundred years was. We realized how we can do economic integration without political integration. And so, you know, we did this through a couple of a multitude of technologies, including free trade zones, where we came to coordination saying, ok, in these areas Free trade is the norm. We had containerization. We came to standards upon how to package goods and ship them. So everyone's following these same standards. We didn't need a government telling us to do it. Rather, we did it through sort of like voluntary organizations. And so institutions helped as well. Things like the un it's not quite a government, but it's like, you know, a common forum where people can come to and just discuss, like, problems and whatnot and like, you know, hopefully try to resolve them as well as, you know, the Internet, I think, you know, Internet has helped obviously a lot now. It reduced transaction costs for doing business with anyone from anywhere over the globe. And, you know, I think hopefully blockchain will help push this as well. Economic integration without political. But so, yeah, these are sort of the technologies that helped create this like, you know, more decentralized political environment that we see today with high amounts of economic integration, but low amounts of political integration, which is, I don't know, in my opinion, you know, this is political. Obviously it's going to be a political statement. But I'm somewhat of a localist and I believe that like you, you know, coordination works at smaller numbers when people have more similarities and like the whole Dunbar's number and all that. So, you know, I think you can get better coordination through smaller political entities while still having the larger economic systems. So let's compare this to the evolution of blockchain development. Step one, Generation one came a bunch of independent blockchains. You know, you had the bitcoin. Bitcoin was the first blockchain. And then after that you had many other blockchains that started coming along, each trying to do like, slightly different applications. Some of them were not doing different applications at all. Right, Like Litecoin and stuff. They were just trying to like, you know, play with the monetary policy a little bit. But then you also had some things like, you know, namecoin, trying to create like a decentralized DNS system. You had Saya, who was trying to create like a, like, store, decentralized storage marketplace. And so you had all of these different blockchains. But like, you know, they weren't really able to communicate with each other or anything. They were kind of all in their own isolated environments. There are also other issues with it back then. Like, you know, bitcoin was the. The bitcoin code base was the only blockchain code base that existed. And so if you wanted to make your own application, really what people used to do was like fork the bitcoin code base and try to modify it. But like you know, Namecoin did this for example and it just clearly a suboptimal solution. It's very poorly designed because it's a fork of the Bitcoin code base. And the Bitcoin code base is like, you know, wasn't designed for that. It was designed to do payments and nothing else. So we'll get into that a bit. But then along came generation two, the Empires. These Ethereum basically created what I consider the first empire which basically said okay here is like one monolithic stack and you know, build your applications on top of me and you know, I will provide you great amounts of economic connectivity and you know, you can have like the 0x project. I can use my make or die to trade to get gain leverage on like and then I can like you know, use that in a 0x or something. So you get high amounts of economic integration. This whole like defi movement that's been going on in Ethereum but you also get a lot of cons. You have like very little extra. Any individual application has very little control over governance. You kind of like, you know, if you, let's say your system has some issue with it and you need governance to solve it, you somehow need to convince the entire Ethereum community to bail you out rather than just like your own personal community. So you lose out on some, your community loses out on some level of sovereignty. You also have to, you know, to use Ethereum you have to pay your fees in Ethereum. This is essentially a tax. It's like no different than the tax that empires charge on their constituents. Essentially the more people they have using Ethereum it boosts the price of the Ether token. Maybe if you had your own blockchain, you don't want to do that, you can use your own token to pay fees. So I propose that the solution is this Generation three where we have many application specific blockchains that are all interoperating with each other. So you know, this is a Cosmos hub chain, this is Namecoin, Sia, Augur, Bitcoin, Ethereum. I still think smart contracting systems will stick around and I think they're useful but I'll get into later, a bit later why where they're useful. But you know, each. We're not going to have Turing complete VMs here. We're not like you know, the Augur contract is not, is not going to be a smart contract written on the evm. It's going to be like something that's written into the core code base of that Blockchain. So kind of like how Bitcoin, its code base isn't written on the EVM or some vm, it's just in the client code base. And you know, this has a lot of efficiencies and whatnot which we'll get into. And so that's what I imagine that most of these blockchains will end up looking like. You'll still have some of Those Turing complete VMs and we need a way for them to interact with each other. We need these links between them where they can, you know, send data between each other, send tokens, send assets, like build a common economic connection. And so that's nice, you know, that sounds good but like, you know, but I don't want to make just an appeal to analogy here, right? Like you know, I think that this like generation 1, 2, 3 of the blockchain ecosystem clearly, you know, maps very well to the of human coordination. But that's like not a strong argument. So let's talk about why. So what I'll do for this presentation is explain why we want this kind of design, what tools my company Tendermint is creating to build this. And so we'll start by talking a little bit about why do we want a generation three, what was wrong with generation one and what was wrong with generation two. So generation one, you know, the benefits here are the sovereignty aspect. Like you know, the SIA community has control over the SIA blockchain. When they realized that people were like, you know, they were ASIC manufacturers who are about to like, you know, gain a controlling share of the SIA blockchain network. They hard fork their hashing algorithm. Right. This is something that they could only do because it was a small, close knit community. You have way more efficient state machines. I mean I claim that the Bitcoin state machine is way more efficient than the Ethereum, the evm, because it's, you know, it's just simpler, it's rich. You know, daps, you're running compiled code not interpreted and you get a high amount of customizability. Right. Like the other thing with Ethereum is like, you know, in this, in the Empire model is like they, they force things upon you. So for example like you know, you can't choose what cryptography you want to use because Ethereum only has certain pre compiles that they chose what precompiles to use. And you can't say oh I don't want to use SHA3, I would rather use a different hashing algorithm. You can't do that. You lose out on a lot of customizability when you're living in someone else's empire. These are the benefits that Generation 1 gave us. Generation 2, on the other hand, gave us all that interoperability I've been talking about. It made it easier to develop. So like I said, if anyone's tried playing with the bitcoin, it's like this spaghetti code C monolithic, very messy, it's very hard to understand. And it's because of that, it's very hard for people to fork it and make complex applications with it. So Ethereum made it way simpler. Solidity is not fun to write, but it's way better than trying to modify the bitcoin code base. And it actually, solidity is not. It's getting better and better over time. So Generation two, it made it way easier to develop. And there's this whole one click deploy thing where I write my code as a developer, but I just press a button and it deploys it and it's live. I don't have to go out and find miners to mine my chain and whatnot. The goal here would be we want this generation 3 to somehow combine the attributes of both generation 1 and 2. Can we get the best of both worlds here? And that's cool. Let's go even further. Can we do even better than just that? What are some. If we're going ahead and building another generation, what else can we add to this system? So, you know, when looking at like designing distributed systems, you know, one of the best places to always look for inspiration is the largest distributed system in the world, which is the Internet. And you know, the Internet, its goal was to connect multiple separate networks of servers into a single network of networks. You know, that's kind of what I'm proposing. Our solution is cosmos, the Internet of blockchains. You know, the ability to scale in terms of throughput and geography and the ability to tolerate and recover from failures. Well, if we look at our goals for the Internet blockchains, it's actually pretty similar, right? We want it to be able to scale a number of users and throughput and geography. We wanted to tolerate and recover from failures. And so, you know, let's go ahead and add those two to our list of desires that we want scalability and fault tolerance. And then I'm going to add a third one that I personally, you know, can care a lot about, which is this is the energy consumption of proof of work over the last year. Luckily it's gone down a little bit because the price of bitcoin has gone down but at its peak it was doing 75 terawatt hours per year. Everyone always gives the analogy of oh that's as much as this country. I don't know what it's actually similar to, but I heard something like Denmark or something at the peak was what it was using as much electricity as. So yeah, this isn't cool. I don't want to, you know, let's. I want to care, I want to like how do. Let's also worry about making this sustainable. So these are the nine goals that we have in the generation three of blockchains. So and there's a 10th goal that like we kind Cosmos, we kind of like don't isn't our focus which is privacy. And so the whole like generation 1, 2, 3 is always a little bit misleading because you know where does like zcash fall on that? Like it's not a linear timeline. It's really like a tree of development or even like a dag. Like things are borrowing stuff from each other. But you know, privacy is like a very important tenth like thing that we need to work on. But quite honestly the Cosmos team, that's not our specialty and so we don't really focus on that ourselves. Instead we just give a lot of money to people who do, do do that. So you know, we fund Dan Bonet's lab at Stanford as well as Alessandro Chiesa's zero knowledge proof research here at Berkeley. So that's not our focus but you know, that's definitely something. Oh well so Dan Bonet. So Chiesa, he's basically focused completely on zero knowledge proofs. That's his focus. He was one of the co authors of the ZK Snarks paper. He's one of the co founders of starkware and he's currently working on a new construction of zero knowledge proofs called Aurora. So Dan on the other hand he's more like. I don't think he actually does much in zero knowledge field at all. He's just focused more on BLS signatures. He's been doing a lot of work on aggregators lately. So he's more like I consider traditional cryptography and making things like more efficient. While Dan is. Sorry while CHSI is more on the zero knowledge proof side of things and so on the privacy side. So one of Dan Bernays grad students, Benedict, he helped create Bulletproofs which is also like a zero knowledge construction. So they do dabble in it a little bit as well. Yeah. Also sorry I should have mentioned this earlier. Feel free to butt in with any questions at any point. Yeah, thank you for that. So, yeah, back to the nine goals. All right, so here's what we want to create. How are we going to do this? These are the tools that Tendermint, by the way, it's going to be a bit confusing because Tendermint is the name of our company, but it's also the name of a bunch of our tools. And so it will be a little bit confusing, but got to bear with it. So, you know, these are the 1, 2, 3, 4, 11, 11 tools that we're building and that we're going to. That are going to achieve the goals that we want for the. For this, you know, generation three blockchain ecosystem. From here on out, I'm just going to call this generation three thing Cosmos. So Cosmos is not the name of a single blockchain. It's not the name of. Cosmos is just the name of this vision of how do we create a Generation 3 ecosystem of application specific chains that are all talking to each other somehow? So these are the tools that we're going to use. Tendermint, Cosmos, SDK and IBC are kind of like what we call our three flagships, and then some of the peripheral stuff that go along with helping us achieve those nine goals that we want. Yeah. **B** (16:07): Are you 100% production ready? **A** (16:11): Yeah. So the one that's the most production ready is Tendermint Core, which is the next thing I'll be going into. But it's been around. I'll just actually go into it. I'll jump into it. So we'll start off with Tendermint, because that's the first thing that we created. Tendermint was created by Jquan back in 2014. He was just really. He got into. He wanted to make an exchange and he was worried about the finality properties of proof of work. So he started like reading into BFT research and, you know, he came up, he's like. He read pbft and he's like, oh, I think I can make this better. So he created a consensus protocol called Tendermint. And so Tendermint was. That's also why it's the name of the company. So we. They spent. Jay and Ethan Buchman, who's the cto, he spent. They spent about like two or three years developing Tendermint alone. And then we started working on this Cosmos vision about two years ago when we were like, all right, we have a BFT consensus engine. What can we do with this now? And then that's kind of when we started thinking about, okay, this is the whole cosmos vision that we're building. So Tendermint, it'll be a little. So Tendermint is also, like I said, it's an overloaded term, it's the company, but it also refers to the consensus protocol, like this abstract notion of the protocol and, and that which I'll call Tendermint bft and then this Tendermint core which is our actual implementation in the software implementation. So with Tendermint bft it's basically this like you know, three round, sorry, two round commit system. I don't want to go too much into the technicals of Tendermint. In each of these sections I'll have like a list of further reading you can do if you want to learn more about any of these topics. So essentially, you know, this is a great like, you know, obviously you can't read it right now, but this is a great like one poster. We need to print it out and have it in our office. I don't know why we don't yet. But this is, this is like probably the best like quick explanation of Tendermint BFT that I've seen. I'll have a link to it. So yeah, what is Tendermint bft? It's a simplified and improved bft. So what this means is I can give a brief summary. What happens in PBFT is you have a BFT consensus protocol that's like going and you have one leader who is proposing values and everyone else is committing. And it works very well in this situation. But the leader stays the same. If the leader goes down, PBFT switches to a different mechanism for leader reelection. And this leader re election mechanism is very complex and whatnot. And so a lot of thought has gone into improving the leader of reelection. So if you guys know thunder, they have a mechanism where they fall back to a proof of work blockchain to do the leader of re election. I think that's actually very silly. What Tenement does instead is basically what Jay's innovation here was. He figured out how to do it all in one round in one mechanism so you can do the leader reelection and at the same time as you're doing consensus on values. And so what this does is it allows you to not have this. It simplifies the protocol significantly and it also allows you to change the leader every single block. So you can imagine that PBFT is not good for a public blockchain because you're designating one person as the proposer every single time. And That's a huge censorship concern. Right. But with Tendermint you, you can change the proposer every single block. And this, you know, allows. It's a censorship resistance mechanism because now you don't have one proposer who can choose to choose what transactions go in or not. If one proposer is censoring you, it's fine. Hopefully the next proposer will not be. And it also was very well designed for, you know, working over a gossip network where the problem in PBFT is the when there's byzantine faults, like malicious faults, to show evidence of it, there's a lot of like back and forth required. So like you know, if we, you know, you faulted and I wanted to like share information from you, we're going to have. There's a lot of back and forth communication and it kind of assumes that the two people have like a direct connection to each other. Tendermint, the evidence is very compact and that makes it very efficient for propagating over a gossip network, which is what blockchain networks usually are. And so it's also very well designed for use in public gossip networks over the public Internet. While PBFT was only really ever tested in private permission settings. So Tendermint we are heavily consistency prioritizing or safety favoring. So Tendermint, what it will do is if there is a it is safe in asynchrony. So what that means is let's say half the nodes cannot talk to the other, the transatlantic cable was cut or something. Right. The entire blockchain will halt. No more blocks will come until we figure out how to resolve the situation. A liveness favoring blockchain, on the other hand, such as any proof of work chain, it will instead go split brain and start creating two forks that will not be able to resolve. And so I think the safety favoring is it's very important from to me, blockchains and consensus protocol were about coming to consensus. Why would you want something that is inferior to coming to consensus? I think safety favoring systems are superior to Liveness and so we have provable liveness in partial synchrony. So unlike Bitcoin where if the synchrony time accidentally goes, let's take Ethereum, it has block times of 15 seconds. If the network delay exceeds 15 seconds, the blockchain will never be able to resolve. It'll just remain in a perpetual fork where it will never come to consensus. In Tendermint it doesn't matter how long the delay is, as long as it resolves at some point it will continue to make progress. So let's say the block time. Suddenly the network propagation time suddenly jumps to 30 seconds. It's fine. The system still works. It will just be making blocks every 30 seconds instead of one second. Yeah, I talked about the rotating Proposer. It has a safety threshold of 1/3 of the validator power. So as long as less than a third of the validators are not malicious, it will never fork. As long as less than 2/3 of the validators are not malicious, we will always be able to attribute who was malicious and be able to punish them somehow. And then finally we have like Tendermint 2.0 in progress. That's how we can make it even more scalable. Things like BLS aggregation for signatures, pipelining. So these are all like, if you're interested in that kind of stuff, you can come talk to me afterwards. And so why does Tenderman BFT help? From a scalability perspective, it comes down to that idea of safety and asynchrony or and liveness and partial synchrony. The problem with Nakamoto consensus is if your propagation and mining time exceeds your block time, the system will go split brain like I talked about. Like, you'll have two forks that will never be able to resolve. On Tendermint, however, if the. So that's what happened here. What happened here is this is like step one, the time increased. Now the system went split brain. In Tendermint, on the other hand, let's say the propagation time increased. Suddenly it's ok. The liveness and partial synchrony aspect of Tendermint will just increase the block time and make it safe. And so what this allows is it allows you to push the block time as low as possible. So in Bitcoin, the reason the block time is so high is in 10 minutes is because they're very paranoid that they don't want to get ever get into this situation. So they think 10 minutes is a long enough time. Same thing with Ethereum. You can't really push it lower than 15 seconds. And already that 15 seconds, I think, is a little bit too low. We're having too many orphan blocks right now. That's why in Tendermint you can push the block time, you know, have the default be one second and it's fine because like if it's not one, if it doesn't work in one second, it'll just happen whenever it needs to. And so you, you know, you can have way more blocks happening, way more transactions happening. You can. The safety property of Tendermint allows you to push the system to its limits, which you cannot do in Nakamoto consensus. **B** (24:50): So yes, how Rails are concerned, will. **A** (24:53): That ever happen in Bitcoin? Not in Bitcoin, because 10 minutes is insanely high, but in Ethereum I could totally see it happen. 15 seconds and sudden Internet network delays, like pushing it beyond 15 seconds I think is a very reasonable system, especially when you're starting to run over, let's say you're trying to run your blockchain over Tor or something where the network delays are very high and unpredictable. So Tendermint, it helps us with two of these concerns we were caring about, which is the scalability like I talked about and the fault tolerance. And if you want to learn more about Tendermint, we have a formal specification written by Zarco, Jay and Ethan. A lot of people didn't like Tendermint for a while, like a lot of academics, because Tendermint has a very engineering focus rather than academia. And so we just rewrote a spec, a small spec and just started implementing it without doing the form. We had heuristical proofs. And so that's why a lot of people academics were like, oh, not real until you have a proper paper. So finally this year, like last year, October or so, we finally put out a proper paper with like formal proofs of safety and liveness. And so you can go ahead and read that, that link, that cool like poster thing, that's that link. And Christine wrote a blog post a few months ago comparing Casper to Tendermint. And so one of the main things is Casper is still seems to be liveness favoring for what reason I cannot imagine. So Tendermint Core, this is our actual implementation of Tendermint. So it's written in Go. There is some very early progress in rewriting it in Rust right now, but it is the first production grade BFT consensus engine. A lot of people thought that BFT doesn't scale, but because almost all of the implementations were written by grad students for their thesis or something, and so they wrote it in Python single threaded. That's not how you build a production system. If you want to build a production system, you need to have a concurrency multi threaded systems and you also have to Writing a Tendermint looks so simple in this nice little diagram. But when you actually start getting to like writing an implementation, it's like no, you have to start worrying about like, you know, you think you're on round three, but you're suddenly getting blocks from round five and you're like what's going on? Are these malicious blocks or are these like, you know, am I just delayed from the rest of the network and everyone else is on round five? On round three, you have a lot of caching and like, you know, building the production implementation is much more complicated than just like a small prototype. **B** (27:42): Yeah. What is Rust going to give you that go doesn't. **A** (27:46): Just slightly better performance? Honestly, I'm not a Rust developer, so everyone else seems to be going crazy over it. So Ethan Buchman, who's the cto, he's the one who's really been pushing the rewrite in Rust. So I think he's just working on it on his own right now as a little side project. But I think it's just a performance benefits. Yeah. Tendermint Core, first production grade BFD consensus engine. I think the second production grade BFT consensus engine we're starting to see is the Honey Badger implementation by the POA Network team. So I have an eye on their implementation. It's pretty cool. And so what Tendermint does is it handles all the P2P and consensus logic for you, which I'll get into in a second. And here's another view of how Tendermint works. Yeah, so scalability. This benchmark was from like three or four years ago. So this is very clearly outdated. And this 14,000 number sounds high, but it's very misleading because this is Tendermint running without a state machine. We're just coming to consensus on bytes, but not actually processing those bytes in any way. So in a blockchain really you're like, lot of limit is actually in the state machine, not in the consensus protocol. So as soon as you slap an EVM on top of Tendermint, it quickly jumps from 14,000 to 200 transactions per second. That's still way better than, you know, Ethereum proof of works 15 transactions per second. So, you know, there is. You do get some scalability benefit. It's not, as you know, it's not the magic bullet because really what you have in scalability is there's two types of scalability. There's what's called vertical scalability and horizontal scalability. Vertical scalability is how much you can scale a singular blockchain. So it's kind of like scaling, getting a beefier and beefier server, while horizontal scalability is you scale out, you buy more servers, or you use some sort of parallelism. That's what horizontal scalability is. And so Tendermint Core gives you a decent amount of vertical scalability, but it's not the magic bullet, which is why we need the rest of Cosmos for the horizontal scalability. So the other thing, what Tendermint does is a blockchain essentially has three layers to it. There's a networking layer which handles peer to peer gossip, et cetera, transaction propagation. There's a consensus layer which does, like, you know, the actual BFT consensus engine. And then there's an application layer or a consensus layer. It could be like the proof of work. And then there's the application layer, which is the state machine of a blockchain. So in Bitcoin, it's their UTXO processing system. In Ethereum, it's the EVM as the application layer. What Tendermint does is it creates a standard software stack that handles these bottom two layers for you. And then you can write your application layer in any language you want. And it talks over a socket protocol called abci. And so it's similar to like, you would have different services running that talk to like an Apache web server. Same thing goes here. You have your state machine written in any language you want, talking to Tendermint Core. And, you know, so you can take the EVM, run it on this, called Ethermint. Someone took the chain.com VM and ran it on Tendermint. They called it Chainmint. And we have, you know, implementations of, you know, we have example applications for running on Tendermint Core in like, every language from like, practical to ocaml. And another cool thing, what Tendermint does is it allows you to define your own validator set however you want. So you can use Tendermint in a proof of authority setting, in a permission setting, or you could use it in a public proof of stake setting. You could even use it in a proof of work setting if you wanted to. Not in Nakamoto consensus proof of work, but rather people are doing hashing, submitting hashes to the chain, getting voting power, and then are able to use that voting power to become validators in the system. I haven't seen anyone implement this yet, but I'll probably go ahead and do it at some point. I don't see anyone else doing it for a little while. I want to show a proof of work BFT system. So that would be really cool. And one of the benefits of this being able to define your own validator set, which is what Tendermint Core allows you to do, is it enables a level of sovereignty. And so if anyone knows what this flag is, it's the flag of a country called Liberland. It's like this little made up country in between Serbia and Croatia caused by an interesting weird geographic quirk. And so, you know, I've been helping their team out just for me, it's just a little sandbox for different blockchain like proof of concepts or like, you know, if I want to create like a voting system or something, I go test it in library land and then like go to a real country and be like, hey, look at my little sandbox. It worked there. You want to like try it in like zug or something. So that's why I've been helping them out with that project a little bit. And so one of the things is I believe that you can have higher security than pure economic incentives alone. This kind of goes back to my whole belief in localism where if you have some level of community incentives beyond just pure economic, you can achieve higher coordination and security. So if like all the validators of Liberland were Liberland citizens, right, like, and that was part of the mechanism of becoming a validator, you know that could you can they have social and political incentives beyond just pure economic and they're less likely to try to attack the system than if they were just doing it out of a pure profit. Profit motive. And so there is this like, but you know, it could still be proof of stake but with other requirements. Right? So having to have that, the library and citizenship, it's like an asset. And so it's like marked on your upward id, so that could be a requirement. So I think there's this interesting continuum between private and public blockchains. It's not just this binary thing. And so there's a lot of room to explore there. And I do think sovereignty can help you with security. So right. Tendermint Core, these are some of the benefits it gave. We got that sovereignty I just talked about. You have the customizability. You can write your state machine in any language you want. You can write any state machine you want. You can take an existing state machine and run it on top of Tendermint like we saw with like the EVM or the chain.com VM. It helps with the scalability, like the vertical scalability we talked about. And it helps with that one click deploy system where like you know, you no longer have to, you still have to go out and find your validator set. But it helps in the situation where you don't have to write a consensus protocol or peer to peer logic. Most developers, they want to write their application logic and not go and write consensus and peer to peer by themselves. It's nice that Tendermint just wraps this up and handles it for you. So if you want to learn more about Tendermint Core, there's the documentation, there's some performance testing results that are way more recent. So that graph I did was something like three or four years ago. These results, BigChainDB just did some performance testing about three or four months ago. And so they have way more up to date performance numbers. And then Ethan Buchman's master's thesis, which it's also a good resource for just Tendermint BFT as well as some of the design of Tendermint Core. All right, so like I said, you know. **B** (35:44): Yes. So about bitching. They announced that they were going to integrate Tendermint last year and they said that as soon as it's stable that they'll launch it and announce it. And what kind of delay. **A** (35:59): I'm not sure what the status of BitchainDB is as a project from what I last rumor. Not rumor, but like last thing I heard was like, you know, they gave that team created a BigChainDB foundation, gave that project to BigChainDB and now they're focusing full time on Ocean Protocol. And I'm not sure who's actually developing BigChainDB right now. I'm not too up to date with the actual internals of their project right now. Sorry. And by the way, a number of people are using Tendermint Core already who maybe aren't using any of the rest of our stack, not using our Cosmos SDK or anything. So like, you know, we have like a FX exchange that you know, does over a billion dollars per day. You know, they're using Tendermint Core internally. The national Thailand is China is using Tendermint right now for their national ID program. I heard rumors that PBoC, the People's bank of China is using Tendermint Core right now. So yeah, there's a number of people who are using Tendermint already in production systems. Yeah. And so any other questions about any other questions about Tendermint, BFT or Tendermint Core? **B** (37:18): So if you go to GitHub, it says Alpha and every time it's been in the past, every time there's an update, the file format changes. Pretty much every update will basically discard your. **A** (37:36): Yeah, right now, basically right now even Tendermint is going under rapid iteration, largely not on the BFT consensus side. The consensus logic is pretty standard. That is done and we're not playing too much with that. What we're playing with more is. **B** (37:58): A. **A** (37:58): Lot of the stuff around ABCI and stuff like some of this, adding fields to that protocol, that socket spec and whatnot. So yes, right now tendermint Core is pretty solid from a BFT standpoint, but just from the tooling around it, it's still going under rapid iteration. And so if you are using tendermint Core, we do highly right now, until it reaches some level of stability, we do recommend like having some sort of direct lines of communication with us. Like we'd love to add you to like our partner Slack or whatnot to coordinate there. **B** (38:36): Yeah, one of my experiences, you got one version and you upgrade to another version and all of a sudden there's new requirements in the config files. Yeah, yeah. So I know. I'm kind of hoping for a time where it's like stable on EB7K and this version and next version is going to not require you to change your infrastructure. Right, right. **A** (38:56): We're going to start shifting into more like versioning, better versioning, where we'll continue to support older versions and obviously upgrade them with bug fixes and stuff. Right now we've kind of been only having one development pipeline where bug fixes are going in the same spot as features and whatnot. And so we, we do definitely have to improve on that process and make it easier for our end users, which is you guys. Yeah. Right. Ok. So like I said, you can use Tendermint Core with any mechanism of choosing your validator set, and that's decided by your state machine. Your state machine basically tells Tendermint Core here is the validator set and you can use it with permission system. But what we personally propose is using it with what we call bonded proof of stake. And you know why proof of stake? You know, this is like a tweet thing I did from like two years ago now, 2017. But like, you know, there's a lot of benefits which is like, you know, the environmental, the scalability, which is actually not correct because, you know, proof of stake itself isn't what's giving you scalability. It's the BFT Tendermint BFT that's giving you scalability. But people often like, you know, same thing with proof of work. People often mix up Nakamoto consensus, the consensus protocol, with the Sybil resistance mechanism and they're really pretty distinct. Same thing with here. So scalability, not really. But you know, it could possibly help with decentralization where like, you know, asics continuously just keep getting more and more centralized. It helps you with like dishonest resistance. And so you know some basics. Like, you know, you use bonded tokens as the resource limiter for determining voting power. So you take some of your tokens and one of the chains that we're building called the Cosmos Hub, the token is called an atom. So you go ahead and take your atoms and you put it in a bond and whatever percentage of the bonds you have were yours. That's how much voting power you get. And it eliminates the wasteful energy consumption of proof of work. Instead of using energy as the resource limiter, you used locked capital. And in my opinion, Dan Robinson made this clip for me where like in proof of work, when you burn electricity, you are burning society's resources. When in proof of stake, when you lock up capital, you're actually just redistributing society's resources because everyone else becomes slightly richer. And so it's not a waste of society's resources, which really bugs me. It's a public permissionless system and I maintain that it is. Just as a lot of people will say, oh, there's more censorship concerns in proof of stake than in proof of work, we can have this discussion afterwards. But I maintain it is just as censorship resistant as proof of work for any practical scenario. And so we can have that discussion later. Yeah. **B** (41:46): So two questions. The first is around distribution. **A** (41:49): It seems as though proof of work, even though you may dislike the burning. **B** (41:53): Of resources, it is a very effective and fair distribution method to get coins out into the market. And the second question is around is around what is the incentive for people to actually stake outside of why would. **A** (42:08): People lock up their capital? How is Cosmos going to compete with. **B** (42:12): Other reasons to allocate your capital elsewhere? Is it going to have a return on all those things? **A** (42:17): I will answer that question in two slides. So, and then we solve this nothing at stake problem with slashing and unbonding, period. So you know, Tendermint Core, it tells the state machine, oh, I found these malicious validators, do what you want with them. And so our bonded proof of stake mechanism, it burns their coins and like, you know, there's other things you can do with them. You could like, you know, put them on a bulletin board and like everyone can publicly shame them. But we focus on like economic incentives of like burning their coins. And we have a mechanism for delegation where like, you know, the process of running a competent validator is not easy as despite what a lot of Ethereum community would like to think like running, I run a validator called CICA and it Requires running a hyper secure, always online hotkey. And if anyone can hack that validator, they can burn all your money. And so that's not okay. That's not like accessible. Your grandma is not going to be running a validator. Right. And so this delegation mechanism allows anyone who has coins to still delegate it to another to a validator and still participate in the staking process. Choose which validators to go to. They have skin in the game, so if their validator misbehaves, they get slashed as well. So they really have to be very careful with who they delegate their coins to. We have automatic reward distribution. So unlike for example Tezos, a lot of their bakers have just been running away with their delegators funds. Instead we have like an efficient mechanism for like, you know, making sure the rewards get distributed properly to the delegators. And so, you know, there's no risk of the validators becoming malicious. The validators can't screw over the delegators without also screwing over themselves. That's kind of one of the goals. There's. And we also solve a lot of the stickiness issues with proof of stake with features such as instant redelegation and something called validator commitments. I gave a talk at csc. I'll have a link to that talk. You can go watch that if you want to learn more about proof of stake about all of these cool features that we've created. And so to answer that question, the multi token model, our claim is that we are not trying to make money here. The staking token should actually be only a staking token and nothing else. In fact, we make it very inflationary in order to punish someone who is not staking. Our goal is to have the majority of atoms be staked. We're talking about like over 80%. Probably money in our system is going to be other stuff, maybe bitcoin or stablecoins, whatever. And the incentive to stake is you earn the fees that other people are using. And so our system allows you to pay fees in any token. So you don't have to. Like I said, we don't like these empires who are charging ether for fees. Right. We want a system where if you have bitcoin and you want to pay your fees in bitcoin, you can do that. If you have ETH and you want to pay your fees in eth, you can do that. If you have DAI and you want to pay your fees and dai, you can do that. So we have an entire mechanism designed to allow this. And so as a validator, your Benefit of staking is that you earn the fees that people are paying in monetary assets like BTC and ETH and DAI and Dogecoin. And so it's very similar. And this like staking token model is very similar to the ASIC security model where like, you know, it's why ASICs are more secure than GPU systems. Because if you have the majority of staking tokens already staked, it's very hard for an attacker to suddenly buy up a large amount of staking tokens on the public, on the open market. And yeah, like I said, it massively improves the user experience and we get away from this like empire like mindset where you have single fee tokens. **B** (46:01): Yeah, you're saying this before but how come you don't think fees should be paid in a token that uses stake? **A** (46:09): Because if the staking token has too much utility outside of staking, it's going to be too liquid on the open market, making it very easy for an attacker to suddenly buy up a large amount of the staking tokens. It's arguing with ASICS as well, right? Like you can imagine that almost every ASIC in product, every SHA 256 ASIC in existence right now is actively mining Bitcoin. Right? Or Bitcoin cash I guess. But it makes, and that's why minority hash power chains are not secure because it's very easy to suddenly bring in a whole bunch of new hash power into a chain that doesn't have it. But In Bitcoin the ASICs are helping secure it because it's almost impossible for any individual to go buy like 51% of the ASICs in existence. Right. And the only way for them to do it is to manufacture those ASICs, which isn't really feasible in like in a non detectable way. **B** (47:10): You know you also mentioned like 80% is pullback state. **A** (47:15): That was a number I made up, but I'm talking about something like high. **B** (47:18): Number and then 20% will be more. **A** (47:23): No, no, no, sorry, no, no, no. What I meant was 80% of the staking token. So let's say there's a billion atoms in existence, we want 800 million of them to be staked. That's what I meant by 80%. Maybe there's 200 million that's open because people are actively using them for trading or whatever they're doing with it. Right? I don't know. **B** (47:40): I guess my question is you guys are. **A** (47:46): Yeah, but the idea is it's going to be hyper inflationary. So if you don't the longer you have your token not being actively staked, you're going to be getting like inflated away very quickly. In fact, we didn't want to do inflation if we could have. We would rather implement it as a demurrage where like if your stake token is not kind of like an asic, right. If you're, if you're not using your asic, it's just like degrading in value. Because it's not. **B** (48:11): My question is, I mean, you know, for mining you set up in such a way, I mean, it's a combination of proof of work or proof of stake. **A** (48:20): It's only proof of stake. There's no, there's no proof of work at all. In our, in our, one of the, in this bonded proof of stake mechanism we're building, there's no proof of work. Now like I said, that's not to say you can't use proof of work in your own chain and connect it to Cosmos. Right. You can completely do that. We're just, this is just one, this just has to do with that. Like one of the goals that I really cared about, sustainability. And we wanted to build a tool that if you, if your chain cares about this, use proof of stake. If you want to go use proof of work, you can do that. And it's completely permissionless. The point of Cosmos is to be an open system where it doesn't discriminate on this basis. On like the basis of that people. **B** (49:02): Who focus too much. Yeah. **A** (49:07): Yeah. And so basically what we've been spending a lot of time on is making sure that like trying our best to mimic the security properties of proof of work in proof of stake. And like, especially like the centralization concerns. I think every proof of stake mechanism that's been proposed so far is going to be way too centralized until we've added these things like instant redelegation and whatnot. **B** (49:28): So you're talking about losing to inflation, you're also saying it's not inflationary. I'm trying to reconcile. No, no. **A** (49:37): This atom token is hyperinflationary. **B** (49:39): Right. So does that mean that new tokens are injected into the system? Yes. And it's going to the stake. Okay, hold it. **A** (49:46): Yeah. So if you're staked, it's going towards this. You get a cut of those new tokens. What I would have liked to do is do demurrage where it's not. There's no inflation, but rather tokens that are not staked are just decaying in value. This would have been really nice from I think it's simplistically like it's less mentally simpler to think about. And it would have also been nice from a tax perspective because then it's not income, but if you're staked, it's rather capital gains. That would have been nice, but it's just very hard to implement this from a technical standpoint. And from a UX standpoint, you're basically. **B** (50:18): Saying people who have atoms stake, they keep getting more and more atom. **A** (50:22): Yeah, but really the goal. Yes, that's the goal here. And the goal is to like allow. Yeah, yeah. The idea is that people who aren't stake are having a smaller and smaller percentage of the total supply of atoms. And the total supply of atoms, the valuation can be like thought of as like a discounted cash flow on like, you know, future fees coming into the chain. Yeah. **B** (50:45): How does that prevent centralization? Because it seems like If I have. **A** (50:48): 30% stake and it's hyperinflating, if it's. **B** (50:51): Not staked getting all the new tokens, then the rich gets richer kind of a scenario. **A** (50:56): Yes, but like I said, it's not going to be that there's no liquid atoms. Right. It's not possible to imagine that 100% of atoms are staked. And we actually designed our inflationary mechanism so that the less atoms that are staked, the more hyperinflationary it becomes to encourage more to stake. And then as it reaches higher numbers like 80%, the inflation amount like decreases. So that way we still have some amount of liquidity in the open market. Yeah. **B** (51:26): So does the inflation come in the form of the transaction fee values changing over time or are you because you can really like in the market in an open market scenario, Right. You can have any curves you want, but that doesn't mean that the markets don't follow that. How does that. **A** (51:43): Are you saying, does inflation account for changes in price? **B** (51:46): So if you just inject more coins. Right. But the value of the transaction to. **A** (51:51): Stake into something remains the same. **B** (51:54): You just added more currency to the system. Right. **A** (51:58): We can't force rationality upon our users. But the idea is that in theory, as we inflate the system, each individual token should become less valuable. But the overall market cap of the entire atoms shouldn't be changing just because we're inflating it. **B** (52:16): What are those ranges of inflation? Is it like instead of years or like. **A** (52:22): Yeah, so no, so I'll say this, and I mentioned this in my actual proof of stake talk, which is this link right here. But like all of these Constants that we're using are just made up right now. Like in my proof of stake talk, one of my constants I used like E over PI for one of my constants just to show the absurdity of these, of some of these constants where these are. And they're just as absurd as like any of the constants that like even Bitcoin created. Right? Like, oh, 21 million. Where did that number come from? Halving every two years. Where did that number come from? Right. And so, you know, just proof of stake. I don't, I don't think we've seen any production implementations yet that are actually like solid and valid. And so hopefully as we deploy proof of stake blockchains, we'll slowly start to learn like where these constants should lie. And so for the Cosmos Hub, which is one of the chains we're building, we're setting the limit. At the minimum, inflation is 7% annual and the maximum is 20% annually. So if it's 0% of stake is staked, then the inflation percent is at 20% and once it gets to 67%, it, it drops to 7% and then it just remains constant for the rest at 7. **B** (53:35): If the currency does get super devalued in the future, does that mean that there's less at stake? You know what I mean? **A** (53:42): Just like from like there's nothing at stake. **B** (53:44): Problem perspective, like if this currency gets too deflated, will people care if they lose those tokens? Yeah, because they have more tokens staked. Right. So it's the same, like it's the. **A** (53:54): Same economic value of. Yeah, each individual token is less valuable, but the amount of tokens that are staked are increasing. Right? Yeah. So if you want to learn more about this. So if you want to learn about all of these features like instant read allocation, whatnot, watch this talk. If you want to read about this multi token model thing, I have a much longer form explanation justifying all of these things. This is a paper I just submitted for a conference, so don't like tweet about it yet because I don't want the conscious people to get mad. But if you want to read it yourself, you can read it there. And then this is another paper that was talking about the efficient token distribution. Reward distribution. No, sorry, that's a typo. It should be reward distribution. How do we make sure that validators don't run away with delegated response? But how do we do this in a computationally efficient manner without like iterating, you know, because there might be Millions of delegators. We can't iterate over every delegate or every block in order to give them their rewards. Right. So we need to. This is just interesting from like a computer science perspective of how we implemented this. All right, yeah. Any more questions, final questions on this proof of stake? **B** (55:05): Yeah, I hear about this game of State that happen over time, like Game of stakes, one, two, whatever. Yeah. Is that, is that directly tied into anything that you're doing? What are you guys learning from those Game of Stakes? Yeah. **A** (55:19): So in Game of Stakes what we were doing was it was a test net for our Cosmos Hub blockchain. And the idea there was, we just, I don't know, it was a weird idea. The idea was let's simulate a long period of time in a short period of time. So let's like make the inflation percentage Instead of like 7 to 20%, we made it like 10,000% annually or something in order to mimic lightspeed over long periods of time. And we just wanted to see what kind of attacks happen in practice. And we were actually pretty happy because a lot of the cartel attacks and stuff just weren't able to happen because validators are actually competitive enough that they don't cartelize. And so that was very interesting that we just got. It was just a mechanism of. It did two things. Gamma stakes, it helped test some of these proof of stake mechanisms. And two, it just helped test our software. **B** (56:13): Is that the same thing as the Gaia network? **A** (56:16): So Gaia is the name of the software that the hub uses. And so yes, the game of stakes was a testnet running Gaia. Cosmos Hub is another chain that's running the Gaia code base. Does that make sense? **B** (56:30): Yeah. **A** (56:30): Cool. Yeah. I'll get into a bit of game stakes later. Ok, cool. All right, next one. Next up, Cosmos SDK. So let's go back to our generations system. Generation one, if you want to develop your own blockchain, got to fork the Bitcoin code base. That's just a recap of what we're saying. Ugly spaghetti Code C, very monolithic stack. So everything's in this like one code base and there's like consensus logic mixed up with state machine logic and stuff. It's like especially things like Segwit makes it even more like so and because of that it's like, you know, even if you fork your code base you have full control over it, the sovereignty aspect, but you know, you just don't have. It's very difficult to work with. It's hard to make anything very advanced which is why basically every early blockchain project was just a slight fork on Bitcoin. You know, changing the monetary mechanism or changing the hash algorithm. Nothing very fancy. Ethereum, you know, like I said, easy solidity makes it super easy or super easy but you know, easier and you know, yeah, we already went over all this, it just makes it a lot easier. But you lose out on the sovereignty and all the stuff we talked about. So Cosmos SDK here the premise is let's build a framework for making it easy for people to write your own blockchains. And the idea is you're writing it in native code, it's in go, you're compiling your blockchain code base and then running it as part of the client code. It's not running on this Turing Complete vm, it's these application specific blockchains in. You know what I was saying, Smart contracting is useful and I'm a big fan of smart contracts. As long as they're used as they sound as contracts. If you need to make a one time contract, if you need to make a short lived thing, smart contracts are great for that, but they're not great for Dapps. You don't want to deploy DEXs, write DEXs in smart contracts. You don't want to write prediction markets in smart contracts. You don't want to write these complex systems. ICOs were the perfect use case for smart contracts. They're a short one time like use thing that's very short lived. That was a perfect use case for smart contracts. But now we start people seeing like deploying like augur on Ethereum and it's just like it's not working. So most production dapps don't actually need a Turing Complete vm. You know the application logic, you're writing in core code and then you deploy it. Having these application specific blockchains, it reduces the attack surface. Like you know, you don't have to worry about the complexities of the vm which essentially caused like you know, the DAO attack, both the parity bugs, et cetera. You get the efficiency gains due to lower computational overhead. So that you know, EVM has you know, about 100 opcodes. Let's say you just wanted to make a simple storage system, right? Nothing else. You don't need that many opcodes. You can, you know, you reduce the complexity. It's all compiled rather than interpreted and you can fine tune to optimize for your application. So you know, Bitcoin uses UTXOs because UTXOs are better for payment systems. They can be parallelized much more easily than the account model. But if you use the vm, you have to use what they tell you to use, which is like the account model. You don't, you don't, you lose out on that ability to fine tune, to optimize and the customizability we were talking about. So the Cosmos SDK, it's a framework for building blockchain applications. You can think of it almost like the Ruby on Rails. The goal with the Cosmos SDK is to do what Ruby on Rails did for web development. It provided this very easy to use web framework that had a lot of packages or gems and you can combine into making more complex. **B** (1:00:36): Apps. **A** (1:00:36): And so it's completely open source and available on GitHub. And it has this concept of like, it's a very modular architecture. So you know, you can pick and choose pieces from like these modules and fit them together to create your own blockchain. These modules are secured by, you know, this thing called principal uses, principle of least authority using this thing called object capabilities, if anyone's familiar with those. But fun security stuff, you can look into that. But yeah, and so the idea is you can use modules that other people have already built or you can build your own modules and hopefully open source them. Well, you have to open source them if you want to deploy your chain and downstream them to enrich and contribute to the Cosmos ecosystem. So we can see what I mean by this. So, so we have these core modules which are, you know, we have accounts with coins and everything. We have that whole automatic reward distribution. Our entire bonded proof of stake mechanism that we proposed. We have it implemented in our staking module slashing ibc. I'll get into governance. We have on chain voting and everything. And like I said, you know, I'm pretty conflicted myself on chain governance but in certain chain you don't want to use it, you just pop it out, you don't have to use it. And so you know, one of the chains that we're building is, you know, called the Cosmos Hub. It's really just a mechanism of dogfooding our own software. And so no it uses the core modules. Oh also Tendermint is like you could think of it as a module in the SDK. Tendermint is cool because you can use it as both a, because it's in Go, you can use it as a socket protocol with anything. But if you have your estate machine go, you can actually import it as a library. So that's kind of cool. So core modules plus another Extra module called peggy. Ethermint is the core modules. Plus this EVM module that we're writing and this shared security module. There's a project called Iris Network. They're doing some microservices stuff that they're writing modules for. There's a project called Lino where they're adding some an auctioning module, a bandwidth fees module. They have like a reputation module that they're building Kava, they're a team that's writing a lot of payment channels modules and like some modules to interact with the Interledger protocol. Fourth State is a team based out of Boston and Berkeley. So for example, they're using our PEGGY module that we originally created for the Cosmos Hub. But they're like, because it's an open source ecosystem, they're using that module along with their own plasma module that they're developing. And so the idea is there's so many more modules that are yet to be built. This slide is actually a little bit old. We have some people already building Dex modules and stablecoin modules and Oracles and stuff. So there's a lot of cool stuff to be built and enrich this module ecosystem. So the idea here is, you know, the efficient state machine. All those benefits of application specific blockchain instead of pure and complete vm, you get a lot of the customizability. So you know, the accounts module that we use actually does use account numbers. But you can also use the SDK to build a system that uses utxos. You have that full customizability there you have. It's easier to develop. You know, GO is just way better than solidity. It has like, you know, so much documentation around it, tooling, linters, IDEs and a 10 billion, I don't know how much Google is worth. Multi, multi, multi billion dollar company pouring billions of dollars of resources into developing this toolkit. Instead of having like five people at the Ethereum foundation developing solidity and then it helps with the scalability aspect from the application specific side that we talked about. And now some more resources. So this SDK tutorial is what. So you know, this talk is part of a series. The third section we're going to have to be doing the going through this tutorial and building a sample module, a sample application on the SDK. So that's the link if you want to get a head start or something. Here's the repo of the Cosmos SDK. And this is a blog post by Gautier, one of our co workers. This longer form exposition on the case for why Application specific blockchains make sense. Cool. Any more questions on any questions on the SDK? Cool. **B** (1:05:11): How long before Mainnet launches? **A** (1:05:15): I mean I'll get to that when I get to the Cosmos Hub section. Yeah, yeah, the. And so the next two sessions of this series are going to be focusing a lot on the SDK. So the next one, Aditya from 4th State is going to be coming and showing how he built a plasma module on the SDK and then the next one will be the tutorial. Then this is sort of some of the other stuff that we work on, like more of the lower level lib stuff we have like we have a encoding standard called Amino. It's basically like what we claim is an improvement on Protobuf. It makes it easier, like it's deterministic, which is nice. And then it naturally supports interfaces instead of using one of like Protobuf. And the cool thing with this is you can actually generate your Proto files, your Amino spec files from GO code. So instead of having to write Protobuf files and then having the translator structs in Go and then your actual operational structure Go, you can just write your code and then Amino handles the creation of the tooling for you. It's just this nice developer tool. We do a lot of just hacking on side developer tools and this is sort of one of them. Another one is IABL tree. It's a self balancing ABL tree where all the values are stored at the leaves and it's immutable and so it updates using snapshots and caching. That's where the I comes from and the plus is from the values being stored at the leaves. All operations are log n and no hashing keys is required. And so this is actually super important which I don't think a lot of people realize and I did not realize for years I have wondered why Bitcoin does not have a state tree. Why doesn't not make a merkle tree of all the current sort the current UTXO set and make a merkle tree out of it. This would help a lot. With like proofs of non inclusion you can prove that a UTXO has been spent or has not been spent yet to a light client. This is so useful and like it makes payment channels much simpler and whatnot. And so I was always just so confused and I've never seen a good explanation for why they don't do this. And one of the Bitcoin cash devs, Amari Sachet, who I'll be doing an epicenter episode with this week. So he's the first person who finally gave me a plausible explanation. Here's the reason this is sort of like a tangent, but I don't know, I just find it so cool. So I'm going to go on this tangent. What happens is if you want to sort the Merkle, if you have a sorted tree, Bitcoin UTXO IDs are hashes as well. Right. And so they're being inserted randomly into this tree. And because of this, every time you insert something into the key you have to remercalize it and you have to get all the inner nodes and to do all this remarkalization as your state becomes bigger, you're going to stop being able to fit this in memory and you're going to have to start writing this to disk, some of your inner nodes to disk. And now because it's random, there's no caching strategy that you can use in order to kind of cache things in a node and have some sort of predictable system. If there's no caching strategy and you're just constantly reading from disk, the system is just going to become so slow. Ethereum has the same problem with their partition tree. They hash the keys and they write it to disk. And I claim that this is one of the biggest problems with Ethereum state model and it doesn't allow it to scale. The Turbo guest team has been doing a lot of work to improve this, but I just think that when he explained this to me they're like, oh that's so cool, I've never thought of this before. And so cool thing is we don't hash our keys so we don't have this problem. You can have an efficient caching strategy and you don't have this state bloat causing an issue with disk reads and writes. Cool. You know and then we do like a couple of other cryptography stuff like you know, we have our own library with amino support built in. Some cool multi signature methods. Some of our interns have been working on like from last summer. We're working on some BLS aggregate and multi aggregate signature work and some implementations and a verifier in the evm. So this is just sort of like you know, other cool stuff that we just create open source work for and we also have a. Actually I'm not going to that. Yeah. So you know, some of the, you know, the low level libs, it just, you know, helps build stuff a lot easier. Especially that cryptography library that has Amino support. It makes it, the development process makes It a much easier, much easier. And the whole IAVL tree with the no hashing I think adds to the scalability benefits as well. Yeah, and you can read more goaminorepo IVL repo and the BLS repo. The SDK was a framework for building your state machine, right? Like you could write your state machine from scratch if you wanted to. And a lot of people do. Like I showed you, like, you know all the languages we have, like people have already built stuff in. Most of them were just built using like bare metal state machine code bases. But the SDK was meant to like it provided you a nice framework, this modular system to make it easy to write a state machine in Go. But it's not going to be the only framework. And so we already have a internally developed secondary framework called Lotion js. And so it's kind of probably hard to read from where you guys are, but it's like super simple. It's this nice framework that allows you to write your state machine in JavaScript and they're building their own little module ecosystem. It was created by two of our engineers, Judd and Matt, who recently just like spun out and created a company called Nomic, still being funded by the icf, by the Cosmos foundation and whatnot. So this is really cool and I think the use cases are different. If I'm going to be building a high security system, I'm still probably going to use go, not JavaScript. But I think there are people out there who maybe will prefer the Lotion JS framework rather than the SDK. There's also one called iovweaver. We built a fork of the Cosmos SDK. So one of our lead engineers, Ethan Fry, he used to work for Tendermint and then he left about a year ago now. And so when he left, he actually took the version of the SDK he was working on and kind of forked it and kind of had his own little vision for it. He really wanted to make it much more simpler. Our SDK is very feature packed and has all these cool things. He wanted to do it as simple as possible with limiting a lot of the features. So I think it's a really cool framework as well. So there's that framework and over time the idea is we can add more and more frameworks. So one of the things I really want to do is take Parity's building a framework called Substrate in Rust and I think that would be really cool too. We can just take any framework, put an ABCI wrapper on it and have it run on Tendermint Core and, and that's really cool. So that's something that I'm going to be looking into in the next few months of how to run use substrate to also create Cosmos chains. And yeah, so you know, benefits here you get the whole efficient state machine customizability easier to develop. Here's the link to the lotion JS repo and here's the link to the IOV weave repo. Cool. And Ethermin, this is a, you know, this is kind of a framework as well as it's a chain that we're building. Ethermint's kind of complex. So ethermint what we did was if you remember from previous slide, what I ha. What I showed was we just took the EVM and ran it on Tendermint Core. We like literally took Go Ethereum Geth, stripped out their mining logic and just ran it directly on Tendermint Core. This is cool. We had Ethermint working and everything but. But the problem is all of these staking modules and stuff that we've built spend a lot of time implementing in the Cosmos SDK. We couldn't really use that in our ethermint. We would have to rewrite our staking logic and figure out where to fit it into Geth. So instead ethermint 2.0 is we just created an EVM module inside the SDK and so it handles all the account databases, state trees, uses the same RLP encoding that the EVM uses. The cool thing you call it into, you can make calls from the EVM module into other SDK modules and to the evm it just looks like a precompiled call so you can have a precompile that's like make a vote and you can just call like go and it'll call the governance module in the SDK. So this is really cool. And so you get the best of both worlds here. If you are still using, let's say you already have a project that you spent a lot of time developing and you already spent a lot of resources investing into solidity code development. So you already have something. You get the scalability of Tendermint, you get all this modularity of SDK, you get to use the existing ecosystem, Ethereum contract and dev tooling and you get the EVM module from Turbo Guest. So we've been working with Alexei from turbogath to take a lot of his massive improvements he's done to the underlying state stuff and database performance improvements and whatnot. And so we're adding that and the important thing is it is Web3 compatible. So there have been other previous implementations of EDM on Tendermint. The most famous one is by a company called Monax. It's a project called Hyperledger Burrow. So that is an implementation of the EVM on Tendermint Core problem is it never did Web3 compatibility and because of that it never really took off. But now that we have Web3 compatibility in this, it works with Metamask and Truffle and all the tooling that exists right now. And so if you want to use Ethernet, you really need that Web3 compatibility. Yeah, you know, these are some of the improvements that Alexei has been working on Turbo Gas, you know, not going to go into it. There's two ways to use the EVM module. You can use it as a blockchain on its own. So you know, you can just run a blockchain that has just EVM module and some other core modules and just say, and you can just use it like you use Ethereum today, or you can use it as a library where you can deploy your own Cosmos chain with EVM support. And so then you can like, you know, this is useful because maybe you need some level of contracting capabilities for your users, right? But you want your core logic of your application to be in Go. But like you want your users to be able to deploy some logic in Solidity. Or you also get, you also get like, you know, you can use it as a modular upgrade path. So let's say you're a project like Augur. You've already spent a lot of time deploying your entire thing in Solidity. What you can do is you can launch it as a chain where currently all of your logic is in the evm. But then over time you can like start moving certain pieces out of the EVM into core SDK modules and have it be this like slower process of shifting over. So like in Augur, you can start moving your like, you know, betting system out, then you can move your Oracle system out and then you can move your like, you know, marketplace for the rep tokens out or whatever. So that it also provides like an interesting upgrade pathway for existing Ethereum based projects. Yeah, it's kind of a repeat of what I've said. And so, you know, this really helps, especially on the, you know, helps the Turbo Gas improvements help make the state machine way more efficient than Ethereum Main Net. Ethereum, you get that customizability. But because of library and stuff you can like, you know, now you can add your own precompiles and it's very easy to write precompiles by writing them as modules and you get that whole like one click deploy that you already are familiar with with Ethereum. So this is a presentation one of my coworkers Chris gave. **B** (1:17:43): Yeah, we've been talking to Augur and other Ethereum Dapps to basically tell them about the benefits of transitioning to Cosmos. **A** (1:17:55): Yeah, yeah, definitely. We've been in touch with a lot of these projects. Augur, Gnosis maker, most of them are definitely interested. And especially when pitching this slow upgrade pathway, I think that's what got people very interested where I think for a lot of these major. That's kind of why we Originally we were only thinking of ethermint as a chain that we're deploying, like ethermint where you deploy stuff. And then we thought ethermint and then Cosmos SDK are separate. But then we really wanted to help people push towards the SDK, but that really freaked people out. We're not going to go rewrite our entire stuff in that. And so now that we pitch this slower upgrade process, people seem to be pretty open to it. And a number of projects, I think ShapeShift is definitely one of the Shapeshift they have that the whole. I forgot what it's called, that product of theirs. But like some they're deploying on Ethermin and like using the EVM but slowly starting to write stuff in the SDK modules and stuff. Yeah. And then so you know, a couple of people who are using. Oh, by the way, some people who are using the SDK like recently Binance announced that they're building their decks using the Cosmos SDK, which is pretty cool. Yeah. So like I said, presentation from Chris at devcon, kind of going through Ethermint and explain that. And then here's the repo that you can take a look at. And now finally, probably the thing that most people. **B** (1:19:24): Yeah, I'm sorry, I had a quick question on ethermint. So we've been following it pretty closely because the project we're working on very well for us, but saw that there. **A** (1:19:33): Hasn'T been any development now for like. **B** (1:19:35): Two months or so. I was curious if is it still part of fuel's plan? Is it evaluated? **A** (1:19:43): Yeah. So what's going on there is the Cosmos Hub was supposed to launch in December of 2017. We are now 14 months delayed. And so what we've kind of done in the past couple of months especially is like all engineering resources are shifted towards focusing on the launch of the Cosmos Hub. But now that that's going to happen within next two or three weeks, we're going to shift resources back into Ethermint and other stuff. Yeah, Yep. **B** (1:20:12): Another thing is because Ethermint is supposed to be a module in the SDK. The SDK used to be feature frozen first before. That makes sense. Oh, right, yeah. **A** (1:20:20): Not true. **B** (1:20:22): So if you want ERC20 functionality, do you deploy Ethernet or do you pick some other route? **A** (1:20:31): So by ERC20 functionality, depends on what you mean by that. If you're talking about you literally want ERC 20s, then yes, you need to deploy an EVM module. If you want a custom token, the SDK provides a mechanism for you to have tokens and you can have as many tokens as you want in the chain and each token is native. The ERC standard of doing tokens is very bad as a contract in our system. In the SDK it allows you to have unlimited native tokens. And so that allows all these tokens, like I said, to be used to pay for fees and whatnot. **B** (1:21:05): What's the development process? Let's say with Ethereum you just inherit from an ERC20 token, flatten it out, compile it to bytecode, deploy it and you're done. Right. How do you do that? **A** (1:21:15): So keep in mind here we're talking about application specific blockchain. So the idea is you should, whatever token you need, you should have deployed it when you deployed your blockchain. Right. But you're not going to add a new token on later. Does that make sense? But you could have mechanisms that like modules that allow people to mint tokens. So I can have a module called Minter and what I can do is any user can just send a transaction to it saying, hey, make a new native token called Sunny Token. Right. And it will do that and it'll create it as a native token and everything. **B** (1:21:47): So the thing to research is the Minter module and how to create tokens with the Minter module. And there's some sort of stack with like a transfer and balance of that. You have a template to start off or. **A** (1:22:01): We'Re working on that. There's a sample Minter module in the demo coin application example in the SDK repo. But like I said, that definitely needs a lot of work. We've kind of built all these sample modules we used to be building. Kind of all on pause right now, waiting. Focus on Hub. Launch another cool sample module that's on there is this proof of work module where what it does is like you. So I Am personally of the belief that proof of stake is better for consensus, but proof of work is better for coin distribution. Like everything that you were saying about like, you know, I think proof of stake is too centralizing for monetary distribution. If you want to try to take your shot at like making money, I would say still use proof of work, but you can. So we have a module that like people can submit these hashes and it mints coins for those hashes. And so you can write modules that like emit coins and things like this. **B** (1:22:56): So with open, you probably know open zeplm, right. It's a repository where you have dozens of contracts that you could look at. For example, if you want an escrow here, so you build an sqr in ERC20 token. Here's various versions of that. Just minting and roles and all that. And I'm wondering if the modules are the parallel of that. **A** (1:23:18): Exactly, that's what the modules are the parallel of. Although the one thing that's missing, I'm sorry, the one thing that's missing right now is we don't have the common repository yet. So the thing with OpenZeppelin is all in this one GitHub repo. It's very nicely organized right now. The modules are supposed to be exactly that. It's the equivalent of that. But we need some mechanism of organizing them and maybe some website where developers can upload their modules. And then there's also this question of auditing, like we need some mechanism for people to read these modules and basically maybe assign some stake to it and basically say like oh, I'm staking my reputation because I audited this module. **B** (1:23:58): Conceptually is that going to be, I mean modules are going to be go code that you pull down, compile and then redeploy to Cosmos to your own chain. Yeah. Okay, so it has to be be to your own chain as opposed to a public chain like Ethereum or Eons, for instance. Exactly. And that is. So it's two different approaches to deployment basically. Right. So you're never going to deploy to a public chain with Cosmos with. **A** (1:24:28): Upgrade the public chain through governance or some whatever mechanism. Right. You can say that governance can choose to add modules, but that's like upgrade hard fork upgrades. Right? Not hard fork. It doesn't have to be hard fork, but those are upgrade processes. It's very different than. It's not like Ethereum where you're uploading code and running it. It's application specific blockchains. You know your application and you're writing that code and you're deploying the application, not like. **B** (1:24:57): Yeah, so just another question. So I guess another concept that I think about is when you're, when you're dealing with a public blockchain like ERC20, if your company ever goes away, hypothetically, somebody else may step in and make use of the existing tokens that are out there floating that they don't have private keys to. Does that concept not apply to anything? **A** (1:25:20): No, it applies completely here as well. It's like it works the same way here. Think of it similar to some of the Generation 1 blockchains. Just because they're application specific doesn't mean they're not public chains. For example, let's say namecoin. Namecoin was originally developed by what's now the Blockstack engineering team. But that team stopped working on Namecoin and instead started working on Blockstack. But namecoin never died because it's this public project that other developers took over and like continued developing it. Just as something is application specific does not mean that it's controlled by one company or it's not a public system. **B** (1:26:05): I guess what I imagine is when you have a whole bunch of validators that have, you know, their own private key and one company controls that if. **A** (1:26:15): That those validators don't have to be run by one company, your chain can be secured by a proof of stake system. Right. Like you have your own token that you use as a staking token, for example. **B** (1:26:27): So you basically have to kind of build up a community that's going to, you know, which is going to take responsibility. **A** (1:26:35): And we also have alternative mechanisms if you don't want to build up your own community, which I will get to in I think the next section. Yeah. **B** (1:26:42): Cool. **A** (1:26:44): Okay. All right. This is probably the one thing that most people know Cosmos for and what we're probably most famous for, which is IBC or inter Blockchain communication. Essentially what's going on here is, okay, we're able to use the, we're doing. It's just a continuation of the side chain protocol that was like kind of originally conceived by Blockstream back three or four years ago, back for Bitcoin. But a lot of the developments that we've done help make it a lot easier, especially Tendermint. So one thing I did not mention in my Tendermint section is Tendermint is very efficient for light clients. The problem with proof of work, like clients is you need every single block in order to verify the head of the chain in Tendermint. That's not true. You can actually do like client security by jumping a number of blocks. You don't need every single block that ever came. And so the thing is when you have two side chains that are communicating with each other, let's say there's no packets going between them for hours. You can actually just send the most recent block as long as the validator set did not change by more than one third. And even if it did, there's a efficient bisection algorithm that we use to how you can transmit the fewest number of blocks necessary in a proof of work sidechain. On the other hand, let's say there were thousands of blocks that went by. The next time you transfer a packet you have to send every single one of those thousands of blocks. And that's just not very scalable for. You can imagine why. And the light client's also nice, just even minus for ibc. It's just really nice from a user perspective. If you turn your phone off for the night and you turn it on in the morning, there's probably about, I don't know like 50 or so Bitcoin blocks that went through it in that time. I've checked. My phone can do about like 3 or 4 SHA256 hashes per second. So it'll still take me about 10 seconds to like sync up to the chain. That's bitcoin, who has 10 minute blocks. And SHA256, a very easy hashing algorithm. I've never actually tested it with Ethereum because there are no Ethereum mobile like clients that as far as I'm aware but you know, 15 second blocks, very complex hash algorithm. And it will probably take me like a few minutes just to sync my light client up to the head of the chain on my phone which is off for one night. And you know, Tendermint just, you know, it makes it way faster. You just jump the blocks and then you do a couple of signature checks and the signature checks will get way more efficient once we do the BLS aggregation I was talking about earlier. So essentially what's happening here is you are basically two chains are light clients of each other and you send this packet between them and it proves state. So something happens in chain foo and you kind of like and it's logged in the state somewhere. You send a message, you make this packet format out of it and a message relayer which is some node that will be incentivized some way, which is still one of our main focus of research right now how to do this incentivization but they'll go ahead and transfer it, relay that packet to Chain bar and chain Bar will have some mechanism of acting upon that. And then it will send a confirmed message back to Chain Foo and then chain Foo can act on that return message however it wants, maybe like deleting that log event from its state so it doesn't just fill up at stake with thousands of log events. And so this is equivalent to application. And so the IBC itself is similar to the TCP IP stack, but on top of this you need, just like in the Internet model you need the application layer. And so just like in the Internet you have application protocols like HTTP for web or SMTP for email. FTP, you have all these FTP, you have all these different protocols on top. And so you're going to need to do the same thing for idc. We're going to have to design these higher level protocols. So the one that we're starting with now is just simple token transfers, because we think that handles the majority of the value. And so how that works is what you do is you lock up coins here, you send a packet to chain B and basically say, hey, look, here's proof that these coins are locked up and cannot be moved. B gets that packet and you unlock the coins. And what you can do later, if you want to go in the other direction, which I don't have the animation for, unfortunately, is you burn these coins and then you send a packet to chain A, saying, here's some proof that I actually did burn these coins. And then chain A will say, okay, cool, I'll remove the lock on these coins for you and you get the coins back. And so really what these tokens are here is they're a claim to the locked asset on this chain. And so that's essentially acts as token transfer. **B** (1:32:01): Yeah, so if I want to spend on B, do I then go back? Would I have to like send a packet back to A and say, hey, like you need to decrease the locked fund? No. **A** (1:32:11): So, well, if you want to send, let's say you want to send it to someone on B, right. You can just send the asset directly because the asset, it's a bearer asset on the claim to the underlying locked asset. So I could send, so I locked these coins, I got them here, I can send them to you, and then you can be the one to burn them here and then these will get sent to your account here. So when you burn them, you tell them, you tell this protocol which account to send the locked coin. So you can Use that for token transfers, which is what we're focusing on now. You could use it for non fungible assets or NFTs as people like to call them. You could use it for data like oracles. So just have some data prove to me that something happened on the other chain. I think private chains can serve as very valuable oracles for public chains using this method. And then there's this thing called Agoric ertpe Central Electronic Rights Transfers protocol. This is something that I realized I've been thinking about for a little while. What's happening here is in our token transfer protocol, these are just claims to underlying tokens, right? They're not the token themselves. And this is fine for most assets because really if an asset just has value, doesn't have like, if the asset's value is just being like a bear, if underlying thing is a bearer asset itself, then it's kind of fine if you just have a claim to an underlying bearer asset. So you know, if you locked bitcoin and like, you know you had this and you know it's always one to one redeemable, it's essentially as good as bitcoin. But then the question I, you know, the thought I had about a year ago was like, what about a cryptokitty? I can lock a crypto, I can lock a cryptokitty and have a bearer have a claim to that underlying cryptokitty. And you know, say this is a Dex chain. I can trade my cryptokitty and do all sorts of fun stuff with it. But here's the thing. CryptoKitties is one. It's a collectible, but it's also a game. There's this game where you're trying to breed the cryptokitties and have them have new cryptokitties and stuff. You can't do that on this though. If you have your cryptokitty here, it's not actually the cryptokitty, it's a claim to a cryptokitty. And you can't breed the claim to a cryptokitty. Right. If you ever want to play the game, you have to move, burn the claim and unlock it here. And all the breeding logic has to be done on the original chain, which isn't. It's not as fun. I want to create especially Cryptokitties is like a toy example, but you can think of it as like a maker CDP for example, right? What if you want to exercise that maker CDP on another or execute the maker CDP on another chain? Or let's say an options contract. Right, an options contract. Is a contract, but at the same time it can be an asset. And maybe you want to be able to move that option contract to another, the asset itself to another chain and then still be able to exercise that option on another chain without having to go back to the original chain every single time. And so Agoric is a team that's been working on this for the last 25 years. Essentially how to do data and logic transfer across chains. And they have this cool offset capabilities approach. So definitely check them out if you're interested in that kind of stuff. And so we're helping them experiment with building this on top of IBC as well. It also helps on the scalability perspective. This kind of goes back to the application specific chains as well as the ibc. If you think about it, this is sort of a type of sharding where we're essentially taking instead of putting everything on one chain, we're kind of spreading across multiple chains. But it's a special type of sharding. I call it application based sharding because it minimizes the bottleneck. The bottleneck in application specific chains in any sharded system is how much inter shard communication there is. So let's say the EVM Ethereum, last I remember from their proposal, they were going to shard by address space. So if the first byte of Your address is one, you go to this shard. If it's two, you go to this shard dot if it's three, you go to this shard. The problem with that is that makes it, let's say you're just as likely to communicate with anyone else. Now there's a 15 out of 16 chance that your transaction is going to have to talk to another shard. And now you have so much overhead going over the relay chain or whatever you have here. And that is not just very scalable application based sharding. My theory, my claim is that most transactions within an application stay within that application and the vast minority of them go to other applications. And I think that's just a logical idea where you have a dex. Most of the transactions are people trading on that dex and then the minority are people withdrawing from the dex and stuff like that. So I think the application based sharding minimizes the bottleneck, which is interchange communication. Yeah. **B** (1:37:11): Do application chains also maintain liveness independent of one another? Like if there's some halting issue somewhere, does that. Okay, yep. So that's also. Yeah. **A** (1:37:22): But now up till now what I've proposed is all of these chains are sovereign. They have their Own validator sets and everything? Yep. **B** (1:37:29): Okay, doing that, I guess. Any extension of that. Do they help secure one another in any way? **A** (1:37:34): Not right now. **B** (1:37:35): Ok. **A** (1:37:37): The other thing is, you guys may have heard of Vitalik's scalability trilemma, which is like you can't. Splitting stuff across multiple chains is the equivalent of a block size increase. It's not actually a scalability solution. You can't just say, oh, I have one chain and has X throughput, let's just make 10 chains. So it has 10 X throughput. But now it's really just the same as increasing the block limit of 1 chain to 10x1. That's not true because of like parallelism, where, like, you know, if these chains are relatively isolated because of their application layers are distinct now you can run them in parallel. And scaling out is much cheaper than scaling up. So that's one thing. But also the thing is you only have to be a valid a user for the chains that you care about. So let's say I'm a user of Saya but not of 0x, right? I don't have to run the 0x chain. And no one's actually a user of every single DAPP that's in existence. And so once you split by application, you're not actually. You're making it easier for people to only validate and run nodes of their services that they actually use, rather than forcing everyone to run a node of everything and validate everything under. Under the sun. Right? And there could be some validators who say, oh, you know, it's their job, they have a company around it, they want to validate every chain. But as long as the, you know, they'll have like a server farm or something somewhere that's doing that. But as long as the users aren't the ones who are validating every single chain in existence. I think that like the trilemma is way too abstract in its thinking and doesn't consider the practical matter of that like users actually have preferences of what chains to use and they, they're not trying to validate everything. I think it also might help Tendermint. We're very much interested in this idea of localized chains. We think that in Tendermint Core, in Tendermint bft, the limit, like I said, we push it as low as possible. And so the limit really is the speed of light and how fast you can do BFT consensus over the public Internet. And you know, it takes time to go from here to here. But if you have localized blockchains like you Know, in a certain region, the validators are more localized and closer to each other. You can do much faster block times and higher scalability. You can also do like, you know, like I said, it kind of goes with the whole sovereignty aspect I mentioned. With like Libra land, if all the validators are in a close geographic proximity, you can get way more scalability that way. We have a project, one of our partners is called Iris. They are building a chain that's focused on just China. And when I first heard about this, I thought that this is like, ah, this is kind of scammy. Like, you know, it's like, like Neo or the Chinese Ethereum. Oh, is Iris with the Chinese Cosmos or something? But no, but then I actually like thought about it. I'm like, okay, I actually like this idea. It's very interesting because I'm worried about the great firewall of China. And if the firewall suddenly comes crashing down and says, oh, we're censoring packets coming into and out of our system, that's not good. And tendermint, it's fast and it can run over Tor, but it'd be nice if we didn't have to. And so it would be nice if we had. It would be fine if we have a chain, a hub that's on the outside and then we have a chain that's inside China and they can communicate over IBC and you can send IBC packets over Tor, but you don't have to do BFT consensus over Tor. That would be very nice. And so I think there's a lot of advantages to be gained from this sort of geographic sharding as long as you still have that interoperability there. But at the same time it comes with other regulatory concerns as well. So now if values are more localized in an area, that also might mean they're more in a common jurisdictional area. If you have a Europe chain that all the validators are physically located in Europe now, does that mean now they have to start being GDPR compliant? I don't know. I don't even know what that means for a blockchain. And then here's a user story I wrote a couple of months ago, kind of a fun example. So you can imagine you take your BTC from the bitcoin blockchain that you're holding onto and you can use it to a casino chain, like a gambling chain and play some poker or something, and great, you won some money and you don't want your friends to know about your degenerate gambling habits. So what you can do is you can go ahead and move it to a zero knowledge chain. So one of the projects I want to build is take the zcash state machine but remove the zcash token, but just have it. So you can move any token into this and use the zero knowledge properties of their state machine without the zcash token. So I can move my bitcoin into the zcash chain and kind of use it as a mixer or I can just keep it in there and use it there permanently, however you want to do it. But you know, I can move it to the zcash chain and use it as a mixer essentially and send my bitcoin back to myself. And like, now I have some level of privacy there. Great. Now I have some extra money to take up my friend on that bet that he had. So I made a bet with him that we, we couldn't have a cryptokitty. My cryptokitty couldn't give birth to an orange cryptokitty within six months. And so this is a really long term bet. Six months. Bitcoin's pretty volatile. We don't want to denominate our bet in bitcoin. So what I'll do is I'll take my btc, move it over to the Binance Dex chain and trade it for some dai. Take that dai and now I'll take it to send it to the ethermint chain. And so here, here's an example where smart contracts are useful. It's a bet, it's a one time thing. We're not deploying an application here. So let's go ahead and write a smart contract that will put the DAI in the smart contract and I can move my to settle the bet. I can take my cryptokitty asset from the cryptokitties chain and I can send it to the ethermint chain and prove it to the smart contract and basically see, once it resolves, I can win the die or I cannot win the die. This is obviously a bit of a toy example, but this kind of shows the user story of what kind of things you could do when all these chains are actually able to interoperate with each other and have their applications work together. Cool. So IBC helps with that interoperability story that I mentioned and it helps between these different DApps and it helps with the scalability stuff with the geographic sharding and application based sharding. **B** (1:44:16): Would IBC module be used for this? Yes. **A** (1:44:21): So ibc, the Cosmos SDK has an IBC module in it that you Just use it. And your thing is IBC compatible. If you want to use a different state machine or framework, we have to develop IBC modules for those frameworks. So the Nomic team, John and Matt, they're working on implementing IBC in lotion and if you, you know, like I said, I want to implement it in substrate at some point and if you're running a bare metal chain, you're going to have to write IBC compatibility into your chain as well. **B** (1:44:55): So you use explicitly for Ethereum integration. Yeah. IBC is Cosmos to support or IBC compatible to IBC compatible which is owned by Cosmos. **A** (1:45:09): Sure, yeah. I mean hopefully it'll grow beyond. But yes, it'll be Cosmos. But like not just things that we work on, like hopefully, you know, we're working with Prismatic Labs, they're one of the Eth 2.0 developers and so we're trying to get IBC natively included into Ethereum 2.0. So if Ethereum itself becomes IBC compatible. **B** (1:45:29): That'D be really great lotion in comparison. You said there's going to be some. **A** (1:45:34): Ibc, there'll be an IBC module in the lotion framework. **B** (1:45:39): Okay. And that would be different than pegi. Yes. **A** (1:45:42): So PEGI is for how do we deal with chains that don't support IBC natively? So Bitcoin, Ethereum, basically everything right now. Right. Because nothing supports IBC and so that's just a mechanism of instead of doing two way light clients, you instead actually have to have the entire validator set of one of the chains run a full node for the other chain. And that's kind of annoying, which is why PEGI isn't scalable to every chain. And the idea is they'll probably only be peggies for certain chains like probably like Ethereum and Bitcoin and I don't know what else is any other. Only really high value chains are going to be worth it to deploy a PEG E for because that actually requires all these validators running lots of stuff. **B** (1:46:33): Are there any enterprise or permission use cases or projects? **A** (1:46:38): Yeah, there's like. So like I said, PBoC is using Tendermint for their stuff. Hyperledger Burrow is like all an enterprise EVM chain. The Thai national government is using it for their national ID program. Clearchain I think it's called, it's a like Live fx, Public FX exchange, one of the biggest in the world. It uses it in their internal stuff. Yeah, so there's a number of enterprise projects. Honestly I think there's actually Currently probably more enterprise projects using Tendermint than public chains because until the Cosmos SDK was ready, it wasn't very. Until the Cosmos SDK was ready, there was no good staking modules or any logic. Right. That's the only way to. Most people are just using Tendermint in a permission setting. Now that the Cosmos SDK is ready and we have a public proof of stake module available now a lot of people are jumping in and like building public blockchain and there's a. I can shoot you a link somewhere that has like a list of some community. One of our community members has been maintaining a giant list of all the projects or that he knows of that are using the SDK for public chains. **B** (1:47:56): And any using the ibc. **A** (1:47:59): Oh no, no one's using ibc. It's not developed yet. IDC is still in spec prototype phase. **B** (1:48:11): So are they number one topology, like you might mentioned them earlier. So I was wondering if that. **A** (1:48:17): Oh no, for pra. I was just saying that they are just like the only other team I've seen that actually has something close to a production grade BFT engine and they're using honeybadger as their consensus protocol, not Tendermint. We can go into a discussion about why Tendermint versus Honey Badger and what are the benefits and pros and cons there. But no, I think it'll be one of the ideas. We definitely will have IBC abstracted. So it doesn't care about the consensus protocol per se. And so that's what we're working with Prismatic on making sure IBC is compatible with both Tendermint and Casper. And so we'd love to work with the Honey Badger team on getting it compatible with IBC as well, but we haven't really reached out to them on that in that regard yet. Yeah. And so if you want to learn more. Chris gave a great talk at the ZK Summit last time. This one's a very technical talk. This one is a talk I gave at edcon, also pretty technical kind of shows. Some of this goes into like a lot. Both of these talks go into a lot more like technical details, like kind of explaining our spec for ibc, how we do packet relay, packet formatting channels and connections and how you open a connection, how you like do an initial point of like how do you initialize a connect IBC connection between two chains. So you know, we have that in a lot of these IBC webinar is Zaki. He did a webinar just like two or three days ago, kind of talking about like, you know, the roadmap of where we are with IBC and like, you know, what its status is and stuff. So you can check those out. Oh, this one has a lot. Here's the IBC spec and here is the blog post about PEG zones. And these are designed for PEGI that we were talking about. Okay, all right, almost done, almost done. Last mile. All right. The Cosmos hub. This is a chain that we are currently actively building. It kind of serves a couple of purposes. It serves a purpose within the Cosmos ecosystem and at the same time it's also just a mechanism for us to dog food the SDK and like show a live public chain built on the SDK and like, you know, have something there. So what are hubs? If we're building an Internet of blockchains and you know, you know, you can see we really like this Internet analogy with the IBC NT and whatnot. Hubs can be thought of as the ISPs in this Internet of blockchains where instead of, you know, the Internet isn't a mesh network, it is a federated system, right? You have ISPs that are peered directly with each other and usually you talk to the Internet through like one or two ISPs that you have some you have service with. This helps because it reduces the number of IBC connections to on the order of N rather than N squared. You don't have to have every chain talking to every other chain. And that doesn't mean there's only going to be one hub. There will be many hubs. We can see here that different hubs are kind of peered with each other. But, and you know, Iris is an example of one hub. Cosmos, we have Cosmos hub is an example of another hub. And there'll be more hubs in the ecosystem over time, but it helps like decrease the like the number of connections, which is good because you know, it makes stuff a lot simpler. It makes it, you know, all of these zone chains, they don't have to keep doing light client proofs and keeping track of every single one of hundreds of other chains. Rather these hubs are specialized blockchains, application specific specialized blockchains whose sole purpose is to just maintain a lot of IBC connections. They're not doing any other application logic. They're just making IBC connections and relaying packets between these zones. And so you can use this multi hop system to reduce the number of connections. And it also acts as a secure medium to prevent chains from double spending each other. So what would happen Here is, let's say you sent a token from Bitcoin to Ethereum and then from Ethereum to a zone. But the thing is Ethereum, let's say Ethereum is malicious, you know because those guys, they do dao forks and stuff like you know they could just like hard fork and say nah, we're not going to take it from the, from the, from the, we're going to take away the token from you and like you know, give it to ourselves or something. The idea is that the hubs should be like very secure blockchains, high value blockchains, hyper secure, that kind of prevent as a double spend protection between other blockchains. So that's kind of one of the values of the hub as hubs as well. And so no, this is the Cosmos hub. Sorry, lost track. And just like ISPs that provide other services, hubs ISPs often provide web hosting, they often have their own DNS provider, they often have some sort of security packages. I think hubs will also provide other services as well. You know they can provide governance services. So like you know, let's say this small chain became unlive and they need a mechanism for coordinating how to fix it. You know the idea is like I said the hub should, these hubs should be the hyper secure chains and hopefully they should be live. And so the idea is you can use like you know they can use the hub as a coordination mechanism and message board to discuss how to do governance on their unlive chain. You could use it as a name service so you know to central point where like you know you can do like name service kind of stuff so you can, or identity stuff so you can have a common identity across many chains, peg zones. So this is like the Cosmos hub validators are essentially going to sign up to say, you know running an Ethereum peg zone is hard because you have to run full nodes for it and it's not as simple as ibc. So the Cosmos hub validators are going to say OK we'll take on the job of running these Peggy zones and do that work there. And the other thing is least security. And this means, so this kind of goes to that thing about right now we're focusing on sovereign chains. Every chain has a separate validator set over time we're going to have a system where let's say you have a small chain, you don't have a big community yet. You don't want to find your own community and validator set. Yeah, you just want that one click Deploy feature. This is like model of Peggy. We'll look at it later. So this is sovereign security. But then you could have replicated shared security where the entire hub validator set can basically say, ok, we'll sign up to also validate your chain. And they could same validator set can be validating multiple chains. And what will happen is like, you know, if when the validator set changes on the hub, it will also change everywhere else. And at the same time, if someone does a byzantine fault on this chain, it will also get slashed everywhere that they were a validator. And so, you know, that's cool, but it's also not as scalable. You know, it's somewhat scalable because of the whole parallelism thing, but those same validators that can't run every chain in existence or everyone who wants least security. So then you can have a system where you have a large validator set and there's a method called Sortition, which means you randomly select subsets of that validator set. So you say, let's say they're all running these two chains. You can say, all right, half of you are supposed to be doing one, half are you supposed to be doing the other. And if there's any fraud happening here, it gets pushed to the entire chain to decide who was right and whatnot. It's faster with smaller partitions, there's slightly less at stake. And this is kind of like what this is now, delving, kind of pushing into Ethereum, sharding and Polkadot style stuff. One of the issues I actually have, what I don't like about how Ethereum and Polkadot are doing like this sortition security is they want to randomly select validators to validate chains. So let's say your polkadot, they have let's say 10,000 validators. And a new chain comes along, it will randomly select 100 validators and say, all right, you guys are all assigned to validating this shard. I would rather have a system in which chains can come along and say, hey, who wants to validate me? And then the hub validators can raise their hand, be like, yeah, we're down to validating you or another. The incentives you're providing here aren't worth it for me to validate you. I'm not going to. And so it seems like a bit more just like free market. Let the validators decide what's worth validating for them. It also allows for different types of validators because there might be some validators who are running out of their dorm room and they only have the ability to run like, you know, validate like a couple of chains while there are some validators who are like full fledged companies doing this and they want to validate thousands of chains. Right. And so what's, why are we stopping them from doing that as long they're still putting their, you know, that seems completely fine to me and I haven't figured out what's wrong with that mechanism. So that's probably the direction that the Cosmos Hub is going to start pushing into when it comes to shared security. And then also plasma is just another type of shared security in my opinion. And so, you know, the hub will possibly like, you know, some of the stuff that fourth state is working on. I think the hub will start to act as a plasma root chain where people can like, you know, use that for that purpose. So yeah, the Cosmos Hub, you know, it helps the interoperability and like, you know, makes it makes interoperability a bit easier. And when it starts to get into these shared security models, it will definitely help with this one. Click deploy user story and you can learn more about the Cosmos Hub. So you learn about the Interchange scaling. Jay did this at the CSC. This is a great thread from Zaki on Polkadot vs Cosmos and kind of showing the difference of how we approach shared security. So that's a really good thread. And then just this intro on Cosmos, a lot of it's on the Cosmos Hub, so I think that's a good resource there too. And then these last ones are pretty quick. Voyager, we just needed a wallet and stuff and UI to make it easier for people to do stuff. It talks to the system through like a standardized rest endpoint that we kind of like. And then the idea is that most chains should support the same core rest endpoints. And so using Voyager you could do voting on governance. You can delegate and everything and stake through Voyager. And really the point here is Voyager should just be like this multi chain wallet. So we're trying to get standards around these rest endpoints for different chains. And so the idea is that hopefully it will help a little bit with that interoperability story. And then I think Voyager will start to build in additional features around interoperability such as like IOP support and whatnot. **B** (1:59:45): Is it going to be like parallel to what metamask is or scatter? **A** (1:59:50): No, no, it's going to be more of a wallet and it's going to be its own UI and stuff standalone. **B** (1:59:55): Without any kind of DApp integration. **A** (1:59:57): Yeah, yeah, well, it's still to be determined right now it is just a wallet that is designed to do like token transfers, governance, voting and staking for any Cosmos SDK chain that has support for these three modules. The future of Voyager I'm not on the Voyager team, so I'm not too sure what their roadmap there is. But from what I've heard, they want to start having a system where developers can write plug ins for this Voyager system. It's kind of almost a Ethereum. When it started it had this project called Mist that never really took off. We should probably do more research into figuring out why it never took off. But it's kind of almost a recreation of that vision of a common portal that you could use. And I'm not sure if that's good or not. Maybe the reason Mist failed was users don't want to use a new portal. They want everything to come to the web browser, which is why we're currently turning Voyager into a web app now. And Maybe like the MetaMask plus web browser model works better than a portal version, I'm not sure. And so Voyager is just one application that's building wallets and tooling around this. Like we have a number, Iris is building their own wallets and stuff. There's a company called Lunament who is building their own wallets and stuff. A number of the validators have actually started building like Explorers and governance. Like governance, like web apps that are like governance portals and stuff. You can do all voting there. **B** (2:01:27): What was the outcome of the LedgerX integration that you guys were working on? **A** (2:01:32): I think it works from my understanding. So basically I have a, since they. **B** (2:01:36): Haven'T launched mainnet, how tokens end up being blended or how others network. So you have Ledger nanos. Right. So at this point there isn't a token from the process. Right. **A** (2:01:49): So on Game of Stakes for example, there's a test, it's a test net. It has its own token that we call Stake, just called plain stake. And so now I've tested that. I can get it to work from my ledger and stuff. I can do transfers and everything. **B** (2:02:04): So basically there's some code somewhere where directly from go it talks to the interface. **A** (2:02:13): The CLI has native support for Ledger. It does all that? Yep. **B** (2:02:20): Cool. **A** (2:02:21): You can read the repo, you can check out, you can use the web app, you know you can, sorry, you can use the Electron app version, you can use that. Or if you want to try the web app version, you can like try it out here at this link and then you know, some sample zones like you know Tendermint. We're pretty, you know, a lot of us. You know, I really like building a lot of this like low level protocol and infrastructure for the Cosmos ecosystem. At some point we also want to start building some cool projects. And so one of the things that a lot of us are interested in is a Dex. I think there's a lot, obviously the Dex space is way overcrowded already hundreds of dexes. But I think we have some. I have a design for Dex that I think is kind of cool that I haven't seen anyone try to implement yet. So we'd like to build that and I think it helps the ecosystem just having different types of dexes on that. Let me actually make an interesting claim as well about why I think Cosmos is important. There's different types of Dexes and they all have different features and functionalities, right? So you can have the 0x model of doing Dexes. You could have the Uniswap model of doing Dexes. You could have the Gnosis, their Dutch auction model. You could have the DEXi zero knowledge model. There's so many. Or you can have a Bancor style model of Dex. Right? Atomic swap model of Dex. There's so many different types of Dexes. And I think what you want is actually everything in blockchain is about trade offs. And there's often a trade off between decentralization and scalability. Now how many validators do you have? There's often a trade off between ease of use and security. Tezos, it's Michaelson, their language is not very easy to use, but it's very well designed for formal verification. And I think most projects are trying to find like, all right, how do we find the perfect balance of all of these trade offs to create the one solution? Cosmos instead allows like, how about we just explore the full range of trade offs. Allow each chain to like have its own kind of trade offs that it makes. You can have centralized chains working with public chains. You can have different types of Dex chains and you can allow like, you know, even, let's say even if some of them take the majority of usage like, you know, you still have these smaller dexes that have their niche uses. Maybe you have like, what do you call it when you have like a dark, a dark pool. A dark pool decks. You can have a dark pool deck that's specifically for privacy purposes. You could have a Dutch auction dex who's like, specifically for like, you know, it's very slow latency, but it's like, you know, you get the best possible Price using a Dutch Oxen dex. So you have all these different dexes that have like different use cases and niches and all being able to interoperate with each other. And so that's one of the reasons I really like Cosmos. It allows you to explore the trade off space. Some other tools we want to build you know fourth state like you know Aditya he like was an intern with us and he was, he's going to be joining full time so and so going to be keep working on fourth state data availability. You know most zero knowledge snark systems require some sort of bulletin board for data availability. So building a chain to do that. Jay, he's very much interested in like governance and like he thinks a lot about voting systems and like discourse systems and so he really wants to build stuff around that Ethermin obviously we mentioned and then we're also really interested in just like you know blockchains are all these dapps and stuff are cool but really a lot of us got into it for like currencies because like that's kind of cool. And so you know we're really interested in monetary experimentation. I personally got into, when I got into Cosmos I was like huge bitcoin maximalist and like I just got into it because my goal was to save bitcoin where like I want bitcoin to be the money and like it just flows out and becomes the money for like all of these different chains. So you're, you'll use Ethermint but you paying your fees in bitcoin you'll use everything paying your fees in bitcoin. Over time I've become less of a bitcoin maximalist but not because I don't think bitcoin. Most people don't like bitcoin because they think there's not much you can do with it. But Cosmos solves that. Once we peg to bitcoin you can use bitcoin for everything. You can use anything else for eth or whatever. I just think bitcoin is going to fail from a monetary policy standpoint. I think the hyper deflationary aspect of it just, I don't know, I think it's somewhat perverse actually. And so you know we're just very interested in like you know doing some cool experimentation with monetary policy. You know we're launching a chain, we're launching a token called Photons which is you know one of the things that we're doing there is we want to experiment with fixed issuance policy which means like it's still inflationary but it's not, you know, sorry, sorry, it's so deflationary. But it's not hyper deflationary. It's, you know, 500 photons per hour till the end of time. And you know, just like experiment with this monetary policy. Turns out Grin actually is doing something similar. So, you know, they already started that. So maybe we should try experimenting with something different, you know, and then something called hard spoons. Like, you know, what if we just like start like kind of like a hard fork, but it's really just forking a distribution and just creating a new token, kind of like airdrops, you know. Just needed a clever marketing term for it, you know. But so photons, what we're going to do is I feel bad like doing ICOs and collecting people's money in order to do monetary experimentation. So instead what we're going to do is we're going to take the ether distribution, just copy it and just start doing fun monetary experimentation with it because no one's money is at risk. We didn't take anything from you to do this experimentation. I think stablecoins would be really interesting. I think there's a lot of work already being done there. We have this design for stablecoin and jokingly called it a neutron because it's like neutral and stable. I think UBI based systems, like, you know, I've recently been reading a lot about a project called Circles and I think they have a really cool decentralized UBI model, Ethan Buckman. He is super into this idea called Local Currencies, which is this idea where like, you know, like currencies for like specific cities, not even like nations and like, you know, and you can do a lot of cool stuff there. And he like advises, so he lives in Toronto, he advises like this like project in Toronto that does this like local currencies thing there and apparently like it's accepted places. I got a haircut in Toronto and they accepted this local currency which is kind of cool. **B** (2:08:45): How did you pay? **A** (2:08:46): I did not pay with the local currency. I just saw that they accepted it but I don't actually have any of it, so. But yeah, I think it was a crypto app. Yeah, it's supposed to be for the city. It's accepted at a few. It's basically accepted at the few places where that team and Bucky, like they went and evangelized it. But I think it's a cool idea. I think this all just still boils down to that whole idea of smaller communities. And like, can you get like Interesting. Integrate like what kind of new systems can you get when you have localized. **B** (2:09:22): Systems that would be interesting in the city, how does the money be an issue? Does somebody have to conversion work? **A** (2:09:31): I also think that UBI would also only like if you want centralized, ubiquitous circles or something. I don't think UBI works at a national scale because I just don't think people have enough empathy for people over large distances. But when you have smaller communities, then you have enough like social cohesion to make I think UBI absolutely to be sustainable. That's just my personal theory. So I don't know. You can talk to Bucky about this. He has like a whole like, like you can look at his like Twitter threads about this and like he has a whole bunch of stuff about talking about local currencies and then I don't know, a lot of people shit on crypto fiat, but I actually think crypto fiat is completely okay and still optimal to current fiat because it might be centralized, but it still has transparency. And then you could have a system where you don't like the government, the government starts being corrupt, you can fork hard spoon the coin distribution. The biggest problem right now is how do we copy the current distribution of wealth into a cryptocurrency if that's your goal, I don't know if it is. But if Fiat was already a cryptocurrency, very simple to just copy it and now turn it into a decentralized distribution that's not controlled by a government. So I think crypto fiat is actually pretty interesting. And so I'm interested to see what like PBoC is doing with this. Yeah, finally done. So here's all our tools. Kind of walked through all of them. And I think I walked through how a combination of all these tools address all of these desires we have for generation three blockchains Cosmos to launch mainnet soon. So now you know that this title is misleading because it's the Cosmos Hub mainnet, not the Cosmos mainnet. Because Cosmos is not a blockchain. What we're launching here essentially is we're launching the Cosmos Hub, which is built with Tendermint and the Cosmos SDK and has our bonded proof of stake and Voyager support with what we do not have is IBC right now. Like I said, IBC is just in its spec and prototyping phase right now. And we figured, you know what, we're launching the first Tendermint chain with like valid proof of stake. Let's just make sure that works and then we'll worry about IBC later. So that's so like if but the SDK is ready to start developing on and there are a number of teams already developing stuff on them. Keep in mind it is an alpha. If you're developing on it, you have to be ready to like you're going to be constantly pulling upstream code so that's just something you have to worry about. Keep in mind and hopefully we should be pushing toward a 1.0 stable release of the SDK hopefully within the next six months. And so that's what we're launching and so you can learn more at all the links I put throughout the entire slide deck but also@tendermint.com and cosmos.network. follow us at twitter cosmos or follow me unnya97 Personal thing is I also run a podcast called Epicenter so you can check that out. We do a weekly podcast on all sorts of things in the crypto space. I think it's the largest podcast in the space. So cool stuff, cool.