Sunny Aggarwal - Why Cosmos?

**A** (0:12): Hey, my name is Sunny and I'm currently a researcher working at Tendermint. Researcher and core developer working at Tendermint on the Cosmos project. Some other stuff I do is I help out on Blockchain at Berkeley and I'm a host on the Epicenter podcast. But I think it means I get to like find cool stuff in the bloxwin space that I find interesting and just like research it and like write about stuff and like just come up with like cool ideas and just like write about them. Lately it's been sort of like a little bit less on the research side, more on the development side because, you know, Cosmos Hub is a little bit delayed. And so it's like, it's kind of like if you can code, it's all hands on deck. But yeah, so I kind of, I like to. One thing I really like about Tendermint is like, you know, a lot. I think a lot of people, like researchers in the space, they focus a lot on just like super theoretical research, but without actually like worrying about like implementation at all. Tendermint has good like, philosophy of like, oh, if you have an idea, well, go implement it, which I really like. So I think one of the things is that like, you know, when you make blockchain design decision, you're basically almost always dealing with some sort of trade off at some point, right? So for example, oftentimes one of the common trade offs you're dealing with is trade offs of like decentralization versus scalability. Do you have fewer validators or do you have more validators? Right, but you're trading off a little bit of scalability there. Another one is like kind of ease of developer access versus security. So an example I like to give is like kind of Tezos, right? Their programming language, Michaelson, is like not exactly the most developer friendly, but it's very well designed for formal verification. And so, you know, almost everything comes off of trade offs. And instead of trying to create one blockchain that tries to like pick the best balance of all trade offs, instead, what if we could have an ecosystem where we can have lots of blockchains that are exploring the full range of trade offs so you don't have to like, we don't always have to be settling for the average case. We can have like explore the full design array. And if that means in the end some blockchains end up winning, that's good because at least we let the marketplace of blockchains decide rather than a few developers basically making all the decisions. I think the two like main features that kind of like overarching, like explain why Cosmos and Tendermint from like a design paradigm, I think are really interesting. Are we really valued modularity and incrementalism where modularity is like all of our pieces are kind of like broken up in smaller pieces and like our abstract lots of really well designed abstractions. So that makes it very easy to kind of like take a view of the. A bigger picture view from like different layers and like you can also like swap in and out different layers. That's why like Tendermint Core is like a separate consensus engine from the Cosmos SDK and the entire Cosmos SDA is super modular and everything. And this just makes like the pro. In my opinion, this is the proper way to like design complex systems as complex systems. As an Internet of blockchain, for example. I think I really, I mean obviously Cosmos we've been focusing a lot on application specific blockchains and I think like we've, we kind of learned from the mistakes that like happened earlier in the blockchain ecosystem where like Bitcoin kind of had this like super monolithic stack. And if you wanted to make your own blockchain, you kind of had to like, back in those days you basically could only like fork bitcoin code base. But it was such a monolithic stack and it was just like spaghetti code C. It was basically very hard for any applications to be really much different than Bitcoin. So most of the early apps were just like, you know, Litecoin and like Dogecoin or like the few that were were like Namecoin but like, they were like, that were different. But like, even Namecoin was like a very suboptimally designed solution for its use case because it had to try to stick to the Bitcoin code base. And then so the other one I was gonna say was incrementalism, where I do think that like a lot of projects try to like take this like very like, you know, kind of related to the thing I was saying about like, if you want to do it, go implement. If you have this idea, go implement it. Where it's like, you know, a lot of projects have like, are working on like very complex like mechanisms like plasma and like, I don't know, there's like 10 different types of plasma at this point or something. But it's like, you know, no one's even figured out like basic interchange communication so far and has like a working implementation of that. So I like this like sort of like slow and steady wins the Race kind of approach. The Cosmos SDK was basically, you know, there's three generations, what I see is three generations of blockchain development. The first was the one I mentioned earlier which is, you know, you see the Bitcoin code base and you kind of fork the bitcoin code base and try to like modify it. And that had all the issues with the monolithic stack. The second was what Ethereum introduced was this idea of hey, we'll provide this general purpose VM and these like tools where you can build smart contracts on top of our general purpose VM and build applications using that and but what you lose out in that one is the ability to kind of change the underlying protocol to match your use case and you kind of are stuck with like what's the general, what's best for the average use case. So you know, the example I always like to give is, you know, I think account model is great for the general use case. If you want to make anything, account model is probably easier. But let's say I specifically wanted to make a payment system, right? I think UTXOs actually make more sense for a payment system. Like there's a reason Bitcoin did those and it has to do with it. Much easier to parallelize it and use concurrency there. But if I wanted to make a payment system on like Ethereum, I'm kind of stuck with their design choices of using an account model. You know, this goes for a lot of things like you know, who decides what the pre compiles in Ethereum are and you know, lots of like design decisions that you can't really change in Ethereum. The SDK was kind of designed to take the ease of development that Ethereum introduced into the space, but allow you to have that more modularity and low level access to your own blockchain so you're not like, you know, the way Ethan Buckman likes to put it is like who's the CTO of Tenement? He likes to say like, you know, instead of like subscribing to someone else's empire and like following their rules, you can have your own little city state and like have your own, your community kind of like has, chooses the rules and you can design optimize for your specialized use cases. I think what we're really talking about when we're talking about interoperability in the Cosmos sense is this idea of being able to move assets and like state between blockchains and so that includes stuff like being able to move tokens, which is what we're starting off with so I can have my bitcoin on the bitcoin blockchain and transfer it to ethereum as like ERC20 called Bitcoin and like I can use it in smart contracts and when I'm done I can move it back to the bitcoin chain. That's something like atomic swaps really can't do. And then also, you know, we're just starting with tokens. Over time you want to move on to more advanced things such as like, you know, NFTs or even like maybe even smart contracts if you have a better designed VM than the evm. Sort of like if you look at Premier, I think you can kind of use, use some of those ideas and be able to move contracts between chains. Even like one thing that I like to call complex objects where it's like NFTs but with associated logic. So for example, if I wanted to move my cryptokitty from the ethereum chain to another zone, another chain, problem is all the breeding logic for my cryptokitty is still stuck on the ethereum chain and to breed them I'd have to move them back. But what I could do is if with a complex object all the breeding logic is actually still with the cryptokitty and I can continue to breed it no matter what chain I move it to. And so these are sort of like, you know, I was going a little bit more into like these are some of the research ideas that we're kind of like looking into in the long term. But like I said, this is kind of another example of incrementalism. Like let's start with the basic thing which is tokens and then slowly work our way up. It's an open protocol, open spec and like literally everything of ours is open. I've looked at it. I personally check to make sure this is true. We do not have any private code repos, so literally everything ours is open source and freely available for any community member to develop on.