Programmable Money Part 2: The Cosmos SDK

The second article in a three-part series, which gives an overview of how the Cosmos SDK brings modular programmability to blockchains.

Table of Contents

• Recap
• Method 1: The Cosmos SDK
• The Lottery App as an Appchain
  - Constructing the Appchain
  - The Appchain in Action
• Improvements over Ethereum
• Conclusion

Recap

Hello dear reader, and welcome to our second article on programmability in blockchain! If you haven’t already, please make sure you read our first article in this series, otherwise, I worry you might get a little confused.

Recall that programmability on Ethereum comes from smart contracts which can be compiled and deployed onto the blockchain using the Ethereum Virtual Machine (or EVM). These smart contracts are extremely versatile, but they introduce challenges with regards to performance, flexibility, security, and sovereignty.

The Cosmos vision of a network of interoperable blockchains is, in our opinion, the natural next step for the programmability that Ethereum brought into this new universe of crypto-assets. Unlike with Ethereum, there are three main ways that a Cosmos appchain can be programmed to go beyond the basics, and in this article, we will focus on the Cosmos SDK.

Method 1: Cosmos SDK

The Cosmos Software Developer Kit (or SDK) is a collection of modules written in the Go programming language. A module is a small block of code that performs a very particular set of tasks. You get these modules ‘out-of-the-box’ when you download the SDK, and the modules work together to bring all the properties of a typical Cosmos blockchain to life.

For example, the x/auth module contains (among other things) all the definitions and parameters for a standard user account — public keys, private keys, authentication, and so on. The x/bank module is used to keep track of a native token (or tokens), and has some other nifty features that we will use later. The complete list of modules is described in the documentation¹.

If you want to build your own appchain, you will need to write a collection of modules that will work together with the existing ones.

The Lottery App as an Appchain

Remember that smart contract we built in the last article? Quick reminder: Our app (a single smart contract) is a simple lottery contract that receives ETH up to a certain jackpot amount, then distributes the jackpot to one random contributor. Let’s look at how we reconstruct this application on a dedicated Cosmos blockchain.

In keeping with the example in our last article, we will walk through what’s involved in creating an entire blockchain whose sole function is the existence of this simple lottery application.

“Isn’t this overkill?”

Absolutely.

But hopefully, it will give you some insight into how a much more complicated appchain (Like Osmosis or Stargaze) is constructed.

Constructing the Appchain

The first step I will need to take is to import the Cosmos SDK. The code for all the various modules is stored in a GitHub repository² and can be freely downloaded (or cloned) by anyone.

This entire application will be hosted by a dedicated blockchain — let’s call it “LotteryChain” with native token LTRY. This token will be used for securing LotteryChain via staking and the CometBFT consensus protocol, just like most Cosmos blockchains.

I will need to add one new module to the existing ones to run this application. Let’s call it “lottery”. In this module, I will need to define this special address that will receive and store incoming assets. Remember the x/auth module I mentioned earlier? Within it is the definition of a Module Account³ which is an account that can make special kinds of transactions like transfer, mint or burn tokens.

Since this account will not mint or burn any assets (only forward them) I don’t need to do anything special to it, I just need to define it in my “lottery” module. Here, I will set:

1. The Jackpot limit (say, 1000 LTRY tokens)
2. The logic for storing any addresses that send tokens (and resetting that list after each jackpot is distributed)
3. The algorithm for selecting the winner

As long as we are sure that this module will work the way we think, we are done! Now we have all the code we need for an appchain that has all the typical Cosmos features but also runs its Lottery application.

If I enable the inter-blockchain communication protocol (IBC) as well (details here), then this application could be able to accept tokens from other Cosmos chains as well!

Finally, we require a validator set — a collection of people or teams with good computers (and good internet connections) to actually run my code, and process transactions. There will be a genesis block — the first block defining the initial state of LotteryChain — to get the blockchain started, and then we’re off!

The Appchain in Action

