Go to file
Christopher Goes 22372bfffd
Add basic Dockerfile to build all binaries and export gaiad
2018-04-10 12:39:47 +02:00
.circleci Upgrade to Circle 2.0 2018-03-21 00:55:55 +01:00
.github github PR template 2018-03-01 18:26:16 -05:00
baseapp more MarshalJSONIndent 2018-04-09 23:18:56 +03:00
client fix tests 2018-04-07 20:56:49 +03:00
cmd gaiacli is just basecli 2018-04-09 20:40:16 +03:00
docs Fix docs; Bump version; Fix makefile 2018-04-07 00:08:53 -07:00
examples basecoin/types: UnmarshalBinaryBare 2018-04-09 21:05:03 +03:00
mock fix mock test 2018-04-05 13:51:32 +03:00
server MarshalJSONIndent 2018-04-09 20:32:19 +03:00
store Merge branch 'develop' into sunny/IAVLsubspace 2018-04-05 22:02:21 +02:00
tests fixes post rebase 2018-03-17 23:09:04 +01:00
tools Fix bug: make will fail if the path contains whitespace 2018-03-09 13:06:36 +08:00
types Merge pull request #767 from cosmos/sunny/IAVLsubspace 2018-04-09 20:22:38 -04:00
version changelog and version 2018-04-09 20:41:03 +03:00
wire MarshalJSONIndent 2018-04-09 20:32:19 +03:00
x Merge pull request #821 from cosmos/adrian/deadcode 2018-04-09 20:34:50 -04:00
.codecov.yml codecov: closes #334 2018-01-17 20:00:54 -05:00
.dockerignore Add basic Dockerfile to build all binaries and export gaiad 2018-04-10 12:39:47 +02:00
.gitignore cleanup gitignore 2018-03-31 19:05:15 +03:00
CHANGELOG.md Merge branch 'master' into develop 2018-04-09 20:56:35 +03:00
CODEOWNERS add ebuchman as codeowner 2018-02-13 08:55:44 -05:00
CODE_OF_CONDUCT.md Create CODE_OF_CONDUCT.md 2018-01-29 12:38:50 +01:00
Dockerfile Add basic Dockerfile to build all binaries and export gaiad 2018-04-10 12:39:47 +02:00
Gopkg.lock deps, changelog, version 2018-04-09 16:51:40 +03:00
Gopkg.toml deps, changelog, version 2018-04-09 16:51:40 +03:00
LICENSE Add README.md to Basecoin; Update licenses 2018-01-28 18:17:19 -08:00
Makefile Fix docs; Bump version; Fix makefile 2018-04-07 00:08:53 -07:00
README.md Merge branch 'develop' into fedekunze/README 2018-04-09 09:50:22 -03:00
Vagrantfile Finally working 2018-01-27 17:40:11 -08:00

README.md

Cosmos SDK

banner

version API Reference Rocket.Chat license LoC Go Report Card

Branch Tests Coverage
develop CircleCI codecov
master CircleCI codecov

WARNING: the libraries are still undergoing breaking changes as we get better ideas and start building out the Apps.

Note: Requires Go 1.9+

Overview

The Cosmos-SDK is a platform for building multi-asset Proof-of-Stake (PoS) blockchains, like the Cosmos Hub. It is both a library for building and securely interacting with blockchain applications.

The goal of the Cosmos-SDK is to allow developers to easily create custom interoperable blockchain applications within the Cosmos Network without having to recreate common blockchain functionality, thus abstracting away the complexities of building a Tendermint ABCI application. We envision the SDK as the npm-like framework to build secure blockchain applications on top of Tendermint.

In terms of its design, the SDK optimizes flexibility and security. The framework is designed around a modular execution stack which allows applications to mix and match elements as desired. In addition, all modules are sandboxed for greater application security.

It is based on two major principles:

  • Composability: Anyone can create a module for the Cosmos-SDK and integrating the already-built modules is as simple as importing them into your blockchain application.

  • Capabilities: The SDK is inspired by capabilities-based security, and informed by years of wrestling with blockchain state machines. Most developers will need to access other 3rd party modules when building their own modules. Given that the Cosmos-SDK is an open framework and that we assume that some those modules may be malicious, we designed the SDK using object-capabilities (ocaps) based principles. In practice, this means that instead of having each module keep an access control list for other modules, each module implements keepers that can be passed to other modules to grant a pre-defined set of capabilities. For example, if an instance of module A's keepers is passed to module B, the latter will be able to call a restricted set of module A's functions.

    The capabilities of each keeper are defined by the module's developer, and it's their job to understand and audit the safety of foreign code from 3rd party modules based on the capabilities they are passing into each 3rd party module. For a deeper look at capabilities, you can read this article.

Note: For now the Cosmos-SDK only exists in Golang, which means that developers can only develop SDK modules in Golang. In the future, we expect that the SDK will be implemented in other programming languages. Funding opportunities supported by the Tendermint team may be available eventually.

Application architecture

Modules

The Cosmos-SDK has all the necessary pre-built modules to add functionality on top of a BaseApp, which is the template to build a blockchain dApp in Cosmos. In this context, a module is a fundamental unit in the Cosmos-SDK. Each module is an extension of the BaseApp functionalities that defines transactions, handles application state and the state transition logic. Each module also contains handlers for messages and transactions, as well as REST and CLI for secure user interactions.

Some of the most important modules already integrated in the SDK are:

  • Auth: Defines a standard account structure (BaseAccount) and how transaction signers are authenticated.
  • Bank: Defines how coins (i.e cryptocurrencies) are transferred.
  • Governance: Governance related implementation including proposals and voting.
  • Staking: Proof of Stake related implementation including bonding and delegation transactions, inflation, fees, unbonding, etc.
  • IBC: Defines the intereoperability of blockchain zones according to the specifications of the IBC Protocol.

Directories

The key directories of the SDK are:

  • baseapp: Defines the template for a basic ABCI application so that your Cosmos-SDK application can communicate with the underlying Tendermint node.
  • client: CLI and REST server tooling.
  • server: RPC server to communicate with the node.
  • examples: Contains examples on how to build working standalone applications.
  • store: Contains code for the multistore (i.e. state). Each module can create any number of KVStores (key-value stores) from the multistore.
  • types: Common types required in any SDK-based application.
  • x(for eXtensions): Folder for storing the BaseApp module and all the already-built modules described in the previous section.

Prerequisites

Getting Started

See the documentation.