Cosmos-SDK Alpha Release

The highly anticipated alpha release of the Cosmos-SDK is here!
View it on GitHub!
Construct a Blockchain using the Cosmos-SDK
The Cosmos-SDK is a generic framework that comes with all the tooling to enable you to construct your own blockchain, called a zone, in the context of the Cosmos Network. It is designed for developers to build decentralized applications as their own zones while removing the daunting task of building a secure state machine from the ground up just to spin up a blockchain-based application. In the past, application developers forked existing codebases in order to do this. Cosmos-SDK gives you a better alternative.
The SDK gives you fine-grained control over your application, enabling highly customizable zones through the use of plugins. It is designed as a bare bones software development kit with basic necessities such as tokens, governance, IBC, and staking built in. You can then add functionality for your particular use case through plugins and easily deploy your application as its very own blockchain (see diagram).

A zone that is spun up using the Cosmos-SDK is comprised of two components: the Cosmos-SDK and Tendermint.
Very briefly, the Tendermint Application Blockchain Interface (ABCI) that you see depicted is the interface between Tendermint and the “application”. Deeper technical dive on that in a future blog post.
Tendermint ABCI documentation can be found here.
The Cosmos-SDK-built blockchain, or the “ABCI app”, is a deterministic state machine that can be run on any replication engine. If you build on the Cosmos-SDK, you’re not locked into Tendermint. Everything within Cosmos is designed to be modular, so you can even swap out the underlying consensus engine with whatever you want, i.e., a non-replicating engine, a fault-tolerant engine, or what-have-you.
For a broad understanding of how the SDK is used to build a zone, watch Sunny Aggarwal’s overview about the architecture of the Cosmos Network.
Core Components of the SDK:
Transactions & messages are designed to be generic enough for developers to specify their own encoding schemes. This enables the SDK to be used as the framework for constructing already specified cryptocurrency state machines, like Ethereum for instance.
Context & Handlers: Each message has a type, which is associated with a handler via BaseApp.Router. Everything required to process the message is contained in the Context, which is passed in as the first argument to the Handler. This is part of a larger object capability security system.
Stores & Mappers: Stores are Merkle-izable persistent stores, such as Ethereum’s Patricia Trie or an IAVL Tree. A Mapper provides specific functionality on top of a store, such as loading or saving account data. A Mapper doesn’t have any persistent state itself, but it is provided the persistent state via a Context.
Key Features:
1. Object Capability Security Model —When thinking about security, it’s good to start with a specific threat model. Our threat model is the following:
We want to assume a thriving ecosystem of Cosmos-SDK modules that are easy to compose into a blockchain application. Some of these modules will be faulty or malicious.
The Cosmos-SDK is designed to address this threat by being the foundation of an object capability-based system. Read the Cosmos-SDK design philosophy.
2. Flexible MultiStore System with Iterators—Supports multiple kinds of Merkle-ized data stores: i.e., Tendermint’s IAVL trees, Ethereum’s Patricia trie. The IAVL tree has native support for fast iteration (with smart caching) to fetch a series of key-value pairs. The IAVL tree also natively supports keys and values of arbitrary length, making it more efficient to store complex structures.
Ongoing Work
Additional modules such as x/gov for blockchain governance, x/ibc for Inter-blockchain-communication, x/staking for staking are all coming soon.
Give the Cosmos-SDK a whirl!
GitHub: https://github.com/cosmos/cosmos-sdk
Contribute: https://github.com/cosmos/cosmos-sdk/issues