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

docs: update sdk & tm version links in docs (#12976)

Browse Source 
* docs: update sdk & tm version links in docs

* revert unrelated change
This commit is contained in:
Julien Robert 2022-08-20 08:42:13 +02:00 committed by GitHub
parent dc361be9e3
commit 77a96d5fe1
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
61 changed files with 311 additions and 310 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
docs/architecture/adr-048-consensus-fees.md
View File

@ -2,7 +2,7 @@
## Changelog
- Dec 1, 2021: Initial Draft
* Dec 1, 2021: Initial Draft
## Status
@ -16,15 +16,15 @@ This ADR describes a flexible mechanism to maintain a consensus level gas prices
Currently, each validator configures it's own `minimal-gas-prices` in `app.yaml`. But setting a proper minimal gas price is critical to protect network from dos attack, and it's hard for all the validators to pick a sensible value, so we propose to maintain a gas price in consensus level.
Since tendermint 0.35 has supported mempool prioritization, we can take advantage of that to implement more sophisticated gas fee system.
Since tendermint 0.34.20 has supported mempool prioritization, we can take advantage of that to implement more sophisticated gas fee system.
## Multi-Tier Price System
We propose a multi-tier price system on consensus to provide maximum flexibility:
- Tier 1: a constant gas price, which could only be modified occasionally through governance proposal.
- Tier 2: a dynamic gas price which is adjusted according to previous block load.
- Tier 3: a dynamic gas price which is adjusted according to previous block load at a higher speed.
* Tier 1: a constant gas price, which could only be modified occasionally through governance proposal.
* Tier 2: a dynamic gas price which is adjusted according to previous block load.
* Tier 3: a dynamic gas price which is adjusted according to previous block load at a higher speed.
The gas price of higher tier should bigger than the lower tier.
@ -68,10 +68,11 @@ Transactions are prioritized based on the tier, the higher the tier, the higher
Within the same tier, follow the default Tendermint order (currently FIFO). Be aware of that the mempool tx ordering logic is not part of consensus and can be modified by malicious validator.
This mechanism can be easily composed with prioritization mechanisms:
* we can add extra tiers out of a user control:
* Example 1: user can set tier 0, 10 or 20, but the protocol will create tiers 0, 1, 2 ... 29. For example IBC transactions will go to tier `user_tier + 5`: if user selected tier 1, then the transaction will go to tier 15.
* Example 2: we can reserve tier 4, 5, ... only for special transaction types. For example, tier 5 is reserved for evidence tx. So if submits a bank.Send transaction and set tier 5, it will be delegated to tier 3 (the max tier level available for any transaction).
* Example 3: we can enforce that all transactions of a sepecific type will go to specific tier. For example, tier 100 will be reserved for evidence transactions and all evidence transactions will always go to that tier.
* Example 1: user can set tier 0, 10 or 20, but the protocol will create tiers 0, 1, 2 ... 29. For example IBC transactions will go to tier `user_tier + 5`: if user selected tier 1, then the transaction will go to tier 15.
* Example 2: we can reserve tier 4, 5, ... only for special transaction types. For example, tier 5 is reserved for evidence tx. So if submits a bank.Send transaction and set tier 5, it will be delegated to tier 3 (the max tier level available for any transaction).
* Example 3: we can enforce that all transactions of a sepecific type will go to specific tier. For example, tier 100 will be reserved for evidence transactions and all evidence transactions will always go to that tier.
### `min-gas-prices`
@ -180,24 +181,24 @@ If attacker spam with lower tier transactions, user can mitigate by sending high
### Backwards Compatibility
- New protocol parameters.
- New consensus states.
- New/changed fields in transaction body.
* New protocol parameters.
* New consensus states.
* New/changed fields in transaction body.
### Positive
- The default tier keeps the same predictable gas price experience for client.
- The higher tier's gas price can adapt to block load.
- No priority conflict with custom priority based on transaction types, since this proposal only occupy three priority levels.
- Possibility to compose different priority rules with tiers
* The default tier keeps the same predictable gas price experience for client.
* The higher tier's gas price can adapt to block load.
* No priority conflict with custom priority based on transaction types, since this proposal only occupy three priority levels.
* Possibility to compose different priority rules with tiers
### Negative
- Wallets & tools need to update to support the new `tier` parameter, and semantic of `fee` field is changed.
* Wallets & tools need to update to support the new `tier` parameter, and semantic of `fee` field is changed.
### Neutral
## References
- https://eips.ethereum.org/EIPS/eip-1559
- https://iohk.io/en/blog/posts/2021/11/26/network-traffic-and-tiered-pricing/
* https://eips.ethereum.org/EIPS/eip-1559
* https://iohk.io/en/blog/posts/2021/11/26/network-traffic-and-tiered-pricing/

2
docs/architecture/adr-050-sign-mode-textual-annex1.md
View File

@ -36,7 +36,7 @@ Value Renderers describe how values of different Protobuf types should be encode
### `coin`
- Applies to `cosmos.base.v1beta1.Coin`.
- Denoms are converted to `display` denoms using `Metadata` (if available). **This requires a state query**. The definition of `Metadata` can be found in the [bank Protobuf definition](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/bank/v1beta1/bank.proto#L79-L108). If the `display` field is empty or nil, then we do not perform any denom conversion.
- Denoms are converted to `display` denoms using `Metadata` (if available). **This requires a state query**. The definition of `Metadata` can be found in the [bank Protobuf definition](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/bank/v1beta1/bank.proto#L79-L108). If the `display` field is empty or nil, then we do not perform any denom conversion.
- Amounts are converted to `display` denom amounts and rendered as `number`s above
- We do not change the capitalization of the denom. In practice, `display` denoms are stored in lowercase in state (e.g. `10 atom`), however they are often showed in UPPERCASE in everyday life (e.g. `10 ATOM`). Value renderers keep the case used in state, but we may recommend chains changing the denom metadata to be uppercase for better user display.
- One space between the denom and amount (e.g. `10 atom`).

22
docs/basics/accounts.md
View File

@ -66,9 +66,9 @@ In the node, all data is stored using Protocol Buffers serialization.
The Cosmos SDK supports the following digital key schemes for creating digital signatures:
* `secp256k1`, as implemented in the [Cosmos SDK's `crypto/keys/secp256k1` package](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/crypto/keys/secp256k1/secp256k1.go).
* `secp256r1`, as implemented in the [Cosmos SDK's `crypto/keys/secp256r1` package](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/crypto/keys/secp256r1/pubkey.go),
* `tm-ed25519`, as implemented in the [Cosmos SDK `crypto/keys/ed25519` package](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/crypto/keys/ed25519/ed25519.go). This scheme is supported only for the consensus validation.
* `secp256k1`, as implemented in the [Cosmos SDK's `crypto/keys/secp256k1` package](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/crypto/keys/secp256k1/secp256k1.go).
* `secp256r1`, as implemented in the [Cosmos SDK's `crypto/keys/secp256r1` package](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/crypto/keys/secp256r1/pubkey.go),
* `tm-ed25519`, as implemented in the [Cosmos SDK `crypto/keys/ed25519` package](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/crypto/keys/ed25519/ed25519.go). This scheme is supported only for the consensus validation.
| | Address length in bytes | Public key length in bytes | Used for transaction authentication | Used for consensus (tendermint) |
| :----------: | :---------------------: | :------------------------: | :---------------------------------: | :-----------------------------: |
@ -88,7 +88,7 @@ Each account is identified using `Address` which is a sequence of bytes derived
These types implement the `Address` interface:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/address.go#L108-L125
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/types/address.go#L108-L125
Address construction algorithm is defined in [ADR-28](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-028-public-key-addresses.md).
Here is the standard way to obtain an account address from a `pub` public key:
@ -101,7 +101,7 @@ Of note, the `Marshal()` and `Bytes()` method both return the same raw `[]byte`
For user interaction, addresses are formatted using [Bech32](https://en.bitcoin.it/wiki/Bech32) and implemented by the `String` method. The Bech32 method is the only supported format to use when interacting with a blockchain. The Bech32 human-readable part (Bech32 prefix) is used to denote an address type. Example:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/address.go#L272-L286
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/types/address.go#L272-L286
| | Address Bech32 Prefix |
| ------------------ | --------------------- |
@ -113,7 +113,7 @@ For user interaction, addresses are formatted using [Bech32](https://en.bitcoin.
Public keys in Cosmos SDK are defined by `cryptotypes.PubKey` interface. Since public keys are saved in a store, `cryptotypes.PubKey` extends the `proto.Message` interface:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/crypto/types/types.go#L8-L17
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/crypto/types/types.go#L8-L17
A compressed format is used for `secp256k1` and `secp256r1` serialization.
@ -123,24 +123,24 @@ A compressed format is used for `secp256k1` and `secp256r1` serialization.
This prefix is followed by the `x`-coordinate.
Public Keys are not used to reference accounts (or users) and in general are not used when composing transaction messages (with few exceptions: `MsgCreateValidator`, `Validator` and `Multisig` messages).
For user interactions, `PubKey` is formatted using Protobufs JSON ([ProtoMarshalJSON](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/codec/json.go#L14-L34) function). Example:
For user interactions, `PubKey` is formatted using Protobufs JSON ([ProtoMarshalJSON](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/codec/json.go#L14-L34) function). Example:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/crypto/keyring/output.go#L23-L39
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/crypto/keyring/output.go#L23-L39
## Keyring
A `Keyring` is an object that stores and manages accounts. In the Cosmos SDK, a `Keyring` implementation follows the `Keyring` interface:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/crypto/keyring/keyring.go#L54-L101
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/crypto/keyring/keyring.go#L54-L101
The default implementation of `Keyring` comes from the third-party [`99designs/keyring`](https://github.com/99designs/keyring) library.
A few notes on the `Keyring` methods:
* `Sign(uid string, msg []byte) ([]byte, types.PubKey, error)` strictly deals with the signature of the `msg` bytes. You must prepare and encode the transaction into a canonical `[]byte` form. Because protobuf is not deterministic, it has been decided in [ADR-020](../architecture/adr-020-protobuf-transaction-encoding.md) that the canonical `payload` to sign is the `SignDoc` struct, deterministically encoded using [ADR-027](../architecture/adr-027-deterministic-protobuf-serialization.md). Note that signature verification is not implemented in the Cosmos SDK by default, it is deferred to the [`anteHandler`](../core/baseapp.md#antehandler).
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L48-L65
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/tx/v1beta1/tx.proto#L48-L65
* `NewAccount(uid, mnemonic, bip39Passphrase, hdPath string, algo SignatureAlgo) (*Record, error)` creates a new account based on the [`bip44 path`](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) and persists it on disk. The `PrivKey` is **never stored unencrypted**, instead it is [encrypted with a passphrase](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/crypto/armor.go) before being persisted. In the context of this method, the key type and sequence number refer to the segment of the BIP44 derivation path (for example, `0`, `1`, `2`, ...) that is used to derive a private and a public key from the mnemonic. Using the same mnemonic and derivation path, the same `PrivKey`, `PubKey` and `Address` is generated. The following keys are supported by the keyring:
* `NewAccount(uid, mnemonic, bip39Passphrase, hdPath string, algo SignatureAlgo) (*Record, error)` creates a new account based on the [`bip44 path`](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) and persists it on disk. The `PrivKey` is **never stored unencrypted**, instead it is [encrypted with a passphrase](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/crypto/armor.go) before being persisted. In the context of this method, the key type and sequence number refer to the segment of the BIP44 derivation path (for example, `0`, `1`, `2`, ...) that is used to derive a private and a public key from the mnemonic. Using the same mnemonic and derivation path, the same `PrivKey`, `PubKey` and `Address` is generated. The following keys are supported by the keyring:
* `secp256k1`
* `ed25519`

16
docs/basics/app-anatomy.md
View File

@ -53,13 +53,13 @@ The first thing defined in `app.go` is the `type` of the application. It is gene
See an example of application type definition from `simapp`, the Cosmos SDK's own app used for demo and testing purposes:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/app.go#L151-L193
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/app.go#L151-L193
### Constructor Function
This function constructs a new application of the type defined in the section above. It must fulfill the `AppCreator` signature in order to be used in the [`start` command](../core/node.md#start-command) of the application's daemon command.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/server/types/app.go#L57-L59
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/server/types/app.go#L57-L59
Here are the main actions performed by this function:
@ -81,7 +81,7 @@ Note that this function only creates an instance of the app, while the actual st
See an example of application constructor from `simapp`:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/app.go#L204-L474
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/app.go#L204-L474
### InitChainer
@ -91,7 +91,7 @@ In general, the `InitChainer` is mostly composed of the [`InitGenesis`](../build
See an example of an `InitChainer` from `simapp`:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/app.go#L524-L532
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/app.go#L524-L532
### BeginBlocker and EndBlocker
@ -103,13 +103,13 @@ As a sidenote, it is important to remember that application-specific blockchains
See an example of `BeginBlocker` and `EndBlocker` functions from `simapp`
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/app.go#L514-L522
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/app.go#L514-L522
### Register Codec
The `EncodingConfig` structure is the last important part of the `app.go` file. The goal of this structure is to define the codecs that will be used throughout the app.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/params/encoding.go#L9-L16
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/params/encoding.go#L9-L16
Here are descriptions of what each of the four fields means:
@ -126,7 +126,7 @@ NOTE: This function is deprecated and should only be used to create an app or in
See an example of a `MakeTestEncodingConfig` from `simapp`:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/encoding.go#L8-L19
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/encoding.go#L8-L19
## Modules
@ -155,7 +155,7 @@ For a more details look at a transaction [lifecycle](./tx-lifecycle.md).
Module developers create custom `Msg` services when they build their own module. The general practice is to define the `Msg` Protobuf service in a `tx.proto` file. For example, the `x/bank` module defines a service with two methods to transfer tokens:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/bank/v1beta1/tx.proto#L12-L19
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/bank/v1beta1/tx.proto#L12-L19
Service methods use `keeper` in order to update the module state.

6
docs/basics/gas-fees.md
View File

@ -21,7 +21,7 @@ In the Cosmos SDK, `gas` is a special unit that is used to track the consumption
In the Cosmos SDK, `gas` is a simple alias for `uint64`, and is managed by an object called a _gas meter_. Gas meters implement the `GasMeter` interface
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/store/types/gas.go#L40-L51
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/store/types/gas.go#L40-L51
where:
@ -70,9 +70,9 @@ The `AnteHandler` is run for every transaction during `CheckTx` and `DeliverTx`,
The anteHandler is not implemented in the core Cosmos SDK but in a module. That said, most applications today use the default implementation defined in the [`auth` module](https://github.com/cosmos/cosmos-sdk/tree/main/x/auth). Here is what the `anteHandler` is intended to do in a normal Cosmos SDK application:
* Verify that the transactions are of the correct type. Transaction types are defined in the module that implements the `anteHandler`, and they follow the transaction interface:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/tx_msg.go#L38-L46
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/types/tx_msg.go#L38-L46
This enables developers to play with various types for the transaction of their application. In the default `auth` module, the default transaction type is `Tx`:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L13-L26
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/tx/v1beta1/tx.proto#L13-L26
* Verify signatures for each [`message`](../building-modules/messages-and-queries.md#messages) contained in the transaction. Each `message` should be signed by one or multiple sender(s), and these signatures must be verified in the `anteHandler`.
* During `CheckTx`, verify that the gas prices provided with the transaction is greater than the local `min-gas-prices` (as a reminder, gas-prices can be deducted from the following equation: `fees = gas * gas-prices`). `min-gas-prices` is a parameter local to each full-node and used during `CheckTx` to discard transactions that do not provide a minimum amount of fees. This ensures that the mempool cannot be spammed with garbage transactions.
* Verify that the sender of the transaction has enough funds to cover for the `fees`. When the end-user generates a transaction, they must indicate 2 of the 3 following parameters (the third one being implicit): `fees`, `gas` and `gas-prices`. This signals how much they are willing to pay for nodes to execute their transaction. The provided `gas` value is stored in a parameter called `GasWanted` for later use.

10
docs/basics/query-lifecycle.md
View File

@ -77,7 +77,7 @@ The first thing that is created in the execution of a CLI command is a `client.C
The `client.Context` also contains various functions such as `Query()` which retrieves the RPC Client and makes an ABCI call to relay a query to a full-node.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/client/context.go#L25-L63
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/client/context.go#L25-L63
The `client.Context`'s primary role is to store data used during interactions with the end-user and provide methods to interact with this data - it is used before and after the query is processed by the full-node. Specifically, in handling `MyQuery`, the `client.Context` is utilized to encode the query parameters, retrieve the full-node, and write the output. Prior to being relayed to a full-node, the query needs to be encoded into a `[]byte` form, as full-nodes are application-agnostic and do not understand specific types. The full-node (RPC Client) itself is retrieved using the `client.Context`, which knows which node the user CLI is connected to. The query is relayed to this full-node to be processed. Finally, the `client.Context` contains a `Writer` to write output when the response is returned. These steps are further described in later sections.
@ -91,19 +91,19 @@ In our case (querying an address's delegations), `MyQuery` contains an [address]
Here is what the code looks like for the CLI command:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/client/cli/query.go#L323-L326
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/staking/client/cli/query.go#L323-L326
#### gRPC Query Client Creation
The Cosmos SDK leverages code generated from Protobuf services to make queries. The `staking` module's `MyQuery` service generates a `queryClient`, which the CLI will use to make queries. Here is the relevant code:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/client/cli/query.go#L317-L341
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/staking/client/cli/query.go#L317-L341
Under the hood, the `client.Context` has a `Query()` function used to retrieve the pre-configured node and relay a query to it; the function takes the query fully-qualified service method name as path (in our case: `/cosmos.staking.v1beta1.Query/Delegations`), and arguments as parameters. It first retrieves the RPC Client (called the [**node**](../core/node.md)) configured by the user to relay this query to, and creates the `ABCIQueryOptions` (parameters formatted for the ABCI call). The node is then used to make the ABCI call, `ABCIQueryWithOptions()`.
Here is what the code looks like:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/client/query.go#L80-L114
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/client/query.go#L80-L114
## RPC
@ -129,7 +129,7 @@ Since `Query()` is an ABCI function, `baseapp` returns the response as an [`abci
The application [`codec`](../core/encoding.md) is used to unmarshal the response to a JSON and the `client.Context` prints the output to the command line, applying any configurations such as the output type (text, JSON or YAML).
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/client/context.go#L315-L343
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/client/context.go#L315-L343
And that's a wrap! The result of the query is outputted to the console by the CLI.

4
docs/building-modules/beginblock-endblock.md
View File

@ -28,11 +28,11 @@ It is possible for developers to define the order of execution between the `Begi
See an example implementation of `BeginBlocker` from the `distribution` module:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/distribution/abci.go#L14-L38
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/distribution/abci.go#L14-L38
and an example implementation of `EndBlocker` from the `staking` module:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/abci.go#L22-L27
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/staking/abci.go#L22-L27
## Next {hide}

4
docs/building-modules/errors.md
View File

@ -18,7 +18,7 @@ Registration of errors is handled via the [`errors` package](https://github.com/
Example:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/distribution/types/errors.go#L1-L21
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/distribution/types/errors.go#L1-L21
Each custom module error must provide the codespace, which is typically the module name
(e.g. "distribution") and is unique per module, and a uint32 code. Together, the codespace and code
@ -38,7 +38,7 @@ execution.
Example:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/keeper/keeper.go#L143-L184
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/bank/keeper/keeper.go#L143-L184
Regardless if an error is wrapped or not, the Cosmos SDK's `errors` package provides a function to determine if
an error is of a particular kind via `Is`.

10
docs/building-modules/genesis.md
View File

@ -17,7 +17,7 @@ The subset of the genesis state defined from a given module is generally defined
See an example of `GenesisState` protobuf message definition from the `auth` module:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/auth/v1beta1/genesis.proto
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/auth/v1beta1/genesis.proto
Next we present the main genesis-related methods that need to be implemented by module developers in order for their module to be used in Cosmos SDK applications.
@ -25,13 +25,13 @@ Next we present the main genesis-related methods that need to be implemented by
The `DefaultGenesis()` method is a simple method that calls the constructor function for `GenesisState` with the default value for each parameter. See an example from the `auth` module:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/module.go#L45-L49
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/module.go#L45-L49
### `ValidateGenesis`
The `ValidateGenesis(data GenesisState)` method is called to verify that the provided `genesisState` is correct. It should perform validity checks on each of the parameters listed in `GenesisState`. See an example from the `auth` module:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/types/genesis.go#L61-L74
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/types/genesis.go#L61-L74
## Other Genesis Methods
@ -45,7 +45,7 @@ The [module manager](./module-manager.md#manager) of the application is responsi
See an example of `InitGenesis` from the `auth` module:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/keeper/genesis.go#L8-L27
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/keeper/genesis.go#L8-L27
### `ExportGenesis`
@ -53,7 +53,7 @@ The `ExportGenesis` method is executed whenever an export of the state is made.
See an example of `ExportGenesis` from the `auth` module.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/keeper/genesis.go#L29-L41
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/keeper/genesis.go#L29-L41
## Next {hide}

12
docs/building-modules/invariants.md
View File

@ -14,7 +14,7 @@ An invariant is a property of the application that should always be true. In the
An `Invariant` is a function that checks for a particular invariant within a module. Module `Invariant`s must follow the `Invariant` type:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/invariant.go#L9
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/types/invariant.go#L9
The `string` return value is the invariant message, which can be used when printing logs, and the `bool` return value is the actual result of the invariant check.
@ -51,9 +51,9 @@ func AllInvariants(k Keeper) sdk.Invariant {
Finally, module developers need to implement the `RegisterInvariants` method as part of the [`AppModule` interface](./module-manager.md#appmodule). Indeed, the `RegisterInvariants` method of the module, implemented in the `module/module.go` file, typically only defers the call to a `RegisterInvariants` method implemented in the `keeper/invariants.go` file. The `RegisterInvariants` method registers a route for each `Invariant` function in the [`InvariantRegistry`](#invariant-registry):
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/keeper/invariants.go#L12-L21
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/staking/keeper/invariants.go#L12-L21
For more, see an example of [`Invariant`s implementation from the `staking` module](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/keeper/invariants.go).
For more, see an example of [`Invariant`s implementation from the `staking` module](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/staking/keeper/invariants.go).
## Invariant Registry
@ -61,17 +61,17 @@ The `InvariantRegistry` is a registry where the `Invariant`s of all the modules
At its core, the `InvariantRegistry` is defined in the Cosmos SDK as an interface:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/invariant.go#L14-L17
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/types/invariant.go#L14-L17
Typically, this interface is implemented in the `keeper` of a specific module. The most used implementation of an `InvariantRegistry` can be found in the `crisis` module:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/crisis/keeper/keeper.go#L49-L53
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/crisis/keeper/keeper.go#L49-L53
The `InvariantRegistry` is therefore typically instantiated by instantiating the `keeper` of the `crisis` module in the [application's constructor function](../basics/app-anatomy.md#constructor-function).
`Invariant`s can be checked manually via [`message`s](./messages-and-queries.md), but most often they are checked automatically at the end of each block. Here is an example from the `crisis` module:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/crisis/abci.go#L12-L21
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/crisis/abci.go#L12-L21
In both cases, if one of the `Invariant`s returns false, the `InvariantRegistry` can trigger special logic (e.g. have the application panic and print the `Invariant`s message in the log).

6
docs/building-modules/keeper.md
View File

@ -36,7 +36,7 @@ type Keeper struct {
For example, here is the type definition of the `keeper` from the `staking` module:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/keeper/keeper.go#L21-L29
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/staking/keeper/keeper.go#L21-L29
Let us go through the different parameters:
@ -74,13 +74,13 @@ and the method will go through the following steps:
2. Marshal `value` to `[]byte` using the codec `cdc`.
3. Set the encoded value in the store at location `key` using the `Set(key []byte, value []byte)` method of the store.
For more, see an example of `keeper`'s [methods implementation from the `staking` module](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/keeper/keeper.go).
For more, see an example of `keeper`'s [methods implementation from the `staking` module](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/staking/keeper/keeper.go).
The [module `KVStore`](../core/store.md#kvstore-and-commitkvstore-interfaces) also provides an `Iterator()` method which returns an `Iterator` object to iterate over a domain of keys.
This is an example from the `auth` module to iterate accounts:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/keeper/account.go#L76-L90
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/keeper/account.go#L76-L90
## Next {hide}

12
docs/building-modules/messages-and-queries.md
View File

@ -22,7 +22,7 @@ Defining Protobuf `Msg` services is the recommended way to handle messages. A Pr
See an example of a `Msg` service definition from `x/bank` module:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/bank/v1beta1/tx.proto#L12-L19
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/bank/v1beta1/tx.proto#L12-L19
Each `Msg` service method must have exactly one argument, which must implement the `sdk.Msg` interface, and a Protobuf response. The naming convention is to call the RPC argument `Msg<service-rpc-name>` and the RPC response `Msg<service-rpc-name>Response`. For example:
@ -49,7 +49,7 @@ Amino `LegacyMsg`s can be defined as protobuf messages. The messages definition
A `LegacyMsg` is typically accompanied by a standard constructor function, that is called from one of the [module's interface](./module-interfaces.md). `message`s also need to implement the `sdk.Msg` interface:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/tx_msg.go#L10-L22
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/types/tx_msg.go#L10-L22
It extends `proto.Message` and contains the following methods:
@ -59,11 +59,11 @@ It extends `proto.Message` and contains the following methods:
* `GetSignBytes() []byte`: Return the canonical byte representation of the message. Used to generate a signature.
* `GetSigners() []AccAddress`: Return the list of signers. The Cosmos SDK will make sure that each `message` contained in a transaction is signed by all the signers listed in the list returned by this method.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/migrations/legacytx/stdsign.go#L20-L36
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/migrations/legacytx/stdsign.go#L20-L36
See an example implementation of a `message` from the `gov` module:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/gov/types/v1/msgs.go#L106-L138
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/gov/types/v1/msgs.go#L106-L138
## Queries
@ -75,7 +75,7 @@ Queries should be defined using [Protobuf services](https://developers.google.co
Here's an example of such a `Query` service definition:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/auth/v1beta1/query.proto#L13-L59
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/auth/v1beta1/query.proto#L13-L59
As `proto.Message`s, generated `Response` types implement by default `String()` method of [`fmt.Stringer`](https://pkg.go.dev/fmt#Stringer).
@ -108,7 +108,7 @@ Store queries query directly for store keys. They use `clientCtx.QueryABCI(req a
See following examples:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/baseapp/abci.go#L756-L777
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/baseapp/abci.go#L756-L777
## Next {hide}

20
docs/building-modules/module-interfaces.md
View File

@ -22,7 +22,7 @@ Transaction commands typically have their own `tx.go` file that lives within the
Here is an example from the `x/bank` module:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/client/cli/tx.go#L35-L71
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/bank/client/cli/tx.go#L35-L71
In the example, `NewSendTxCmd()` creates and returns the transaction command for a transaction that wraps and delivers `MsgSend`. `MsgSend` is the message used to send tokens from one account to another.
@ -42,17 +42,17 @@ In general, the getter function does the following:
Each module must implement `NewTxCmd()`, which aggregates all of the transaction commands of the module. Here is an example from the `x/bank` module:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/client/cli/tx.go#L17-L33
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/bank/client/cli/tx.go#L17-L33
Each module must also implement the `GetTxCmd()` method for `AppModuleBasic` that simply returns `NewTxCmd()`. This allows the root command to easily aggregate all of the transaction commands for each module. Here is an example:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/module.go#L70-L73
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/bank/module.go#L70-L73
### Query Commands
[Queries](./messages-and-queries.md#queries) allow users to gather information about the application or network state; they are routed by the application and processed by the module in which they are defined. Query commands typically have their own `query.go` file in the module's `./client/cli` folder. Like transaction commands, they are specified in getter functions. Here is an example of a query command from the `x/auth` module:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/client/cli/query.go#L83-L125
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/client/cli/query.go#L83-L125
In the example, `GetAccountCmd()` creates and returns a query command that returns the state of an account based on the provided account address.
@ -72,11 +72,11 @@ In general, the getter function does the following:
Each module must implement `GetQueryCmd()`, which aggregates all of the query commands of the module. Here is an example from the `x/auth` module:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/client/cli/query.go#L25-L42
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/client/cli/query.go#L25-L42
Each module must also implement the `GetQueryCmd()` method for `AppModuleBasic` that returns the `GetQueryCmd()` function. This allows for the root command to easily aggregate all of the query commands for each module. Here is an example:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/client/cli/query.go#L32-L50
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/client/cli/query.go#L32-L50
### Flags
@ -102,13 +102,13 @@ For more detailed information on creating flags, visit the [Cobra Documentation]
As mentioned in [transaction commands](#transaction-commands), there is a set of flags that all transaction commands must add. This is done with the `AddTxFlagsToCmd` method defined in the Cosmos SDK's `./client/flags` package.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/client/flags/flags.go#L103-L131
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/client/flags/flags.go#L103-L131
Since `AddTxFlagsToCmd(cmd *cobra.Command)` includes all of the basic flags required for a transaction command, module developers may choose not to add any of their own (specifying arguments instead may often be more appropriate).
Similarly, there is a `AddQueryFlagsToCmd(cmd *cobra.Command)` to add common flags to a module query command.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/client/flags/flags.go#L92-L101
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/client/flags/flags.go#L92-L101
## gRPC
@ -120,7 +120,7 @@ In order to do that, modules must implement `RegisterGRPCGatewayRoutes(clientCtx
Here's an example from the `x/auth` module:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/module.go#L61-L66
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/module.go#L61-L66
## gRPC-gateway REST
@ -128,7 +128,7 @@ Applications need to support web services that use HTTP requests (e.g. a web wal
Modules that want to expose REST queries should add `google.api.http` annotations to their `rpc` methods, such as in the example below from the `x/auth` module:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/auth/v1beta1/query.proto#L13-L59
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/auth/v1beta1/query.proto#L13-L59
gRPC gateway is started in-process along with the application and Tendermint. It can be enabled or disabled by setting gRPC Configuration `enable` in [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml).

12
docs/building-modules/module-manager.md
View File

@ -29,7 +29,7 @@ are only used for genesis can take advantage of the `Module` patterns without ha
The `AppModuleBasic` interface defines the independent methods modules need to implement.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/module/module.go#L47-L60
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/types/module/module.go#L47-L60
Let us go through the methods:
@ -48,7 +48,7 @@ All the `AppModuleBasic` of an application are managed by the [`BasicManager`](#
The `AppModuleGenesis` interface is a simple embedding of the `AppModuleBasic` interface with two added methods.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/module/module.go#L140-L146
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/types/module/module.go#L140-L146
Let us go through the two added methods:
@ -61,7 +61,7 @@ It does not have its own manager, and exists separately from [`AppModule`](#appm
The `AppModule` interface defines the inter-dependent methods that modules need to implement.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/module/module.go#L148-L176
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/types/module/module.go#L148-L176
`AppModule`s are managed by the [module manager](#manager). This interface embeds the `AppModuleGenesis` interface so that the manager can access all the independent and genesis inter-dependent methods of the module. This means that a concrete type implementing the `AppModule` interface must either implement all the methods of `AppModuleGenesis` (and by extension `AppModuleBasic`), or include a concrete type that does as parameter.
@ -105,7 +105,7 @@ Module managers are used to manage collections of `AppModuleBasic` and `AppModul
The `BasicManager` is a structure that lists all the `AppModuleBasic` of an application:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/module/module.go#L62-L72
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/types/module/module.go#L62-L72
It implements the following methods:
@ -122,7 +122,7 @@ It implements the following methods:
The `Manager` is a structure that holds all the `AppModule` of an application, and defines the order of execution between several key components of these modules:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/module/module.go#L216-L225
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/types/module/module.go#L216-L225
The module manager is used throughout the application whenever an action on a collection of modules is required. It implements the following methods:
@ -144,7 +144,7 @@ The module manager is used throughout the application whenever an action on a co
Here's an example of a concrete integration within an application:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/app.go#L342-L409
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/app.go#L342-L409
## Next {hide}

12
docs/building-modules/msg-services.md
View File

@ -19,15 +19,15 @@ As further described in [ADR 031](../architecture/adr-031-msg-service.md), this
Protobuf generates a `MsgServer` interface based on a definition of `Msg` service. It is the role of the module developer to implement this interface, by implementing the state transition logic that should happen upon receival of each `sdk.Msg`. As an example, here is the generated `MsgServer` interface for `x/bank`, which exposes two `sdk.Msg`s:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/types/tx.pb.go#L288-L294
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/bank/types/tx.pb.go#L288-L294
When possible, the existing module's [`Keeper`](keeper.md) should implement `MsgServer`, otherwise a `msgServer` struct that embeds the `Keeper` can be created, typically in `./keeper/msg_server.go`:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/keeper/msg_server.go#L14-L16
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/bank/keeper/msg_server.go#L14-L16
`msgServer` methods can retrieve the `sdk.Context` from the `context.Context` parameter method using the `sdk.UnwrapSDKContext`:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/keeper/msg_server.go#L27-L27
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/bank/keeper/msg_server.go#L27-L27
`sdk.Msg` processing usually follows these 3 steps:
@ -77,11 +77,11 @@ These events are relayed back to the underlying consensus engine and can be used
The invoked `msgServer` method returns a `proto.Message` response and an `error`. These return values are then wrapped into an `*sdk.Result` or an `error` using `sdk.WrapServiceResult(ctx sdk.Context, res proto.Message, err error)`:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/baseapp/msg_service_router.go#L127
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/baseapp/msg_service_router.go#L127
This method takes care of marshaling the `res` parameter to protobuf and attaching any events on the `ctx.EventManager()` to the `sdk.Result`.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/base/abci/v1beta1/abci.proto#L88-L109
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/base/abci/v1beta1/abci.proto#L88-L109
This diagram shows a typical structure of a Protobuf `Msg` service, and how the message propagates through the module.
@ -93,7 +93,7 @@ New [telemetry metrics](../core/telemetry.md) can be created from `msgServer` me
This is an example from the `x/auth/vesting` module:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/vesting/msg_server.go#L73-L85
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/vesting/msg_server.go#L73-L85
## Next {hide}

6
docs/building-modules/query-services.md
View File

@ -15,7 +15,7 @@ A Protobuf Query service processes [`queries`](./messages-and-queries.md#queries
The `querier` type defined in the Cosmos SDK will be deprecated in favor of [gRPC Services](#grpc-service). It specifies the typical structure of a `querier` function:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/queryable.go#L9
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/types/queryable.go#L9
Let us break it down:
@ -43,7 +43,7 @@ from the store. Therefore, the Cosmos SDK provides a function `sdk.UnwrapSDKCont
Here's an example implementation for the bank module:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/keeper/grpc_query.go
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/bank/keeper/grpc_query.go
### Legacy Queriers
@ -70,7 +70,7 @@ This simple switch returns a `querier` function specific to the type of the rece
The `querier` functions themselves are pretty straightforward. They generally fetch a value or values from the state using the [`keeper`](./keeper.md). Then, they marshall the value(s) using the [`codec`](../core/encoding.md) and return the `[]byte` obtained as result.
For a deeper look at `querier`s, see this [example implementation of a `querier` function](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/gov/keeper/querier.go) from the bank module.
For a deeper look at `querier`s, see this [example implementation of a `querier` function](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/gov/keeper/querier.go) from the bank module.
## Next {hide}

10
docs/building-modules/simulator.md
View File

@ -32,7 +32,7 @@ for the key-value pairs from the stores to be decoded (_i.e_ unmarshalled)
to their corresponding types. In particular, it matches the key to a concrete type
and then unmarshals the value from the `KVPair` to the type provided.
You can use the example [here](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/distribution/simulation/decoder.go) from the distribution module to implement your store decoders.
You can use the example [here](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/distribution/simulation/decoder.go) from the distribution module to implement your store decoders.
### Randomized genesis
@ -43,13 +43,13 @@ Once the module genesis parameter are generated randomly (or with the key and
values defined in a `params` file), they are marshaled to JSON format and added
to the app genesis JSON to use it on the simulations.
You can check an example on how to create the randomized genesis [here](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/simulation/genesis.go).
You can check an example on how to create the randomized genesis [here](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/staking/simulation/genesis.go).
### Randomized parameter changes
The simulator is able to test parameter changes at random. The simulator package from each module must contain a `RandomizedParams` func that will simulate parameter changes of the module throughout the simulations lifespan.
You can see how an example of what is needed to fully test parameter changes [here](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/simulation/params.go)
You can see how an example of what is needed to fully test parameter changes [here](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/staking/simulation/params.go)
### Random weighted operations
@ -62,7 +62,7 @@ Operations on the simulation are simulated using the full [transaction cycle](..
Shown below is how weights are set:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/simulation/operations.go#L17-L75
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/staking/simulation/operations.go#L17-L75
As you can see, the weights are predefined in this case. Options exist to override this behavior with different weights. One option is to use `*rand.Rand` to define a random weight for the operation, or you can inject your own predefined weights.
@ -82,7 +82,7 @@ them to be used on the parameters.
Now that all the required functions are defined, we need to integrate them into the module pattern within the `module.go`:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/distribution/module.go
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/distribution/module.go
## App Simulator manager

4
docs/building-modules/upgrade.md
View File

@ -41,7 +41,7 @@ func (am AppModule) RegisterServices(cfg module.Configurator) {
Since these migrations are functions that need access to a Keeper's store, use a wrapper around the keepers called `Migrator` as shown in this example:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/keeper/migrations.go#L9-L27
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/bank/keeper/migrations.go#L9-L27
## Writing Migration Scripts
@ -54,4 +54,4 @@ func (m Migrator) Migrate1to2(ctx sdk.Context) error {
}
```
To see example code of changes that were implemented in a migration of balance keys, check out [migrateBalanceKeys](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/migrations/v2/store.go#L50-L71). For context, this code introduced migrations of the bank store that updated addresses to be prefixed by their length in bytes as outlined in [ADR-028](../architecture/adr-028-public-key-addresses.md).
To see example code of changes that were implemented in a migration of balance keys, check out [migrateBalanceKeys](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/bank/migrations/v2/store.go#L50-L71). For context, this code introduced migrations of the bank store that updated addresses to be prefixed by their length in bytes as outlined in [ADR-028](../architecture/adr-028-public-key-addresses.md).

20
docs/core/baseapp.md
View File

@ -45,7 +45,7 @@ management logic.
The `BaseApp` type holds many important parameters for any Cosmos SDK based application.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/baseapp/baseapp.go#L45-L137
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/baseapp/baseapp.go#L45-L137
Let us go through the most important components.
@ -111,7 +111,7 @@ func NewBaseApp(
```
The `BaseApp` constructor function is pretty straightforward. The only thing worth noting is the
possibility to provide additional [`options`](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/baseapp/options.go)
possibility to provide additional [`options`](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/baseapp/options.go)
to the `BaseApp`, which will execute them in order. The `options` are generally `setter` functions
for important parameters, like `SetPruning()` to set pruning options or `SetMinGasPrices()` to set
the node's `min-gas-prices`.
@ -192,7 +192,7 @@ When messages and queries are received by the application, they must be routed t
[`sdk.Msg`s](#../building-modules/messages-and-queries.md#messages) need to be routed after they are extracted from transactions, which are sent from the underlying Tendermint engine via the [`CheckTx`](#checktx) and [`DeliverTx`](#delivertx) ABCI messages. To do so, `BaseApp` holds a `msgServiceRouter` which maps fully-qualified service methods (`string`, defined in each module's Protobuf `Msg` service) to the appropriate module's `MsgServer` implementation.
The [default `msgServiceRouter` included in `BaseApp`](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/baseapp/msg_service_router.go) is stateless. However, some applications may want to make use of more stateful routing mechanisms such as allowing governance to disable certain routes or point them to new modules for upgrade purposes. For this reason, the `sdk.Context` is also passed into each [route handler inside `msgServiceRouter`](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/baseapp/msg_service_router.go#L31-L32). For a stateless router that doesn't want to make use of this, you can just ignore the `ctx`.
The [default `msgServiceRouter` included in `BaseApp`](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/baseapp/msg_service_router.go) is stateless. However, some applications may want to make use of more stateful routing mechanisms such as allowing governance to disable certain routes or point them to new modules for upgrade purposes. For this reason, the `sdk.Context` is also passed into each [route handler inside `msgServiceRouter`](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/baseapp/msg_service_router.go#L31-L32). For a stateless router that doesn't want to make use of this, you can just ignore the `ctx`.
The application's `msgServiceRouter` is initialized with all the routes using the application's [module manager](../building-modules/module-manager.md#manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](../basics/app-anatomy.md#constructor-function).
@ -262,7 +262,7 @@ The response contains:
* `Info (string):` Additional information. May be non-deterministic.
* `GasWanted (int64)`: Amount of gas requested for transaction. It is provided by users when they generate the transaction.
* `GasUsed (int64)`: Amount of gas consumed by transaction. During `CheckTx`, this value is computed by multiplying the standard cost of a transaction byte by the size of the raw transaction. Next is an example:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/ante/basic.go#L95-L95
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/ante/basic.go#L95-L95
* `Events ([]cmn.KVPair)`: Key-Value tags for filtering and indexing transactions (eg. by account). See [`event`s](./events.md) for more.
* `Codespace (string)`: Namespace for the Code.
@ -288,7 +288,7 @@ Before the first transaction of a given block is processed, a [volatile state](#
During the additional fifth step outlined in (2), each read/write to the store increases the value of `GasConsumed`. You can find the default cost of each operation:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/store/types/gas.go#L230-L241
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/store/types/gas.go#L230-L241
At any point, if `GasConsumed > GasWanted`, the function returns with `Code != 0` and `DeliverTx` fails.
@ -315,7 +315,7 @@ After that, `RunTx()` calls `ValidateBasic()` on each `sdk.Msg`in the `Tx`, whic
Then, the [`anteHandler`](#antehandler) of the application is run (if it exists). In preparation of this step, both the `checkState`/`deliverState`'s `context` and `context`'s `CacheMultiStore` are branched using the `cacheTxContext()` function.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/baseapp/baseapp.go#L647-L654
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/baseapp/baseapp.go#L647-L654
This allows `RunTx` not to commit the changes made to the state during the execution of `anteHandler` if it ends up failing. It also prevents the module implementing the `anteHandler` from writing to state, which is an important part of the [object-capabilities](./ocap.md) of the Cosmos SDK.
@ -325,7 +325,7 @@ Finally, the [`RunMsgs()`](#runmsgs) function is called to process the `sdk.Msg`
The `AnteHandler` is a special handler that implements the `AnteHandler` interface and is used to authenticate the transaction before the transaction's internal messages are processed.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/handler.go#L6-L8
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/types/handler.go#L6-L8
The `AnteHandler` is theoretically optional, but still a very important component of public blockchain networks. It serves 3 primary purposes:
@ -333,7 +333,7 @@ The `AnteHandler` is theoretically optional, but still a very important componen
* Perform preliminary _stateful_ validity checks like ensuring signatures are valid or that the sender has enough funds to pay for fees.
* Play a role in the incentivisation of stakeholders via the collection of transaction fees.
`BaseApp` holds an `anteHandler` as parameter that is initialized in the [application's constructor](../basics/app-anatomy.md#application-constructor). The most widely used `anteHandler` is the [`auth` module](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/ante/ante.go).
`BaseApp` holds an `anteHandler` as parameter that is initialized in the [application's constructor](../basics/app-anatomy.md#application-constructor). The most widely used `anteHandler` is the [`auth` module](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/ante/ante.go).
Click [here](../basics/gas-fees.md#antehandler) for more on the `anteHandler`.
@ -350,7 +350,7 @@ _PostHandler_ are like `AnteHandler` (they share the same signature), but they e
Like `AnteHandler`s, `PostHandler`s are theoretically optional, one use case for `PostHandler`s is transaction tips (enabled by default in simapp).
Other use cases like unused gas refund can also be enabled by `PostHandler`s.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/posthandler/post.go#L14:L27
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/posthandler/post.go#L14:L27
Note, when `PostHandler`s fail, the state from `runMsgs` is also reverted, effectively making the transaction fail.
@ -371,7 +371,7 @@ Finally, the `InitChain(req abci.RequestInitChain)` method of `BaseApp` calls th
The [`BeginBlock` ABCI message](https://docs.tendermint.com/master/spec/abci/abci.html#beginblock) is sent from the underlying Tendermint engine when a block proposal created by the correct proposer is received, before [`DeliverTx`](#delivertx) is run for each transaction in the block. It allows developers to have logic be executed at the beginning of each block. In the Cosmos SDK, the `BeginBlock(req abci.RequestBeginBlock)` method does the following:
* Initialize [`deliverState`](#state-updates) with the latest header using the `req abci.RequestBeginBlock` passed as parameter via the `setDeliverState` function.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/baseapp/baseapp.go#L386-L396
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/baseapp/baseapp.go#L386-L396
This function also resets the [main gas meter](../basics/gas-fees.md#main-gas-meter).
* Initialize the [block gas meter](../basics/gas-fees.md#block-gas-meter) with the `maxGas` limit. The `gas` consumed within the block cannot go above `maxGas`. This parameter is defined in the application's consensus parameters.
* Run the application's [`beginBlocker()`](../basics/app-anatomy.md#beginblocker-and-endblock), which mainly runs the [`BeginBlocker()`](../building-modules/beginblock-endblock.md#beginblock) method of each of the application's modules.

26
docs/core/cli.md
View File

@ -40,7 +40,7 @@ The `main.go` file needs to have a `main()` function that creates a root command
The `main()` function finally creates an executor and [execute](https://pkg.go.dev/github.com/spf13/cobra#Command.Execute) the root command. See an example of `main()` function from the `simapp` application:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/simd/main.go#L12-L24
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/simd/main.go#L12-L24
The rest of the document will detail what needs to be implemented for each step and include smaller portions of code from the `simapp` CLI files.
@ -53,24 +53,24 @@ Every application CLI first constructs a root command, then adds functionality b
The root command (called `rootCmd`) is what the user first types into the command line to indicate which application they wish to interact with. The string used to invoke the command (the "Use" field) is typically the name of the application suffixed with `-d`, e.g. `simd` or `gaiad`. The root command typically includes the following commands to support basic functionality in the application.
* **Status** command from the Cosmos SDK rpc client tools, which prints information about the status of the connected [`Node`](../core/node.md). The Status of a node includes `NodeInfo`,`SyncInfo` and `ValidatorInfo`.
* **Keys** [commands](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/client/keys) from the Cosmos SDK client tools, which includes a collection of subcommands for using the key functions in the Cosmos SDK crypto tools, including adding a new key and saving it to the keyring, listing all public keys stored in the keyring, and deleting a key. For example, users can type `simd keys add <name>` to add a new key and save an encrypted copy to the keyring, using the flag `--recover` to recover a private key from a seed phrase or the flag `--multisig` to group multiple keys together to create a multisig key. For full details on the `add` key command, see the code [here](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/client/keys/add.go). For more details about usage of `--keyring-backend` for storage of key credentials look at the [keyring docs](../run-node/keyring.md).
* **Server** commands from the Cosmos SDK server package. These commands are responsible for providing the mechanisms necessary to start an ABCI Tendermint application and provides the CLI framework (based on [cobra](github.com/spf13/cobra)) necessary to fully bootstrap an application. The package exposes two core functions: `StartCmd` and `ExportCmd` which creates commands to start the application and export state respectively. Click [here](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/server) to learn more.
* **Keys** [commands](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/client/keys) from the Cosmos SDK client tools, which includes a collection of subcommands for using the key functions in the Cosmos SDK crypto tools, including adding a new key and saving it to the keyring, listing all public keys stored in the keyring, and deleting a key. For example, users can type `simd keys add <name>` to add a new key and save an encrypted copy to the keyring, using the flag `--recover` to recover a private key from a seed phrase or the flag `--multisig` to group multiple keys together to create a multisig key. For full details on the `add` key command, see the code [here](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/client/keys/add.go). For more details about usage of `--keyring-backend` for storage of key credentials look at the [keyring docs](../run-node/keyring.md).
* **Server** commands from the Cosmos SDK server package. These commands are responsible for providing the mechanisms necessary to start an ABCI Tendermint application and provides the CLI framework (based on [cobra](github.com/spf13/cobra)) necessary to fully bootstrap an application. The package exposes two core functions: `StartCmd` and `ExportCmd` which creates commands to start the application and export state respectively. Click [here](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/server) to learn more.
* [**Transaction**](#transaction-commands) commands.
* [**Query**](#query-commands) commands.
Next is an example `rootCmd` function from the `simapp` application. It instantiates the root command, adds a [_persistent_ flag](#flags) and `PreRun` function to be run before every execution, and adds all of the necessary subcommands.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/simd/cmd/root.go#L39-L85
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/simd/cmd/root.go#L39-L85
`rootCmd` has a function called `initAppConfig()` which is useful for setting the application's custom configs.
By default app uses Tendermint app config template from Cosmos SDK, which can be over-written via `initAppConfig()`.
Here's an example code to override default `app.toml` template.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/simd/cmd/root.go#L99-L153
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/simd/cmd/root.go#L99-L153
The `initAppConfig()` also allows overriding the default Cosmos SDK's [server config](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/server/config/config.go#L235). One example is the `min-gas-prices` config, which defines the minimum gas prices a validator is willing to accept for processing a transaction. By default, the Cosmos SDK sets this parameter to `""` (empty string), which forces all validators to tweak their own `app.toml` and set a non-empty value, or else the node will halt on startup. This might not be the best UX for validators, so the chain developer can set a default `app.toml` value for validators inside this `initAppConfig()` function.
The `initAppConfig()` also allows overriding the default Cosmos SDK's [server config](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/server/config/config.go#L235). One example is the `min-gas-prices` config, which defines the minimum gas prices a validator is willing to accept for processing a transaction. By default, the Cosmos SDK sets this parameter to `""` (empty string), which forces all validators to tweak their own `app.toml` and set a non-empty value, or else the node will halt on startup. This might not be the best UX for validators, so the chain developer can set a default `app.toml` value for validators inside this `initAppConfig()` function.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/simd/cmd/root.go#L119-L134
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/simd/cmd/root.go#L119-L134
The root-level `status` and `keys` subcommands are common across most applications and do not interact with application state. The bulk of an application's functionality - what users can actually _do_ with it - is enabled by its `tx` and `query` commands.
@ -78,7 +78,7 @@ The root-level `status` and `keys` subcommands are common across most applicatio
[Transactions](./transactions.md) are objects wrapping [`Msg`s](../building-modules/messages-and-queries.md#messages) that trigger state changes. To enable the creation of transactions using the CLI interface, a function `txCommand` is generally added to the `rootCmd`:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/simd/cmd/root.go#L175-L181
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/simd/cmd/root.go#L175-L181
This `txCommand` function adds all the transaction available to end-users for the application. This typically includes:
@ -88,13 +88,13 @@ This `txCommand` function adds all the transaction available to end-users for th
Here is an example of a `txCommand` aggregating these subcommands from the `simapp` application:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/simd/cmd/root.go#L215-L240
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/simd/cmd/root.go#L215-L240
### Query Commands
[**Queries**](../building-modules/messages-and-queries.md#queries) are objects that allow users to retrieve information about the application's state. To enable the creation of queries using the CLI interface, a function `queryCommand` is generally added to the `rootCmd`:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/simd/cmd/root.go#L175-L181
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/simd/cmd/root.go#L175-L181
This `queryCommand` function adds all the queries available to end-users for the application. This typically includes:
@ -106,7 +106,7 @@ This `queryCommand` function adds all the queries available to end-users for the
Here is an example of a `queryCommand` aggregating subcommands from the `simapp` application:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/simd/cmd/root.go#L191-L213
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/simd/cmd/root.go#L191-L213
## Flags
@ -116,7 +116,7 @@ A _persistent_ flag (as opposed to a _local_ flag) added to a command transcends
Flags are added to commands directly (generally in the [module's CLI file](../building-modules/module-interfaces.md#flags) where module commands are defined) and no flag except for the `rootCmd` persistent flags has to be added at application level. It is common to add a _persistent_ flag for `--chain-id`, the unique identifier of the blockchain the application pertains to, to the root command. Adding this flag can be done in the `main()` function. Adding this flag makes sense as the chain ID should not be changing across commands in this application CLI. Here is an example from the `simapp` application:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/simd/cmd/root.go#L210-L210
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/simd/cmd/root.go#L210-L210
## Environment variables
@ -145,7 +145,7 @@ It is vital that the root command of an application uses `PersistentPreRun()` co
Here is an example of an `PersistentPreRun()` function from `simapp`:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/simd/cmd/root.go#L56-L79
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/simd/cmd/root.go#L56-L79
The `SetCmdClientContextHandler` call reads persistent flags via `ReadPersistentCommandFlags` which creates a `client.Context` and sets that on the root command's `Context`.

2
docs/core/context.md
View File

@ -15,7 +15,7 @@ The `context` is a data structure intended to be passed from function to functio
The Cosmos SDK `Context` is a custom data structure that contains Go's stdlib [`context`](https://pkg.go.dev/context) as its base, and has many additional types within its definition that are specific to the Cosmos SDK. The `Context` is integral to transaction processing in that it allows modules to easily access their respective [store](./store.md#base-layer-kvstores) in the [`multistore`](./store.md#multistore) and retrieve transactional context such as the block header and gas meter.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/context.go#L17-L42
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/types/context.go#L17-L42
* **Base Context:** The base type is a Go [Context](https://pkg.go.dev/context), which is explained further in the [Go Context Package](#go-context-package) section below.
* **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`.

16
docs/core/encoding.md
View File

@ -109,13 +109,13 @@ the consensus engine accepts only transactions in the form of raw bytes.
* The `TxEncoder` object performs the encoding.
* The `TxDecoder` object performs the decoding.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/tx_msg.go#L72-L76
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/types/tx_msg.go#L72-L76
A standard implementation of both these objects can be found in the [`auth` module](../../x/auth/spec/README.md):
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/tx/decoder.go
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/tx/decoder.go
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/tx/encoder.go
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/tx/encoder.go
See [ADR-020](../architecture/adr-020-protobuf-transaction-encoding.md) for details of how a transaction is encoded.
@ -134,7 +134,7 @@ message Profile {
In this `Profile` example, we hardcoded `account` as a `BaseAccount`. However, there are several other types of [user accounts related to vesting](../../x/auth/spec/05_vesting.md), such as `BaseVestingAccount` or `ContinuousVestingAccount`. All of these accounts are different, but they all implement the `AccountI` interface. How would you create a `Profile` that allows all these types of accounts with an `account` field that accepts an `AccountI` interface?
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/types/account.go#L301-L324
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/types/account.go#L301-L324
In [ADR-019](../architecture/adr-019-protobuf-state-encoding.md), it has been decided to use [`Any`](https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/any.proto)s to encode interfaces in protobuf. An `Any` contains an arbitrary serialized message as bytes, along with a URL that acts as a globally unique identifier for and resolves to that message's type. This strategy allows us to pack arbitrary Go types inside protobuf messages. Our new `Profile` then looks like:
@ -172,7 +172,7 @@ bz, err := cdc.Marshal(profile)
jsonBz, err := cdc.MarshalJSON(profile)
```
To summarize, to encode an interface, you must 1/ pack the interface into an `Any` and 2/ marshal the `Any`. For convenience, the Cosmos SDK provides a `MarshalInterface` method to bundle these two steps. Have a look at [a real-life example in the x/auth module](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/keeper/keeper.go#L230-L233).
To summarize, to encode an interface, you must 1/ pack the interface into an `Any` and 2/ marshal the `Any`. For convenience, the Cosmos SDK provides a `MarshalInterface` method to bundle these two steps. Have a look at [a real-life example in the x/auth module](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/keeper/keeper.go#L230-L233).
The reverse operation of retrieving the concrete Go type from inside an `Any`, called "unpacking", is done with the `GetCachedValue()` on `Any`.
@ -216,11 +216,11 @@ The above `Profile` example is a fictive example used for educational purposes.
* the `AccountI` interface for encodinig different types of accounts (similar to the above example) in the x/auth query responses,
* the `Evidencei` interface for encoding different types of evidences in the x/evidence module,
* the `AuthorizationI` interface for encoding different types of x/authz authorizations,
* the [`Validator`](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/types/staking.pb.go#L306-L339) struct that contains information about a validator.
* the [`Validator`](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/staking/types/staking.pb.go#L306-L339) struct that contains information about a validator.
A real-life example of encoding the pubkey as `Any` inside the Validator struct in x/staking is shown in the following example:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/types/validator.go#L40-L61
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/staking/types/validator.go#L40-L61
## FAQ
@ -264,7 +264,7 @@ The Cosmos SDK `codec.Codec` interface provides support methods `MarshalInterfac
Module should register interfaces using `InterfaceRegistry` which provides a mechanism for registering interfaces: `RegisterInterface(protoName string, iface interface{}, impls ...proto.Message)` and implementations: `RegisterImplementations(iface interface{}, impls ...proto.Message)` that can be safely unpacked from Any, similarly to type registration with Amino:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/codec/types/interface_registry.go#L25-L55
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/codec/types/interface_registry.go#L25-L55
In addition, an `UnpackInterfaces` phase should be introduced to deserialization to unpack interfaces before they're needed. Protobuf types that contain a protobuf `Any` either directly or via one of their members should implement the `UnpackInterfacesMessage` interface:

14
docs/core/events.md
View File

@ -16,7 +16,7 @@ order: 9
Events are implemented in the Cosmos SDK as an alias of the ABCI `Event` type and
take the form of: `{eventType}.{attributeKey}={attributeValue}`.
+++ https://github.com/tendermint/tendermint/blob/v0.35.4/proto/tendermint/abci/types.proto#L273-L279
+++ https://github.com/tendermint/tendermint/blob/v0.34.21/proto/tendermint/abci/types.proto#L310-L319
An Event contains:
@ -59,19 +59,19 @@ In Cosmos SDK applications, Events are managed by an abstraction called the `Eve
Internally, the `EventManager` tracks a list of Events for the entire execution flow of a
transaction or `BeginBlock`/`EndBlock`.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/events.go#L17-L25
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/types/events.go#L17-L25
The `EventManager` comes with a set of useful methods to manage Events. The method
that is used most by module and application developers is `EmitTypedEvent` that tracks
an Event in the `EventManager`.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/events.go#L50-L59
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/types/events.go#L50-L59
Module developers should handle Event emission via the `EventManager#EmitTypedEvent` in each message
`Handler` and in each `BeginBlock`/`EndBlock` handler. The `EventManager` is accessed via
the [`Context`](./context.md), where Event should be already registered, and emitted like this:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/group/keeper/msg_server.go#L89-L92
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/group/keeper/msg_server.go#L89-L92
Module's `handler` function should also set a new `EventManager` to the `context` to isolate emitted Events per `message`:
@ -109,7 +109,7 @@ The main `eventCategory` you can subscribe to are:
These Events are triggered from the `state` package after a block is committed. You can get the
full list of Event categories [on the Tendermint Go documentation](https://pkg.go.dev/github.com/tendermint/tendermint/types#pkg-constants).
The `type` and `attribute` value of the `query` allow you to filter the specific Event you are looking for. For example, a `Mint` transaction triggers an Event of type `EventMint` and has an `Id` and an `Owner` as `attributes` (as defined in the [`events.proto` file of the `NFT` module](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/nft/v1beta1/event.proto#L14-L19)).
The `type` and `attribute` value of the `query` allow you to filter the specific Event you are looking for. For example, a `Mint` transaction triggers an Event of type `EventMint` and has an `Id` and an `Owner` as `attributes` (as defined in the [`events.proto` file of the `NFT` module](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/nft/v1beta1/event.proto#L14-L19)).
Subscribing to this Event would be done like so:
@ -126,11 +126,11 @@ Subscribing to this Event would be done like so:
where `ownerAddress` is an address following the [`AccAddress`](../basics/accounts.md#addresses) format.
## Events (Deprecated)
## Events
Previously, the Cosmos SDK supported emitting Events that were defined in `types/events.go`. It is the responsibility of the module developer to define Event types and Event attributes. Except in the `spec/XX_events.md` file, these Event types and attributes are unfortunately not easily discoverable,
This is why this methods as been deprecated, and replaced by _[Typed Events](#typed-events).
This is why this methods as been deprecated, and replaced by [Typed Events](#typed-events).
To learn more about the previous way of defining events, please refer to the [previous SDK documentation](https://docs.cosmos.network/v0.45/core/events.html#events-2).

6
docs/core/grpc_rest.md
View File

@ -24,7 +24,7 @@ In the Cosmos SDK, Protobuf is the main [encoding](./encoding) library. This bri
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:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/server/types/app.go#L45-L47
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/server/types/app.go#L45-L47
Note: It is not possible to expose any [Protobuf `Msg` service](../building-modules/messages-and-queries.md#messages) endpoints via gRPC. Transactions must be generated and signed using the CLI or programmatically before they can be broadcasted using gRPC. See [Generating, Signing, and Broadcasting Transactions](../run-node/txs.html) for more information.
@ -57,7 +57,7 @@ If, for various reasons, you cannot use gRPC (for example, you are building a we
[gRPC-gateway](https://grpc-ecosystem.github.io/grpc-gateway/) is a tool to expose gRPC endpoints as REST endpoints. For each gRPC endpoint defined in a Protobuf `Query` service, the Cosmos SDK offers a REST equivalent. For instance, querying a balance could be done via the `/cosmos.bank.v1beta1.QueryAllBalances` gRPC endpoint, or alternatively via the gRPC-gateway `"/cosmos/bank/v1beta1/balances/{address}"` REST endpoint: both will return the same result. For each RPC method defined in a Protobuf `Query` service, the corresponding REST endpoint is defined as an option:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/bank/v1beta1/query.proto#L19-L22
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/bank/v1beta1/query.proto#L19-L22
For application developers, gRPC-gateway REST routes needs to be wired up to the REST server, this is done by calling the `RegisterGRPCGatewayRoutes` function on the ModuleManager.
@ -68,7 +68,7 @@ A [Swagger](https://swagger.io/) (or OpenAPIv2) specification file is exposed un
Enabling the `/swagger` endpoint is configurable inside `~/.simapp/config/app.toml` via the `api.swagger` field, which is set to true by default.
For application developers, you may want to generate your own Swagger definitions based on your custom modules.
The Cosmos SDK's [Swagger generation script](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/scripts/protoc-swagger-gen.sh) is a good place to start.
The Cosmos SDK's [Swagger generation script](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/scripts/protoc-swagger-gen.sh) is a good place to start.
## Tendermint RPC

18
docs/core/node.md
View File

@ -18,15 +18,15 @@ In general, developers will implement the `main.go` function with the following
* First, an [`encodingCodec`](./encoding.md) is instantiated for the application.
* Then, the `config` is retrieved and config parameters are set. This mainly involves setting the Bech32 prefixes for [addresses](../basics/accounts.md#addresses).
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/config.go#L14-L29
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/types/config.go#L14-L29
* Using [cobra](https://github.com/spf13/cobra), the root command of the full-node client is created. After that, all the custom commands of the application are added using the `AddCommand()` method of `rootCmd`.
* Add default server commands to `rootCmd` using the `server.AddCommands()` method. These commands are separated from the ones added above since they are standard and defined at Cosmos SDK level. They should be shared by all Cosmos SDK-based applications. They include the most important command: the [`start` command](#start-command).
* Prepare and execute the `executor`.
+++ https://github.com/tendermint/tendermint/blob/v0.35.4/libs/cli/setup.go#L74-L78
+++ https://github.com/tendermint/tendermint/blob/v0.34.21/libs/cli/setup.go#L74-L78
See an example of `main` function from the `simapp` application, the Cosmos SDK's application for demo purposes:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/simd/main.go
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/simd/main.go
## `start` command
@ -46,25 +46,25 @@ The flow of the `start` command is pretty straightforward. First, it retrieves t
With the `db`, the `start` command creates a new instance of the application using an `appCreator` function:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/server/start.go#L209-L209
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/server/start.go#L209-L209
Note that an `appCreator` is a function that fulfills the `AppCreator` signature:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/server/types/app.go#L57-L59
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/server/types/app.go#L57-L59
In practice, the [constructor of the application](../basics/app-anatomy.md#constructor-function) is passed as the `appCreator`.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/simd/cmd/root.go#L246-L295
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/simd/cmd/root.go#L246-L295
Then, the instance of `app` is used to instantiate a new Tendermint node:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/server/start.go#L291-L294
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/server/start.go#L291-L294
The Tendermint node can be created with `app` because the latter satisfies the [`abci.Application` interface](https://github.com/tendermint/tendermint/blob/v0.35.4/abci/types/application.go#L7-L32) (given that `app` extends [`baseapp`](./baseapp.md)). As part of the `node.New` 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, `node.New` 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.
The Tendermint node can be created with `app` because the latter satisfies the [`abci.Application` interface](https://github.com/tendermint/tendermint/blob/v0.34.21/abci/types/application.go#L7-L32) (given that `app` extends [`baseapp`](./baseapp.md)). As part of the `node.New` 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, `node.New` 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 instantiated and in sync with the application, the node can be started:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/server/start.go#L296-L298
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/server/start.go#L296-L298
Upon starting, the node will bootstrap its RPC and P2P server and start dialing peers. During handshake with its peers, if the node realizes they are ahead, it will query all the blocks sequentially in order to catch up. Then, it will wait for new block proposals and block signatures from validators in order to make progress.

2
docs/core/ocap.md
View File

@ -67,7 +67,7 @@ sumValue := externalModule.ComputeSumValue(*account)
In the Cosmos SDK, you can see the application of this principle in simapp.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/app.go#L258-L283
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/app.go#L258-L283
The following diagram shows the current dependencies between keepers.

4
docs/core/runtx_middleware.md
View File

@ -8,11 +8,11 @@ order: 12
Depending on the panic type different handler is used, for instance the default one prints an error log message.
Recovery middleware is used to add custom panic recovery for Cosmos SDK application developers.
More context can found in the corresponding [ADR-022](../architecture/adr-022-custom-panic-handling.md) and the implementation in [recovery.go](https://github.com/cosmos/cosmos-sdk/tree/v0.46.0-rc1/baseapp/recovery.go).
More context can found in the corresponding [ADR-022](../architecture/adr-022-custom-panic-handling.md) and the implementation in [recovery.go](https://github.com/cosmos/cosmos-sdk/tree/v0.46.0/baseapp/recovery.go).
## Interface
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/baseapp/recovery.go#L11-L14
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/baseapp/recovery.go#L11-L14
`recoveryObj` is a return value for `recover()` function from the `buildin` Go package.

12
docs/core/simulation.md
View File

@ -7,8 +7,8 @@ order: 13
The Cosmos SDK offers a full fledged simulation framework to fuzz test every
message defined by a module.
On the Cosmos SDK, this functionality is provided by the[`SimApp`](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/app.go), which is a
`Baseapp` application that is used for running the [`simulation`](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/simulation) module.
On the Cosmos SDK, this functionality is provided by the[`SimApp`](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/app.go), which is a
`Baseapp` application that is used for running the [`simulation`](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/simulation) module.
This module defines all the simulation logic as well as the operations for
randomized parameters like accounts, balances etc.
@ -41,7 +41,7 @@ failure type:
Each simulation must receive a set of inputs (_i.e_ flags) such as the number of
blocks that the simulation is run, seed, block size, etc.
Check the full list of flags [here](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/config.go#L32-L55).
Check the full list of flags [here](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/config.go#L32-L55).
## Simulator Modes
@ -53,7 +53,7 @@ In addition to the various inputs and commands, the simulator runs in three mode
This mode is helpful for running simulations on a known state such as a live network export where a new (mostly likely breaking) version of the application needs to be tested.
3. From a `params.json` file where the initial state is pseudo-randomly generated but the module and simulation parameters can be provided manually.
This allows for a more controlled and deterministic simulation setup while allowing the state space to still be pseudo-randomly simulated.
The list of available parameters are listed [here](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/config.go#L33-L57).
The list of available parameters are listed [here](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/config.go#L33-L57).
::: tip
These modes are not mutually exclusive. So you can for example run a randomly
@ -63,7 +63,7 @@ generated genesis state (`1`) with manually generated simulation params (`3`).
## Usage
This is a general example of how simulations are run. For more specific examples
check the Cosmos SDK [Makefile](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/Makefile#L263-L299).
check the Cosmos SDK [Makefile](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/Makefile#L263-L299).
```bash
$ go test -mod=readonly github.com/cosmos/cosmos-sdk/simapp \
@ -90,7 +90,7 @@ Here are some suggestions when encountering a simulation failure:
* Run invariants on every operation with `-SimulateEveryOperation`. _Note_: this
will slow down your simulation **a lot**.
* Try adding logs to operations that are not logged. You will have to define a
[Logger](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/keeper/keeper.go#L60-L63) on your `Keeper`.
[Logger](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/staking/keeper/keeper.go#L60-L63) on your `Keeper`.
## Use simulation in your Cosmos SDK-based application

52
docs/core/store.md
View File

@ -58,11 +58,11 @@ The Cosmos SDK comes with a large set of stores to persist the state of applicat
At its very core, a Cosmos SDK `store` is an object that holds a `CacheWrapper` and has a `GetStoreType()` method:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/store/types/store.go#L16-L19
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/store/types/store.go#L16-L19
The `GetStoreType` is a simple method that returns the type of store, whereas a `CacheWrapper` is a simple interface that implements store read caching and write branching through `Write` method:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/store/types/store.go#L247-L277
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/store/types/store.go#L247-L277
Branching and cache is used ubiquitously in the Cosmos SDK and required to be implemented on every store type. A storage branch creates an isolated, ephemeral branch of a store that can be passed around and updated without affecting the main underlying store. This is used to trigger temporary state-transitions that may be reverted later should an error occur. Read more about it in [context](./context.md#Store-branching)
@ -70,11 +70,11 @@ Branching and cache is used ubiquitously in the Cosmos SDK and required to be im
A commit store is a store that has the ability to commit changes made to the underlying tree or db. The Cosmos SDK differentiates simple stores from commit stores by extending the basic store interfaces with a `Committer`:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/store/types/store.go#L30-L34
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/store/types/store.go#L30-L34
The `Committer` is an interface that defines methods to persist changes to disk:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/store/types/store.go#L21-L28
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/store/types/store.go#L21-L28
The `CommitID` is a deterministic commit of the state tree. Its hash is returned to the underlying consensus engine and stored in the block header. Note that commit store interfaces exist for various purposes, one of which is to make sure not every object can commit the store. As part of the [object-capabilities model](./ocap.md) of the Cosmos SDK, only `baseapp` should have the ability to commit stores. For example, this is the reason why the `ctx.KVStore()` method by which modules typically access stores returns a `KVStore` and not a `CommitKVStore`.
@ -86,7 +86,7 @@ The Cosmos SDK comes with many types of stores, the most used being [`CommitMult
Each Cosmos SDK application holds a multistore at its root to persist its state. The multistore is a store of `KVStores` that follows the `Multistore` interface:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/store/types/store.go#L97-L133
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/store/types/store.go#L97-L133
If tracing is enabled, then branching the multistore will firstly wrap all the underlying `KVStore` in [`TraceKv.Store`](#tracekv-store).
@ -94,19 +94,19 @@ If tracing is enabled, then branching the multistore will firstly wrap all the u
The main type of `Multistore` used in the Cosmos SDK is `CommitMultiStore`, which is an extension of the `Multistore` interface:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/store/types/store.go#L141-L187
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/store/types/store.go#L141-L187
As for concrete implementation, the [`rootMulti.Store`] is the go-to implementation of the `CommitMultiStore` interface.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/store/rootmulti/store.go#L38-L61
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/store/rootmulti/store.go#L38-L61
The `rootMulti.Store` is a base-layer multistore built around a `db` on top of which multiple `KVStores` can be mounted, and is the default multistore store used in [`baseapp`](./baseapp.md).
### CacheMultiStore
Whenever the `rootMulti.Store` needs to be branched, a [`cachemulti.Store`](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/store/cachemulti/store.go) is used.
Whenever the `rootMulti.Store` needs to be branched, a [`cachemulti.Store`](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/store/cachemulti/store.go) is used.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/store/cachemulti/store.go#L20-L36
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/store/cachemulti/store.go#L20-L36
`cachemulti.Store` branches all substores (creates a virtual store for each substore) in its constructor and hold them in `Store.stores`. Moreover caches all read queries. `Store.GetKVStore()` returns the store from `Store.stores`, and `Store.Write()` recursively calls `CacheWrap.Write()` on all the substores.
@ -120,17 +120,17 @@ Individual `KVStore`s are used by modules to manage a subset of the global state
`CommitKVStore`s are declared by proxy of their respective `key` and mounted on the application's [multistore](#multistore) in the [main application file](../basics/app-anatomy.md#core-application-file). In the same file, the `key` is also passed to the module's `keeper` that is responsible for managing the store.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/store/types/store.go#L192-L226
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/store/types/store.go#L192-L226
Apart from the traditional `Get` and `Set` methods, that a `KVStore` must implement via the `BasicKVStore` interface; a `KVStore` must provide an `Iterator(start, end)` method which returns an `Iterator` object. It is used to iterate over a range of keys, typically keys that share a common prefix. Below is an example from the bank's module keeper, used to iterate over all account balances:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/keeper/view.go#L114-L132
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/bank/keeper/view.go#L114-L132
### `IAVL` Store
The default implementation of `KVStore` and `CommitKVStore` used in `baseapp` is the `iavl.Store`.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/store/iavl/store.go#L37-L40
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/store/iavl/store.go#L37-L40
`iavl` stores are based around an [IAVL Tree](https://github.com/cosmos/iavl), a self-balancing binary tree which guarantees that:
@ -144,7 +144,7 @@ The documentation on the IAVL Tree is located [here](https://github.com/cosmos/i
`dbadapter.Store` is a adapter for `dbm.DB` making it fulfilling the `KVStore` interface.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/store/dbadapter/store.go#L14-L17
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/store/dbadapter/store.go#L14-L17
`dbadapter.Store` embeds `dbm.DB`, meaning most of the `KVStore` interface functions are implemented. The other functions (mostly miscellaneous) are manually implemented. This store is primarily used within [Transient Stores](#transient-stores)
@ -152,17 +152,17 @@ The documentation on the IAVL Tree is located [here](https://github.com/cosmos/i
`Transient.Store` is a base-layer `KVStore` which is automatically discarded at the end of the block.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/store/transient/store.go#L16-L19
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/store/transient/store.go#L16-L19
`Transient.Store` is a `dbadapter.Store` with a `dbm.NewMemDB()`. All `KVStore` methods are reused. When `Store.Commit()` is called, a new `dbadapter.Store` is assigned, discarding previous reference and making it garbage collected.
This type of store is useful to persist information that is only relevant per-block. One example would be to store parameter changes (i.e. a bool set to `true` if a parameter changed in a block).
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/params/types/subspace.go#L21-L31
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/params/types/subspace.go#L21-L31
Transient stores are typically accessed via the [`context`](./context.md) via the `TransientStore()` method:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/context.go#L264-L267
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/types/context.go#L264-L267
## KVStore Wrappers
@ -170,7 +170,7 @@ Transient stores are typically accessed via the [`context`](./context.md) via th
`cachekv.Store` is a wrapper `KVStore` which provides buffered writing / cached reading functionalities over the underlying `KVStore`.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/store/cachekv/store.go#L27-L35
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/store/cachekv/store.go#L27-L35
This is the type used whenever an IAVL Store needs to be branched to create an isolated store (typically when we need to mutate a state that might be reverted later).
@ -188,27 +188,27 @@ This is the type used whenever an IAVL Store needs to be branched to create an i
### `GasKv` Store
Cosmos SDK applications use [`gas`](../basics/gas-fees.md) to track resources usage and prevent spam. [`GasKv.Store`](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/store/gaskv/store.go) is a `KVStore` wrapper that enables automatic gas consumption each time a read or write to the store is made. It is the solution of choice to track storage usage in Cosmos SDK applications.
Cosmos SDK applications use [`gas`](../basics/gas-fees.md) to track resources usage and prevent spam. [`GasKv.Store`](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/store/gaskv/store.go) is a `KVStore` wrapper that enables automatic gas consumption each time a read or write to the store is made. It is the solution of choice to track storage usage in Cosmos SDK applications.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/store/gaskv/store.go#L11-L17
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/store/gaskv/store.go#L11-L17
When methods of the parent `KVStore` are called, `GasKv.Store` automatically consumes appropriate amount of gas depending on the `Store.gasConfig`:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/store/types/gas.go#L219-L228
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/store/types/gas.go#L219-L228
By default, all `KVStores` are wrapped in `GasKv.Stores` when retrieved. This is done in the `KVStore()` method of the [`context`](./context.md):
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/context.go#L259-L262
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/types/context.go#L259-L262
In this case, the default gas configuration is used:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/store/types/gas.go#L230-L241
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/store/types/gas.go#L230-L241
### `TraceKv` Store
`tracekv.Store` is a wrapper `KVStore` which provides operation tracing functionalities over the underlying `KVStore`. It is applied automatically by the Cosmos SDK on all `KVStore` if tracing is enabled on the parent `MultiStore`.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/store/tracekv/store.go#L20-L43
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/store/tracekv/store.go#L20-L43
When each `KVStore` methods are called, `tracekv.Store` automatically logs `traceOperation` to the `Store.writer`. `traceOperation.Metadata` is filled with `Store.context` when it is not nil. `TraceContext` is a `map[string]interface{}`.
@ -216,7 +216,7 @@ When each `KVStore` methods are called, `tracekv.Store` automatically logs `trac
`prefix.Store` is a wrapper `KVStore` which provides automatic key-prefixing functionalities over the underlying `KVStore`.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/store/prefix/store.go#L16-L22
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/store/prefix/store.go#L16-L22
When `Store.{Get, Set}()` is called, the store forwards the call to its parent, with the key prefixed with the `Store.prefix`.
@ -226,9 +226,9 @@ When `Store.Iterator()` is called, it does not simply prefix the `Store.prefix`,
`listenkv.Store` is a wrapper `KVStore` which provides state listening capabilities over the underlying `KVStore`.
It is applied automatically by the Cosmos SDK on any `KVStore` whose `StoreKey` is specified during state streaming configuration.
Additional information about state streaming configuration can be found in the [store/streaming/README.md](https://github.com/cosmos/cosmos-sdk/tree/v0.46.0-rc1/store/streaming).
Additional information about state streaming configuration can be found in the [store/streaming/README.md](https://github.com/cosmos/cosmos-sdk/tree/v0.46.0/store/streaming).
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/store/listenkv/store.go#L11-L18
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/store/listenkv/store.go#L11-L18
When `KVStore.Set` or `KVStore.Delete` methods are called, `listenkv.Store` automatically writes the operations to the set of `Store.listeners`.

2
docs/core/telemetry.md
View File

@ -17,7 +17,7 @@ To query active metrics (see retention note above) you have to enable API server
If telemetry is enabled via configuration, a single global metrics collector is registered via the
[go-metrics](https://github.com/armon/go-metrics) library. This allows emitting and collecting
metrics through simple [API](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/telemetry/wrapper.go). Example:
metrics through simple [API](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/telemetry/wrapper.go). Example:
```go
func EndBlocker(ctx sdk.Context, k keeper.Keeper) {

8
docs/core/tips.md
View File

@ -26,15 +26,15 @@ The transaction tips flow happens in multiple steps.
2. The tipper drafts a transaction to be executed on the chain A. It can include chain A `Msg`s. However, instead of creating a normal transaction, they create the following `AuxSignerData` document:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L230-L249
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/tx/v1beta1/tx.proto#L230-L249
where we have defined `SignDocDirectAux` as:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L67-L93
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/tx/v1beta1/tx.proto#L67-L93
where `Tip` is defined as
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L219-L228
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/tx/v1beta1/tx.proto#L219-L228
Notice that this document doesn't sign over the final chain A fees. Instead, it includes a `Tip` field. It also doesn't include the whole `AuthInfo` object as in `SIGN_MODE_DIRECT`, only the minimum information needed by the tipper
@ -152,7 +152,7 @@ For both commands, the flag `--sign-mode=amino-json` is still available for hard
## Programmatic Usage
For the tipper, the SDK exposes a new transaction builder, the `AuxTxBuilder`, for generating an `AuxSignerData`. The API of `AuxTxBuilder` is defined [in `client/tx`](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/client/tx/aux_builder.go#L16), and can be used as follows:
For the tipper, the SDK exposes a new transaction builder, the `AuxTxBuilder`, for generating an `AuxSignerData`. The API of `AuxTxBuilder` is defined [in `client/tx`](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/client/tx/aux_builder.go#L16), and can be used as follows:
```go
// Note: there's no need to use clientCtx.TxConfig anymore.

22
docs/core/transactions.md
View File

@ -20,7 +20,7 @@ When users want to interact with an application and make state changes (e.g. sen
Transaction objects are Cosmos SDK types that implement the `Tx` interface
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/tx_msg.go#L38-L46
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/types/tx_msg.go#L38-L46
It contains the following methods:
@ -37,11 +37,11 @@ Every message in a transaction must be signed by the addresses specified by its
The most used implementation of the `Tx` interface is the Protobuf `Tx` message, which is used in `SIGN_MODE_DIRECT`:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L13-L26
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/tx/v1beta1/tx.proto#L13-L26
Because Protobuf serialization is not deterministic, the Cosmos SDK uses an additional `TxRaw` type to denote the pinned bytes over which a transaction is signed. Any user can generate a valid `body` and `auth_info` for a transaction, and serialize these two messages using Protobuf. `TxRaw` then pins the user's exact binary representation of `body` and `auth_info`, called respectively `body_bytes` and `auth_info_bytes`. The document that is signed by all signers of the transaction is `SignDoc` (deterministically serialized using [ADR-027](../architecture/adr-027-deterministic-protobuf-serialization.md)):
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L48-L65
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/tx/v1beta1/tx.proto#L48-L65
Once signed by all signers, the `body_bytes`, `auth_info_bytes` and `signatures` are gathered into `TxRaw`, whose serialized bytes are broadcasted over the network.
@ -49,11 +49,11 @@ Once signed by all signers, the `body_bytes`, `auth_info_bytes` and `signatures`
The legacy implementation of the `Tx` interface is the `StdTx` struct from `x/auth`:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/migrations/legacytx/stdtx.go#L82-L92
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/migrations/legacytx/stdtx.go#L82-L92
The document signed by all signers is `StdSignDoc`:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/migrations/legacytx/stdsign.go#L38-L52
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/migrations/legacytx/stdsign.go#L38-L52
which is encoded into bytes using Amino JSON. Once all signatures are gathered into `StdTx`, `StdTx` is serialized using Amino JSON, and these bytes are broadcasted over the network.
@ -66,7 +66,7 @@ The Cosmos SDK also provides a couple of other sign modes for particular use cas
`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-rc1/proto/cosmos/tx/v1beta1/tx.proto#L67-L93
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/tx/v1beta1/tx.proto#L67-L93
The use case is a multi-signer transaction, where one of the signers is appointed to gather all signatures, broadcast the signature and pay for fees, and the others only care about the transaction body. This generally allows for a better multi-signing UX. If Alice, Bob and Charlie are part of a 3-signer transaction, then Alice and Bob can both use `SIGN_MODE_DIRECT_AUX` to sign over the `TxBody` and their own signer info (no need an additional step to gather other signers' ones, like in `SIGN_MODE_DIRECT`), without specifying a fee in their SignDoc. Charlie can then gather both signatures from Alice and Bob, and
create the final transaction by appending a fee. Note that the fee payer of the transaction (in our case Charlie) must sign over the fees, so must use `SIGN_MODE_DIRECT` or `SIGN_MODE_LEGACY_AMINO_JSON`.
@ -106,7 +106,7 @@ While messages contain the information for state transition logic, a transaction
The `TxBuilder` interface contains data closely related with the generation of transactions, which an end-user can freely set to generate the desired transaction:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/client/tx_config.go#L33-L50
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/client/tx_config.go#L33-L50
* `Msg`s, the array of [messages](#messages) included in the transaction.
* `GasLimit`, option chosen by the users for how to calculate how much gas they will need to pay.
@ -117,12 +117,12 @@ The `TxBuilder` interface contains data closely related with the generation of t
As there are currently two sign modes for signing transactions, there are also two implementations of `TxBuilder`:
* [wrapper](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/tx/builder.go#L18-L34) for creating transactions for `SIGN_MODE_DIRECT`,
* [StdTxBuilder](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/migrations/legacytx/stdtx_builder.go#L15-L21) for `SIGN_MODE_LEGACY_AMINO_JSON`.
* [wrapper](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/tx/builder.go#L18-L34) for creating transactions for `SIGN_MODE_DIRECT`,
* [StdTxBuilder](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/migrations/legacytx/stdtx_builder.go#L15-L21) for `SIGN_MODE_LEGACY_AMINO_JSON`.
However, the two implementation of `TxBuilder` should be hidden away from end-users, as they should prefer using the overarching `TxConfig` interface:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/client/tx_config.go#L22-L31
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/client/tx_config.go#L22-L31
`TxConfig` is an app-wide configuration for managing transactions. Most importantly, it holds the information about whether to sign each transaction with `SIGN_MODE_DIRECT` or `SIGN_MODE_LEGACY_AMINO_JSON`. By calling `txBuilder := txConfig.NewTxBuilder()`, a new `TxBuilder` will be created with the appropriate sign mode.
@ -154,7 +154,7 @@ simd tx send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000stake
[gRPC](https://grpc.io) is the main component for the Cosmos SDK's RPC layer. Its principal usage is in the context of modules' [`Query` services](../building-modules). However, the Cosmos SDK also exposes a few other module-agnostic gRPC services, one of them being the `Tx` service:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/tx/v1beta1/service.proto
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/tx/v1beta1/service.proto
The `Tx` service exposes a handful of utility functions, such as simulating a transaction or querying a transaction, and also one method to broadcast transactions.

2
docs/intro/sdk-app-architecture.md
View File

@ -88,7 +88,7 @@ Here are the most important messages of the ABCI:
* `DeliverTx`: When a [valid block](https://docs.tendermint.com/v0.34/spec/blockchain/blockchain.html#validation) is received by Tendermint Core, each transaction in the block is passed to the application via `DeliverTx` in order to be processed. It is during this stage that the state transitions occur. The `AnteHandler` executes again, along with the actual [`Msg` service](../building-modules/msg-services.md) RPC for each message in the transaction.
* `BeginBlock`/`EndBlock`: These messages are executed at the beginning and the end of each block, whether the block contains transactions or not. It is useful to trigger automatic execution of logic. Proceed with caution though, as computationally expensive loops could slow down your blockchain, or even freeze it if the loop is infinite.
Find a more detailed view of the ABCI methods from the [Tendermint docs](https://docs.tendermint.com/v0.35/introduction/what-is-tendermint.html#abci-overview).
Find a more detailed view of the ABCI methods from the [Tendermint docs](https://docs.tendermint.com/v0.34/introduction/what-is-tendermint.html#abci-overview).
Any application built on Tendermint needs to implement the ABCI interface in order to communicate with the underlying local Tendermint engine. Fortunately, you do not have to implement the ABCI interface. The Cosmos SDK provides a boilerplate implementation of it in the form of [baseapp](./sdk-design.md#baseapp).

2
docs/intro/sdk-design.md
View File

@ -19,7 +19,7 @@ Here is a simplified view of how transactions are handled by an application buil
Here is an example of this from `simapp`, the Cosmos SDK demonstration app:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/app.go#L154-L193
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/app.go#L154-L193
The goal of `baseapp` is to provide a secure interface between the store and the extensible state machine while defining as little about the state machine as possible (staying true to the ABCI).

2
docs/migrations/README.md
View File

@ -10,4 +10,4 @@ This document contains all the migration guides to update your app and modules t
1. Chain Upgrade Guide to v0.46:
* See [UPGRADING.md (TODO)](https://github.com/cosmos/cosmos-sdk/blob/main/UPGRADING.md) for breaking changes and deprecations upgrade instructions.
* See [Release Notes](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/RELEASE_NOTES.md) and [changelog](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/CHANGELOG.md) for the exhaustive list of API and State Machine breaking changes.
* See [Release Notes](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/RELEASE_NOTES.md) and [changelog](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/CHANGELOG.md) for the exhaustive list of API and State Machine breaking changes.

2
docs/run-node/run-node.md
View File

@ -121,7 +121,7 @@ You should see blocks come in.
The previous command allow you to run a single node. This is enough for the next section on interacting with this node, but you may wish to run multiple nodes at the same time, and see how consensus happens between them.
The naive way would be to run the same commands again in separate terminal windows. This is possible, however in the Cosmos SDK, we leverage the power of [Docker Compose](https://docs.docker.com/compose/) to run a localnet. If you need inspiration on how to set up your own localnet with Docker Compose, you can have a look at the Cosmos SDK's [`docker-compose.yml`](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/docker-compose.yml).
The naive way would be to run the same commands again in separate terminal windows. This is possible, however in the Cosmos SDK, we leverage the power of [Docker Compose](https://docs.docker.com/compose/) to run a localnet. If you need inspiration on how to set up your own localnet with Docker Compose, you can have a look at the Cosmos SDK's [`docker-compose.yml`](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/docker-compose.yml).
## Next {hide}

2
docs/run-node/txs.md
View File

@ -143,7 +143,7 @@ priv2, _, addr2 := testdata.KeyTestPubAddr()
priv3, _, addr3 := testdata.KeyTestPubAddr()
```
Populating the `TxBuilder` can be done via its [methods](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/client/tx_config.go#L33-L50):
Populating the `TxBuilder` can be done via its [methods](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/client/tx_config.go#L33-L50):
```go
import (

12
x/auth/spec/05_vesting.md
View File

@ -100,19 +100,19 @@ type VestingAccount interface {
### BaseVestingAccount
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/vesting/v1beta1/vesting.proto#L10-L24
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/vesting/v1beta1/vesting.proto#L10-L24
### ContinuousVestingAccount
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/vesting/v1beta1/vesting.proto#L26-L34
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/vesting/v1beta1/vesting.proto#L26-L34
### DelayedVestingAccount
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/vesting/v1beta1/vesting.proto#L36-L44
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/vesting/v1beta1/vesting.proto#L36-L44
### Period
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/vesting/v1beta1/vesting.proto#L46-L53
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/vesting/v1beta1/vesting.proto#L46-L53
```go
// Stores all vesting periods passed as part of a PeriodicVestingAccount
@ -122,7 +122,7 @@ type Periods []Period
### PeriodicVestingAccount
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/vesting/v1beta1/vesting.proto#L55-L64
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/vesting/v1beta1/vesting.proto#L55-L64
In order to facilitate less ad-hoc type checking and assertions and to support
flexibility in account balance usage, the existing `x/bank` `ViewKeeper` interface
@ -142,7 +142,7 @@ type ViewKeeper interface {
### PermanentLockedAccount
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/vesting/v1beta1/vesting.proto#L66-L76
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/vesting/v1beta1/vesting.proto#L66-L76
## Vesting Account Specification

14
x/authz/spec/01_concepts.md
View File

@ -14,7 +14,7 @@ Authorization is an interface that must be implemented by a concrete authorizati
**Note:** The authz module is different from the [auth (authentication)](../modules/auth/) module that is responsible for specifying the base transaction and account types.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/authz/authorizations.go#L11-L25
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/authz/authorizations.go#L11-L25
## Built-in Authorizations
@ -24,9 +24,9 @@ The Cosmos SDK `x/authz` module comes with following authorization types:
`GenericAuthorization` implements the `Authorization` interface that gives unrestricted permission to execute the provided Msg on behalf of granter's account.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/authz/v1beta1/authz.proto#L13-L20
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/authz/v1beta1/authz.proto#L13-L20
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/authz/generic_authorization.go#L16-L29
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/authz/generic_authorization.go#L16-L29
* `msg` stores Msg type URL.
@ -34,9 +34,9 @@ The Cosmos SDK `x/authz` module comes with following authorization types:
`SendAuthorization` implements the `Authorization` interface for the `cosmos.bank.v1beta1.MsgSend` Msg. It takes a (positive) `SpendLimit` that specifies the maximum amount of tokens the grantee can spend. The `SpendLimit` is updated as the tokens are spent.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/bank/v1beta1/authz.proto#L10-L19
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/bank/v1beta1/authz.proto#L10-L19
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/types/send_authorization.go#L23-L38
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/bank/types/send_authorization.go#L23-L38
* `spend_limit` keeps track of how many coins are left in the authorization.
@ -44,9 +44,9 @@ The Cosmos SDK `x/authz` module comes with following authorization types:
`StakeAuthorization` implements the `Authorization` interface for messages in the [staking module](https://docs.cosmos.network/v0.44/modules/staking/). It takes an `AuthorizationType` to specify whether you want to authorise delegating, undelegating or redelegating (i.e. these have to be authorised seperately). It also takes a required `MaxTokens` that keeps track of a limit to the amount of tokens that can be delegated/undelegated/redelegated. If left empty, the amount is unlimited. Additionally, this Msg takes an `AllowList` or a `DenyList`, which allows you to select which validators you allow or deny grantees to stake with.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/authz.proto#L10-L33
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/staking/v1beta1/authz.proto#L10-L33
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/types/authz.go#L15-L35
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/staking/types/authz.go#L15-L35
## Gas

4
x/authz/spec/02_state.md
View File

@ -12,7 +12,7 @@ Grants are identified by combining granter address (the address bytes of the gra
The grant object encapsulates an `Authorization` type and an expiration timestamp:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/authz/v1beta1/authz.proto#L22-L30
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/authz/v1beta1/authz.proto#L22-L30
## GrantQueue
@ -20,4 +20,4 @@ We are maintaining a queue for authz pruning, whenever a grant created an item w
* GrantQueue: `0x02 | granter_address_len (1 byte) | granter_address_bytes | grantee_address_len (1 byte) | grantee_address_bytes | expiration_bytes -> ProtocalBuffer([]string{msgTypeUrls})`
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/authz/keeper/keys.go#L78-L93
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/authz/keeper/keys.go#L78-L93

6
x/authz/spec/03_messages.md
View File

@ -11,7 +11,7 @@ In this section we describe the processing of messages for the authz module.
An authorization grant is created using the `MsgGrant` message.
If there is already a grant for the `(granter, grantee, Authorization)` triple, then the new grant overwrites the previous one. To update or extend an existing grant, a new grant with the same `(granter, grantee, Authorization)` triple should be created.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/authz/v1beta1/tx.proto#L32-L41
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/authz/v1beta1/tx.proto#L32-L41
The message handling should fail if:
@ -24,7 +24,7 @@ The message handling should fail if:
A grant can be removed with the `MsgRevoke` message.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/authz/v1beta1/tx.proto#L66-L72
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/authz/v1beta1/tx.proto#L66-L72
The message handling should fail if:
@ -37,7 +37,7 @@ NOTE: The `MsgExec` message removes a grant if the grant has expired.
When a grantee wants to execute a transaction on behalf of a granter, they must send `MsgExec`.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/authz/v1beta1/tx.proto#L51-L59
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/authz/v1beta1/tx.proto#L51-L59
The message handling should fail if:

4
x/bank/spec/03_messages.md
View File

@ -8,7 +8,7 @@ order: 3
Send coins from one address to another.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/bank/v1beta1/tx.proto#L21-L32
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/bank/v1beta1/tx.proto#L21-L32
The message will fail under the following conditions:
@ -18,7 +18,7 @@ The message will fail under the following conditions:
## MsgMultiSend
Send coins from and to a series of different address. If any of the receiving addresses do not correspond to an existing account, a new account is created.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/bank/v1beta1/tx.proto#L37-L45
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/bank/v1beta1/tx.proto#L37-L45
The message will fail under the following conditions:

2
x/crisis/spec/02_messages.md
View File

@ -11,7 +11,7 @@ corresponding updates to the state.
Blockchain invariants can be checked using the `MsgVerifyInvariant` message.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/crisis/v1beta1/tx.proto#L16-L26
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/crisis/v1beta1/tx.proto#L16-L26
This message is expected to fail if:

4
x/distribution/spec/02_state.md
View File

@ -27,7 +27,7 @@ type DecCoin struct {
}
```
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/distribution/v1beta1/distribution.proto#L92-L96
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/distribution/v1beta1/distribution.proto#L92-L96
## Validator Distribution
@ -70,4 +70,4 @@ it can be updated with governance or the address with authority.
* Params: `0x09 | ProtocolBuffer(Params)`
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/distribution/v1beta1/distribution.proto#L11-L30
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/distribution/v1beta1/distribution.proto#L11-L30

4
x/distribution/spec/04_messages.md
View File

@ -13,7 +13,7 @@ The withdraw address cannot be any of the module accounts. These accounts are bl
Response:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/distribution/v1beta1/tx.proto#L31-L41
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/distribution/v1beta1/tx.proto#L31-L41
```go
func (k Keeper) SetWithdrawAddr(ctx sdk.Context, delegatorAddr sdk.AccAddress, withdrawAddr sdk.AccAddress) error
@ -63,7 +63,7 @@ The final calculated stake is equivalent to the actual staked coins in the deleg
Response:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/distribution/v1beta1/tx.proto#L46-L56
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/distribution/v1beta1/tx.proto#L46-L56
## WithdrawValidatorCommission

18
x/feegrant/spec/01_concepts.md
View File

@ -8,11 +8,11 @@ order: 1
`Grant` is stored in the KVStore to record a grant with full context. Every grant will contain `granter`, `grantee` and what kind of `allowance` is granted. `granter` is an account address who is giving permission to `grantee` (the beneficiary account address) to pay for some or all of `grantee`'s transaction fees. `allowance` defines what kind of fee allowance (`BasicAllowance` or `PeriodicAllowance`, see below) is granted to `grantee`. `allowance` accepts an interface which implements `FeeAllowanceI`, encoded as `Any` type. There can be only one existing fee grant allowed for a `grantee` and `granter`, self grants are not allowed.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/feegrant/v1beta1/feegrant.proto#L76-L77
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/feegrant/v1beta1/feegrant.proto#L76-L77
`FeeAllowanceI` looks like:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/feegrant/fees.go#L9-L32
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/feegrant/fees.go#L9-L32
## Fee Allowance types
@ -26,7 +26,7 @@ There are two types of fee allowances present at the moment:
`BasicAllowance` is permission for `grantee` to use fee from a `granter`'s account. If any of the `spend_limit` or `expiration` reaches its limit, the grant will be removed from the state.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/feegrant/v1beta1/feegrant.proto#L13-L26
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/feegrant/v1beta1/feegrant.proto#L13-L26
* `spend_limit` is the limit of coins that are allowed to be used from the `granter` account. If it is empty, it assumes there's no spend limit, `grantee` can use any number of available coins from `granter` account address before the expiration.
@ -38,7 +38,7 @@ There are two types of fee allowances present at the moment:
`PeriodicAllowance` is a repeating fee allowance for the mentioned period, we can mention when the grant can expire as well as when a period can reset. We can also define the maximum number of coins that can be used in a mentioned period of time.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/feegrant/v1beta1/feegrant.proto#L29-L54
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/feegrant/v1beta1/feegrant.proto#L29-L54
* `basic` is the instance of `BasicAllowance` which is optional for periodic fee allowance. If empty, the grant will have no `expiration` and no `spend_limit`.
@ -54,7 +54,7 @@ There are two types of fee allowances present at the moment:
`AllowedMsgAllowance` is a fee allowance, it can be any of `BasicFeeAllowance`, `PeriodicAllowance` but restricted only to the allowed messages mentioned by the granter.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/feegrant/v1beta1/feegrant.proto#L56-L66
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/feegrant/v1beta1/feegrant.proto#L56-L66
* `allowance` is either `BasicAllowance` or `PeriodicAllowance`.
@ -64,13 +64,13 @@ There are two types of fee allowances present at the moment:
`feegrant` module introduces a `FeeGranter` flag for CLI for the sake of executing transactions with fee granter. When this flag is set, `clientCtx` will append the granter account address for transactions generated through CLI.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/client/cmd.go#L236-L246
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/client/cmd.go#L236-L246
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/client/tx/tx.go#L109-L109
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/client/tx/tx.go#L109-L109
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/tx/builder.go#L270-L279
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/tx/builder.go#L270-L279
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L196-L217
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/tx/v1beta1/tx.proto#L196-L217
Example cmd:

2
x/feegrant/spec/02_state.md
View File

@ -12,7 +12,7 @@ Fee allowance grants are stored in the state as follows:
* Grant: `0x00 | grantee_addr_len (1 byte) | grantee_addr_bytes | granter_addr_len (1 byte) | granter_addr_bytes -> ProtocolBuffer(Grant)`
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/feegrant/feegrant.pb.go#L221-L229
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/feegrant/feegrant.pb.go#L221-L229
## FeeAllowanceQueue

4
x/feegrant/spec/03_messages.md
View File

@ -8,10 +8,10 @@ order: 3
A fee allowance grant will be created with the `MsgGrantAllowance` message.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/feegrant/v1beta1/tx.proto#L23-L36
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/feegrant/v1beta1/tx.proto#L23-L36
## Msg/RevokeAllowance
An allowed grant fee allowance can be removed with the `MsgRevokeAllowance` message.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/feegrant/v1beta1/tx.proto#L41-L50
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/feegrant/v1beta1/tx.proto#L41-L50

4
x/gov/spec/01_concepts.md
View File

@ -124,9 +124,9 @@ Often times the entity owning that address might not be a single individual. For
To represent weighted vote on chain, we use the following Protobuf message.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/gov/v1beta1/gov.proto#L33-L43
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/gov/v1beta1/gov.proto#L33-L43
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/gov/v1beta1/gov.proto#L136-L150
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/gov/v1beta1/gov.proto#L136-L150
For a weighted vote to be valid, the `options` field must not contain duplicate vote options, and the sum of weights of all options must be equal to 1.

10
x/gov/spec/02_state.md
View File

@ -12,7 +12,7 @@ to resolve and then execute if the proposal passes. `Proposal`'s are identified
unique id and contains a series of timestamps: `submit_time`, `deposit_end_time`,
`voting_start_time`, `voting_end_time` which track the lifecycle of a proposal
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/gov/v1/gov.proto#L42-L59
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/gov/v1/gov.proto#L42-L59
A proposal will generally require more than just a set of messages to explain its
purpose but need some greater justification and allow a means for interested participants
@ -58,15 +58,15 @@ parameter set has to be created and the previous one rendered inactive.
### DepositParams
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/gov/v1/gov.proto#L102-L112
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/gov/v1/gov.proto#L102-L112
### VotingParams
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/gov/v1/gov.proto#L114-L118
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/gov/v1/gov.proto#L114-L118
### TallyParams
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/gov/v1/gov.proto#L120-L132
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/gov/v1/gov.proto#L120-L132
Parameters are stored in a global `GlobalParams` KVStore.
@ -104,7 +104,7 @@ const (
## Deposit
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/gov/v1/gov.proto#L34-L40
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/gov/v1/gov.proto#L34-L40
## ValidatorGovInfo

6
x/gov/spec/03_messages.md
View File

@ -9,7 +9,7 @@ order: 3
Proposals can be submitted by any account via a `MsgSubmitProposal`
transaction.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/gov/v1/tx.proto#L33-L43
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/gov/v1/tx.proto#L33-L43
All `sdk.Msgs` passed into the `messages` field of a `MsgSubmitProposal` message
must be registered in the app's `MsgServiceRouter`. Each of these messages must
@ -78,7 +78,7 @@ Once a proposal is submitted, if
`Proposal.TotalDeposit < ActiveParam.MinDeposit`, Atom holders can send
`MsgDeposit` transactions to increase the proposal's deposit.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/gov/v1/tx.proto#L90-L97
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/gov/v1/tx.proto#L90-L97
**State modifications:**
@ -144,7 +144,7 @@ Once `ActiveParam.MinDeposit` is reached, voting period starts. From there,
bonded Atom holders are able to send `MsgVote` transactions to cast their
vote on the proposal.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/gov/v1/tx.proto#L64-L72
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/gov/v1/tx.proto#L64-L72
**State modifications:**

6
x/group/internal/orm/spec/01_table.md
View File

@ -2,7 +2,7 @@
A table can be built given a `codec.ProtoMarshaler` model type, a prefix to access the underlying prefix store used to store table data as well as a `Codec` for marshalling/unmarshalling.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/group/internal/orm/table.go#L30-L36
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/group/internal/orm/table.go#L30-L36
In the prefix store, entities should be stored by an unique identifier called `RowID` which can be based either on an `uint64` auto-increment counter, string or dynamic size bytes.
Regular CRUD operations can be performed on a table, these methods take a `sdk.KVStore` as parameter to get the table prefix store.
@ -21,7 +21,7 @@ The `table` struct is private, so that we only have custom tables built on top o
`AutoUInt64Table` is a table type with an auto incrementing `uint64` ID.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/group/internal/orm/auto_uint64.go#L15-L18
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/group/internal/orm/auto_uint64.go#L15-L18
It's based on the `Sequence` struct which is a persistent unique key generator based on a counter encoded using 8 byte big endian.
@ -33,7 +33,7 @@ It's based on the `Sequence` struct which is a persistent unique key generator b
The model provided for creating a `PrimaryKeyTable` should implement the `PrimaryKeyed` interface:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/group/internal/orm/primary_key.go#L30-L44
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/group/internal/orm/primary_key.go#L30-L44
`PrimaryKeyFields()` method returns the list of key parts for a given object.
The primary key parts can be []byte, string, and `uint64` types.

8
x/group/internal/orm/spec/02_secondary_index.md
View File

@ -2,19 +2,19 @@
Secondary indexes can be used on `Indexable` [tables](01_table.md). Indeed, those tables implement the `Indexable` interface that provides a set of functions that can be called by indexes to register and interact with the tables, like callback functions that are called on entries creation, update or deletion to create, update or remove corresponding entries in the table secondary indexes.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/group/internal/orm/types.go#L88-L93
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/group/internal/orm/types.go#L88-L93
## MultiKeyIndex
A `MultiKeyIndex` is an index where multiple entries can point to the same underlying object.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/group/internal/orm/index.go#L26-L32
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/group/internal/orm/index.go#L26-L32
Internally, it uses an `Indexer` that manages the persistence of the index based on searchable keys and create/update/delete operations.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/group/internal/orm/index.go#L15-L20
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/group/internal/orm/index.go#L15-L20
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/group/internal/orm/indexer.go#L15-L19
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/group/internal/orm/indexer.go#L15-L19
The currently used implementation of an `indexer`, `Indexer`, relies on an `IndexerFunc` that should be provided when instantiating the index. Based on the source object, this function returns one or multiple index keys as `[]interface{}`. Such secondary index keys should be bytes, string or `uint64` in order to be handled properly by the [key codec](01_table.md#key-codec) which defines specific encoding for those types.
In the index prefix store, the keys are built based on the source object's `RowID` and its secondary index key(s) using the key codec and the values are set as empty bytes.

8
x/group/internal/orm/spec/03_iterator_pagination.md
View File

@ -6,15 +6,15 @@ Both [tables](01_table.md) and [secondary indexes](02_secondary_index.md) suppor
An `Iterator` allows iteration through a sequence of key value pairs.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/group/internal/orm/types.go#L77-L85
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/group/internal/orm/types.go#L77-L85
Tables rely on a `typeSafeIterator` that is used by `PrefixScan` and `ReversePrefixScan` `table` methods to iterate through a range of `RowID`s.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/group/internal/orm/table.go#L285-L290
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/group/internal/orm/table.go#L285-L290
Secondary indexes rely on an `indexIterator` that can strip the `RowID` from the full index key in order to get the underlying value in the table prefix store.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/group/internal/orm/index.go#L232-L238
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/group/internal/orm/index.go#L232-L238
Under the hood, both use a prefix store `Iterator` (alias for tm-db `Iterator`).
@ -23,6 +23,6 @@ Under the hood, both use a prefix store `Iterator` (alias for tm-db `Iterator`).
The `Paginate` function does pagination given an [`Iterator`](#iterator) and a `query.PageRequest`, and returns a `query.PageResponse`.
It unmarshals the results into the provided dest interface that should be a pointer to a slice of models.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/group/internal/orm/iterator.go#L102-L220
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/group/internal/orm/iterator.go#L102-L220
Secondary indexes have a `GetPaginated` method that returns an `Iterator` for the given searched secondary index key, starting from the `query.PageRequest` key if provided. It's important to note that this `query.PageRequest` key should be a `RowID` (that could have been returned by a previous paginated request). The returned `Iterator` can then be used with the `Paginate` function and the same `query.PageRequest`.

2
x/group/spec/01_concepts.md
View File

@ -46,7 +46,7 @@ and percentage. Any chain developer can extend upon these two, by creating
custom decision policies, as long as they adhere to the `DecisionPolicy`
interface:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/group/types.go#L27-L41
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/group/types.go#L27-L41
### Threshold decision policy

28
x/group/spec/03_messages.md
View File

@ -11,7 +11,7 @@ A new group can be created with the `MsgCreateGroup`, which has an admin address
The metadata has a maximum length that is chosen by the app developer, and
passed into the group keeper as a config.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/group/v1/tx.proto#L66-L78
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/group/v1/tx.proto#L66-L78
It's expected to fail if
@ -23,7 +23,7 @@ It's expected to fail if
Group members can be updated with the `UpdateGroupMembers`.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/group/v1/tx.proto#L87-L100
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/group/v1/tx.proto#L87-L100
In the list of `MemberUpdates`, an existing member can be removed by setting its weight to 0.
@ -36,7 +36,7 @@ It's expected to fail if:
The `UpdateGroupAdmin` can be used to update a group admin.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/group/v1/tx.proto#L105-L117
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/group/v1/tx.proto#L105-L117
It's expected to fail if the signer is not the admin of the group.
@ -44,7 +44,7 @@ It's expected to fail if the signer is not the admin of the group.
The `UpdateGroupMetadata` can be used to update a group metadata.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/group/v1/tx.proto#L122-L134
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/group/v1/tx.proto#L122-L134
It's expected to fail if:
@ -55,7 +55,7 @@ It's expected to fail if:
A new group policy can be created with the `MsgCreateGroupPolicy`, which has an admin address, a group id, a decision policy and some optional metadata.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/group/v1/tx.proto#L143-L160
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/group/v1/tx.proto#L143-L160
It's expected to fail if:
@ -67,7 +67,7 @@ It's expected to fail if:
A new group with policy can be created with the `MsgCreateGroupWithPolicy`, which has an admin address, a list of members, a decision policy, a `group_policy_as_admin` field to optionally set group and group policy admin with group policy address and some optional metadata for group and group policy.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/group/v1/tx.proto#L183-L206
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/group/v1/tx.proto#L183-L206
It's expected to fail for the same reasons as `Msg/CreateGroup` and `Msg/CreateGroupPolicy`.
@ -75,7 +75,7 @@ It's expected to fail for the same reasons as `Msg/CreateGroup` and `Msg/CreateG
The `UpdateGroupPolicyAdmin` can be used to update a group policy admin.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/group/v1/tx.proto#L169-L181
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/group/v1/tx.proto#L169-L181
It's expected to fail if the signer is not the admin of the group policy.
@ -83,7 +83,7 @@ It's expected to fail if the signer is not the admin of the group policy.
The `UpdateGroupPolicyDecisionPolicy` can be used to update a decision policy.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/group/v1/tx.proto#L219-L235
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/group/v1/tx.proto#L219-L235
It's expected to fail if:
@ -94,7 +94,7 @@ It's expected to fail if:
The `UpdateGroupPolicyMetadata` can be used to update a group policy metadata.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/group/v1/tx.proto#L240-L252
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/group/v1/tx.proto#L240-L252
It's expected to fail if:
@ -106,7 +106,7 @@ It's expected to fail if:
A new proposal can be created with the `MsgSubmitProposal`, which has a group policy account address, a list of proposers addresses, a list of messages to execute if the proposal is accepted and some optional metadata.
An optional `Exec` value can be provided to try to execute the proposal immediately after proposal creation. Proposers signatures are considered as yes votes in this case.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/group/v1/tx.proto#L275-L298
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/group/v1/tx.proto#L275-L298
It's expected to fail if:
@ -117,7 +117,7 @@ It's expected to fail if:
A proposal can be withdrawn using `MsgWithdrawProposal` which has an `address` (can be either a proposer or the group policy admin) and a `proposal_id` (which has to be withdrawn).
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/group/v1/tx.proto#L307-L316
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/group/v1/tx.proto#L307-L316
It's expected to fail if:
@ -129,7 +129,7 @@ It's expected to fail if:
A new vote can be created with the `MsgVote`, given a proposal id, a voter address, a choice (yes, no, veto or abstain) and some optional metadata.
An optional `Exec` value can be provided to try to execute the proposal immediately after voting.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/group/v1/tx.proto#L321-L339
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/group/v1/tx.proto#L321-L339
It's expected to fail if:
@ -140,7 +140,7 @@ It's expected to fail if:
A proposal can be executed with the `MsgExec`.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/group/v1/tx.proto#L341-L353
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/group/v1/tx.proto#L341-L353
The messages that are part of this proposal won't be executed if:
@ -151,7 +151,7 @@ The messages that are part of this proposal won't be executed if:
The `MsgLeaveGroup` allows group member to leave a group.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/group/v1/tx.proto#L362-L370
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/group/v1/tx.proto#L362-L370
It's expected to fail if:

4
x/mint/spec/02_state.md
View File

@ -10,7 +10,7 @@ The minter is a space for holding current inflation information.
* Minter: `0x00 -> ProtocolBuffer(minter)`
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/mint/v1beta1/mint.proto#L9-L23
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/mint/v1beta1/mint.proto#L9-L23
## Params
@ -19,4 +19,4 @@ it can be updated with governance or the address with authority.
* Params: `mint/params -> legacy_amino(params)`
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/mint/v1beta1/mint.proto#L25-L57
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/mint/v1beta1/mint.proto#L25-L57

2
x/slashing/spec/02_state.md
View File

@ -48,7 +48,7 @@ bonded validator. The `SignedBlocksWindow` parameter defines the size
The information stored for tracking validator liveness is as follows:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/slashing/v1beta1/slashing.proto#L12-L33
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/slashing/v1beta1/slashing.proto#L12-L33
## Params

18
x/staking/spec/01_state.md
View File

@ -22,7 +22,7 @@ it can be updated with governance or the address with authority.
* Params: `0x51 | ProtocolBuffer(Params)`
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/staking.proto#L285-L306
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/staking/v1beta1/staking.proto#L285-L306
## Validator
@ -75,9 +75,9 @@ is updated during the validator set update process which takes place in [`EndBlo
Each validator's state is stored in a `Validator` struct:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/staking.proto#L78-L127
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/staking/v1beta1/staking.proto#L78-L127
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/staking.proto#L24-L76
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/staking/v1beta1/staking.proto#L24-L76
## Delegation
@ -91,7 +91,7 @@ funds are held in a `Delegation` data structure. It is owned by one
delegator, and is associated with the shares for one validator. The sender of
the transaction is the owner of the bond.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/staking.proto#L187-L205
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/staking/v1beta1/staking.proto#L187-L205
### Delegator Shares
@ -130,7 +130,7 @@ slashed.
A UnbondingDelegation object is created every time an unbonding is initiated.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/staking.proto#L207-L220
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/staking/v1beta1/staking.proto#L207-L220
## Redelegation
@ -158,7 +158,7 @@ A redelegation object is created every time a redelegation occurs. To prevent
* and, the (re)delegator is attempting to create a _new_ redelegation
where the source validator for this new redelegation is `Validator X`.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/staking.proto#L245-L283
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/staking/v1beta1/staking.proto#L245-L283
## Queues
@ -180,7 +180,7 @@ delegations queue is kept.
* UnbondingDelegation: `0x41 | format(time) -> []DVPair`
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/staking.proto#L151-L161
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/staking/v1beta1/staking.proto#L151-L161
### RedelegationQueue
@ -189,7 +189,7 @@ kept.
* RedelegationQueue: `0x42 | format(time) -> []DVVTriplet`
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/staking.proto#L168-L179
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/staking/v1beta1/staking.proto#L168-L179
### ValidatorQueue
@ -208,7 +208,7 @@ that multiple validators exist in the queue at the same location.
HistoricalInfo objects are stored and pruned at each block such that the staking keeper persists
the `n` most recent historical info defined by staking module parameter: `HistoricalEntries`.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/staking.proto#L15-L22
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/staking/v1beta1/staking.proto#L15-L22
At each BeginBlock, the staking keeper will persist the current Header and the Validators that committed
the current block in a `HistoricalInfo` object. The Validators are sorted on their address to ensure that

28
x/staking/spec/03_messages.md
View File

@ -11,9 +11,9 @@ In this section we describe the processing of the staking messages and the corre
A validator is created using the `MsgCreateValidator` message.
The validator must be created with an initial delegation from the operator.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/tx.proto#L18-L19
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/staking/v1beta1/tx.proto#L18-L19
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/tx.proto#L43-L65
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/staking/v1beta1/tx.proto#L43-L65
This message is expected to fail if:
@ -36,9 +36,9 @@ in the first end-block.
The `Description`, `CommissionRate` of a validator can be updated using the
`MsgEditValidator` message.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/tx.proto#L21-L22
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/staking/v1beta1/tx.proto#L21-L22
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/tx.proto#L70-L88
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/staking/v1beta1/tx.proto#L70-L88
This message is expected to fail if:
@ -55,9 +55,9 @@ Within this message the delegator provides coins, and in return receives
some amount of their validator's (newly created) delegator-shares that are
assigned to `Delegation.Shares`.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/tx.proto#L24-L26
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/staking/v1beta1/tx.proto#L24-L26
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/tx.proto#L93-L104
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/staking/v1beta1/tx.proto#L93-L104
This message is expected to fail if:
@ -87,13 +87,13 @@ will not be added to the power index until it is unjailed.
The `MsgUndelegate` message allows delegators to undelegate their tokens from
validator.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/tx.proto#L32-L34
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/staking/v1beta1/tx.proto#L32-L34
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/tx.proto#L128-L139
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/staking/v1beta1/tx.proto#L128-L139
This message returns a response containing the completion time of the undelegation:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/tx.proto#L128-L144
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/staking/v1beta1/tx.proto#L128-L144
This message is expected to fail if:
@ -120,9 +120,9 @@ When this message is processed the following actions occur:
The `MsgCancelUnbondingDelegation` message allows delegators to cancel the `unbondingDelegation` entry and deleagate back to a previous validator.
+++ hhttps://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/tx.proto#L36-L40
+++ hhttps://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/staking/v1beta1/tx.proto#L36-L40
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/tx.proto#L146-L165
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/staking/v1beta1/tx.proto#L146-L165
This message is expected to fail if:
@ -143,13 +143,13 @@ The redelegation command allows delegators to instantly switch validators. Once
the unbonding period has passed, the redelegation is automatically completed in
the EndBlocker.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/tx.proto#L28-L30
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/staking/v1beta1/tx.proto#L28-L30
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/tx.proto#L109-L121
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/staking/v1beta1/tx.proto#L109-L121
This message returns a response containing the completion time of the redelegation:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/tx.proto#L123-L126
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/staking/v1beta1/tx.proto#L123-L126
This message is expected to fail if:

4
x/upgrade/spec/01_concepts.md
View File

@ -82,7 +82,7 @@ This proposal prescribes to the standard governance process. If the proposal pas
the `Plan`, which targets a specific `Handler`, is persisted and scheduled. The
upgrade can be delayed or hastened by updating the `Plan.Height` in a new proposal.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/upgrade/v1beta1/tx.proto#L24-L36
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/upgrade/v1beta1/tx.proto#L24-L36
### Cancelling Upgrade Proposals
@ -92,7 +92,7 @@ remove the scheduled upgrade `Plan`.
Of course this requires that the upgrade was known to be a bad idea well before the
upgrade itself, to allow time for a vote.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/upgrade/v1beta1/tx.proto#L43-L51
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/upgrade/v1beta1/tx.proto#L43-L51
If such a possibility is desired, the upgrade height is to be
`2 * (VotingPeriod + DepositPeriod) + (SafetyDelta)` from the beginning of the