LaconicNetwork/cosmos-sdk
9
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 2 Wiki Activity

chore: migrate a few diagrams to mermaid (#20473)

Browse Source
This commit is contained in:
Marko 2024-05-29 06:43:46 +02:00 committed by GitHub
parent 6a07568e30
commit 2141ddb676
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
2 changed files with 25 additions and 80 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

58
docs/build/building-modules/00-intro.md vendored
View File

@ -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.

47
docs/learn/advanced/04-store.md
View File

@ -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 |
| |
+-----------------------------------------------------+
```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
Application's State
MainMultistore --> ApplicationState["Application's State"]
```
### Store Interface