Let’s now suppose that my blockchain is up and running. It has its own set of validators and people are using the LTRY token. Let’s run through what actually happens when a user transfers 1 LTRY token to this special module account.

1. The transaction will be received by one of the validators at the CometBFT level.
2. CometBFT will do a global check to make sure the transaction is valid, and then pass the transaction to a special piece of the Cosmos SDK called baseapp. It is the job of baseapp to route messages in the transaction to the relevant modules. Since this transaction transfers tokens, its message will be routed to the bank module. Let’s suppose our transaction passes all validity checks.
3. Our special module account will store the 1 LTRY and add the sender’s address to its local storage. If the 1 LTRY is enough to hit the threshold, it will forward the jackpot to one of the stored sender addresses. Since this module account will have sufficient funds to reward the jackpot winner, its forwarding transaction will also be valid.
4. The winner will receive their jackpot and the process will begin again!

Ok, so we’ve built our Cosmos appchain and it was a lot more work than just writing an Ethereum smart contract. So… was it worth it?

Improvements Over Ethereum

Performance: There are a few notable improvements to performance, but allow me to focus on the most obvious and maybe the most important: Your dedicated appchain will not need to process transactions from other applications — only the ones generated by your users.

This means there is no competition for blockspace. We have already seen in the past, for example, that NFT events can clog up transactions for financial applications on Ethereum. On a Cosmos appchain, this cannot happen since totally separate chains would host the two applications.

Flexibility & Sovereignty: The existing SDK modules are just a starting point — they can all be modified to provide even more customizability, and there are currently many versions of modified SDK modules in production today.

Even CometBFT is not required! The SDK includes an interface called ABCI that can handle different consensus protocols (though CometBFT is the default that comes ready for use).

In addition, there is no longer some common layer-1 chain that’s capturing the value from many unrelated dapps. Your native token can capture the value of your application in whatever way you want it to.

Distribute gas fees to stakers? Sure. Token burn mechanism? Can do. The modularity allows developers to take full control over their Web3 products.

Security: On Ethereum, anyone can create malicious or poorly written contracts that could endanger your user’s funds. But on your appchain, the space of possible attacks is far smaller since users can only perform a small, well-defined set of operations. Remember, Bitcoin’s security benefits enormously from its simplicity.

Of course, it is possible for poor module design to result in exploits, and the Cosmos has seen some of these, but there is even an improvement to security after the modules have been deployed and the chain is up and running:

Suppose there is an exploit in your appchain — as long as you can make enough validators (with ⅓ of the voting power) aware of it, you can halt the chain while upgrades are made to protect user funds. Such a precaution would never be possible on Ethereum, as a halt to the chain would halt ALL applications running on it, even the ones that were working without issue.

Conclusion

Congratulations on making it through an introduction to the Cosmos SDK! Hopefully you now understand that:

• The Cosmos SDK contains a collection of modules that give Cosmos blockchains their features
• An appchain is an application hosted by a dedicated blockchain
• Appchains can be created by adding new modules with additional functionality
• Hosting an application on an appchain comes with several security and performance advantages when compared to smart contracts on Ethereum.

It should be noted that the advantages can also be a deficits when it comes to upgrading a Cosmos blockchain. Upgrades to modules must be handled manually by individual validators and thus coordinated carefully to minimize the chances of a fork. Interestingly, the solution to this issue lies in the reintroduction of smart contracts! Read through our next article to find out how!

Thanks for reading ❤
Robin Tunley
Twitter: @the5thforce0_0
Special thanks to Ruslan Akhtariev for his input in this series.

References

[1]: Cosmos SDK Documentation, Modules, https://docs.cosmos.network/main/modules

[2]: Cosmos SDK Github: https://github.com/cosmos/cosmos-sdk

[3]: Cosmos SDK Documentation, x/bank: https://docs.cosmos.network/main/modules/bank

If you found this article interesting or informative, please help us out by sharing it with your friends and family. If there are other topics within the Cosmos you’d like to know more about, don’t hesitate to contact us and let us know!

Notional: Website
Notional on Twitter: @notionaldao