github.com/fibonacci-chain/fbc@v0.0.0-20231124064014-c7636198c1e9/libs/cosmos-sdk/docs/intro/sdk-design.md (about)

     1  <!--
     2  order: 4
     3  -->
     4  
     5  # Main Components of the Cosmos SDK
     6  
     7  The Cosmos SDK is a framework that facilitates the development of secure state-machines on top of Tendermint. At its core, the SDK is a boilerplate implementation of the [ABCI](./sdk-app-architecture.md#abci) in Golang. It comes with a [`multistore`](../core/store.md#multistore) to persist data and a [`router`](../core/baseapp.md#routing) to handle transactions.
     8  
     9  Here is a simplified view of how transactions are handled by an application built on top of the Cosmos SDK when transferred from Tendermint via `DeliverTx`:
    10  
    11  1. Decode `transactions` received from the Tendermint consensus engine (remember that Tendermint only deals with `[]bytes`).
    12  2. Extract `messages` from `transactions` and do basic sanity checks.
    13  3. Route each message to the appropriate module so that it can be processed.
    14  4. Commit state changes.
    15  
    16  ## `baseapp`
    17  
    18  `baseapp` is the boilerplate implementation of a Cosmos SDK application. It comes with an implementation of the ABCI to handle the connexion with the underlying consensus engine. Typically, a Cosmos SDK application extends `baseapp` by embedding it in [`app.go`](../basics/app-anatomy.md#core-application-file). See an example of this from the SDK application tutorial:
    19  
    20  +++ https://github.com/cosmos/sdk-tutorials/blob/c6754a1e313eb1ed973c5c91dcc606f2fd288811/app.go#L72-L92
    21  
    22  The goal of `baseapp` is to provide a secure interface between the store and the extensible state machine while defining as little about the state machine as possible (staying true to the ABCI).
    23  
    24  For more on `baseapp`, please click [here](../core/baseapp.md).
    25  
    26  ## Multistore
    27  
    28  The Cosmos SDK provides a [`multistore`](../core/store.md#multisotre) for persisting state. The multistore allows developers to declare any number of [`KVStores`](../core/store.md#base-layer-kvstores). These `KVStores` only accept the `[]byte` type as value and therefore any custom structure needs to be marshalled using [a codec](../core/encoding.md) before being stored.
    29  
    30  The multistore abstraction is used to divide the state in distinct compartments, each managed by its own module. For more on the multistore, click [here](../core/store.md#multistore)
    31  
    32  ## Modules
    33  
    34  The power of the Cosmos SDK lies in its modularity. 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 SDK is responsible for routing each message to its respective module.
    35  
    36  Here is a simplified view of how a transaction is processed by the application of each full-node when it is received in a valid block:
    37  
    38  ```
    39                                        +
    40                                        |
    41                                        |  Transaction relayed from the full-node's Tendermint engine
    42                                        |  to the node's application via DeliverTx
    43                                        |
    44                                        |
    45                                        |
    46                  +---------------------v--------------------------+
    47                  |                 APPLICATION                    |
    48                  |                                                |
    49                  |     Using baseapp's methods: Decode the Tx,    |
    50                  |     extract and route the message(s)           |
    51                  |                                                |
    52                  +---------------------+--------------------------+
    53                                        |
    54                                        |
    55                                        |
    56                                        +---------------------------+
    57                                                                    |
    58                                                                    |
    59                                                                    |
    60                                                                    |  Message routed to the correct
    61                                                                    |  module to be processed
    62                                                                    |
    63                                                                    |
    64  +----------------+  +---------------+  +----------------+  +------v----------+
    65  |                |  |               |  |                |  |                 |
    66  |  AUTH MODULE   |  |  BANK MODULE  |  | STAKING MODULE |  |   GOV MODULE    |
    67  |                |  |               |  |                |  |                 |
    68  |                |  |               |  |                |  | Handles message,|
    69  |                |  |               |  |                |  | Updates state   |
    70  |                |  |               |  |                |  |                 |
    71  +----------------+  +---------------+  +----------------+  +------+----------+
    72                                                                    |
    73                                                                    |
    74                                                                    |
    75                                                                    |
    76                                         +--------------------------+
    77                                         |
    78                                         | Return result to Tendermint
    79                                         | (0=Ok, 1=Err)
    80                                         v
    81  ```
    82  
    83  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 (*Note:* `messages` are extracted from `transactions` by `baseapp`). In general, each module declares its own `KVStore` in the `multistore` to persist the subset of the state it defines. Most developers will need to access other 3rd party modules when building their own modules. Given that the Cosmos-SDK is an open framework, some of the modules may be malicious, which means there is a need for security principles to reason about inter-module interactions. These principles are based on [object-capabilities](../core/ocap.md). In practice, this means that instead of having each module keep an access control list for other modules, each module implements special objects called `keepers` that can be passed to other modules to grant a pre-defined set of capabilities. 
    84  
    85  SDK modules are defined in the `x/` folder of the SDK. Some core modules include:
    86  
    87  - `x/auth`: Used to manage accounts and signatures.
    88  - `x/bank`: Used to enable tokens and token transfers.
    89  - `x/staking` + `x/slashing`: Used to build Proof-Of-Stake blockchains.
    90  
    91  In addition to the already existing modules in `x/`, that anyone can use in their app, the SDK lets you build your own custom modules. You can check an [example of that in the tutorial](https://cosmos.network/docs/tutorial/keeper.html).
    92  
    93  ## Next {hide}
    94  
    95  Learn more about the [anatomy of an SDK application](../basics/app-anatomy.md) {hide}