From 2141ddb6764a8e484d29d2e5fda30fd0cfb0bfae Mon Sep 17 00:00:00 2001 From: Marko Date: Wed, 29 May 2024 06:43:46 +0200 Subject: [PATCH] chore: migrate a few diagrams to mermaid (#20473) --- docs/build/building-modules/00-intro.md | 58 +++++++------------------ docs/learn/advanced/04-store.md | 49 +++++---------------- 2 files changed, 26 insertions(+), 81 deletions(-) diff --git a/docs/build/building-modules/00-intro.md b/docs/build/building-modules/00-intro.md index 9547efa70187..b055dfd1e42c 100644 --- a/docs/build/building-modules/00-intro.md +++ b/docs/build/building-modules/00-intro.md @@ -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. diff --git a/docs/learn/advanced/04-store.md b/docs/learn/advanced/04-store.md index 570281f605cd..3a9b114768ac 100644 --- a/docs/learn/advanced/04-store.md +++ b/docs/learn/advanced/04-store.md @@ -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