Skip to content

Commit

Permalink
chore: migrate a few diagrams to mermaid (#20473)
Browse files Browse the repository at this point in the history
  • Loading branch information
@tac0turtle
tac0turtle authored May 29, 2024
1 parent 6a07568 commit 2141ddb
Show file tree
Hide file tree
Showing 2 changed files with 26 additions and 81 deletions.
58 changes: 15 additions & 43 deletions docs/build/building-modules/00-intro.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -23,49 +23,21 @@ On top of this core, the Cosmos SDK enables developers to build modules that imp

Cosmos SDK modules can be seen as little state-machines within the state-machine. They generally define a subset of the state using one or more `KVStore`s in the [main multistore](../../learn/advanced/04-store.md), as well as a subset of [message types](./02-messages-and-queries.md#messages). These messages are routed by one of the main components of Cosmos SDK core, [`BaseApp`](../../learn/advanced/00-baseapp.md), to a module Protobuf [`Msg` service](./03-msg-services.md) that defines them.

```text
+
|
| Transaction relayed from the full-node's consensus engine
| to the node's application via DeliverTx
|
|
|
+---------------------v--------------------------+
| APPLICATION |
| |
| Using baseapp's methods: Decode the Tx, |
| extract and route the message(s) |
| |
+---------------------+--------------------------+
|
|
|
+---------------------------+
|
|
|
| Message routed to the correct
| module to be processed
|
|
+----------------+ +---------------+ +----------------+ +------v----------+
| | | | | | | |
| AUTH MODULE | | BANK MODULE | | STAKING MODULE | | GOV MODULE |
| | | | | | | |
| | | | | | | Handles message,|
| | | | | | | Updates state |
| | | | | | | |
+----------------+ +---------------+ +----------------+ +------+----------+
|
|
|
|
+--------------------------+
|
| Return result to the underlying consensus engine (e.g. CometBFT)
| (0=Ok, 1=Err)
v
```mermaid
flowchart TD
A[Transaction relayed from the full-node's consensus engine to the node's application via DeliverTx]
A --> B[APPLICATION]
B --> C["Using baseapp's methods: Decode the Tx, extract and route the message(s)"]
C --> D[Message routed to the correct module to be processed]
D --> E[AUTH MODULE]
D --> F[BANK MODULE]
D --> G[STAKING MODULE]
D --> H[GOV MODULE]
H --> I[Handles message, Updates state]
E --> I
F --> I
G --> I
I --> J["Return result to the underlying consensus engine (e.g. CometBFT) (0=Ok, 1=Err)"]
```

As a result of this architecture, building a Cosmos SDK application usually revolves around writing modules to implement the specialized logic of the application and composing them with existing modules to complete the application. Developers will generally work on modules that implement logic needed for their specific use case that do not exist yet, and will use existing modules for more generic functionalities like staking, accounts, or token management.
Expand Down
49 changes: 11 additions & 38 deletions docs/learn/advanced/04-store.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -18,44 +18,17 @@ A store is a data structure that holds the state of the application.

The Cosmos SDK comes with a large set of stores to persist the state of applications. By default, the main store of Cosmos SDK applications is a `multistore`, i.e. a store of stores. Developers can add any number of key-value stores to the multistore, depending on their application needs. The multistore exists to support the modularity of the Cosmos SDK, as it lets each module declare and manage their own subset of the state. Key-value stores in the multistore can only be accessed with a specific capability `key`, which is typically held in the [`keeper`](../../build/building-modules/06-keeper.md) of the module that declared the store.

```text
+-----------------------------------------------------+
| |
| +--------------------------------------------+ |
| | | |
| | KVStore 1 - Manage by keeper of Module 1 |
| | | |
| +--------------------------------------------+ |
| |
| +--------------------------------------------+ |
| | | |
| | KVStore 2 - Manage by keeper of Module 2 | |
| | | |
| +--------------------------------------------+ |
| |
| +--------------------------------------------+ |
| | | |
| | KVStore 3 - Manage by keeper of Module 2 | |
| | | |
| +--------------------------------------------+ |
| |
| +--------------------------------------------+ |
| | | |
| | KVStore 4 - Manage by keeper of Module 3 | |
| | | |
| +--------------------------------------------+ |
| |
| +--------------------------------------------+ |
| | | |
| | KVStore 5 - Manage by keeper of Module 4 | |
| | | |
| +--------------------------------------------+ |
| |
| Main Multistore |
| |
+-----------------------------------------------------+
Application's State
```mermaid
flowchart TB
subgraph MainMultistore["Main Multistore"]
KVStore1["KVStore 1 - Managed by keeper of Module 1"]
KVStore2["KVStore 2 - Managed by keeper of Module 2"]
KVStore3["KVStore 3 - Managed by keeper of Module 2"]
KVStore4["KVStore 4 - Managed by keeper of Module 3"]
KVStore5["KVStore 5 - Managed by keeper of Module 4"]
end
MainMultistore --> ApplicationState["Application's State"]
```

### Store Interface
Expand Down

0 comments on commit 2141ddb

Please sign in to comment.