Cosmos SDK

What is Cosmos SDK

The Cosmos SDK is the most advanced framework for building custom application-specific blockchains today. It is open source and designed to build blockchains out of composable modules with ease. At its core, the Cosmos SDK is a boilerplate implementation of the ABCI in Golang. It comes with a multistore to persist data and a router to handle transactions. An application built on top of the Cosmos SDK handles transactions from Tendermint via the DeliverTx method of the ABCI in four steps:

1. Decode transactions received from the Tendermint consensus engine

2. Extract messages from transactions and do basic sanity checks

3. Route each message to appropriate module so that it can be processed

4. Commit state changes

Main components of the Cosmos SDK

Baseapp

Like other Comos SDK applications, our blockchain extends from the baseapp, which is the boilerplate implementation of a Cosmos SDK application. It comes with an implementation of the ABCI to handle the connection with the underlying consensus engine. The goal of baseapp is to provide a secure interface between the store and textensible state machine while defining as little about the state machine as possible.

Multistore

The Cosmos SDK provides a multistore for persisting state. The multistore allows developers to declare any number of KVStores. These KVStores only accept the []byte type as value and therefore any custom structure needs to be marshalled using a codec before being stored. The Multistore abstraction is used to divide the state in distinct compartments, each managed by its own module.

Modules

Cosmos SDK applications are built by aggregating a collection of interoperable modules. Each module defines a subset of the state and contains its own message/transaction processor, while the Cosmos SDK is responsible for routing each message to its respective module. Each module can be seen as a little state-machine.

Developers need to define the subset of the state handled by the module, as well as custom message types that modify the state. In general, each module declares its own KVStore in the multistore to persist the subset of the state it defines and developers can leverage on 3rd party modules when building their own modules.