docs: remove typos and IBC documentation (#11933)
This commit is contained in:
Julien Robert
@@ -139,7 +139,7 @@ To avoid unnecessary roundtrip to the main state, all reads to the branched stor
|
||||
|
||||
During `CheckTx`, the `checkState`, which is based off of the last committed state from the root
|
||||
store, is used for any reads and writes. Here we only execute the wired middlewares `CheckTx` and verify a service router
|
||||
exists for every message in the transaction. Note, that if the a middleware's `CheckTx` fails,
|
||||
exists for every message in the transaction. Note, that if a middleware's `CheckTx` fails,
|
||||
the state transitions won't be reflected in the `checkState` -- i.e. `checkState` is only updated on
|
||||
success.
|
||||
|
||||
@@ -266,7 +266,7 @@ This allows certain checks like signature verification can be skipped during `Ch
|
||||
|
||||
When the underlying consensus engine receives a block proposal, each transaction in the block needs to be processed by the application. To that end, the underlying consensus engine sends a `DeliverTx` message to the application for each transaction in a sequential order.
|
||||
|
||||
Before the first transaction of a given block is processed, a [volatile state](#state-updates) called `deliverState` is intialized during [`BeginBlock`](#beginblock). This state is updated each time a transaction is processed via `DeliverTx`, and committed to the [main state](#main-state) when the block is [committed](#commit), after what is is set to `nil`.
|
||||
Before the first transaction of a given block is processed, a [volatile state](#state-updates) called `deliverState` is initialized during [`BeginBlock`](#beginblock). This state is updated each time a transaction is processed via `DeliverTx`, and committed to the [main state](#main-state) when the block is [committed](#commit), after what it is set to `nil`.
|
||||
|
||||
`DeliverTx` performs the **exact same steps as `CheckTx`**, with a little caveat at step 3 and the addition of a fifth step:
|
||||
|
||||
@@ -292,7 +292,7 @@ At any point, if `GasConsumed > GasWanted`, the function returns with `Code != 0
|
||||
|
||||
## Middlewares
|
||||
|
||||
Middlewares implement the `tx.Handler` interface. They are called within BaseApp `CheckTx` and `DeliverTx`, allowing to run custom logic before or after the transaction is processed. They are primaraly used to authenticate the transaction before the transaction's internal messages are processed, but also to perform additional checks on the transaction itself.
|
||||
Middlewares implement the `tx.Handler` interface. They are called within BaseApp `CheckTx` and `DeliverTx`, allowing to run custom logic before or after the transaction is processed. They are primarily used to authenticate the transaction before the transaction's internal messages are processed, but also to perform additional checks on the transaction itself.
|
||||
|
||||
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-beta2/types/tx/middleware.go#L62:L68
|
||||
|
||||
@@ -346,9 +346,9 @@ The [`EndBlock` ABCI message](https://docs.tendermint.com/master/spec/abci/abci.
|
||||
|
||||
### Commit
|
||||
|
||||
The [`Commit` ABCI message](https://docs.tendermint.com/master/spec/abci/abci.html#commit) is sent from the underlying Tendermint engine after the full-node has received _precommits_ from 2/3+ of validators (weighted by voting power). On the `BaseApp` end, the `Commit(res abci.ResponseCommit)` function is implemented to commit all the valid state transitions that occured during `BeginBlock`, `DeliverTx` and `EndBlock` and to reset state for the next block.
|
||||
The [`Commit` ABCI message](https://docs.tendermint.com/master/spec/abci/abci.html#commit) is sent from the underlying Tendermint engine after the full-node has received _precommits_ from 2/3+ of validators (weighted by voting power). On the `BaseApp` end, the `Commit(res abci.ResponseCommit)` function is implemented to commit all the valid state transitions that occurred during `BeginBlock`, `DeliverTx` and `EndBlock` and to reset state for the next block.
|
||||
|
||||
To commit state-transitions, the `Commit` function calls the `Write()` function on `deliverState.ms`, where `deliverState.ms` is a branched multistore of the main store `app.cms`. Then, the `Commit` function sets `checkState` to the latest header (obtbained from `deliverState.ctx.BlockHeader`) and `deliverState` to `nil`.
|
||||
To commit state-transitions, the `Commit` function calls the `Write()` function on `deliverState.ms`, where `deliverState.ms` is a branched multistore of the main store `app.cms`. Then, the `Commit` function sets `checkState` to the latest header (obtained from `deliverState.ctx.BlockHeader`) and `deliverState` to `nil`.
|
||||
|
||||
Finally, `Commit` returns the hash of the commitment of `app.cms` back to the underlying consensus engine. This hash is used as a reference in the header of the next block.
|
||||
|
||||
@@ -360,7 +360,7 @@ The [`Info` ABCI message](https://docs.tendermint.com/master/spec/abci/abci.html
|
||||
|
||||
The [`Query` ABCI message](https://docs.tendermint.com/master/spec/abci/abci.html#query-2) is used to serve queries received from the underlying consensus engine, including queries received via RPC like Tendermint RPC. It used to be the main entrypoint to build interfaces with the application, but with the introduction of [gRPC queries](../building-modules/query-services.md) in Cosmos SDK v0.40, its usage is more limited. The application must respect a few rules when implementing the `Query` method, which are outlined [here](https://docs.tendermint.com/master/spec/abci/apps.html#query).
|
||||
|
||||
Each Tendermint `query` comes with a `path`, which is a `string` which denotes what to query. If the `path` matches a gRPC fully-qualified service method, then `BaseApp` will defer the query to the `grpcQueryRouter` and let it handle it like explained [above](#grpc-query-router). Otherwise, the `path` represents a query that is not (yet) handled by the gRPC router. `BaseApp` splits the `path` string with the `/` delimiter. By convention, the first element of the splitted string (`splitted[0]`) contains the category of `query` (`app`, `p2p`, `store` or `custom` ). The `BaseApp` implementation of the `Query(req abci.RequestQuery)` method is a simple dispatcher serving these 4 main categories of queries:
|
||||
Each Tendermint `query` comes with a `path`, which is a `string` which denotes what to query. If the `path` matches a gRPC fully-qualified service method, then `BaseApp` will defer the query to the `grpcQueryRouter` and let it handle it like explained [above](#grpc-query-router). Otherwise, the `path` represents a query that is not (yet) handled by the gRPC router. `BaseApp` splits the `path` string with the `/` delimiter. By convention, the first element of the split string (`split[0]`) contains the category of `query` (`app`, `p2p`, `store` or `custom` ). The `BaseApp` implementation of the `Query(req abci.RequestQuery)` method is a simple dispatcher serving these 4 main categories of queries:
|
||||
|
||||
* Application-related queries like querying the application's version, which are served via the `handleQueryApp` method.
|
||||
* Direct queries to the multistore, which are served by the `handlerQueryStore` method. These direct queries are different from custom queries which go through `app.queryRouter`, and are mainly used by third-party service provider like block explorers.
|
||||
|
||||
+3
-3
@@ -4,7 +4,7 @@ order: 9
|
||||
|
||||
# Command-Line Interface
|
||||
|
||||
This document describes how commmand-line interface (CLI) works on a high-level, for an [**application**](../basics/app-anatomy.md). A separate document for implementing a CLI for a Cosmos SDK [**module**](../building-modules/intro.md) can be found [here](../building-modules/module-interfaces.md#cli). {synopsis}
|
||||
This document describes how command-line interface (CLI) works on a high-level, for an [**application**](../basics/app-anatomy.md). A separate document for implementing a CLI for a Cosmos SDK [**module**](../building-modules/intro.md) can be found [here](../building-modules/module-interfaces.md#cli). {synopsis}
|
||||
|
||||
## Command-Line Interface
|
||||
|
||||
@@ -120,13 +120,13 @@ Flags are added to commands directly (generally in the [module's CLI file](../bu
|
||||
|
||||
## Environment variables
|
||||
|
||||
Each flag is bound to it's respecteve named environment variable. Then name of the environment variable consist of two parts - capital case `basename` followed by flag name of the flag. `-` must be substituted with `_`. For example flag `--home` for application with basename `GAIA` is bound to `GAIA_HOME`. It allows to reduce amount of flags typed for routine operations. For example instead of:
|
||||
Each flag is bound to it's respecteve named environment variable. Then name of the environment variable consist of two parts - capital case `basename` followed by flag name of the flag. `-` must be substituted with `_`. For example flag `--home` for application with basename `GAIA` is bound to `GAIA_HOME`. It allows reducing the amount of flags typed for routine operations. For example instead of:
|
||||
|
||||
```sh
|
||||
gaia --home=./ --node=<node address> --chain-id="testchain-1" --keyring-backend=test tx ... --from=<key name>
|
||||
```
|
||||
|
||||
this will be more convinient:
|
||||
this will be more convenient:
|
||||
|
||||
```sh
|
||||
# define env variables in .env, .envrc etc
|
||||
|
||||
@@ -4,7 +4,7 @@ order: 3
|
||||
|
||||
# Context
|
||||
|
||||
The `context` is a data structure intended to be passed from function to function that carries information about the current state of the application. It provides an access to a branched storage (a safe branch of the entire state) as well as useful objects and information like `gasMeter`, `block height`, `consensus parameters` and more. {synopsis}
|
||||
The `context` is a data structure intended to be passed from function to function that carries information about the current state of the application. It provides access to a branched storage (a safe branch of the entire state) as well as useful objects and information like `gasMeter`, `block height`, `consensus parameters` and more. {synopsis}
|
||||
|
||||
## Pre-requisites Readings
|
||||
|
||||
@@ -21,7 +21,7 @@ The Cosmos SDK `Context` is a custom data structure that contains Go's stdlib [`
|
||||
* **Multistore:** Every application's `BaseApp` contains a [`CommitMultiStore`](./store.md#multistore) which is provided when a `Context` is created. Calling the `KVStore()` and `TransientStore()` methods allows modules to fetch their respective [`KVStore`](./store.md#base-layer-kvstores) using their unique `StoreKey`.
|
||||
* **Header:** The [header](https://docs.tendermint.com/master/spec/core/data_structures.html#header) is a Blockchain type. It carries important information about the state of the blockchain, such as block height and proposer of the current block.
|
||||
* **Chain ID:** The unique identification number of the blockchain a block pertains to.
|
||||
* **Transaction Bytes:** The `[]byte` representation of a transaction being processed using the context. Every transaction is processed by various parts of the Cosmos SDK and consensus engine (e.g. Tendermint) throughout its [lifecycle](../basics/tx-lifecycle.md), some of which to not have any understanding of transaction types. Thus, transactions are marshaled into the generic `[]byte` type using some kind of [encoding format](./encoding.md) such as [Amino](./encoding.md).
|
||||
* **Transaction Bytes:** The `[]byte` representation of a transaction being processed using the context. Every transaction is processed by various parts of the Cosmos SDK and consensus engine (e.g. Tendermint) throughout its [lifecycle](../basics/tx-lifecycle.md), some of which do not have any understanding of transaction types. Thus, transactions are marshaled into the generic `[]byte` type using some kind of [encoding format](./encoding.md) such as [Amino](./encoding.md).
|
||||
* **Logger:** A `logger` from the Tendermint libraries. Learn more about logs [here](https://docs.tendermint.com/master/nodes/logging.html). Modules call this method to create their own unique module-specific logger.
|
||||
* **VoteInfo:** A list of the ABCI type [`VoteInfo`](https://docs.tendermint.com/master/spec/abci/abci.html#voteinfo), which includes the name of a validator and a boolean indicating whether they have signed the block.
|
||||
* **Gas Meters:** Specifically, a [`gasMeter`](../basics/gas-fees.md#main-gas-meter) for the transaction currently being processed using the context and a [`blockGasMeter`](../basics/gas-fees.md#block-gas-meter) for the entire block it belongs to. Users specify how much in fees they wish to pay for the execution of their transaction; these gas meters keep track of how much [gas](../basics/gas-fees.md) has been used in the transaction or block so far. If the gas meter runs out, execution halts.
|
||||
|
||||
@@ -30,8 +30,8 @@ tree.
|
||||
For store encoding, protobuf definitions can exist for any type and will typically
|
||||
have an Amino-based "intermediary" type. Specifically, the protobuf-based type
|
||||
definition is used for serialization and persistence, whereas the Amino-based type
|
||||
is used for business logic in the state-machine where they may converted back-n-forth.
|
||||
Note, the Amino-based types may slowly be phased-out in the future so developers
|
||||
is used for business logic in the state-machine where they may convert back-n-forth.
|
||||
Note, the Amino-based types may slowly be phased-out in the future, so developers
|
||||
should take note to use the protobuf message definitions where possible.
|
||||
|
||||
In the `codec` package, there exists two core interfaces, `Marshaler` and `ProtoMarshaler`,
|
||||
@@ -43,7 +43,7 @@ In addition, there exists two implementations of `Marshaler`. The first being
|
||||
second being `ProtoCodec`, where both binary and JSON serialization is handled
|
||||
via Protobuf.
|
||||
|
||||
This means that modules may use Amino or Protobuf encoding but the types must
|
||||
This means that modules may use Amino or Protobuf encoding, but the types must
|
||||
implement `ProtoMarshaler`. If modules wish to avoid implementing this interface
|
||||
for their types, they may use an Amino codec directly.
|
||||
|
||||
|
||||
@@ -32,7 +32,7 @@ replace google.golang.org/grpc => google.golang.org/grpc v1.33.2
|
||||
Please see [issue #8392](https://github.com/cosmos/cosmos-sdk/issues/8392) for more info.
|
||||
:::
|
||||
|
||||
Cosmos SDK v0.40 introduced Protobuf as the main [encoding](./encoding) library, and this brings a wide range of Protobuf-based tools that can be plugged into the Cosmos SDK. One such tool is [gRPC](https://grpc.io), a modern open source high performance RPC framework that has decent client support in several languages.
|
||||
Cosmos SDK v0.40 introduced Protobuf as the main [encoding](./encoding) library, and this brings a wide range of Protobuf-based tools that can be plugged into the Cosmos SDK. One such tool is [gRPC](https://grpc.io), a modern open-source high performance RPC framework that has decent client support in several languages.
|
||||
|
||||
Each module exposes a [Protobuf `Query` service](../building-modules/messages-and-queries.md#queries) that defines state queries. The `Query` services and a transaction service used to broadcast transactions are hooked up to the gRPC server via the following function inside the application:
|
||||
|
||||
@@ -51,7 +51,7 @@ The `grpc.Server` is a concrete gRPC server, which spawns and serves all gRPC qu
|
||||
|
||||
Once the gRPC server is started, you can send requests to it using a gRPC client. Some examples are given in our [Interact with the Node](../run-node/interact-node.md#using-grpc) tutorial.
|
||||
|
||||
An overview of all available gRPC endpoints shipped with the Cosmos SDK is [Protobuf documention](https://buf.build/cosmos/cosmos-sdk).
|
||||
An overview of all available gRPC endpoints shipped with the Cosmos SDK is [Protobuf documentation](https://buf.build/cosmos/cosmos-sdk).
|
||||
|
||||
## REST Server
|
||||
|
||||
|
||||
+2
-2
@@ -55,13 +55,13 @@ In practice, the [constructor of the application](../basics/app-anatomy.md#const
|
||||
|
||||
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/simapp/simd/cmd/root.go#L170-L215
|
||||
|
||||
Then, the instance of `app` is used to instanciate a new Tendermint node:
|
||||
Then, the instance of `app` is used to instantiate a new Tendermint node:
|
||||
|
||||
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/server/start.go#L235-L244
|
||||
|
||||
The Tendermint node can be created with `app` because the latter satisfies the [`abci.Application` interface](https://github.com/tendermint/tendermint/blob/v0.34.0/abci/types/application.go#L7-L32) (given that `app` extends [`baseapp`](./baseapp.md)). As part of the `NewNode` method, Tendermint makes sure that the height of the application (i.e. number of blocks since genesis) is equal to the height of the Tendermint node. The difference between these two heights should always be negative or null. If it is strictly negative, `NewNode` will replay blocks until the height of the application reaches the height of the Tendermint node. Finally, if the height of the application is `0`, the Tendermint node will call [`InitChain`](./baseapp.md#initchain) on the application to initialize the state from the genesis file.
|
||||
|
||||
Once the Tendermint node is instanciated and in sync with the application, the node can be started:
|
||||
Once the Tendermint node is instantiated and in sync with the application, the node can be started:
|
||||
|
||||
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/server/start.go#L250-L252
|
||||
|
||||
|
||||
@@ -76,7 +76,7 @@ check the Cosmos SDK [Makefile](https://github.com/cosmos/cosmos-sdk/blob/v0.40.
|
||||
|
||||
Here are some suggestions when encountering a simulation failure:
|
||||
|
||||
* Export the app state at the height were the failure was found. You can do this
|
||||
* Export the app state at the height where the failure was found. You can do this
|
||||
by passing the `-ExportStatePath` flag to the simulator.
|
||||
* Use `-Verbose` logs. They could give you a better hint on all the operations
|
||||
involved.
|
||||
@@ -84,7 +84,7 @@ Here are some suggestions when encountering a simulation failure:
|
||||
frequently.
|
||||
* Print all the failed invariants at once with `-PrintAllInvariants`.
|
||||
* Try using another `-Seed`. If it can reproduce the same error and if it fails
|
||||
sooner you will spend less time running the simulations.
|
||||
sooner, you will spend less time running the simulations.
|
||||
* Reduce the `-NumBlocks` . How's the app state at the height previous to the
|
||||
failure?
|
||||
* Run invariants on every operation with `-SimulateEveryOperation`. _Note_: this
|
||||
|
||||
+1
-1
@@ -20,7 +20,7 @@ Assuming we have two chains, A and B, we define the following terms:
|
||||
|
||||
## Transaction Tips Flow
|
||||
|
||||
The transaction tips flow happens in multipe steps.
|
||||
The transaction tips flow happens in multiple steps.
|
||||
|
||||
1. The tipper sends via IBC some chain B tokens to chain A. These tokens will cover for fees on the target chain A. This means that chain A's bank module holds some IBC tokens under the tipper's address.
|
||||
|
||||
|
||||
@@ -47,7 +47,7 @@ Once signed by all signers, the `body_bytes`, `auth_info_bytes` and `signatures`
|
||||
|
||||
#### `SIGN_MODE_LEGACY_AMINO_JSON`
|
||||
|
||||
The legacy implemention of the `Tx` interface is the `StdTx` struct from `x/auth`:
|
||||
The legacy implementation of the `Tx` interface is the `StdTx` struct from `x/auth`:
|
||||
|
||||
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/x/auth/legacy/legacytx/stdtx.go#L120-L130
|
||||
|
||||
@@ -63,7 +63,7 @@ The Cosmos SDK also provides a couple of other sign modes for particular use cas
|
||||
|
||||
#### `SIGN_MODE_DIRECT_AUX`
|
||||
|
||||
`SIGN_MODE_DIRECT_AUX` is a sign mode released in the Cosmos SDK v0.46 which targets transactions with multiple signers. Whereas `SIGN_MODE_DIRECT` expects each signer to sign over both `TxBody` and `AuthInfo` (which includes all other signers' signer infos, i.e. their account sequence, public key and mode info), `SIGN_MODE_DIRECT_AUX` allows N-1 signers to only sign over `TxBody` and _their own_ signer info. Morover, each auxiliary signer (i.e. a signer using `SIGN_MODE_DIRECT_AUX`) doesn't
|
||||
`SIGN_MODE_DIRECT_AUX` is a sign mode released in the Cosmos SDK v0.46 which targets transactions with multiple signers. Whereas `SIGN_MODE_DIRECT` expects each signer to sign over both `TxBody` and `AuthInfo` (which includes all other signers' signer infos, i.e. their account sequence, public key and mode info), `SIGN_MODE_DIRECT_AUX` allows N-1 signers to only sign over `TxBody` and _their own_ signer info. Morever, each auxiliary signer (i.e. a signer using `SIGN_MODE_DIRECT_AUX`) doesn't
|
||||
need to sign over the fees:
|
||||
|
||||
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-beta2/proto/cosmos/tx/v1beta1/tx.proto#L67-L93
|
||||
@@ -142,7 +142,7 @@ Once the transaction bytes are generated, there are currently three ways of broa
|
||||
|
||||
#### CLI
|
||||
|
||||
Application developers create entrypoints to the application by creating a [command-line interface](../core/cli.md), [gRPC and/or REST interface](../core/grpc_rest.md), typically found in the application's `./cmd` folder. These interfaces allow users to interact with the application through command-line.
|
||||
Application developers create entry points to the application by creating a [command-line interface](../core/cli.md), [gRPC and/or REST interface](../core/grpc_rest.md), typically found in the application's `./cmd` folder. These interfaces allow users to interact with the application through command-line.
|
||||
|
||||
For the [command-line interface](../building-modules/module-interfaces.md#cli), module developers create subcommands to add as children to the application top-level transaction command `TxCmd`. CLI commands actually bundle all the steps of transaction processing into one simple command: creating messages, generating transactions and broadcasting. For concrete examples, see the [Interacting with a Node](../run-node/interact-node.md) section. An example transaction made using CLI looks like:
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ order: 15
|
||||
# In-Place Store Migrations
|
||||
|
||||
::: warning
|
||||
Read and understand all of the in-place store migration documentation before you run a migration on a live chain.
|
||||
Read and understand all the in-place store migration documentation before you run a migration on a live chain.
|
||||
:::
|
||||
|
||||
Upgrade your app modules smoothly with custom in-place store migration logic. {synopsis}
|
||||
@@ -67,7 +67,7 @@ To learn more about configuring migration scripts for your modules, see the [Mod
|
||||
|
||||
By default, all migrations are run in module name alphabetical ascending order, except `x/auth` which is run last. The reason is state dependencies between x/auth and other modules (you can read more in [issue #10606](https://github.com/cosmos/cosmos-sdk/issues/10606)).
|
||||
|
||||
If you want to change the order of migration then you should call `app.mm.SetOrderMigrations(module1, module2, ...)` in your app.go file. The function will panic if you forget to include a module in the argument list.
|
||||
If you want to change the order of migration, then you should call `app.mm.SetOrderMigrations(module1, module2, ...)` in your app.go file. The function will panic if you forget to include a module in the argument list.
|
||||
|
||||
## Adding New Modules During Upgrades
|
||||
|
||||
@@ -155,6 +155,6 @@ app.UpgradeKeeper.SetUpgradeHandler("my-plan", func(ctx sdk.Context, plan upgrad
|
||||
|
||||
You can sync a full node to an existing blockchain which has been upgraded using Cosmovisor
|
||||
|
||||
In order to successfully sync, you must start with the initial binary that the blockchain started with at genesis. If all Software Upgrade Plans contain binary instruction then you can run Cosmovisor with auto download option to automatically handle downloading and switching to the binaries associated with each sequential upgrade. Otherwise you need to manually provide all binaries to Cosmovisor.
|
||||
To successfully sync, you must start with the initial binary that the blockchain started with at genesis. If all Software Upgrade Plans contain binary instruction, then you can run Cosmovisor with auto-download option to automatically handle downloading and switching to the binaries associated with each sequential upgrade. Otherwise, you need to manually provide all binaries to Cosmovisor.
|
||||
|
||||
To learn more about Cosmovisor, see the [Cosmovisor Quick Start](../run-node/cosmovisor.md).
|
||||
|
||||
Reference in New Issue
Block a user