Cosmos SDK documentation overview: SDK design overview

Cosmos SDK Design Overview

The Cosmos SDK is a blockchain framework for securely developing state machines based on Tendermint. The SDK uses the module of the ABCI interface developed by Go in the core. It includes a persistent data storage multistore data storage module and a router routing module that handles transactions.

Here's a simplified process of how transactions are handled by top-level applications built on the Cosmos SDK when transactions are sent from Tendermint via DeliverTx.

1. Decode the transaction received from the Tendermint consensus engine (remember that only bytes are processed on Tendermint).

2. Extract the message from the transaction and perform a basic normal check.

• Polkadot wave card chain: verifier node cloud deployment tutorial
• Blockchain Internet: The "China Network" Opportunity for Network Infrastructure
• Switzerland's blockchain regulation policy and practice

3. Route each message to the appropriate module for routing to handle it.

4. Submit a status change.

The application also allows you to create transactions, encode them, and pass them to the underlying Tendermint engine to broadcast them.

Baseapp

baseApp is a case implementation of the Cosmos SDK ABCI interface, which also includes a router to route transactions to their respective modules for processing. Your app's main program file app.go will customize your app type to embed baseapp. In this way, your custom app type will automatically inherit the baseapp's ABCI method. See the SDK application tutorial for an example of this.

The goal of the base app is to provide a secure interface between the storage and the scalable state machine while defining the state machine as little as possible (keeping the nativeness of ABCI).

To learn more about baseapp, please click here .

Multistore

The Cosmos SDK provides multiple ways to store persistent storage. Multiple storage methods mean allowing developers to declare any number of KVStores . The KVStores store only accepts values ​​of byte type arrays ([]BYTE). That is, any custom data structure needs to be serialized using go-amino before being stored.

Multistore is abstractly used to divide states into different partitions, each of which has its own module to manage. To learn more about Multistore, click here .

Modules

The power of the Cosmos SDK is its modularity, and the SDK application is built with a bunch of interoperable modules. Each module defines a subset of the state and contains the message/transaction handlers associated with itself, and the SDK is responsible for routing each message to the module associated with them.

This is a simple flow diagram of how each full-node application handles the transaction process when it receives an available block.

(Translator's Note: The transaction is sent to the application by the Tendermint engine via DeliverTx, the application decodes the byte array through the baseapp method, extracts the message, distributes it to different routing modules, the module processes the message update status, and returns the successful result to Tendermint)

Each module can be considered the smallest state machine. Developers need to define a subset of the state each module can handle, as well as custom message types that modify the state (note: the message is extracted from the transaction using the baseapp method). In practice, each module usually declares its own key-value store KVStore to implement persistent storage of state subsets in the multistore. Most developers will need to introduce third-party modules when developing their own modules. Considering that Cosmos-SDK is an open framework, some modules may be malicious, which means that some security rules are needed to control the interaction between modules. . These principles are based on object-oriented. In practice, this means that instead of keeping a list of other modules accessible to each module, each module implements a special object called keeper, which is passed to the predefined function. Other modules.

The SDK module is defined in the x/ folder of the SDK. Some core modules include:

x/auth: Used to manage accounts and signatures.

x/bank: Used to enable tokens and implement token transfers.

x/staking + x/slashing: used to build POS blockchain

In addition to the existing modules in x/ (anyone can use them in their applications), the SDK also allows you to build your own custom modules. You can view this example in this tutorial .

Next, learn more about the OCAP security model for the Cosmos SDK.

Original address: https://cosmos.network/docs/intro/sdk-design.html

We will continue to update Blocking; if you have any questions or suggestions, please contact us!