docs: update sdk & tm version links in docs (#12976)
* docs: update sdk & tm version links in docs * revert unrelated change
This commit is contained in:
Julien Robert
+11
-11
@@ -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`
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user