**A** (0:05):
Unfortunately, that's all the Chinese I know. So I will be speaking in English. I'm sorry, but hello everyone. My name is Sunny Agarwal and I am a researcher working with Tendermin on the Cosmos project. And you know, Cosmos, we've been working on a lot of things over the past year. We were here at one strong blockchain summit last year and we talked to you a lot about the work we're doing with Interchange communication and like building the Internet of blockchains. And then one thing that we realized over the past year is while we were building this like vision of an Internet of blockchains, our vision is that we want there to be thousands of blockchains. All of them have like specific applications. So, you know, we kind of saw this like Turing Complete VM blockchain, like one chain to rule the ball. All applications on one chain is just really never going to scale. It's not going to work. And what we wanted, our vision of Cosmos has always been a ecosystem of these DAPP chains or application specific blockchains. And what we realized last year is right now, there's really no good framework for building these kind of blockchains. Right now. Really. If you want to go build your own application, you kind of have two choices at this point. You can either go build Ethereum smart contracts or you can go fork the Bitcoin code base, which, you know, a lot of projects do, and kind of like try to modify that. But the Bitcoin code base is this like very spaghetti code C. And that's not very much fun either. And so that's why we decided to go ahead and realize, you know what, we need a good framework for anyone to be able to build their own blockchains in an easy to use way. And so that's where the Cosmos SDK came up. You know, the purpose of the Cosmos SDK, like I mentioned, was we want you to be able to build your own DAPP chain. So if I want to build a Dex, I can write a Dex on its own blockchain. I don't have to be running on someone else's blockchain. If I want to build a prediction market, I can make my own blockchain that runs these prediction markets. And one of the best things about this is that because you're running your own application, you as the developer are the owner of that, of that, of that blockchain. You have full control over everything. We realize we can get away with not having to use the Turing Complete vm. And so this allows you to write your blockchain in a language like Go rather than Solidity. So for all the developers in the room who have written like Ethereum smart contract before, you know how much of a nightmare it can be sometimes with like solidity, there's just like not a lot. It's a very new language. There's not a lot of tooling, there's not a lot of support behind it. Meanwhile, Go is a language that's like, you know, very stable and it has like the backing of like big industry people at Google and whatnot. And it's a very developed language, there's whole lots of tooling around it and it just in general a much easier platform upon which to build your blockchain. And then what we've done is, you know, we realized that you don't want to build everything from scratch that you might want. We designed to be a very modular ecosystem. And if you're here tomorrow, Jae Kwan, who's founder, he's giving a talk, talking a lot about the modularity of our system. But what I'm going to talk to you about today is, you know, today is the tech day, so I thought maybe it'd be cool or let's do like a hands on workshop of like let's build a very basic application and you know, let's, yeah, let's try this. And so what? What? One of the cool things the Cosmos SDK does is Tendermint, the company we work on along with Cosmos, we work on a project called Tendermint, which is this consensus engine. So, you know, you can think about it. A blockchain has like three main pieces. It has the networking layer, like the peer to peer, it has the consensus layer and it has the application layer. But as an application developer, you don't want to have to think about the peer to peer and the consensus. Like you just want to build your awesome application, right? So what's cool is Tendermint Core is a piece of software that handles all of that networking and consensus and everything for you. And you can use the SDK as just to focus on your application. And essentially all the SDK is, is it's a state machine. You can take any state machine and run it on Tendermint Core. But the SDK makes it easy. A state machine. So you have your state, you have transactions that are applying to the state and you have a new state. And this is just like how every blockchain today always works. So let's jump right in into the hands on tutorial. So a state machine, the I guess the first thing you need is a state. So you need a store, basically something that allows you to what, what are you updating? And so you know, this is our basic store. It has all the, by the way, all of this is in Go. So if you are familiar with Go, you can like kind of understand the code that's in here. But yeah, you know, it has the basic stuff. Like, you know, you can get something from the store, you can put something in the store, you can delete something from the store. And you know, one of the cool things is like we've been doing a lot of like work on what the underlying store is. And the nice thing is, as you can see, this is an interface. You don't have to know what the underlying store is. It handles all the heavy duty lifting for you. But we've been working a lot on making it as simple for the end developer as possible. And so what we have in the SDK is what we call modules. So modules are sort of like special features of your blockchain. So for example, let's say you have proof of stake, right? You might have a module that's specifically for staking, or let's say you have a dex, you might have a module that's specifically for an order book or for prediction markets. You'll have a module that's specifically for prediction markets or oracles or something similar. And so in a module what you do is you have these stores, right? The module is basically storing some sort of data. So let's say, you know, we're building a dex, you're storing the orders, right? So what you want to be able to do is you want to say, okay, put the order in this store. But some, you know, one store is not really, you know, sufficient. You often need multiple stores. You want maybe one store to hold all the open orders and you want a different store to hold all the closed orders or the ones that are, you know, pending execution. And so the module, what we allow is that like each one can have these multiple stores or separate resources. And one of the things that we did, we spent a lot of time on was the security model of the Cosmos SDK. We looked at how the EVM security model works and we realized that it's like, you know, a lot of the biggest bugs that have happened in the Ethereum ecosystem lately, like both of the parity bugs, even the DAO bug can often be chalked up to a issue with access control. Right? The whole issue with the parity bug, where a lot of money was Locked up was the fact that anyone could call a contract that was only supposed to be controlled by certain people. And so we looked into a paradigm called Object Capability Security, which I'm not going to go too much into today. But for anyone who's familiar, it's like, you know, a different model of security that allows much more fine grained access control. So keepers, keepers are sort of the main part of a module. It keeps all of the modules functionality in this very stateless manner. And what a keeper sort of does is it like I said, it holds all the stores. So you know, let's say make a sample. The application we're going to build today is a name service. So anyone who knows namecoin or Handshake or DNS, we're going to do something similar to that. So you know, what you need is basically basic ability to do like you can get a name from the store, or you could set a name from the store and the keeper sort of holds the key to the store. Then you have these functions in your store. You can, let's say there's a name in the store and you want to capitalize it, right? You can just, all you have to do is get the name, capitalize it and then you set the new name. If you want to delete something, you just set the name to empty. The reason I'm showing you this, this is like, look how simple this is. Like imagine trying to write the same kind of thing in solidity. It's so complicated and like really hard to wrap your head around. And the thing I was talking about modules is you don't like, you can take the modules that other people have written. So for example, let's say in our name point, we want the ability for people to buy names. The nice thing is you don't have to implement the coins and the buying and everything by yourself. You can take in a keeper that like someone else has written. So for example, we have a keeper called Payne and you can take in that keeper and then you can call the function on the other keeper. So let's say in the by name we set the name to what I want to set it to and it takes away the coins from my account. But it's not like I didn't have to write the whole thing of like going into the account and subtracting the coins all you can take the functionality from other modules. Yes. Cool. So you know, we can see here how keepers can sort of interact with other keepers, right? But how do users interact with the blockchain? You Know this is where we get into transactions and we have made it so simple for people to use how to interact with the blockchain. You don't, you know, in Ethereum and stuff like they basically sort of only have one transaction and that's it. And all of like any kind of anything that's going to any contract is all coming from the same transaction type. And the only way you can tell the difference is like when it actually reaches the contract it will say oh, the contract will say oh, this is this data. I didn't expect it to look like this. I don't know what to do now. And oftentimes the problem is a lot of Ethereum contracts don't do this sort of like in this case they often fail, there's often a lot of bugs and like, you know, it's all because of the like super generalized nature of Ethereum when instead if you had a more specialized specific purpose, you can allow yourself to sort of error check much more powerfully and stuff. So what we have here is what we have. We have what's called the standard transaction, which has a couple of things. Primarily the messages which we'll get into in a minute, you have a fee so you know, blockchains need some sort of transaction fees. You do the signatures and then you have a memo where you can like sort of, you know, you can add an extra piece of data of like, you know, off returns. In Bitcoin you can say, you can put the timestamp, you can put today's date or you can put a love note or something, whatever you want. One of the things that we also handle for you is the anti handler. So you know, it does all sorts of stuff like checking the signatures on the block on the, on the transaction. It checks the sequence numbers or nonces as they're called in Ethereum it checks, it does all the fees and gas checking for you. You don't have to like worry about any of this. And it passes the messages to the proper handler. So what is a message? A message is basically a transaction that's designed for a specific module. So for example, and so this is sort of the interface that a Mexican has to fulfilled. And so back to our name point example, right, here's a simple message that we'll have. We'll say what when a user wants to pop like change, set the name right, what are the things that they have to do? They have to say what is the name that they're changing? What is the, like you know, what's the result? IP address or something. And who am I? And so, you know, you can ignore all of this stuff as a kind of like, extra stuff. And so, you know, here you can do like, there's, there's something called Validate Basic. So this is kind of like what I was saying. In Ethereum, there's no way for the chain to like even make sure that the transaction is designed properly or not. It just accepts a transaction. This might cause you to lose a lot of gas or like, you pay fees and your transaction fails. Here we get, we give you the ability to do a lot of checks before the transaction even hits the blockchain. So we can check to make sure none of these fields are empty. You can check to make sure that you know none of the fields. You can check to make sure that you're actually the owner of the name. You're not allowing someone else to like, change it. So we give you the ability to do a lot of these checks before the transaction takes the blockchain. It does it on the client side so that way you don't end up wasting a lot of gas. And, and you know, I've done this before on Ethereum where I've tried to like use augur and then it turns out my transaction fails for some reason and it ends up losing like $13 of gas. And then you can also do like get signers. So in Ethereum you kind of have this situation where there can only be like one signer on a transaction. While sometimes, let's say you want to do like atomic swap or something, right? You want both people to be signers on the transaction. And so we actually give you the ability to do that where you can put, define who are the signers on a transaction. This is something that like, just isn't possible on other systems. And then a handler is sort of the thing that actually like takes in the message and kind of, you know, calls the right functions on the keepers. So the handler will take in this set name message and then call the relevant functions on the keeper and it will kind of return the result. So it gives you one of the things that we've built in the SDK, this ability to return like error codes. It does all the logs for you, it does events, it kind of handles a lot of this for you. All you have to do is just like, this is simple struct and you just set these and it handles everything else for you. And so, you know, kind of maybe to give a visual model of what I've been talking about so far is a Transaction. You know a transaction comes into the blockchain, it has a couple of main pieces, it has the authentication data and then it has, it can have one message, it can have multiple messages. So that one thing, that one thing that's kind of cool is you can kind of do many things at once. Let's say I know I want to do something on a prediction market and buy something on the decks at the same time instead of having to do two different transactions where like that I have to like that's more expensive because it costs more gas and stuff. I can do all of these at the same time and it's like much, much cheaper because like I don't have the same. I'm not doing two transactions, I'm doing all in a single transaction. So the first thing that comes in is the authentication data checks. It comes to the anti handler and it's checking the authentication data. It looks at the authentication data and if it says oh no, something's wrong, the signature is wrong or you know, it doesn't pass the basic like verification, it will just. What it will do is it will right away just go and throw at the transaction. And like I said, the nice thing is you don't have to pay any gas fees. So if a signature is wrong or anything, it doesn't hurt you at all. On the other hand, if the anti handler says yes, this is good to go, the transaction will go on to the next step, which is the router and the router will pass it to the right handler. So the pink message, it will say, oh, okay, you're supposed to go to that handler over there, it'll send it to that handler and the handler that you define will execute whatever logic you wanted to do. And then you know, it'll keep on doing the same. And you know, using this like simple three step piece, we handle all of this for you. All you have to do is like just write your handler at the end and that's how sort of simple it is. And so, you know, bit of a review. It's no, it's a well constrained and easy to reason about business logic defining your application's functionality. You can use this to basically write any type of blockchain you want. What we're working on right now is a project called the Cosmos Hub, which is a chain that's designed for interchange communication and helping other blockchains talk to each other. But you can use the Cosmos SDK to do all sorts of things. There are many projects already building on the Cosmos SDK. One of them is irisnet, which Harriet will be talking about right next after me. We have projects, we're building stuff like video streaming, we have projects, we're building payment channel networks, we have projects that are building plasma blockchains. Like the SDK is this like super general purpose thing that you can sort of use to build any blockchain you want in a very easy way. Like no more solidity, no more C. It's all in go. And so you know, what I did was this hands on tutorial, but you know, it was kind of iffy, like, you know, I was kind of talking through it. What I've done is I actually took this entire tutorial and wrote it up as this tutorial on GitHub. So you can go to this URL and it'll give you this whole tutorial and it'll help you basically make a full namecoin application real basically on the Cosmos SDK, which you can go ahead and get started on. And then tomorrow J. Kwon will be, who is the founder of Cosmos, will be giving a keynote in the morning at 9:50am talking a lot about a little bit more on the high level overview of the Cosmos SDK. Today was the tech day, so I decided to go very technical. But tomorrow he'll be talking more about like what is the vision of Cosmos SDK and a lot about the modularity of the system. So yeah, thank you so much.