docs: migrate diagrams to mermaidjs (#20503)
Co-authored-by: Facundo Medica <14063057+facundomedica@users.noreply.github.com>
This commit is contained in:
Marko
Facundo Medica
@@ -12,22 +12,31 @@ This document describes the core parts of a Cosmos SDK application, represented
|
||||
|
||||
The Daemon, or [Full-Node Client](../advanced/03-node.md), is the core process of a Cosmos SDK-based blockchain. Participants in the network run this process to initialize their state-machine, connect with other full-nodes, and update their state-machine as new blocks come in.
|
||||
|
||||
```text
|
||||
^ +-------------------------------+ ^
|
||||
| | | |
|
||||
| | State-machine = Application | |
|
||||
| | | | Built with Cosmos SDK
|
||||
| | ^ + | |
|
||||
| +----------- | ABCI | ----------+ v
|
||||
| | + v | ^
|
||||
| | | |
|
||||
Blockchain Node | | Consensus | |
|
||||
| | | |
|
||||
| +-------------------------------+ | CometBFT
|
||||
| | | |
|
||||
| | Networking | |
|
||||
| | | |
|
||||
v +-------------------------------+ v
|
||||
```mermaid
|
||||
flowchart TD
|
||||
subgraph Blockchain_Node[Blockchain Node]
|
||||
subgraph SM[State-machine = Application]
|
||||
direction TB
|
||||
SM1[Cosmos SDK]
|
||||
end
|
||||
subgraph ABCI[ABCI]
|
||||
direction TB
|
||||
end
|
||||
subgraph Consensus[Consensus]
|
||||
direction TB
|
||||
end
|
||||
subgraph Networking[Networking]
|
||||
direction TB
|
||||
end
|
||||
end
|
||||
|
||||
SM <--> ABCI
|
||||
ABCI <--> Consensus
|
||||
Consensus <--> Networking
|
||||
|
||||
Blockchain_Node -->|Includes| SM
|
||||
Blockchain_Node -->|Includes| Consensus
|
||||
Blockchain_Node -->|Includes| Networking
|
||||
```
|
||||
|
||||
The blockchain full-node presents itself as a binary, generally suffixed by `-d` for "daemon" (e.g. `appd` for `app` or `gaiad` for `gaia`). This binary is built by running a simple [`main.go`](../advanced/03-node.md#main-function) function placed in `./cmd/appd/`. This operation usually happens through the [Makefile](#dependencies-and-makefile).
|
||||
@@ -112,13 +121,15 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/simapp/app.go#L626-L63
|
||||
|
||||
There are two semantics around the new lifecycle method:
|
||||
|
||||
- It runs before the `BeginBlocker` of all modules
|
||||
- It can modify consensus parameters in storage, and signal the caller through the return value.
|
||||
* It runs before the `BeginBlocker` of all modules
|
||||
* It can modify consensus parameters in storage, and signal the caller through the return value.
|
||||
|
||||
When it returns `ConsensusParamsChanged=true`, the caller must refresh the consensus parameter in the finalize context:
|
||||
|
||||
```
|
||||
app.finalizeBlockState.ctx = app.finalizeBlockState.ctx.WithConsensusParams(app.GetConsensusParams())
|
||||
```
|
||||
|
||||
The new ctx must be passed to all the other lifecycle methods.
|
||||
|
||||
### BeginBlocker and EndBlocker
|
||||
|
||||
@@ -163,46 +163,13 @@ that receive a block proposal from the correct proposer execute the transactions
|
||||
As mentioned throughout the documentation `BeginBlock`, `ExecuteTx` and `EndBlock` are called within FinalizeBlock.
|
||||
Although every full-node operates individually and locally, the outcome is always consistent and unequivocal. This is because the state changes brought about by the messages are predictable, and the transactions are specifically sequenced in the proposed block.
|
||||
|
||||
```text
|
||||
--------------------------
|
||||
| Receive Block Proposal |
|
||||
--------------------------
|
||||
|
|
||||
v
|
||||
-------------------------
|
||||
| FinalizeBlock |
|
||||
-------------------------
|
||||
|
|
||||
v
|
||||
-------------------
|
||||
| BeginBlock |
|
||||
-------------------
|
||||
|
|
||||
v
|
||||
--------------------
|
||||
| ExecuteTx(tx0) |
|
||||
| ExecuteTx(tx1) |
|
||||
| ExecuteTx(tx2) |
|
||||
| ExecuteTx(tx3) |
|
||||
| . |
|
||||
| . |
|
||||
| . |
|
||||
-------------------
|
||||
|
|
||||
v
|
||||
--------------------
|
||||
| EndBlock |
|
||||
--------------------
|
||||
|
|
||||
v
|
||||
-------------------------
|
||||
| Consensus |
|
||||
-------------------------
|
||||
|
|
||||
v
|
||||
-------------------------
|
||||
| Commit |
|
||||
-------------------------
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Receive Block Proposal] --> B[FinalizeBlock]
|
||||
B --> C[BeginBlock]
|
||||
C --> D["ExecuteTx(tx0, tx1, 1x2)"]
|
||||
D --> E[EndBlock]
|
||||
E --> F[Commit]
|
||||
```
|
||||
|
||||
### Transaction Execution
|
||||
|
||||
@@ -21,44 +21,21 @@ In the Cosmos SDK, an _account_ designates a pair of _public key_ `PubKey` and _
|
||||
|
||||
For HD key derivation the Cosmos SDK uses a standard called [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki). The BIP32 allows users to create an HD wallet (as specified in [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)) - a set of accounts derived from an initial secret seed. A seed is usually created from a 12- or 24-word mnemonic. A single seed can derive any number of `PrivKey`s using a one-way cryptographic function. Then, a `PubKey` can be derived from the `PrivKey`. Naturally, the mnemonic is the most sensitive information, as private keys can always be re-generated if the mnemonic is preserved.
|
||||
|
||||
```text
|
||||
Account 0 Account 1 Account 2
|
||||
|
||||
+------------------+ +------------------+ +------------------+
|
||||
| | | | | |
|
||||
| Address 0 | | Address 1 | | Address 2 |
|
||||
| ^ | | ^ | | ^ |
|
||||
| | | | | | | | |
|
||||
| | | | | | | | |
|
||||
| | | | | | | | |
|
||||
| + | | + | | + |
|
||||
| Public key 0 | | Public key 1 | | Public key 2 |
|
||||
| ^ | | ^ | | ^ |
|
||||
| | | | | | | | |
|
||||
| | | | | | | | |
|
||||
| | | | | | | | |
|
||||
| + | | + | | + |
|
||||
| Private key 0 | | Private key 1 | | Private key 2 |
|
||||
| ^ | | ^ | | ^ |
|
||||
+------------------+ +------------------+ +------------------+
|
||||
| | |
|
||||
| | |
|
||||
| | |
|
||||
+--------------------------------------------------------------------+
|
||||
|
|
||||
|
|
||||
+---------+---------+
|
||||
| |
|
||||
| Master PrivKey |
|
||||
| |
|
||||
+-------------------+
|
||||
|
|
||||
|
|
||||
+---------+---------+
|
||||
| |
|
||||
| Mnemonic (Seed) |
|
||||
| |
|
||||
+-------------------+
|
||||
```mermaid
|
||||
graph BT
|
||||
A0A[Address 0] --> A0[Account 0]
|
||||
A0PK[Public key 0] --> A0A[Address 0]
|
||||
A0SK[Private key 0] --> A0PK[Public key 0]
|
||||
A1A[Address 1] --> A1[Account 1]
|
||||
A1PK[Public key 1] --> A1A[Address 1]
|
||||
A1SK[Private key 1] --> A1PK[Public key 1]
|
||||
A2A[Address 2] --> A2[Account 2]
|
||||
A2PK[Public key 2] --> A2A[Address 2]
|
||||
A2SK[Private key 2] --> A2PK[Public key 2]
|
||||
MasterPK[Master PrivKey] --> A0SK[Private key 0]
|
||||
MasterPK[Master PrivKey] --> A1SK[Private key 1]
|
||||
MasterPK[Master PrivKey] --> A2SK[Private key 2]
|
||||
Mnemonic["Mnemonic (Seed)"] --> MasterPK[Master PrivKey]
|
||||
```
|
||||
|
||||
In the Cosmos SDK, keys are stored and managed by using an object called a [`Keyring`](#keyring).
|
||||
|
||||
Reference in New Issue
Block a user