From b31e0bcaf46e39a3cfe60b29d728f1008059eeb9 Mon Sep 17 00:00:00 2001 From: Cordt Date: Thu, 23 Oct 2025 19:22:20 -0600 Subject: [PATCH 01/10] fix: update broken internal links across EVM and SDK documentation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Fix EVM docs: chain-customization-checklist → quick-start - Fix EVM docs: runtime-and-launch → node-configuration - Add missing /docs prefix to VM module href links - Fix SDK docs: add missing /learn/ prefix to beginner/advanced paths - Fix SDK docs: add missing /build/ prefix to modules/architecture/tooling - Fix SDK docs: update module paths to include /build/modules/ - Fix SDK docs: rename overview-app → app-anatomy Only links to pages in navigation (per docs.json) 74 files changed across EVM v0.5.0/next and SDK v0.47/v0.50/v0.53 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude --- .../concepts/predeployed-contracts.mdx | 4 +- .../build-a-chain/build-a-chain_v.mdx | 2 +- .../build-a-chain/quick-start.mdx | 2 +- .../build-a-chain/using-local-node.mdx | 2 +- .../smart-contracts/precompiles/overview.mdx | 2 +- .../concepts/predeployed-contracts.mdx | 4 +- .../cosmos-sdk/modules/feemarket.mdx | 2 +- .../documentation/cosmos-sdk/modules/vm.mdx | 2 +- .../predeployed-contracts.mdx | 2 +- .../smart-contracts/precompiles/overview.mdx | 2 +- .../build/building-modules/depinject.mdx | 4 +- .../build/building-modules/msg-services.mdx | 2 +- .../build/building-modules/structure.mdx | 2 +- .../v0.47/build/building-modules/testing.mdx | 2 +- .../v0.47/build/building-modules/upgrade.mdx | 2 +- docs/sdk/v0.47/build/migrations/upgrading.mdx | 2 +- docs/sdk/v0.47/build/modules/auth/aut.mdx | 2 +- docs/sdk/v0.47/build/modules/authz/README.mdx | 2 +- docs/sdk/v0.47/build/rfc/README.mdx | 2 +- docs/sdk/v0.47/learn/advanced/baseapp.mdx | 40 +++++++------- docs/sdk/v0.47/learn/advanced/cli.mdx | 2 +- docs/sdk/v0.47/learn/advanced/context.mdx | 6 +-- docs/sdk/v0.47/learn/advanced/encoding.mdx | 4 +- docs/sdk/v0.47/learn/advanced/events.mdx | 4 +- docs/sdk/v0.47/learn/advanced/node.mdx | 6 +-- .../sdk/v0.47/learn/advanced/transactions.mdx | 8 +-- docs/sdk/v0.47/learn/intro/sdk-design.mdx | 2 +- docs/sdk/v0.50/build/architecture/PROCESS.mdx | 2 +- docs/sdk/v0.50/build/architecture/README.mdx | 2 +- .../v0.50/build/architecture/adr-template.mdx | 2 +- .../v0.50/build/building-apps/app-mempool.mdx | 6 +-- .../v0.50/build/building-modules/genesis.mdx | 2 +- .../building-modules/module-interfaces.mdx | 4 +- .../build/building-modules/msg-services.mdx | 4 +- .../building-modules/protobuf-annotations.mdx | 2 +- .../build/building-modules/query-services.mdx | 2 +- docs/sdk/v0.50/build/migrations/intro.mdx | 2 +- docs/sdk/v0.50/build/modules/auth/authre.mdx | 2 +- docs/sdk/v0.50/build/modules/authz/README.mdx | 2 +- .../v0.50/build/modules/evidence/README.mdx | 2 +- .../v0.50/build/modules/feegrant/README.mdx | 2 +- docs/sdk/v0.50/build/modules/gov/README.mdx | 4 +- docs/sdk/v0.50/build/modules/group/README.mdx | 4 +- .../v0.50/build/modules/slashing/README.mdx | 2 +- docs/sdk/v0.50/build/packages/README.mdx | 2 +- docs/sdk/v0.50/build/rfc.mdx | 2 +- docs/sdk/v0.50/build/rfc/PROCESS.mdx | 2 +- docs/sdk/v0.50/build/rfc/README.mdx | 6 +-- docs/sdk/v0.50/build/rfc/rfc/PROCESS.mdx | 2 +- docs/sdk/v0.50/build/rfc/rfc/README.mdx | 6 +-- docs/sdk/v0.50/build/spec/README.mdx | 2 +- docs/sdk/v0.50/build/tooling/README.mdx | 2 +- docs/sdk/v0.50/learn/advanced/baseapp.mdx | 54 +++++++++---------- docs/sdk/v0.50/learn/advanced/cli.mdx | 8 +-- docs/sdk/v0.50/learn/advanced/context.mdx | 20 +++---- docs/sdk/v0.50/learn/advanced/encoding.mdx | 4 +- docs/sdk/v0.50/learn/advanced/events.mdx | 14 ++--- docs/sdk/v0.50/learn/advanced/grpc_rest.mdx | 4 +- docs/sdk/v0.50/learn/advanced/node.mdx | 8 +-- docs/sdk/v0.50/learn/advanced/store.mdx | 16 +++--- .../sdk/v0.50/learn/advanced/transactions.mdx | 10 ++-- docs/sdk/v0.50/learn/beginner/app-anatomy.mdx | 6 +-- .../v0.50/learn/beginner/query-lifecycle.mdx | 4 +- .../sdk/v0.50/learn/beginner/tx-lifecycle.mdx | 8 +-- docs/sdk/v0.50/learn/intro/sdk-design.mdx | 2 +- docs/sdk/v0.53/build/architecture/PROCESS.mdx | 2 +- docs/sdk/v0.53/build/architecture/README.mdx | 2 +- .../v0.53/build/building-apps/app-go-di.mdx | 2 +- .../sdk/v0.53/build/building-apps/runtime.mdx | 4 +- docs/sdk/v0.53/build/rfc.mdx | 2 +- docs/sdk/v0.53/learn/advanced/baseapp.mdx | 18 +++---- docs/sdk/v0.53/learn/advanced/node.mdx | 2 +- docs/sdk/v0.53/learn/advanced/store.mdx | 2 +- docs/sdk/v0.53/learn/intro/sdk-design.mdx | 2 +- 74 files changed, 190 insertions(+), 190 deletions(-) diff --git a/docs/evm/next/documentation/concepts/predeployed-contracts.mdx b/docs/evm/next/documentation/concepts/predeployed-contracts.mdx index 50694bb3..d44aa179 100644 --- a/docs/evm/next/documentation/concepts/predeployed-contracts.mdx +++ b/docs/evm/next/documentation/concepts/predeployed-contracts.mdx @@ -89,7 +89,7 @@ Predeployed contracts are configured during chain genesis through the `preinstal The default preinstalls are defined in the codebase at [`x/vm/types/preinstall.go:13-39`](https://github.com/cosmos/evm/blob/main/x/vm/types/preinstall.go#L13-L39). For complete guidance on customizing preinstalls, see: - [Building Your Chain Guide](/docs/evm/next/documentation/getting-started/build-a-chain/overview#configuring-predeployed-contracts) - Quick start configuration - [Predeployed Contracts Integration](/docs/evm/next/documentation/getting-started/build-a-chain/additional-configuration/predeployed-contracts) - Detailed implementation guide -- [Chain Customization Checklist](/docs/evm/next/documentation/getting-started/build-a-chain/chain-customization-checklist) - Step-by-step setup +- [Chain Customization Checklist](/docs/evm/next/documentation/getting-started/build-a-chain/configuration-reference) - Step-by-step setup ## Common Examples @@ -113,5 +113,5 @@ For comprehensive information on each contract including usage examples and inte ## Implementation Guides - [Predeployed Contracts Integration](/docs/evm/next/documentation/getting-started/build-a-chain/additional-configuration/predeployed-contracts) - Detailed technical guide for deploying and managing preinstalled contracts -- [Chain Customization Checklist](/docs/evm/next/documentation/getting-started/build-a-chain/chain-customization-checklist) - Step-by-step setup checklist +- [Chain Customization Checklist](/docs/evm/next/documentation/getting-started/build-a-chain/configuration-reference) - Step-by-step setup checklist - [Individual Contract Documentation](/docs/evm/next/documentation/smart-contracts/predeployed-contracts/overview) - Usage examples and integration patterns for each contract \ No newline at end of file diff --git a/docs/evm/next/documentation/getting-started/build-a-chain/build-a-chain_v.mdx b/docs/evm/next/documentation/getting-started/build-a-chain/build-a-chain_v.mdx index 2d62bc1f..c3b0b537 100644 --- a/docs/evm/next/documentation/getting-started/build-a-chain/build-a-chain_v.mdx +++ b/docs/evm/next/documentation/getting-started/build-a-chain/build-a-chain_v.mdx @@ -195,7 +195,7 @@ After adding the network: ### Recommended Reading - + EVM execution and parameter configuration diff --git a/docs/evm/next/documentation/getting-started/build-a-chain/quick-start.mdx b/docs/evm/next/documentation/getting-started/build-a-chain/quick-start.mdx index 330f16b2..1a07bc56 100644 --- a/docs/evm/next/documentation/getting-started/build-a-chain/quick-start.mdx +++ b/docs/evm/next/documentation/getting-started/build-a-chain/quick-start.mdx @@ -228,7 +228,7 @@ For detailed setup and configuration instructions, see the comprehensive guides ### Recommended Reading - + EVM execution and parameter configuration diff --git a/docs/evm/next/documentation/getting-started/build-a-chain/using-local-node.mdx b/docs/evm/next/documentation/getting-started/build-a-chain/using-local-node.mdx index c9ebe5ac..f5c913fb 100644 --- a/docs/evm/next/documentation/getting-started/build-a-chain/using-local-node.mdx +++ b/docs/evm/next/documentation/getting-started/build-a-chain/using-local-node.mdx @@ -256,7 +256,7 @@ Deploy standard contracts at genesis for Create2, Multicall3, Permit2, and Safe ### Recommended Reading - + EVM execution and parameter configuration diff --git a/docs/evm/next/documentation/smart-contracts/precompiles/overview.mdx b/docs/evm/next/documentation/smart-contracts/precompiles/overview.mdx index b45e3de6..75cdf902 100644 --- a/docs/evm/next/documentation/smart-contracts/precompiles/overview.mdx +++ b/docs/evm/next/documentation/smart-contracts/precompiles/overview.mdx @@ -78,7 +78,7 @@ Precompiles must be enabled in the genesis file to be available on the network. ``` -For complete genesis configuration including EVM and fee market parameters, see the [Node Configuration](/docs/evm/next/documentation/getting-started/runtime-and-launch#genesis-json) reference. +For complete genesis configuration including EVM and fee market parameters, see the [Node Configuration](/docs/evm/next/documentation/getting-started/network-operators/node-configuration) reference. ## v0.5.0 Breaking Changes diff --git a/docs/evm/v0.5.0/documentation/concepts/predeployed-contracts.mdx b/docs/evm/v0.5.0/documentation/concepts/predeployed-contracts.mdx index 5ec3bc2d..7b4b9ed7 100644 --- a/docs/evm/v0.5.0/documentation/concepts/predeployed-contracts.mdx +++ b/docs/evm/v0.5.0/documentation/concepts/predeployed-contracts.mdx @@ -89,7 +89,7 @@ Predeployed contracts are configured during chain genesis through the `preinstal The default preinstalls are defined in the codebase at [`x/vm/types/preinstall.go:13-39`](https://github.com/cosmos/evm/blob/main/x/vm/types/preinstall.go#L13-L39). For complete guidance on customizing preinstalls, see: - [Building Your Chain Guide](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/overview#configuring-predeployed-contracts) - Quick start configuration - [Predeployed Contracts Integration](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/additional-configuration/predeployed-contracts) - Detailed implementation guide -- [Chain Customization Checklist](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/chain-customization-checklist) - Step-by-step setup +- [Chain Customization Checklist](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start) - Step-by-step setup ## Common Examples @@ -113,5 +113,5 @@ For comprehensive information on each contract including usage examples and inte ## Implementation Guides - [Predeployed Contracts Integration](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/additional-configuration/predeployed-contracts) - Detailed technical guide for deploying and managing preinstalled contracts -- [Chain Customization Checklist](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/chain-customization-checklist) - Step-by-step setup checklist +- [Chain Customization Checklist](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start) - Step-by-step setup checklist - [Individual Contract Documentation](/docs/evm/v0.5.0/documentation/smart-contracts/predeployed-contracts/overview) - Usage examples and integration patterns for each contract \ No newline at end of file diff --git a/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/feemarket.mdx b/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/feemarket.mdx index 0921965f..28854bfc 100644 --- a/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/feemarket.mdx +++ b/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/feemarket.mdx @@ -848,7 +848,7 @@ evmd tx gov submit-proposal param-change proposal.json --from validator --chain- ## Related Documentation - [Building Your Chain Guide](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/overview) - Main configuration walkthrough -- [Chain Customization Checklist](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/chain-customization-checklist) - Complete parameter checklist +- [Chain Customization Checklist](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start) - Complete parameter checklist - [VM Module](/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/vm) - EVM configuration - [Token Configuration Guide](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/pre-genesis-and-genesis-setup) - Token economics setup - [EIP-1559 Specification](https://eips.ethereum.org/EIPS/eip-1559) - Original Ethereum proposal diff --git a/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/vm.mdx b/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/vm.mdx index 86f62dbf..f48442df 100644 --- a/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/vm.mdx +++ b/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/vm.mdx @@ -574,7 +574,7 @@ Or in genesis.json directly: ## Related Documentation - [Building Your Chain Guide](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/overview) - Main configuration walkthrough -- [Chain Customization Checklist](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/chain-customization-checklist) - Complete parameter checklist +- [Chain Customization Checklist](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start) - Complete parameter checklist - [Token Configuration Guide](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/pre-genesis-and-genesis-setup) - Token decimals and evm_denom setup - [Fee Market Module](/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/feemarket) - EIP-1559 fee configuration - [local_node.sh](https://github.com/cosmos/evm/blob/main/local_node.sh) - Reference implementation diff --git a/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/additional-configuration/predeployed-contracts.mdx b/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/additional-configuration/predeployed-contracts.mdx index edfeb95c..f8286036 100644 --- a/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/additional-configuration/predeployed-contracts.mdx +++ b/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/additional-configuration/predeployed-contracts.mdx @@ -366,5 +366,5 @@ preinstalls := append(evmtypes.DefaultPreinstalls, customPreinstall) ### Cosmos EVM Resources - [VM Module Reference](/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/vm) - Complete VM module configuration -- [Chain Customization Checklist](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/chain-customization-checklist) - Step-by-step setup guide +- [Chain Customization Checklist](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start) - Step-by-step setup guide - [Configuration Parameters](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/configuration-parameters) - All genesis parameters explained \ No newline at end of file diff --git a/docs/evm/v0.5.0/documentation/smart-contracts/precompiles/overview.mdx b/docs/evm/v0.5.0/documentation/smart-contracts/precompiles/overview.mdx index 54cb88b2..38feccc5 100644 --- a/docs/evm/v0.5.0/documentation/smart-contracts/precompiles/overview.mdx +++ b/docs/evm/v0.5.0/documentation/smart-contracts/precompiles/overview.mdx @@ -78,7 +78,7 @@ Precompiles must be enabled in the genesis file to be available on the network. ``` -For complete genesis configuration including EVM and fee market parameters, see the [Node Configuration](/docs/evm/v0.5.0/documentation/getting-started/runtime-and-launch#genesis-json) reference. +For complete genesis configuration including EVM and fee market parameters, see the [Node Configuration](/docs/evm/v0.5.0/documentation/getting-started/network-operators/node-configuration) reference. ## v0.5.0 Breaking Changes diff --git a/docs/sdk/v0.47/build/building-modules/depinject.mdx b/docs/sdk/v0.47/build/building-modules/depinject.mdx index 6844fae3..6af607a3 100644 --- a/docs/sdk/v0.47/build/building-modules/depinject.mdx +++ b/docs/sdk/v0.47/build/building-modules/depinject.mdx @@ -6,11 +6,11 @@ title: Modules depinject-ready ### Pre-requisite Readings -* [Depinject Documentation](/docs/sdk/v0.47/packages/depinject) +* [Depinject Documentation](/docs/sdk/v0.47/build/packages/depinject) -[`depinject`](/docs/sdk/v0.47/packages/depinject) is used to wire any module in `app.go`. +[`depinject`](/docs/sdk/v0.47/build/packages/depinject) is used to wire any module in `app.go`. All core modules are already configured to support dependency injection. To work with `depinject` a module must define its configuration and requirements so that `depinject` can provide the right dependencies. diff --git a/docs/sdk/v0.47/build/building-modules/msg-services.mdx b/docs/sdk/v0.47/build/building-modules/msg-services.mdx index b3c1f868..11ec862c 100644 --- a/docs/sdk/v0.47/build/building-modules/msg-services.mdx +++ b/docs/sdk/v0.47/build/building-modules/msg-services.mdx @@ -20,7 +20,7 @@ A Protobuf `Msg` service processes [messages](/docs/sdk/v0.47/build/building-mod Each module should define a Protobuf `Msg` service, which will be responsible for processing requests (implementing `sdk.Msg`) and returning responses. -As further described in [ADR 031](/docs/sdk/v0.47/architecture/adr-031-msg-service), this approach has the advantage of clearly specifying return types and generating server and client code. +As further described in [ADR 031](/docs/sdk/v0.47/build/architecture/adr-031-msg-service), this approach has the advantage of clearly specifying return types and generating server and client code. 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: diff --git a/docs/sdk/v0.47/build/building-modules/structure.mdx b/docs/sdk/v0.47/build/building-modules/structure.mdx index 117dc2b4..96043d12 100644 --- a/docs/sdk/v0.47/build/building-modules/structure.mdx +++ b/docs/sdk/v0.47/build/building-modules/structure.mdx @@ -79,7 +79,7 @@ x/{module_name} * `keeper/`: The module's `Keeper` and `MsgServer` implementation. * `module/`: The module's `AppModule` and `AppModuleBasic` implementation. * `abci.go`: The module's `BeginBlocker` and `EndBlocker` implementations (this file is only required if `BeginBlocker` and/or `EndBlocker` need to be defined). - * `autocli.go`: The module [autocli](/docs/sdk/v0.47/tooling/autocli) options. + * `autocli.go`: The module [autocli](/docs/sdk/v0.47/build/tooling/autocli) options. * `simulation/`: The module's [simulation](/docs/sdk/v0.47/build/building-modules/simulator) package defines functions used by the blockchain simulator application (`simapp`). * `REAMDE.md`: The module's specification documents outlining important concepts, state storage structure, and message and event type definitions. Learn more how to write module specs in the [spec guidelines](/docs/sdk/v0.47/spec/SPEC_MODULE). * The root directory includes type definitions for messages, events, and genesis state, including the type definitions generated by Protocol Buffers. diff --git a/docs/sdk/v0.47/build/building-modules/testing.mdx b/docs/sdk/v0.47/build/building-modules/testing.mdx index 6b98600c..2797f793 100644 --- a/docs/sdk/v0.47/build/building-modules/testing.mdx +++ b/docs/sdk/v0.47/build/building-modules/testing.mdx @@ -1500,7 +1500,7 @@ testdata.DeterministicIterations(suite.ctx, suite.Require(), req, suite.queryCli ## Simulations -Simulations uses as well a minimal application, built with [`depinject`](/docs/sdk/v0.47/packages/depinject): +Simulations uses as well a minimal application, built with [`depinject`](/docs/sdk/v0.47/build/packages/depinject): You can as well use the `AppConfig` `configurator` for creating an `AppConfig` [inline](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/slashing/app_test.go#L54-L62). There is no difference between those two ways, use whichever you prefer. diff --git a/docs/sdk/v0.47/build/building-modules/upgrade.mdx b/docs/sdk/v0.47/build/building-modules/upgrade.mdx index a50bb777..319279c0 100644 --- a/docs/sdk/v0.47/build/building-modules/upgrade.mdx +++ b/docs/sdk/v0.47/build/building-modules/upgrade.mdx @@ -123,4 +123,4 @@ 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.47.0-rc1/x/bank/migrations/v2/store.go#L52-L73). 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](/docs/sdk/v0.47/architecture/adr-028-public-key-addresses). +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.47.0-rc1/x/bank/migrations/v2/store.go#L52-L73). 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](/docs/sdk/v0.47/build/architecture/adr-028-public-key-addresses). diff --git a/docs/sdk/v0.47/build/migrations/upgrading.mdx b/docs/sdk/v0.47/build/migrations/upgrading.mdx index 6f000f45..63772832 100644 --- a/docs/sdk/v0.47/build/migrations/upgrading.mdx +++ b/docs/sdk/v0.47/build/migrations/upgrading.mdx @@ -330,7 +330,7 @@ This allows you to remove the replace directive `replace github.com/gogo/protobu Please use the `ghcr.io/cosmos/proto-builder` image (version `>=` `0.11.5`) for generating protobuf files. -See which buf commit for `cosmos/cosmos-sdk` to pin in your `buf.yaml` file [here](/docs/sdk/v0.47/tooling). +See which buf commit for `cosmos/cosmos-sdk` to pin in your `buf.yaml` file [here](/docs/sdk/v0.47/build/tooling). #### Gogoproto Import Paths diff --git a/docs/sdk/v0.47/build/modules/auth/aut.mdx b/docs/sdk/v0.47/build/modules/auth/aut.mdx index 4a8728a8..a812021c 100644 --- a/docs/sdk/v0.47/build/modules/auth/aut.mdx +++ b/docs/sdk/v0.47/build/modules/auth/aut.mdx @@ -31,7 +31,7 @@ This module is used in the Cosmos Hub. ## Concepts -**Note:** The auth module is different from the [authz module](/docs/sdk/v0.47/modules/authz/). +**Note:** The auth module is different from the [authz module](/docs/sdk/v0.47/build/modules/auth/authz/). The differences are: diff --git a/docs/sdk/v0.47/build/modules/authz/README.mdx b/docs/sdk/v0.47/build/modules/authz/README.mdx index 9c527504..c3dbdd21 100644 --- a/docs/sdk/v0.47/build/modules/authz/README.mdx +++ b/docs/sdk/v0.47/build/modules/authz/README.mdx @@ -36,7 +36,7 @@ on behalf of one account to other accounts. The design is defined in the [ADR 03 A *grant* is an allowance to execute a Msg by the grantee on behalf of the granter. Authorization is an interface that must be implemented by a concrete authorization logic to validate and execute grants. Authorizations are extensible and can be defined for any Msg service method even outside of the module where the Msg method is defined. See the `SendAuthorization` example in the next section for more details. -**Note:** The authz module is different from the [auth (authentication)](/docs/sdk/v0.47/modules/auth/) module that is responsible for specifying the base transaction and account types. +**Note:** The authz module is different from the [auth (authentication)](/docs/sdk/v0.47/build/modules/auth/auth/) module that is responsible for specifying the base transaction and account types. ```go expandable package authz diff --git a/docs/sdk/v0.47/build/rfc/README.mdx b/docs/sdk/v0.47/build/rfc/README.mdx index 638125f1..5a67e764 100644 --- a/docs/sdk/v0.47/build/rfc/README.mdx +++ b/docs/sdk/v0.47/build/rfc/README.mdx @@ -15,7 +15,7 @@ discussion that might otherwise only be recorded in an ad-hoc way (for example, via gists or Google docs) that are difficult to discover for someone after the fact. An RFC *may* give rise to more specific architectural *decisions* for the Cosmos SDK, but those decisions must be recorded separately in -[Architecture Decision Records (ADR)](/docs/sdk/v0.47/architecture/README). +[Architecture Decision Records (ADR)](/docs/sdk/v0.47/build/architecture/README). As a rule of thumb, if you can articulate a specific question that needs to be answered, write an ADR. If you need to explore the topic and get input from diff --git a/docs/sdk/v0.47/learn/advanced/baseapp.mdx b/docs/sdk/v0.47/learn/advanced/baseapp.mdx index 4fe4c3c2..df569aa5 100644 --- a/docs/sdk/v0.47/learn/advanced/baseapp.mdx +++ b/docs/sdk/v0.47/learn/advanced/baseapp.mdx @@ -11,8 +11,8 @@ This document describes `BaseApp`, the abstraction that implements the core func ### Pre-requisite Readings -* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.47/beginner/overview-app) -* [Lifecycle of a Cosmos SDK transaction](/docs/sdk/v0.47/beginner/tx-lifecycle) +* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.47/learn/beginner/app-anatomy) +* [Lifecycle of a Cosmos SDK transaction](/docs/sdk/v0.47/learn/beginner/tx-lifecycle) @@ -1253,8 +1253,8 @@ First, the important parameters that are initialized during the bootstrapping of * [`AnteHandler`](#antehandler): This handler is used to handle signature verification, fee payment, and other pre-message execution checks when a transaction is received. It's executed during [`CheckTx/RecheckTx`](#checktx) and [`DeliverTx`](#delivertx). -* [`InitChainer`](/docs/sdk/v0.47/beginner/overview-app#initchainer), - [`BeginBlocker` and `EndBlocker`](/docs/sdk/v0.47/beginner/overview-app#beginblocker-and-endblocker): These are +* [`InitChainer`](/docs/sdk/v0.47/learn/beginner/app-anatomy#initchainer), + [`BeginBlocker` and `EndBlocker`](/docs/sdk/v0.47/learn/beginner/app-anatomy#beginblocker-and-endblocker): These are the functions executed when the application receives the `InitChain`, `BeginBlock` and `EndBlock` ABCI messages from the underlying CometBFT engine. @@ -1280,7 +1280,7 @@ Finally, a few more important parameters: `minGasPrices` (e.g. if `minGasPrices == 1uatom,1photon`, the `gas-price` of the transaction must be greater than `1uatom` OR `1photon`). * `appVersion`: Version of the application. It is set in the - [application's constructor function](/docs/sdk/v0.47/beginner/overview-app#constructor-function). + [application's constructor function](/docs/sdk/v0.47/learn/beginner/app-anatomy#constructor-function). ## Constructor @@ -1402,13 +1402,13 @@ When messages and queries are received by the application, they must be routed t The [default `msgServiceRouter` included in `BaseApp`](https://github.com/cosmos/cosmos-sdk/blob/v0.47.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.47.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 application's `msgServiceRouter` is initialized with all the routes using the application's [module manager](/docs/sdk/v0.47//build/building-modules/module-manager#manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.47/beginner/overview-app#constructor-function). +The application's `msgServiceRouter` is initialized with all the routes using the application's [module manager](/docs/sdk/v0.47//build/building-modules/module-manager#manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.47/learn/beginner/app-anatomy#constructor-function). ### gRPC Query Router Similar to `sdk.Msg`s, [`queries`](/docs/sdk/v0.47//build/building-modules/messages-and-queries#queries) need to be routed to the appropriate module's [`Query` service](/docs/sdk/v0.47//build/building-modules/query-services). To do so, `BaseApp` holds a `grpcQueryRouter`, which maps modules' fully-qualified service methods (`string`, defined in their Protobuf `Query` gRPC) to their `QueryServer` implementation. The `grpcQueryRouter` is called during the initial stages of query processing, which can be either by directly sending a gRPC query to the gRPC endpoint, or via the [`Query` ABCI message](#query) on the CometBFT RPC endpoint. -Just like the `msgServiceRouter`, the `grpcQueryRouter` is initialized with all the query routes using the application's [module manager](/docs/sdk/v0.47//build/building-modules/module-manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.47/beginner/overview-app#app-constructor). +Just like the `msgServiceRouter`, the `grpcQueryRouter` is initialized with all the query routes using the application's [module manager](/docs/sdk/v0.47//build/building-modules/module-manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.47/learn/beginner/app-anatomy#app-constructor). ## Main ABCI 1.0 Messages @@ -1494,16 +1494,16 @@ to do the following checks: first, as *stateless* checks are less computationally expensive than *stateful* checks. If `ValidateBasic()` fail, `CheckTx` returns before running *stateful* checks, which saves resources. This check is still performed for messages that have not yet migrated to the new message validation mechanism defined in [RFC 001](https://docs.cosmos.network/main/rfc/rfc-001-tx-validation) and still have a `ValidateBasic()` method. -3. Perform non-module related *stateful* checks on the [account](/docs/sdk/v0.47/beginner/accounts). This step is mainly about checking +3. Perform non-module related *stateful* checks on the [account](/docs/sdk/v0.47/learn/beginner/accounts). This step is mainly about checking that the `sdk.Msg` signatures are valid, that enough fees are provided and that the sending account - has enough funds to pay for said fees. Note that no precise [`gas`](/docs/sdk/v0.47/beginner/gas-fees) counting occurs here, - as `sdk.Msg`s are not processed. Usually, the [`AnteHandler`](/docs/sdk/v0.47/beginner/gas-fees#antehandler) will check that the `gas` provided + has enough funds to pay for said fees. Note that no precise [`gas`](/docs/sdk/v0.47/learn/beginner/gas-fees) counting occurs here, + as `sdk.Msg`s are not processed. Usually, the [`AnteHandler`](/docs/sdk/v0.47/learn/beginner/gas-fees#antehandler) will check that the `gas` provided with the transaction is superior to a minimum reference gas amount based on the raw transaction size, in order to avoid spam with transactions that provide 0 gas. `CheckTx` does **not** process `sdk.Msg`s - they only need to be processed when the canonical state need to be updated, which happens during `DeliverTx`. -Steps 2. and 3. are performed by the [`AnteHandler`](/docs/sdk/v0.47/beginner/gas-fees#antehandler) in the [`RunTx()`](#runtx) +Steps 2. and 3. are performed by the [`AnteHandler`](/docs/sdk/v0.47/learn/beginner/gas-fees#antehandler) in the [`RunTx()`](#runtx) function, which `CheckTx()` calls with the `runTxModeCheck` mode. During each step of `CheckTx()`, a special [volatile state](#state-updates) called `checkState` is updated. This state is used to keep track of the temporary changes triggered by the `CheckTx()` calls of each transaction without modifying @@ -2162,7 +2162,7 @@ At any point, if `GasConsumed > GasWanted`, the function returns with `Code != 0 `RunTx` is called from `CheckTx`/`DeliverTx` to handle the transaction, with `runTxModeCheck` or `runTxModeDeliver` as parameter to differentiate between the two modes of execution. Note that when `RunTx` receives a transaction, it has already been decoded. -The first thing `RunTx` does upon being called is to retrieve the `context`'s `CacheMultiStore` by calling the `getContextForTx()` function with the appropriate mode (either `runTxModeCheck` or `runTxModeDeliver`). This `CacheMultiStore` is a branch of the main store, with cache functionality (for query requests), instantiated during `BeginBlock` for `DeliverTx` and during the `Commit` of the previous block for `CheckTx`. After that, two `defer func()` are called for [`gas`](/docs/sdk/v0.47/beginner/gas-fees) management. They are executed when `runTx` returns and make sure `gas` is actually consumed, and will throw errors, if any. +The first thing `RunTx` does upon being called is to retrieve the `context`'s `CacheMultiStore` by calling the `getContextForTx()` function with the appropriate mode (either `runTxModeCheck` or `runTxModeDeliver`). This `CacheMultiStore` is a branch of the main store, with cache functionality (for query requests), instantiated during `BeginBlock` for `DeliverTx` and during the `Commit` of the previous block for `CheckTx`. After that, two `defer func()` are called for [`gas`](/docs/sdk/v0.47/learn/beginner/gas-fees) management. They are executed when `runTx` returns and make sure `gas` is actually consumed, and will throw errors, if any. After that, `RunTx()` calls `ValidateBasic()`, when available and for backward compatibility, on each `sdk.Msg`in the `Tx`, which runs preliminary *stateless* validity checks. If any `sdk.Msg` fails to pass `ValidateBasic()`, `RunTx()` returns with an error. @@ -3441,9 +3441,9 @@ 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](/docs/sdk/v0.47/beginner/overview-app#application-constructor). The most widely used `anteHandler` is the [`auth` module](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/ante/ante.go). +`BaseApp` holds an `anteHandler` as parameter that is initialized in the [application's constructor](/docs/sdk/v0.47/learn/beginner/app-anatomy#application-constructor). The most widely used `anteHandler` is the [`auth` module](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/ante/ante.go). -Click [here](/docs/sdk/v0.47/beginner/gas-fees#antehandler) for more on the `anteHandler`. +Click [here](/docs/sdk/v0.47/learn/beginner/gas-fees#antehandler) for more on the `anteHandler`. ### RunMsgs @@ -3489,9 +3489,9 @@ The [`InitChain` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x * [Consensus Parameters](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_app_requirements.md#consensus-parameters) via `setConsensusParams`. * [`checkState` and `deliverState`](#state-updates) via `setState`. -* The [block gas meter](/docs/sdk/v0.47/beginner/gas-fees#block-gas-meter), with infinite gas to process genesis transactions. +* The [block gas meter](/docs/sdk/v0.47/learn/beginner/gas-fees#block-gas-meter), with infinite gas to process genesis transactions. -Finally, the `InitChain(req abci.RequestInitChain)` method of `BaseApp` calls the [`initChainer()`](/docs/sdk/v0.47/beginner/overview-app#initchainer) of the application in order to initialize the main state of the application from the `genesis file` and, if defined, call the [`InitGenesis`](/docs/sdk/v0.47//build/building-modules/genesis#initgenesis) function of each of the application's modules. +Finally, the `InitChain(req abci.RequestInitChain)` method of `BaseApp` calls the [`initChainer()`](/docs/sdk/v0.47/learn/beginner/app-anatomy#initchainer) of the application in order to initialize the main state of the application from the `genesis file` and, if defined, call the [`InitGenesis`](/docs/sdk/v0.47//build/building-modules/genesis#initgenesis) function of each of the application's modules. ### BeginBlock @@ -4677,17 +4677,17 @@ The [`BeginBlock` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37. } ``` - This function also resets the [main gas meter](/docs/sdk/v0.47/beginner/gas-fees#main-gas-meter). + This function also resets the [main gas meter](/docs/sdk/v0.47/learn/beginner/gas-fees#main-gas-meter). -* Initialize the [block gas meter](/docs/sdk/v0.47/beginner/gas-fees#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. +* Initialize the [block gas meter](/docs/sdk/v0.47/learn/beginner/gas-fees#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()`](/docs/sdk/v0.47/beginner/overview-app#beginblocker-and-endblock), which mainly runs the [`BeginBlocker()`](/docs/sdk/v0.47//build/building-modules/beginblock-endblock#beginblock) method of each of the application's modules. +* Run the application's [`beginBlocker()`](/docs/sdk/v0.47/learn/beginner/app-anatomy#beginblocker-and-endblock), which mainly runs the [`BeginBlocker()`](/docs/sdk/v0.47//build/building-modules/beginblock-endblock#beginblock) method of each of the application's modules. * Set the [`VoteInfos`](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_methods.md#voteinfo) of the application, i.e. the list of validators whose *precommit* for the previous block was included by the proposer of the current block. This information is carried into the [`Context`](/docs/sdk/v0.47/learn/advanced/context) so that it can be used during `DeliverTx` and `EndBlock`. ### EndBlock -The [`EndBlock` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_basic_concepts.md#method-overview) is sent from the underlying CometBFT engine after [`DeliverTx`](#delivertx) as been run for each transaction in the block. It allows developers to have logic be executed at the end of each block. In the Cosmos SDK, the bulk `EndBlock(req abci.RequestEndBlock)` method is to run the application's [`EndBlocker()`](/docs/sdk/v0.47/beginner/overview-app#beginblocker-and-endblock), which mainly runs the [`EndBlocker()`](/docs/sdk/v0.47//build/building-modules/beginblock-endblock#beginblock) method of each of the application's modules. +The [`EndBlock` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_basic_concepts.md#method-overview) is sent from the underlying CometBFT engine after [`DeliverTx`](#delivertx) as been run for each transaction in the block. It allows developers to have logic be executed at the end of each block. In the Cosmos SDK, the bulk `EndBlock(req abci.RequestEndBlock)` method is to run the application's [`EndBlocker()`](/docs/sdk/v0.47/learn/beginner/app-anatomy#beginblocker-and-endblock), which mainly runs the [`EndBlocker()`](/docs/sdk/v0.47//build/building-modules/beginblock-endblock#beginblock) method of each of the application's modules. ### Commit diff --git a/docs/sdk/v0.47/learn/advanced/cli.mdx b/docs/sdk/v0.47/learn/advanced/cli.mdx index 839abed0..341b3647 100644 --- a/docs/sdk/v0.47/learn/advanced/cli.mdx +++ b/docs/sdk/v0.47/learn/advanced/cli.mdx @@ -4,7 +4,7 @@ title: Command-Line Interface **Synopsis** -This document describes how command-line interface (CLI) works on a high-level, for an [**application**](/docs/sdk/v0.47/beginner/overview-app). A separate document for implementing a CLI for a Cosmos SDK [**module**](/docs/sdk/v0.47//build/building-modules/intro) can be found [here](/docs/sdk/v0.47//build/building-modules/module-interfaces#cli). +This document describes how command-line interface (CLI) works on a high-level, for an [**application**](/docs/sdk/v0.47/learn/beginner/app-anatomy). A separate document for implementing a CLI for a Cosmos SDK [**module**](/docs/sdk/v0.47//build/building-modules/intro) can be found [here](/docs/sdk/v0.47//build/building-modules/module-interfaces#cli). ## Command-Line Interface diff --git a/docs/sdk/v0.47/learn/advanced/context.mdx b/docs/sdk/v0.47/learn/advanced/context.mdx index d54d4aaa..99d01d6c 100644 --- a/docs/sdk/v0.47/learn/advanced/context.mdx +++ b/docs/sdk/v0.47/learn/advanced/context.mdx @@ -619,12 +619,12 @@ return ctx.Value(SdkContextKey).(Context) * **Header:** The [header](https://docs.cometbft.com/v0.37/spec/core/data_structures#header) is a Blockchain type. It carries important information about the state of the blockchain, such as block height and proposer of the current block. * **Header Hash:** The current block header hash, obtained during `abci.RequestBeginBlock`. * **Chain ID:** The unique identification number of the blockchain a block pertains to. -* **Transaction Bytes:** The `[]byte` representation of a transaction being processed using the context. Every transaction is processed by various parts of the Cosmos SDK and consensus engine (e.g. CometBFT) throughout its [lifecycle](/docs/sdk/v0.47/beginner/tx-lifecycle), some of which do not have any understanding of transaction types. Thus, transactions are marshaled into the generic `[]byte` type using some kind of [encoding format](/docs/sdk/v0.47/learn/advanced/encoding) such as [Amino](/docs/sdk/v0.47/learn/advanced/encoding). +* **Transaction Bytes:** The `[]byte` representation of a transaction being processed using the context. Every transaction is processed by various parts of the Cosmos SDK and consensus engine (e.g. CometBFT) throughout its [lifecycle](/docs/sdk/v0.47/learn/beginner/tx-lifecycle), some of which do not have any understanding of transaction types. Thus, transactions are marshaled into the generic `[]byte` type using some kind of [encoding format](/docs/sdk/v0.47/learn/advanced/encoding) such as [Amino](/docs/sdk/v0.47/learn/advanced/encoding). * **Logger:** A `logger` from the CometBFT libraries. Learn more about logs [here](https://docs.cometbft.com/v0.37/core/configuration). Modules call this method to create their own unique module-specific logger. * **VoteInfo:** A list of the ABCI type [`VoteInfo`](https://docs.cometbft.com/master/spec/abci/abci.html#voteinfo), which includes the name of a validator and a boolean indicating whether they have signed the block. -* **Gas Meters:** Specifically, a [`gasMeter`](/docs/sdk/v0.47/beginner/gas-fees#main-gas-meter) for the transaction currently being processed using the context and a [`blockGasMeter`](/docs/sdk/v0.47/beginner/gas-fees#block-gas-meter) for the entire block it belongs to. Users specify how much in fees they wish to pay for the execution of their transaction; these gas meters keep track of how much [gas](/docs/sdk/v0.47/beginner/gas-fees) has been used in the transaction or block so far. If the gas meter runs out, execution halts. +* **Gas Meters:** Specifically, a [`gasMeter`](/docs/sdk/v0.47/learn/beginner/gas-fees#main-gas-meter) for the transaction currently being processed using the context and a [`blockGasMeter`](/docs/sdk/v0.47/learn/beginner/gas-fees#block-gas-meter) for the entire block it belongs to. Users specify how much in fees they wish to pay for the execution of their transaction; these gas meters keep track of how much [gas](/docs/sdk/v0.47/learn/beginner/gas-fees) has been used in the transaction or block so far. If the gas meter runs out, execution halts. * **CheckTx Mode:** A boolean value indicating whether a transaction should be processed in `CheckTx` or `DeliverTx` mode. -* **Min Gas Price:** The minimum [gas](/docs/sdk/v0.47/beginner/gas-fees) price a node is willing to take in order to include a transaction in its block. This price is a local value configured by each node individually, and should therefore **not be used in any functions used in sequences leading to state-transitions**. +* **Min Gas Price:** The minimum [gas](/docs/sdk/v0.47/learn/beginner/gas-fees) price a node is willing to take in order to include a transaction in its block. This price is a local value configured by each node individually, and should therefore **not be used in any functions used in sequences leading to state-transitions**. * **Consensus Params:** The ABCI type [Consensus Parameters](https://docs.cometbft.com/master/spec/abci/apps.html#consensus-parameters), which specify certain limits for the blockchain, such as maximum gas for a block. * **Event Manager:** The event manager allows any caller with access to a `Context` to emit [`Events`](/docs/sdk/v0.47/learn/advanced/events). Modules may define module specific `Events` by defining various `Types` and `Attributes` or use the common definitions found in `types/`. Clients can subscribe or query for these `Events`. These `Events` are collected throughout `DeliverTx`, `BeginBlock`, and `EndBlock` and are returned to CometBFT for indexing. For example: diff --git a/docs/sdk/v0.47/learn/advanced/encoding.mdx b/docs/sdk/v0.47/learn/advanced/encoding.mdx index 06617537..a139be30 100644 --- a/docs/sdk/v0.47/learn/advanced/encoding.mdx +++ b/docs/sdk/v0.47/learn/advanced/encoding.mdx @@ -11,7 +11,7 @@ While encoding in the Cosmos SDK used to be mainly handled by `go-amino` codec, ### Pre-requisite Readings -* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.47/beginner/overview-app) +* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.47/learn/beginner/app-anatomy) @@ -500,7 +500,7 @@ See [ADR-020](/docs/sdk/v0.47//build/architecture/adr-020-protobuf-transaction-e ### Interface Encoding and Usage of `Any` -The Protobuf DSL is strongly typed, which can make inserting variable-typed fields difficult. Imagine we want to create a `Profile` protobuf message that serves as a wrapper over [an account](/docs/sdk/v0.47/beginner/accounts): +The Protobuf DSL is strongly typed, which can make inserting variable-typed fields difficult. Imagine we want to create a `Profile` protobuf message that serves as a wrapper over [an account](/docs/sdk/v0.47/learn/beginner/accounts): ```protobuf message Profile { diff --git a/docs/sdk/v0.47/learn/advanced/events.mdx b/docs/sdk/v0.47/learn/advanced/events.mdx index c632a2a9..7529e380 100644 --- a/docs/sdk/v0.47/learn/advanced/events.mdx +++ b/docs/sdk/v0.47/learn/advanced/events.mdx @@ -11,7 +11,7 @@ title: Events ### Pre-requisite Readings -* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.47/beginner/overview-app) +* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.47/learn/beginner/app-anatomy) * [CometBFT Documentation on Events](https://docs.cometbft.com/v0.37/spec/abci/abci++_basic_concepts#events) @@ -2205,7 +2205,7 @@ Subscribing to this Event would be done like so: } ``` -where `ownerAddress` is an address following the [`AccAddress`](/docs/sdk/v0.47/beginner/accounts#addresses) format. +where `ownerAddress` is an address following the [`AccAddress`](/docs/sdk/v0.47/learn/beginner/accounts#addresses) format. The same way can be used to subscribe to [legacy events](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/bank/types/events.go). diff --git a/docs/sdk/v0.47/learn/advanced/node.mdx b/docs/sdk/v0.47/learn/advanced/node.mdx index 3fe4155d..e6db7e41 100644 --- a/docs/sdk/v0.47/learn/advanced/node.mdx +++ b/docs/sdk/v0.47/learn/advanced/node.mdx @@ -11,7 +11,7 @@ The main endpoint of a Cosmos SDK application is the daemon client, otherwise kn ### Pre-requisite Readings -* [Anatomy of an SDK application](/docs/sdk/v0.47/beginner/overview-app) +* [Anatomy of an SDK application](/docs/sdk/v0.47/learn/beginner/app-anatomy) @@ -22,7 +22,7 @@ The full-node client of any Cosmos SDK application is built by running a `main` In general, developers will implement the `main.go` function with the following structure: * First, an [`encodingCodec`](/docs/sdk/v0.47/learn/advanced/encoding) is instantiated for the application. -* Then, the `config` is retrieved and config parameters are set. This mainly involves setting the Bech32 prefixes for [addresses](/docs/sdk/v0.47/beginner/accounts#addresses). +* Then, the `config` is retrieved and config parameters are set. This mainly involves setting the Bech32 prefixes for [addresses](/docs/sdk/v0.47/learn/beginner/accounts#addresses). ```go expandable package types @@ -1321,7 +1321,7 @@ Application ) ``` -In practice, the [constructor of the application](/docs/sdk/v0.47/beginner/overview-app#constructor-function) is passed as the `appCreator`. +In practice, the [constructor of the application](/docs/sdk/v0.47/learn/beginner/app-anatomy#constructor-function) is passed as the `appCreator`. ```go expandable package cmd diff --git a/docs/sdk/v0.47/learn/advanced/transactions.mdx b/docs/sdk/v0.47/learn/advanced/transactions.mdx index 8ff83c9e..d96eee39 100644 --- a/docs/sdk/v0.47/learn/advanced/transactions.mdx +++ b/docs/sdk/v0.47/learn/advanced/transactions.mdx @@ -11,7 +11,7 @@ title: Transactions ### Pre-requisite Readings -* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.47/beginner/overview-app) +* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.47/learn/beginner/app-anatomy) @@ -19,7 +19,7 @@ title: Transactions Transactions are comprised of metadata held in [contexts](/docs/sdk/v0.47/learn/advanced/context) and [`sdk.Msg`s](/docs/sdk/v0.47//build/building-modules/messages-and-queries) that trigger state changes within a module through the module's Protobuf [`Msg` service](/docs/sdk/v0.47//build/building-modules/msg-services). -When users want to interact with an application and make state changes (e.g. sending coins), they create transactions. Each of a transaction's `sdk.Msg` must be signed using the private key associated with the appropriate account(s), before the transaction is broadcasted to the network. A transaction must then be included in a block, validated, and approved by the network through the consensus process. To read more about the lifecycle of a transaction, click [here](/docs/sdk/v0.47/beginner/tx-lifecycle). +When users want to interact with an application and make state changes (e.g. sending coins), they create transactions. Each of a transaction's `sdk.Msg` must be signed using the private key associated with the appropriate account(s), before the transaction is broadcasted to the network. A transaction must then be included in a block, validated, and approved by the network through the consensus process. To read more about the lifecycle of a transaction, click [here](/docs/sdk/v0.47/learn/beginner/tx-lifecycle). ## Type Definition @@ -159,10 +159,10 @@ return msg, nil It contains the following methods: * **GetMsgs:** unwraps the transaction and returns a list of contained `sdk.Msg`s - one transaction may have one or multiple messages, which are defined by module developers. -* **ValidateBasic:** lightweight, [*stateless*](/docs/sdk/v0.47/beginner/tx-lifecycle#types-of-checks) checks used by ABCI messages [`CheckTx`](/docs/sdk/v0.47/learn/advanced/baseapp#checktx) and [`DeliverTx`](/docs/sdk/v0.47/learn/advanced/baseapp#delivertx) to make sure transactions are not invalid. For example, the [`auth`](https://github.com/cosmos/cosmos-sdk/tree/main/x/auth) module's `ValidateBasic` function checks that its transactions are signed by the correct number of signers and that the fees do not exceed what the user's maximum. When [`runTx`](/docs/sdk/v0.47/learn/advanced/baseapp#runtx) is checking a transaction created from the [`auth`](https://github.com/cosmos/cosmos-sdk/tree/main/x/auth/spec) module, it first runs `ValidateBasic` on each message, then runs the `auth` module AnteHandler which calls `ValidateBasic` for the transaction itself. +* **ValidateBasic:** lightweight, [*stateless*](/docs/sdk/v0.47/learn/beginner/tx-lifecycle#types-of-checks) checks used by ABCI messages [`CheckTx`](/docs/sdk/v0.47/learn/advanced/baseapp#checktx) and [`DeliverTx`](/docs/sdk/v0.47/learn/advanced/baseapp#delivertx) to make sure transactions are not invalid. For example, the [`auth`](https://github.com/cosmos/cosmos-sdk/tree/main/x/auth) module's `ValidateBasic` function checks that its transactions are signed by the correct number of signers and that the fees do not exceed what the user's maximum. When [`runTx`](/docs/sdk/v0.47/learn/advanced/baseapp#runtx) is checking a transaction created from the [`auth`](https://github.com/cosmos/cosmos-sdk/tree/main/x/auth/spec) module, it first runs `ValidateBasic` on each message, then runs the `auth` module AnteHandler which calls `ValidateBasic` for the transaction itself. :::note - This function is different from the deprecated `sdk.Msg` [`ValidateBasic`](/docs/sdk/v0.47/beginner/tx-lifecycle#ValidateBasic) methods, which was performing basic validity checks on messages only. + This function is different from the deprecated `sdk.Msg` [`ValidateBasic`](/docs/sdk/v0.47/learn/beginner/tx-lifecycle#ValidateBasic) methods, which was performing basic validity checks on messages only. As a developer, you should rarely manipulate `Tx` directly, as `Tx` is really an intermediate type used for transaction generation. Instead, developers should prefer the `TxBuilder` interface, which you can learn more about [below](#transaction-generation). diff --git a/docs/sdk/v0.47/learn/intro/sdk-design.mdx b/docs/sdk/v0.47/learn/intro/sdk-design.mdx index 2ebf6fc9..7fc3a30c 100644 --- a/docs/sdk/v0.47/learn/intro/sdk-design.mdx +++ b/docs/sdk/v0.47/learn/intro/sdk-design.mdx @@ -13,7 +13,7 @@ Here is a simplified view of how transactions are handled by an application buil ## `baseapp` -`baseapp` is the boilerplate implementation of a Cosmos SDK application. It comes with an implementation of the ABCI to handle the connection with the underlying consensus engine. Typically, a Cosmos SDK application extends `baseapp` by embedding it in [`app.go`](/docs/sdk/v0.47/beginner/overview-app#core-application-file). +`baseapp` is the boilerplate implementation of a Cosmos SDK application. It comes with an implementation of the ABCI to handle the connection with the underlying consensus engine. Typically, a Cosmos SDK application extends `baseapp` by embedding it in [`app.go`](/docs/sdk/v0.47/learn/beginner/app-anatomy#core-application-file). Here is an example of this from `simapp`, the Cosmos SDK demonstration app: diff --git a/docs/sdk/v0.50/build/architecture/PROCESS.mdx b/docs/sdk/v0.50/build/architecture/PROCESS.mdx index 247e7f34..1143076d 100644 --- a/docs/sdk/v0.50/build/architecture/PROCESS.mdx +++ b/docs/sdk/v0.50/build/architecture/PROCESS.mdx @@ -5,7 +5,7 @@ title: ADR Creation Process 1. Copy the `adr-template.md` file. Use the following filename pattern: `adr-next_number-title.md` 2. Create a draft Pull Request if you want to get an early feedback. 3. Make sure the context and a solution is clear and well documented. -4. Add an entry to a list in the [README](/docs/sdk/v0.50/README) file. +4. Add an entry to a list in the [README](/docs/sdk/v0.50/build/architecture/README) file. 5. Create a Pull Request to propose a new ADR. ## What is an ADR? diff --git a/docs/sdk/v0.50/build/architecture/README.mdx b/docs/sdk/v0.50/build/architecture/README.mdx index 66f6460a..eaa40f0e 100644 --- a/docs/sdk/v0.50/build/architecture/README.mdx +++ b/docs/sdk/v0.50/build/architecture/README.mdx @@ -33,7 +33,7 @@ If recorded decisions turned out to be lacking, convene a discussion, record the ## Creating new ADR -Read about the [PROCESS](/docs/sdk/v0.50/PROCESS). +Read about the [PROCESS](/docs/sdk/v0.50/build/architecture/PROCESS). ### Use RFC 2119 Keywords diff --git a/docs/sdk/v0.50/build/architecture/adr-template.mdx b/docs/sdk/v0.50/build/architecture/adr-template.mdx index c4ea3c92..48d51ce9 100644 --- a/docs/sdk/v0.50/build/architecture/adr-template.mdx +++ b/docs/sdk/v0.50/build/architecture/adr-template.mdx @@ -6,7 +6,7 @@ {DRAFT | PROPOSED} Not Implemented -> Please have a look at the [PROCESS](/docs/sdk/v0.50/PROCESS#adr-status) page. +> Please have a look at the [PROCESS](/docs/sdk/v0.50/build/architecture/PROCESS#adr-status) page. > Use DRAFT if the ADR is in a draft stage (draft PR) or PROPOSED if it's in review. ## Abstract diff --git a/docs/sdk/v0.50/build/building-apps/app-mempool.mdx b/docs/sdk/v0.50/build/building-apps/app-mempool.mdx index 0332b5c3..16331499 100644 --- a/docs/sdk/v0.50/build/building-apps/app-mempool.mdx +++ b/docs/sdk/v0.50/build/building-apps/app-mempool.mdx @@ -390,7 +390,7 @@ sdk.VerifyVoteExtensionHandler { ``` This default implementation can be overridden by the application developer in -favor of a custom implementation in [`app.go`](/docs/sdk/v0.50/app-go-v2): +favor of a custom implementation in [`app.go`](/docs/sdk/v0.50/build/building-apps/app-go-v2): ```go prepareOpt := func(app *baseapp.BaseApp) { @@ -760,7 +760,7 @@ sdk.VerifyVoteExtensionHandler { ``` Like `PrepareProposal` this implementation is the default and can be modified by -the application developer in [`app.go`](/docs/sdk/v0.50/app-go-v2). If you decide to implement +the application developer in [`app.go`](/docs/sdk/v0.50/build/building-apps/app-go-v2). If you decide to implement your own `ProcessProposal` handler, you must be sure to ensure that the transactions provided in the proposal DO NOT exceed the maximum block gas (if set). @@ -785,7 +785,7 @@ Namely, the SDK provides the following mempools: * [Sender Nonce Mempool](#sender-nonce-mempool) * [Priority Nonce Mempool](#priority-nonce-mempool) -The default SDK is a [No-op Mempool](#no-op-mempool), but it can be replaced by the application developer in [`app.go`](/docs/sdk/v0.50/app-go-v2): +The default SDK is a [No-op Mempool](#no-op-mempool), but it can be replaced by the application developer in [`app.go`](/docs/sdk/v0.50/build/building-apps/app-go-v2): ```go nonceMempool := mempool.NewSenderNonceMempool() diff --git a/docs/sdk/v0.50/build/building-modules/genesis.mdx b/docs/sdk/v0.50/build/building-modules/genesis.mdx index 3c637eb8..1e6457fd 100644 --- a/docs/sdk/v0.50/build/building-modules/genesis.mdx +++ b/docs/sdk/v0.50/build/building-modules/genesis.mdx @@ -612,7 +612,7 @@ Other than the methods related directly to `GenesisState`, module developers are ### `InitGenesis` -The `InitGenesis` method is executed during [`InitChain`](/docs/sdk/v0.50//learn/advanced/baseapp#initchain) when the application is first started. Given a `GenesisState`, it initializes the subset of the state managed by the module by using the module's [`keeper`](/docs/sdk/v0.50/keeper) setter function on each parameter within the `GenesisState`. +The `InitGenesis` method is executed during [`InitChain`](/docs/sdk/v0.50//learn/advanced/baseapp#initchain) when the application is first started. Given a `GenesisState`, it initializes the subset of the state managed by the module by using the module's [`keeper`](/docs/sdk/v0.50/build/building-modules/keeper) setter function on each parameter within the `GenesisState`. The [module manager](/docs/sdk/v0.50/build/building-modules/module-manager) of the application is responsible for calling the `InitGenesis` method of each of the application's modules in order. This order is set by the application developer via the manager's `SetOrderGenesisMethod`, which is called in the [application's constructor function](/docs/sdk/v0.50//learn/beginner/app-anatomy#constructor-function). diff --git a/docs/sdk/v0.50/build/building-modules/module-interfaces.mdx b/docs/sdk/v0.50/build/building-modules/module-interfaces.mdx index 12aa985d..365eef4f 100644 --- a/docs/sdk/v0.50/build/building-modules/module-interfaces.mdx +++ b/docs/sdk/v0.50/build/building-modules/module-interfaces.mdx @@ -1077,6 +1077,6 @@ Modules that want to expose REST queries should add `google.api.http` annotation // Reference: https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/proto/cosmos/auth/v1beta1/query.proto#L14-L89 ``` -gRPC gateway is started in-process along with the application and CometBFT. It can be enabled or disabled by setting gRPC Configuration `enable` in [`app.toml`](/docs/sdk/v0.50/run-node/run-node#configuring-the-node-using-apptoml-and-configtoml). +gRPC gateway is started in-process along with the application and CometBFT. It can be enabled or disabled by setting gRPC Configuration `enable` in [`app.toml`](/docs/sdk/v0.50/user/run-node/run-node#configuring-the-node-using-apptoml-and-configtoml). -The Cosmos SDK provides a command for generating [Swagger](https://swagger.io/) documentation (`protoc-gen-swagger`). Setting `swagger` in [`app.toml`](/docs/sdk/v0.50/run-node/run-node#configuring-the-node-using-apptoml-and-configtoml) defines if swagger documentation should be automatically registered. +The Cosmos SDK provides a command for generating [Swagger](https://swagger.io/) documentation (`protoc-gen-swagger`). Setting `swagger` in [`app.toml`](/docs/sdk/v0.50/user/run-node/run-node#configuring-the-node-using-apptoml-and-configtoml) defines if swagger documentation should be automatically registered. diff --git a/docs/sdk/v0.50/build/building-modules/msg-services.mdx b/docs/sdk/v0.50/build/building-modules/msg-services.mdx index 31d5fe86..936ef394 100644 --- a/docs/sdk/v0.50/build/building-modules/msg-services.mdx +++ b/docs/sdk/v0.50/build/building-modules/msg-services.mdx @@ -2657,7 +2657,7 @@ ErrUnexpectedEndOfGroupTx = fmt.Errorf("proto: unexpected end of group") ) ``` -When possible, the existing module's [`Keeper`](/docs/sdk/v0.50/keeper) should implement `MsgServer`, otherwise a `msgServer` struct that embeds the `Keeper` can be created, typically in `./keeper/msg_server.go`: +When possible, the existing module's [`Keeper`](/docs/sdk/v0.50/build/building-modules/keeper) should implement `MsgServer`, otherwise a `msgServer` struct that embeds the `Keeper` can be created, typically in `./keeper/msg_server.go`: ```go expandable package keeper @@ -3097,7 +3097,7 @@ This way of validating is deprecated, this means the `msgServer` must perform al ### State Transition -After the validation is successful, the `msgServer` method uses the [`keeper`](/docs/sdk/v0.50/keeper) functions to access the state and perform a state transition. +After the validation is successful, the `msgServer` method uses the [`keeper`](/docs/sdk/v0.50/build/building-modules/keeper) functions to access the state and perform a state transition. ### Events diff --git a/docs/sdk/v0.50/build/building-modules/protobuf-annotations.mdx b/docs/sdk/v0.50/build/building-modules/protobuf-annotations.mdx index cf39cf68..fe3a640b 100644 --- a/docs/sdk/v0.50/build/building-modules/protobuf-annotations.mdx +++ b/docs/sdk/v0.50/build/building-modules/protobuf-annotations.mdx @@ -11,7 +11,7 @@ This document explains the various protobuf scalars that have been added to make Signer specifies which field should be used to determine the signer of a message for the Cosmos SDK. This field can be used for clients as well to infer which field should be used to determine the signer of a message. -Read more about the signer field [here](/docs/sdk/v0.50/messages-and-queries). +Read more about the signer field [here](/docs/sdk/v0.50/build/building-modules/messages-and-queries). ```protobuf // Reference: https://github.com/cosmos/cosmos-sdk/blob/e6848d99b55a65d014375b295bdd7f9641aac95e/proto/cosmos/bank/v1beta1/tx.proto#L40 diff --git a/docs/sdk/v0.50/build/building-modules/query-services.mdx b/docs/sdk/v0.50/build/building-modules/query-services.mdx index d997c2f8..0b9248aa 100644 --- a/docs/sdk/v0.50/build/building-modules/query-services.mdx +++ b/docs/sdk/v0.50/build/building-modules/query-services.mdx @@ -5,7 +5,7 @@ title: Query Services **Synopsis** -A Protobuf Query service processes [`queries`](/docs/sdk/v0.50/messages-and-queries#queries). Query services are specific to the module in which they are defined, and only process `queries` defined within said module. They are called from `BaseApp`'s [`Query` method](/docs/sdk/v0.50//learn/advanced/baseapp#query). +A Protobuf Query service processes [`queries`](/docs/sdk/v0.50/build/building-modules/messages-and-queries#queries). Query services are specific to the module in which they are defined, and only process `queries` defined within said module. They are called from `BaseApp`'s [`Query` method](/docs/sdk/v0.50//learn/advanced/baseapp#query). diff --git a/docs/sdk/v0.50/build/migrations/intro.mdx b/docs/sdk/v0.50/build/migrations/intro.mdx index 0c7d8a5c..a79a73fa 100644 --- a/docs/sdk/v0.50/build/migrations/intro.mdx +++ b/docs/sdk/v0.50/build/migrations/intro.mdx @@ -10,4 +10,4 @@ Additionally, the SDK includes in-place migrations for its core modules. These i Migration from a version older than the last two major releases is not supported. -When migrating from a previous version, refer to the [`UPGRADING.md`](/docs/sdk/v0.50/upgrading) and the `CHANGELOG.md` of the version you are migrating to. +When migrating from a previous version, refer to the [`UPGRADING.md`](/docs/sdk/v0.50/build/migrations/upgrading) and the `CHANGELOG.md` of the version you are migrating to. diff --git a/docs/sdk/v0.50/build/modules/auth/authre.mdx b/docs/sdk/v0.50/build/modules/auth/authre.mdx index 3bfa3225..2cc3759b 100644 --- a/docs/sdk/v0.50/build/modules/auth/authre.mdx +++ b/docs/sdk/v0.50/build/modules/auth/authre.mdx @@ -31,7 +31,7 @@ This module is used in the Cosmos Hub. ## Concepts -**Note:** The auth module is different from the [authz module](/docs/sdk/v0.50/modules/authz/). +**Note:** The auth module is different from the [authz module](/docs/sdk/v0.50/build/modules/auth/authrez/). The differences are: diff --git a/docs/sdk/v0.50/build/modules/authz/README.mdx b/docs/sdk/v0.50/build/modules/authz/README.mdx index ee7da111..75dcfe36 100644 --- a/docs/sdk/v0.50/build/modules/authz/README.mdx +++ b/docs/sdk/v0.50/build/modules/authz/README.mdx @@ -36,7 +36,7 @@ on behalf of one account to other accounts. The design is defined in the [ADR 03 A *grant* is an allowance to execute a Msg by the grantee on behalf of the granter. Authorization is an interface that must be implemented by a concrete authorization logic to validate and execute grants. Authorizations are extensible and can be defined for any Msg service method even outside of the module where the Msg method is defined. See the `SendAuthorization` example in the next section for more details. -**Note:** The authz module is different from the [auth (authentication)](/docs/sdk/v0.50/modules/auth/) module that is responsible for specifying the base transaction and account types. +**Note:** The authz module is different from the [auth (authentication)](/docs/sdk/v0.50/build/modules/auth/authre/) module that is responsible for specifying the base transaction and account types. ```go expandable package authz diff --git a/docs/sdk/v0.50/build/modules/evidence/README.mdx b/docs/sdk/v0.50/build/modules/evidence/README.mdx index d2c926db..2b3764ee 100644 --- a/docs/sdk/v0.50/build/modules/evidence/README.mdx +++ b/docs/sdk/v0.50/build/modules/evidence/README.mdx @@ -412,7 +412,7 @@ k.SetEvidence(ctx, evidence) **Note:** The slashing, jailing, and tombstoning calls are delegated through the `x/slashing` module that emits informative events and finally delegates calls to the `x/staking` module. See documentation -on slashing and jailing in [State Transitions](/docs/sdk/v0.50/staking/README#state-transitions). +on slashing and jailing in [State Transitions](/docs/sdk/v0.50/build/modules/staking/README#state-transitions). ## Client diff --git a/docs/sdk/v0.50/build/modules/feegrant/README.mdx b/docs/sdk/v0.50/build/modules/feegrant/README.mdx index e98ca2e3..d53c23f0 100644 --- a/docs/sdk/v0.50/build/modules/feegrant/README.mdx +++ b/docs/sdk/v0.50/build/modules/feegrant/README.mdx @@ -1597,7 +1597,7 @@ Example cmd: ### Granted Fee Deductions -Fees are deducted from grants in the `x/auth` ante handler. To learn more about how ante handlers work, read the [Auth Module AnteHandlers Guide](/docs/sdk/v0.50/auth/README#antehandlers). +Fees are deducted from grants in the `x/auth` ante handler. To learn more about how ante handlers work, read the [Auth Module AnteHandlers Guide](/docs/sdk/v0.50/build/modules/auth/authre#antehandlers). ### Gas diff --git a/docs/sdk/v0.50/build/modules/gov/README.mdx b/docs/sdk/v0.50/build/modules/gov/README.mdx index 55621947..e9af8fbc 100644 --- a/docs/sdk/v0.50/build/modules/gov/README.mdx +++ b/docs/sdk/v0.50/build/modules/gov/README.mdx @@ -2497,7 +2497,7 @@ The gov module has two locations for metadata where users can provide further co ### Proposal -Location: off-chain as json object stored on IPFS (mirrors [group proposal](/docs/sdk/v0.50/group/README#metadata)) +Location: off-chain as json object stored on IPFS (mirrors [group proposal](/docs/sdk/v0.50/build/modules/group/README#metadata)) ```json { @@ -2517,7 +2517,7 @@ In v0.46, the `authors` field is a comma-separated string. Frontends are encoura ### Vote -Location: on-chain as json within 255 character limit (mirrors [group vote](/docs/sdk/v0.50/group/README#metadata)) +Location: on-chain as json within 255 character limit (mirrors [group vote](/docs/sdk/v0.50/build/modules/group/README#metadata)) ```json { diff --git a/docs/sdk/v0.50/build/modules/group/README.mdx b/docs/sdk/v0.50/build/modules/group/README.mdx index b2176a6e..ae85a287 100644 --- a/docs/sdk/v0.50/build/modules/group/README.mdx +++ b/docs/sdk/v0.50/build/modules/group/README.mdx @@ -8963,7 +8963,7 @@ The group module has four locations for metadata where users can provide further ### Proposal -Location: off-chain as json object stored on IPFS (mirrors [gov proposal](/docs/sdk/v0.50/gov/README#metadata)) +Location: off-chain as json object stored on IPFS (mirrors [gov proposal](/docs/sdk/v0.50/build/modules/gov/README#metadata)) ```json { @@ -8983,7 +8983,7 @@ In v0.46, the `authors` field is a comma-separated string. Frontends are encoura ### Vote -Location: on-chain as json within 255 character limit (mirrors [gov vote](/docs/sdk/v0.50/gov/README#metadata)) +Location: on-chain as json within 255 character limit (mirrors [gov vote](/docs/sdk/v0.50/build/modules/gov/README#metadata)) ```json { diff --git a/docs/sdk/v0.50/build/modules/slashing/README.mdx b/docs/sdk/v0.50/build/modules/slashing/README.mdx index c2baa9ec..bba37692 100644 --- a/docs/sdk/v0.50/build/modules/slashing/README.mdx +++ b/docs/sdk/v0.50/build/modules/slashing/README.mdx @@ -107,7 +107,7 @@ long as it contains precommits from +2/3 of total voting power. Proposers are incentivized to include precommits from all validators in the CometBFT `LastCommitInfo` by receiving additional fees proportional to the difference between the voting -power included in the `LastCommitInfo` and +2/3 (see [fee distribution](/docs/sdk/v0.47/distribution/README#begin-block)). +power included in the `LastCommitInfo` and +2/3 (see [fee distribution](/docs/sdk/v0.47/build/modules/distribution/README#begin-block)). ```go type LastCommitInfo struct { diff --git a/docs/sdk/v0.50/build/packages/README.mdx b/docs/sdk/v0.50/build/packages/README.mdx index 6383e37a..9ac6238b 100644 --- a/docs/sdk/v0.50/build/packages/README.mdx +++ b/docs/sdk/v0.50/build/packages/README.mdx @@ -23,7 +23,7 @@ For more information on SDK tooling, see the [Tooling](https://docs.cosmos.netwo ## State Management * [Collections](/docs/sdk/v0.50/build/packages/collections) - State management library -* [ORM](/docs/sdk/v0.50/orm) - State management library +* [ORM](/docs/sdk/v0.50/build/packages/collections) - State management library ## Automation diff --git a/docs/sdk/v0.50/build/rfc.mdx b/docs/sdk/v0.50/build/rfc.mdx index ab9d4ae0..901d08e2 100644 --- a/docs/sdk/v0.50/build/rfc.mdx +++ b/docs/sdk/v0.50/build/rfc.mdx @@ -5,7 +5,7 @@ description: "Version: v0.50" A Request for Comments (RFC) is a record of discussion on an open-ended topic related to the design and implementation of the Cosmos SDK, for which no immediate decision is required. -The purpose of an RFC is to serve as a historical record of a high-level discussion that might otherwise only be recorded in an ad-hoc way (for example, via gists or Google docs) that are difficult to discover for someone after the fact. An RFC *may* give rise to more specific architectural *decisions* for the Cosmos SDK, but those decisions must be recorded separately in [Architecture Decision Records (ADR)](/docs/sdk/v0.50/architecture). +The purpose of an RFC is to serve as a historical record of a high-level discussion that might otherwise only be recorded in an ad-hoc way (for example, via gists or Google docs) that are difficult to discover for someone after the fact. An RFC *may* give rise to more specific architectural *decisions* for the Cosmos SDK, but those decisions must be recorded separately in [Architecture Decision Records (ADR)](/docs/sdk/v0.50/build/architecture/README). As a rule of thumb, if you can articulate a specific question that needs to be answered, write an ADR. If you need to explore the topic and get input from others to know what questions need to be answered, an RFC may be appropriate. diff --git a/docs/sdk/v0.50/build/rfc/PROCESS.mdx b/docs/sdk/v0.50/build/rfc/PROCESS.mdx index 334b8388..3e1cbff1 100644 --- a/docs/sdk/v0.50/build/rfc/PROCESS.mdx +++ b/docs/sdk/v0.50/build/rfc/PROCESS.mdx @@ -5,7 +5,7 @@ title: RFC Creation Process 1. Copy the `rfc-template.md` file. Use the following filename pattern: `rfc-next_number-title.md` 2. Create a draft Pull Request if you want to get an early feedback. 3. Make sure the context and a solution is clear and well documented. -4. Add an entry to a list in the [README](/docs/sdk/v0.50/README) file. +4. Add an entry to a list in the [README](/docs/sdk/v0.50/build/architecture/README) file. 5. Create a Pull Request to propose a new ADR. ## What is an RFC? diff --git a/docs/sdk/v0.50/build/rfc/README.mdx b/docs/sdk/v0.50/build/rfc/README.mdx index 66037852..a1b01418 100644 --- a/docs/sdk/v0.50/build/rfc/README.mdx +++ b/docs/sdk/v0.50/build/rfc/README.mdx @@ -15,7 +15,7 @@ discussion that might otherwise only be recorded in an ad-hoc way (for example, via gists or Google docs) that are difficult to discover for someone after the fact. An RFC *may* give rise to more specific architectural *decisions* for the Cosmos SDK, but those decisions must be recorded separately in -[Architecture Decision Records (ADR)](/docs/sdk/v0.50/architecture). +[Architecture Decision Records (ADR)](/docs/sdk/v0.50/build/architecture/README). As a rule of thumb, if you can articulate a specific question that needs to be answered, write an ADR. If you need to explore the topic and get input from @@ -32,9 +32,9 @@ An RFC should provide: substance of the discussion (links to other documents are fine here). * The **discussion**, the primary content of the document. -The [rfc-template.md](/docs/sdk/v0.50/rfc-template) file includes placeholders for these +The [rfc-template.md](/docs/sdk/v0.50/build/rfc/rfc-template) file includes placeholders for these sections. ## Table of Contents -* [RFC-001: Tx Validation](/docs/sdk/v0.50/rfc-001-tx-validation) +* [RFC-001: Tx Validation](/docs/sdk/v0.50/build/rfc/rfc-001-tx-validation) diff --git a/docs/sdk/v0.50/build/rfc/rfc/PROCESS.mdx b/docs/sdk/v0.50/build/rfc/rfc/PROCESS.mdx index 334b8388..3e1cbff1 100644 --- a/docs/sdk/v0.50/build/rfc/rfc/PROCESS.mdx +++ b/docs/sdk/v0.50/build/rfc/rfc/PROCESS.mdx @@ -5,7 +5,7 @@ title: RFC Creation Process 1. Copy the `rfc-template.md` file. Use the following filename pattern: `rfc-next_number-title.md` 2. Create a draft Pull Request if you want to get an early feedback. 3. Make sure the context and a solution is clear and well documented. -4. Add an entry to a list in the [README](/docs/sdk/v0.50/README) file. +4. Add an entry to a list in the [README](/docs/sdk/v0.50/build/architecture/README) file. 5. Create a Pull Request to propose a new ADR. ## What is an RFC? diff --git a/docs/sdk/v0.50/build/rfc/rfc/README.mdx b/docs/sdk/v0.50/build/rfc/rfc/README.mdx index 66037852..a1b01418 100644 --- a/docs/sdk/v0.50/build/rfc/rfc/README.mdx +++ b/docs/sdk/v0.50/build/rfc/rfc/README.mdx @@ -15,7 +15,7 @@ discussion that might otherwise only be recorded in an ad-hoc way (for example, via gists or Google docs) that are difficult to discover for someone after the fact. An RFC *may* give rise to more specific architectural *decisions* for the Cosmos SDK, but those decisions must be recorded separately in -[Architecture Decision Records (ADR)](/docs/sdk/v0.50/architecture). +[Architecture Decision Records (ADR)](/docs/sdk/v0.50/build/architecture/README). As a rule of thumb, if you can articulate a specific question that needs to be answered, write an ADR. If you need to explore the topic and get input from @@ -32,9 +32,9 @@ An RFC should provide: substance of the discussion (links to other documents are fine here). * The **discussion**, the primary content of the document. -The [rfc-template.md](/docs/sdk/v0.50/rfc-template) file includes placeholders for these +The [rfc-template.md](/docs/sdk/v0.50/build/rfc/rfc-template) file includes placeholders for these sections. ## Table of Contents -* [RFC-001: Tx Validation](/docs/sdk/v0.50/rfc-001-tx-validation) +* [RFC-001: Tx Validation](/docs/sdk/v0.50/build/rfc/rfc-001-tx-validation) diff --git a/docs/sdk/v0.50/build/spec/README.mdx b/docs/sdk/v0.50/build/spec/README.mdx index 2153b35e..a649334c 100644 --- a/docs/sdk/v0.50/build/spec/README.mdx +++ b/docs/sdk/v0.50/build/spec/README.mdx @@ -13,7 +13,7 @@ block. ## Cosmos SDK specifications -* [Store](/docs/sdk/v0.50/store) - The core Merkle store that holds the state. +* [Store](/docs/sdk/v0.50/learn/advanced/store) - The core Merkle store that holds the state. * [Bech32](/docs/sdk/v0.50/addresses/bech32) - Address format for Cosmos SDK applications. ## Modules specifications diff --git a/docs/sdk/v0.50/build/tooling/README.mdx b/docs/sdk/v0.50/build/tooling/README.mdx index a311bab6..1d564859 100644 --- a/docs/sdk/v0.50/build/tooling/README.mdx +++ b/docs/sdk/v0.50/build/tooling/README.mdx @@ -13,7 +13,7 @@ This includes tools for development, operating a node, and ease of use of a Cosm * [Cosmovisor](/docs/sdk/v0.50/build/tooling/cosmovisor) * [Confix](/docs/sdk/v0.50/build/tooling/confix) -* [Hubl](/docs/sdk/v0.50/hubl) +* [Hubl](/docs/sdk/v0.50/build/tooling/hubl) * [Rosetta](https://docs.cosmos.network/main/run-node/rosetta) ## Other Tools diff --git a/docs/sdk/v0.50/learn/advanced/baseapp.mdx b/docs/sdk/v0.50/learn/advanced/baseapp.mdx index 9c7ef56a..912d3d7e 100644 --- a/docs/sdk/v0.50/learn/advanced/baseapp.mdx +++ b/docs/sdk/v0.50/learn/advanced/baseapp.mdx @@ -10,8 +10,8 @@ This document describes `BaseApp`, the abstraction that implements the core func **Pre-requisite Readings** -* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.50/beginner/app-anatomy) -* [Lifecycle of a Cosmos SDK transaction](/docs/sdk/v0.50/beginner/tx-lifecycle) +* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.50/learn/beginner/app-anatomy) +* [Lifecycle of a Cosmos SDK transaction](/docs/sdk/v0.50/learn/beginner/tx-lifecycle) @@ -1340,7 +1340,7 @@ Let us go through the most important components. First, the important parameters that are initialized during the bootstrapping of the application: -* [`CommitMultiStore`](/docs/sdk/v0.50/store#commitmultistore): This is the main store of the application, +* [`CommitMultiStore`](/docs/sdk/v0.50/learn/advanced/store#commitmultistore): This is the main store of the application, which holds the canonical state that is committed at the [end of each block](#commit). This store is **not** cached, meaning it is not used to update the application's volatile (un-committed) states. The `CommitMultiStore` is a multi-store, meaning a store of stores. Each module of the application @@ -1358,7 +1358,7 @@ First, the important parameters that are initialized during the bootstrapping of * [`AnteHandler`](#antehandler): This handler is used to handle signature verification, fee payment, and other pre-message execution checks when a transaction is received. It's executed during [`CheckTx/RecheckTx`](#checktx) and [`FinalizeBlock`](#finalizeblock). -* [`InitChainer`](/docs/sdk/v0.50/beginner/app-anatomy#initchainer), [`PreBlocker`](/docs/sdk/v0.50/beginner/app-anatomy#preblocker), [`BeginBlocker` and `EndBlocker`](/docs/sdk/v0.50/beginner/app-anatomy#beginblocker-and-endblocker): These are +* [`InitChainer`](/docs/sdk/v0.50/learn/beginner/app-anatomy#initchainer), [`PreBlocker`](/docs/sdk/v0.50/learn/beginner/app-anatomy#preblocker), [`BeginBlocker` and `EndBlocker`](/docs/sdk/v0.50/learn/beginner/app-anatomy#beginblocker-and-endblocker): These are the functions executed when the application receives the `InitChain` and `FinalizeBlock` ABCI messages from the underlying CometBFT engine. @@ -1374,7 +1374,7 @@ Finally, a few more important parameters: * `voteInfos`: This parameter carries the list of validators whose precommit is missing, either because they did not vote or because the proposer did not include their vote. This information is - carried by the [Context](/docs/sdk/v0.50/context) and can be used by the application for various things like + carried by the [Context](/docs/sdk/v0.50/learn/advanced/context) and can be used by the application for various things like punishing absent validators. * `minGasPrices`: This parameter defines the minimum gas prices accepted by the node. This is a **local** parameter, meaning each full-node can set a different `minGasPrices`. It is used in the @@ -1384,7 +1384,7 @@ Finally, a few more important parameters: `minGasPrices` (e.g. if `minGasPrices == 1uatom,1photon`, the `gas-price` of the transaction must be greater than `1uatom` OR `1photon`). * `appVersion`: Version of the application. It is set in the - [application's constructor function](/docs/sdk/v0.50/beginner/app-anatomy#constructor-function). + [application's constructor function](/docs/sdk/v0.50/learn/beginner/app-anatomy#constructor-function). ## Constructor @@ -1500,13 +1500,13 @@ When messages and queries are received by the application, they must be routed t The [default `msgServiceRouter` included in `BaseApp`](https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.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.50.0-alpha.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](/docs/sdk/v0.50//build/building-modules/module-manager#manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.50/beginner/app-anatomy#constructor-function). +The application's `msgServiceRouter` is initialized with all the routes using the application's [module manager](/docs/sdk/v0.50//build/building-modules/module-manager#manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.50/learn/beginner/app-anatomy#constructor-function). ### gRPC Query Router Similar to `sdk.Msg`s, [`queries`](/docs/sdk/v0.50//build/building-modules/messages-and-queries#queries) need to be routed to the appropriate module's [`Query` service](/docs/sdk/v0.50//build/building-modules/query-services). To do so, `BaseApp` holds a `grpcQueryRouter`, which maps modules' fully-qualified service methods (`string`, defined in their Protobuf `Query` gRPC) to their `QueryServer` implementation. The `grpcQueryRouter` is called during the initial stages of query processing, which can be either by directly sending a gRPC query to the gRPC endpoint, or via the [`Query` ABCI message](#query) on the CometBFT RPC endpoint. -Just like the `msgServiceRouter`, the `grpcQueryRouter` is initialized with all the query routes using the application's [module manager](/docs/sdk/v0.50//build/building-modules/module-manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.50/beginner/app-anatomy#app-constructor). +Just like the `msgServiceRouter`, the `grpcQueryRouter` is initialized with all the query routes using the application's [module manager](/docs/sdk/v0.50//build/building-modules/module-manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.50/learn/beginner/app-anatomy#app-constructor). ## Main ABCI 2.0 Messages @@ -1586,7 +1586,7 @@ Unconfirmed transactions are relayed to peers only if they pass `CheckTx`. `CheckTx()` can perform both *stateful* and *stateless* checks, but developers should strive to make the checks **lightweight** because gas fees are not charged for the resources (CPU, data load...) used during the `CheckTx`. -In the Cosmos SDK, after [decoding transactions](/docs/sdk/v0.50/encoding), `CheckTx()` is implemented +In the Cosmos SDK, after [decoding transactions](/docs/sdk/v0.50/learn/advanced/encoding), `CheckTx()` is implemented to do the following checks: 1. Extract the `sdk.Msg`s from the transaction. @@ -1594,16 +1594,16 @@ to do the following checks: first, as *stateless* checks are less computationally expensive than *stateful* checks. If `ValidateBasic()` fail, `CheckTx` returns before running *stateful* checks, which saves resources. This check is still performed for messages that have not yet migrated to the new message validation mechanism defined in [RFC 001](https://docs.cosmos.network/main/rfc/rfc-001-tx-validation) and still have a `ValidateBasic()` method. -3. Perform non-module related *stateful* checks on the [account](/docs/sdk/v0.50/beginner/accounts). This step is mainly about checking +3. Perform non-module related *stateful* checks on the [account](/docs/sdk/v0.50/learn/beginner/accounts). This step is mainly about checking that the `sdk.Msg` signatures are valid, that enough fees are provided and that the sending account - has enough funds to pay for said fees. Note that no precise [`gas`](/docs/sdk/v0.50/beginner/gas-fees) counting occurs here, - as `sdk.Msg`s are not processed. Usually, the [`AnteHandler`](/docs/sdk/v0.50/beginner/gas-fees#antehandler) will check that the `gas` provided + has enough funds to pay for said fees. Note that no precise [`gas`](/docs/sdk/v0.50/learn/beginner/gas-fees) counting occurs here, + as `sdk.Msg`s are not processed. Usually, the [`AnteHandler`](/docs/sdk/v0.50/learn/beginner/gas-fees#antehandler) will check that the `gas` provided with the transaction is superior to a minimum reference gas amount based on the raw transaction size, in order to avoid spam with transactions that provide 0 gas. `CheckTx` does **not** process `sdk.Msg`s - they only need to be processed when the canonical state needs to be updated, which happens during `FinalizeBlock`. -Steps 2. and 3. are performed by the [`AnteHandler`](/docs/sdk/v0.50/beginner/gas-fees#antehandler) in the [`RunTx()`](#runtx-antehandler-and-runmsgs) +Steps 2. and 3. are performed by the [`AnteHandler`](/docs/sdk/v0.50/learn/beginner/gas-fees#antehandler) in the [`RunTx()`](#runtx-antehandler-and-runmsgs) function, which `CheckTx()` calls with the `runTxModeCheck` mode. During each step of `CheckTx()`, a special [volatile state](#state-updates) called `checkState` is updated. This state is used to keep track of the temporary changes triggered by the `CheckTx()` calls of each transaction without modifying @@ -1873,7 +1873,7 @@ return next(ctx, tx, simulate) } ``` -* `Events ([]cmn.KVPair)`: Key-Value tags for filtering and indexing transactions (eg. by account). See [`event`s](/docs/sdk/v0.50/events) for more. +* `Events ([]cmn.KVPair)`: Key-Value tags for filtering and indexing transactions (eg. by account). See [`event`s](/docs/sdk/v0.50/learn/advanced/events) for more. * `Codespace (string)`: Namespace for the Code. #### RecheckTx @@ -1891,7 +1891,7 @@ This allows certain checks like signature verification can be skipped during `Ch `RunTx` is called from `CheckTx`/`Finalizeblock` to handle the transaction, with `execModeCheck` or `execModeFinalize` as parameter to differentiate between the two modes of execution. Note that when `RunTx` receives a transaction, it has already been decoded. -The first thing `RunTx` does upon being called is to retrieve the `context`'s `CacheMultiStore` by calling the `getContextForTx()` function with the appropriate mode (either `runTxModeCheck` or `execModeFinalize`). This `CacheMultiStore` is a branch of the main store, with cache functionality (for query requests), instantiated during `FinalizeBlock` for transaction execution and during the `Commit` of the previous block for `CheckTx`. After that, two `defer func()` are called for [`gas`](/docs/sdk/v0.50/beginner/gas-fees) management. They are executed when `runTx` returns and make sure `gas` is actually consumed, and will throw errors, if any. +The first thing `RunTx` does upon being called is to retrieve the `context`'s `CacheMultiStore` by calling the `getContextForTx()` function with the appropriate mode (either `runTxModeCheck` or `execModeFinalize`). This `CacheMultiStore` is a branch of the main store, with cache functionality (for query requests), instantiated during `FinalizeBlock` for transaction execution and during the `Commit` of the previous block for `CheckTx`. After that, two `defer func()` are called for [`gas`](/docs/sdk/v0.50/learn/beginner/gas-fees) management. They are executed when `runTx` returns and make sure `gas` is actually consumed, and will throw errors, if any. After that, `RunTx()` calls `ValidateBasic()`, when available and for backward compatibility, on each `sdk.Msg`in the `Tx`, which runs preliminary *stateless* validity checks. If any `sdk.Msg` fails to pass `ValidateBasic()`, `RunTx()` returns with an error. @@ -3181,7 +3181,7 @@ error { } ``` -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](/docs/sdk/v0.50/ocap) of the Cosmos SDK. +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](/docs/sdk/v0.50/learn/advanced/ocap) of the Cosmos SDK. Finally, the [`RunMsgs()`](#runmsgs) function is called to process the `sdk.Msg`s in the `Tx`. In preparation of this step, just like with the `anteHandler`, both the `checkState`/`finalizeBlockState`'s `context` and `context`'s `CacheMultiStore` are branched using the `cacheTxContext()` function. @@ -3323,13 +3323,13 @@ PostHandle(ctx Context, _ Tx, _, _ bool, _ PostHandler) (Context, error) { The `AnteHandler` is theoretically optional, but still a very important component of public blockchain networks. It serves 3 primary purposes: -* Be a primary line of defense against spam and second line of defense (the first one being the mempool) against transaction replay with fees deduction and [`sequence`](/docs/sdk/v0.50/transactions#transaction-generation) checking. +* Be a primary line of defense against spam and second line of defense (the first one being the mempool) against transaction replay with fees deduction and [`sequence`](/docs/sdk/v0.50/learn/advanced/transactions#transaction-generation) checking. * 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](/docs/sdk/v0.50/beginner/app-anatomy#application-constructor). The most widely used `anteHandler` is the [`auth` module](https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/auth/ante/ante.go). +`BaseApp` holds an `anteHandler` as parameter that is initialized in the [application's constructor](/docs/sdk/v0.50/learn/beginner/app-anatomy#application-constructor). The most widely used `anteHandler` is the [`auth` module](https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/auth/ante/ante.go). -Click [here](/docs/sdk/v0.50/beginner/gas-fees#antehandler) for more on the `anteHandler`. +Click [here](/docs/sdk/v0.50/learn/beginner/gas-fees#antehandler) for more on the `anteHandler`. ### RunMsgs @@ -3376,9 +3376,9 @@ The [`InitChain` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x * [Consensus Parameters](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_app_requirements.md#consensus-parameters) via `setConsensusParams`. * [`checkState` and `finalizeBlockState`](#state-updates) via `setState`. -* The [block gas meter](/docs/sdk/v0.50/beginner/gas-fees#block-gas-meter), with infinite gas to process genesis transactions. +* The [block gas meter](/docs/sdk/v0.50/learn/beginner/gas-fees#block-gas-meter), with infinite gas to process genesis transactions. -Finally, the `InitChain(req abci.RequestInitChain)` method of `BaseApp` calls the [`initChainer()`](/docs/sdk/v0.50/beginner/app-anatomy#initchainer) of the application in order to initialize the main state of the application from the `genesis file` and, if defined, call the [`InitGenesis`](/docs/sdk/v0.50//build/building-modules/genesis#initgenesis) function of each of the application's modules. +Finally, the `InitChain(req abci.RequestInitChain)` method of `BaseApp` calls the [`initChainer()`](/docs/sdk/v0.50/learn/beginner/app-anatomy#initchainer) of the application in order to initialize the main state of the application from the `genesis file` and, if defined, call the [`InitGenesis`](/docs/sdk/v0.50//build/building-modules/genesis#initgenesis) function of each of the application's modules. ### FinalizeBlock @@ -4703,7 +4703,7 @@ return legacyVotes #### PreBlock -* Run the application's [`preBlocker()`](/docs/sdk/v0.50/beginner/app-anatomy#preblocker), which mainly runs the [`PreBlocker()`](/docs/sdk/v0.50//build/building-modules/preblock#preblock) method of each of the modules. +* Run the application's [`preBlocker()`](/docs/sdk/v0.50/learn/beginner/app-anatomy#preblocker), which mainly runs the [`PreBlocker()`](/docs/sdk/v0.50//build/building-modules/preblock#preblock) method of each of the modules. #### BeginBlock @@ -5993,13 +5993,13 @@ return legacyVotes } ``` - This function also resets the [main gas meter](/docs/sdk/v0.50/beginner/gas-fees#main-gas-meter). + This function also resets the [main gas meter](/docs/sdk/v0.50/learn/beginner/gas-fees#main-gas-meter). -* Initialize the [block gas meter](/docs/sdk/v0.50/beginner/gas-fees#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. +* Initialize the [block gas meter](/docs/sdk/v0.50/learn/beginner/gas-fees#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()`](/docs/sdk/v0.50/beginner/app-anatomy#beginblocker-and-endblocker), which mainly runs the [`BeginBlocker()`](/docs/sdk/v0.50//build/building-modules/beginblock-endblock#beginblock) method of each of the modules. +* Run the application's [`beginBlocker()`](/docs/sdk/v0.50/learn/beginner/app-anatomy#beginblocker-and-endblocker), which mainly runs the [`BeginBlocker()`](/docs/sdk/v0.50//build/building-modules/beginblock-endblock#beginblock) method of each of the modules. -* Set the [`VoteInfos`](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_methods.md#voteinfo) of the application, i.e. the list of validators whose *precommit* for the previous block was included by the proposer of the current block. This information is carried into the [`Context`](/docs/sdk/v0.50/context) so that it can be used during transaction execution and EndBlock. +* Set the [`VoteInfos`](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_methods.md#voteinfo) of the application, i.e. the list of validators whose *precommit* for the previous block was included by the proposer of the current block. This information is carried into the [`Context`](/docs/sdk/v0.50/learn/advanced/context) so that it can be used during transaction execution and EndBlock. #### Transaction Execution @@ -7666,7 +7666,7 @@ Each transactions returns a response to the underlying consensus engine of type * `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 transaction execution, this value is computed by multiplying the standard cost of a transaction byte by the size of the raw transaction, and by adding gas each time a read/write to the store occurs. -* `Events ([]cmn.KVPair)`: Key-Value tags for filtering and indexing transactions (eg. by account). See [`event`s](/docs/sdk/v0.50/events) for more. +* `Events ([]cmn.KVPair)`: Key-Value tags for filtering and indexing transactions (eg. by account). See [`event`s](/docs/sdk/v0.50/learn/advanced/events) for more. * `Codespace (string)`: Namespace for the Code. #### EndBlock diff --git a/docs/sdk/v0.50/learn/advanced/cli.mdx b/docs/sdk/v0.50/learn/advanced/cli.mdx index 0b13b37f..3d9169d1 100644 --- a/docs/sdk/v0.50/learn/advanced/cli.mdx +++ b/docs/sdk/v0.50/learn/advanced/cli.mdx @@ -28,7 +28,7 @@ The first four strings specify the command: The next two strings are arguments: the `from_address` the user wishes to send from, the `to_address` of the recipient, and the `amount` they want to send. Finally, the last few strings of the command are optional flags to indicate how much the user is willing to pay in fees (calculated using the amount of gas used to execute the transaction and the gas prices provided by the user). -The CLI interacts with a [node](/docs/sdk/v0.50/node) to handle this command. The interface itself is defined in a `main.go` file. +The CLI interacts with a [node](/docs/sdk/v0.50/learn/advanced/node) to handle this command. The interface itself is defined in a `main.go` file. ### Building the CLI @@ -36,7 +36,7 @@ The `main.go` file needs to have a `main()` function that creates a root command * **setting configurations** by reading in configuration files (e.g. the Cosmos SDK config file). * **adding any flags** to it, such as `--chain-id`. -* **instantiating the `codec`** by injecting the application codecs. The [`codec`](/docs/sdk/v0.50/encoding) is used to encode and decode data structures for the application - stores can only persist `[]byte`s so the developer must define a serialization format for their data structures or use the default, Protobuf. +* **instantiating the `codec`** by injecting the application codecs. The [`codec`](/docs/sdk/v0.50/learn/advanced/encoding) is used to encode and decode data structures for the application - stores can only persist `[]byte`s so the developer must define a serialization format for their data structures or use the default, Protobuf. * **adding subcommand** for all the possible user interactions, including [transaction commands](#transaction-commands) and [query commands](#query-commands). 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: @@ -73,7 +73,7 @@ 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`](/docs/sdk/v0.50/node). The Status of a node includes `NodeInfo`,`SyncInfo` and `ValidatorInfo`. +* **Status** command from the Cosmos SDK rpc client tools, which prints information about the status of the connected [`Node`](/docs/sdk/v0.50/learn/advanced/node). The Status of a node includes `NodeInfo`,`SyncInfo` and `ValidatorInfo`. * **Keys** [commands](https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.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 ` 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.50.0-alpha.0/client/keys/add.go). For more details about usage of `--keyring-backend` for storage of key credentials look at the [keyring docs](/docs/sdk/v0.50//user/run-node/keyring). * **Server** commands from the Cosmos SDK server package. These commands are responsible for providing the mechanisms necessary to start an ABCI CometBFT application and provides the CLI framework (based on [cobra](https://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. Learn more [here](https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/server). @@ -1217,7 +1217,7 @@ The root-level `status` and `keys` subcommands are common across most applicatio ### Transaction Commands -[Transactions](/docs/sdk/v0.50/transactions) are objects wrapping [`Msg`s](/docs/sdk/v0.50//build/building-modules/messages-and-queries#messages) that trigger state changes. To enable the creation of transactions using the CLI interface, a function `txCommand` is generally added to the `rootCmd`: +[Transactions](/docs/sdk/v0.50/learn/advanced/transactions) are objects wrapping [`Msg`s](/docs/sdk/v0.50//build/building-modules/messages-and-queries#messages) that trigger state changes. To enable the creation of transactions using the CLI interface, a function `txCommand` is generally added to the `rootCmd`: ```go expandable //go:build !app_v1 diff --git a/docs/sdk/v0.50/learn/advanced/context.mdx b/docs/sdk/v0.50/learn/advanced/context.mdx index 014f5cd4..30ecb799 100644 --- a/docs/sdk/v0.50/learn/advanced/context.mdx +++ b/docs/sdk/v0.50/learn/advanced/context.mdx @@ -17,7 +17,7 @@ The `context` is a data structure intended to be passed from function to functio ## Context Definition -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](/docs/sdk/v0.50/store#base-layer-kvstores) in the [`multistore`](/docs/sdk/v0.50/store#multistore) and retrieve transactional context such as the block header and gas meter. +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](/docs/sdk/v0.50/learn/advanced/store#base-layer-kvstores) in the [`multistore`](/docs/sdk/v0.50/learn/advanced/store#multistore) and retrieve transactional context such as the block header and gas meter. ```go expandable package types @@ -722,18 +722,18 @@ return ctx.Value(SdkContextKey).(Context) ``` * **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`](/docs/sdk/v0.50/store#multistore) which is provided when a `Context` is created. Calling the `KVStore()` and `TransientStore()` methods allows modules to fetch their respective [`KVStore`](/docs/sdk/v0.50/store#base-layer-kvstores) using their unique `StoreKey`. +* **Multistore:** Every application's `BaseApp` contains a [`CommitMultiStore`](/docs/sdk/v0.50/learn/advanced/store#multistore) which is provided when a `Context` is created. Calling the `KVStore()` and `TransientStore()` methods allows modules to fetch their respective [`KVStore`](/docs/sdk/v0.50/learn/advanced/store#base-layer-kvstores) using their unique `StoreKey`. * **Header:** The [header](https://docs.cometbft.com/v0.37/spec/core/data_structures#header) is a Blockchain type. It carries important information about the state of the blockchain, such as block height and proposer of the current block. * **Header Hash:** The current block header hash, obtained during `abci.FinalizeBlock`. * **Chain ID:** The unique identification number of the blockchain a block pertains to. -* **Transaction Bytes:** The `[]byte` representation of a transaction being processed using the context. Every transaction is processed by various parts of the Cosmos SDK and consensus engine (e.g. CometBFT) throughout its [lifecycle](/docs/sdk/v0.50/beginner/tx-lifecycle), some of which do not have any understanding of transaction types. Thus, transactions are marshaled into the generic `[]byte` type using some kind of [encoding format](/docs/sdk/v0.50/encoding) such as [Amino](/docs/sdk/v0.50/encoding). +* **Transaction Bytes:** The `[]byte` representation of a transaction being processed using the context. Every transaction is processed by various parts of the Cosmos SDK and consensus engine (e.g. CometBFT) throughout its [lifecycle](/docs/sdk/v0.50/learn/beginner/tx-lifecycle), some of which do not have any understanding of transaction types. Thus, transactions are marshaled into the generic `[]byte` type using some kind of [encoding format](/docs/sdk/v0.50/learn/advanced/encoding) such as [Amino](/docs/sdk/v0.50/learn/advanced/encoding). * **Logger:** A `logger` from the CometBFT libraries. Learn more about logs [here](https://docs.cometbft.com/v0.37/core/configuration). Modules call this method to create their own unique module-specific logger. * **VoteInfo:** A list of the ABCI type [`VoteInfo`](https://docs.cometbft.com/master/spec/abci/abci.html#voteinfo), which includes the name of a validator and a boolean indicating whether they have signed the block. -* **Gas Meters:** Specifically, a [`gasMeter`](/docs/sdk/v0.50/beginner/gas-fees#main-gas-meter) for the transaction currently being processed using the context and a [`blockGasMeter`](/docs/sdk/v0.50/beginner/gas-fees#block-gas-meter) for the entire block it belongs to. Users specify how much in fees they wish to pay for the execution of their transaction; these gas meters keep track of how much [gas](/docs/sdk/v0.50/beginner/gas-fees) has been used in the transaction or block so far. If the gas meter runs out, execution halts. +* **Gas Meters:** Specifically, a [`gasMeter`](/docs/sdk/v0.50/learn/beginner/gas-fees#main-gas-meter) for the transaction currently being processed using the context and a [`blockGasMeter`](/docs/sdk/v0.50/learn/beginner/gas-fees#block-gas-meter) for the entire block it belongs to. Users specify how much in fees they wish to pay for the execution of their transaction; these gas meters keep track of how much [gas](/docs/sdk/v0.50/learn/beginner/gas-fees) has been used in the transaction or block so far. If the gas meter runs out, execution halts. * **CheckTx Mode:** A boolean value indicating whether a transaction should be processed in `CheckTx` or `DeliverTx` mode. -* **Min Gas Price:** The minimum [gas](/docs/sdk/v0.50/beginner/gas-fees) price a node is willing to take in order to include a transaction in its block. This price is a local value configured by each node individually, and should therefore **not be used in any functions used in sequences leading to state-transitions**. +* **Min Gas Price:** The minimum [gas](/docs/sdk/v0.50/learn/beginner/gas-fees) price a node is willing to take in order to include a transaction in its block. This price is a local value configured by each node individually, and should therefore **not be used in any functions used in sequences leading to state-transitions**. * **Consensus Params:** The ABCI type [Consensus Parameters](https://docs.cometbft.com/master/spec/abci/apps.html#consensus-parameters), which specify certain limits for the blockchain, such as maximum gas for a block. -* **Event Manager:** The event manager allows any caller with access to a `Context` to emit [`Events`](/docs/sdk/v0.50/events). Modules may define module specific +* **Event Manager:** The event manager allows any caller with access to a `Context` to emit [`Events`](/docs/sdk/v0.50/learn/advanced/events). Modules may define module specific `Events` by defining various `Types` and `Attributes` or use the common definitions found in `types/`. Clients can subscribe or query for these `Events`. These `Events` are collected throughout `FinalizeBlock` and are returned to CometBFT for indexing. * **Priority:** The transaction priority, only relevant in `CheckTx`. * **KV `GasConfig`:** Enables applications to set a custom `GasConfig` for the `KVStore`. @@ -769,14 +769,14 @@ goes wrong. The pattern of usage for a Context is as follows: 1. A process receives a Context `ctx` from its parent process, which provides information needed to perform the process. -2. The `ctx.ms` is a **branched store**, i.e. a branch of the [multistore](/docs/sdk/v0.50/store#multistore) is made so that the process can make changes to the state as it executes, without changing the original`ctx.ms`. This is useful to protect the underlying multistore in case the changes need to be reverted at some point in the execution. +2. The `ctx.ms` is a **branched store**, i.e. a branch of the [multistore](/docs/sdk/v0.50/learn/advanced/store#multistore) is made so that the process can make changes to the state as it executes, without changing the original`ctx.ms`. This is useful to protect the underlying multistore in case the changes need to be reverted at some point in the execution. 3. The process may read and write from `ctx` as it is executing. It may call a subprocess and pass `ctx` to it as needed. 4. When a subprocess returns, it checks if the result is a success or failure. If a failure, nothing needs to be done - the branch `ctx` is simply discarded. If successful, the changes made to the `CacheMultiStore` can be committed to the original `ctx.ms` via `Write()`. -For example, here is a snippet from the [`runTx`](/docs/sdk/v0.50/baseapp#runtx-antehandler-runmsgs-posthandler) function in [`baseapp`](/docs/sdk/v0.50/baseapp): +For example, here is a snippet from the [`runTx`](/docs/sdk/v0.50/learn/advanced/baseapp#runtx-antehandler-runmsgs-posthandler) function in [`baseapp`](/docs/sdk/v0.50/learn/advanced/baseapp): ```go runMsgCtx, msCache := app.cacheTxContext(ctx, txBytes) @@ -797,7 +797,7 @@ Here is the process: 1. Prior to calling `runMsgs` on the message(s) in the transaction, it uses `app.cacheTxContext()` to branch and cache the context and multistore. 2. `runMsgCtx` - the context with branched store, is used in `runMsgs` to return a result. -3. If the process is running in [`checkTxMode`](/docs/sdk/v0.50/baseapp#checktx), there is no need to write the +3. If the process is running in [`checkTxMode`](/docs/sdk/v0.50/learn/advanced/baseapp#checktx), there is no need to write the changes - the result is returned immediately. -4. If the process is running in [`deliverTxMode`](/docs/sdk/v0.50/baseapp#delivertx) and the result indicates +4. If the process is running in [`deliverTxMode`](/docs/sdk/v0.50/learn/advanced/baseapp#delivertx) and the result indicates a successful run over all the messages, the branched multistore is written back to the original. diff --git a/docs/sdk/v0.50/learn/advanced/encoding.mdx b/docs/sdk/v0.50/learn/advanced/encoding.mdx index 330c699a..f9d91bcc 100644 --- a/docs/sdk/v0.50/learn/advanced/encoding.mdx +++ b/docs/sdk/v0.50/learn/advanced/encoding.mdx @@ -69,7 +69,7 @@ Code generators can then match the `accepts_interface` and `implements_interface ### Transaction Encoding Another important use of Protobuf is the encoding and decoding of -[transactions](/docs/sdk/v0.50/transactions). Transactions are defined by the application or +[transactions](/docs/sdk/v0.50/learn/advanced/transactions). Transactions are defined by the application or the Cosmos SDK but are then passed to the underlying consensus engine to be relayed to other peers. Since the underlying consensus engine is agnostic to the application, the consensus engine accepts only transactions in the form of raw bytes. @@ -477,7 +477,7 @@ See [ADR-020](/docs/sdk/v0.50//architecture/adr-020-protobuf-transaction-encodin ### Interface Encoding and Usage of `Any` -The Protobuf DSL is strongly typed, which can make inserting variable-typed fields difficult. Imagine we want to create a `Profile` protobuf message that serves as a wrapper over [an account](/docs/sdk/v0.50/beginner/accounts): +The Protobuf DSL is strongly typed, which can make inserting variable-typed fields difficult. Imagine we want to create a `Profile` protobuf message that serves as a wrapper over [an account](/docs/sdk/v0.50/learn/beginner/accounts): ```protobuf message Profile { diff --git a/docs/sdk/v0.50/learn/advanced/events.mdx b/docs/sdk/v0.50/learn/advanced/events.mdx index 997208e6..f7d7950d 100644 --- a/docs/sdk/v0.50/learn/advanced/events.mdx +++ b/docs/sdk/v0.50/learn/advanced/events.mdx @@ -44,10 +44,10 @@ In addition, each module documents its events under in the `Events` sections of Lastly, Events are returned to the underlying consensus engine in the response of the following ABCI messages: -* [`BeginBlock`](/docs/sdk/v0.50/baseapp#beginblock) -* [`EndBlock`](/docs/sdk/v0.50/baseapp#endblock) -* [`CheckTx`](/docs/sdk/v0.50/baseapp#checktx) -* [`Transaction Execution`](/docs/sdk/v0.50/baseapp#transactionexecution) +* [`BeginBlock`](/docs/sdk/v0.50/learn/advanced/baseapp#beginblock) +* [`EndBlock`](/docs/sdk/v0.50/learn/advanced/baseapp#endblock) +* [`CheckTx`](/docs/sdk/v0.50/learn/advanced/baseapp#checktx) +* [`Transaction Execution`](/docs/sdk/v0.50/learn/advanced/baseapp#transactionexecution) ### Examples @@ -956,7 +956,7 @@ return updatedEvents Module developers should handle Event emission via the `EventManager#EmitTypedEvent` or `EventManager#EmitEvent` in each message `Handler` and in each `BeginBlock`/`EndBlock` handler. The `EventManager` is accessed via -the [`Context`](/docs/sdk/v0.50/context), where Event should be already registered, and emitted like this: +the [`Context`](/docs/sdk/v0.50/learn/advanced/context), where Event should be already registered, and emitted like this: **Typed events:** @@ -2255,7 +2255,7 @@ ctx.EventManager().EmitEvent( ) ``` -Where the `EventManager` is accessed via the [`Context`](/docs/sdk/v0.50/context). +Where the `EventManager` is accessed via the [`Context`](/docs/sdk/v0.50/learn/advanced/context). See the [`Msg` services](/docs/sdk/v0.50//build/building-modules/msg-services) concept doc for a more detailed view on how to typically implement Events and use the `EventManager` in modules. @@ -2299,7 +2299,7 @@ Subscribing to this Event would be done like so: } ``` -where `ownerAddress` is an address following the [`AccAddress`](/docs/sdk/v0.50/beginner/accounts#addresses) format. +where `ownerAddress` is an address following the [`AccAddress`](/docs/sdk/v0.50/learn/beginner/accounts#addresses) format. The same way can be used to subscribe to [legacy events](https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/bank/types/events.go). diff --git a/docs/sdk/v0.50/learn/advanced/grpc_rest.mdx b/docs/sdk/v0.50/learn/advanced/grpc_rest.mdx index 74ff381f..1c5eafc9 100644 --- a/docs/sdk/v0.50/learn/advanced/grpc_rest.mdx +++ b/docs/sdk/v0.50/learn/advanced/grpc_rest.mdx @@ -25,7 +25,7 @@ All endpoints are defaulted to localhost and must be modified to be exposed to t ## gRPC Server -In the Cosmos SDK, Protobuf is the main [encoding](/docs/sdk/v0.50/encoding) library. This brings a wide range of Protobuf-based tools that can be plugged into the Cosmos SDK. One such tool is [gRPC](https://grpc.io), a modern open-source high performance RPC framework that has decent client support in several languages. +In the Cosmos SDK, Protobuf is the main [encoding](/docs/sdk/v0.50/learn/advanced/encoding) library. This brings a wide range of Protobuf-based tools that can be plugged into the Cosmos SDK. One such tool is [gRPC](https://grpc.io), a modern open-source high performance RPC framework that has decent client support in several languages. Each module exposes a [Protobuf `Query` service](/docs/sdk/v0.50//build/building-modules/messages-and-queries#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: @@ -199,7 +199,7 @@ Some CometBFT RPC endpoints are directly related to the Cosmos SDK: * `/store/{storeName}/subspace`: this will directly query the named store for key/value pairs in which the key has the value of the `data` parameter as a prefix. * `/p2p/filter/addr/{port}`: this will return a filtered list of the node's P2P peers by address port. * `/p2p/filter/id/{id}`: this will return a filtered list of the node's P2P peers by ID. -* `/broadcast_tx_{sync,async,commit}`: these 3 endpoints will broadcast a transaction to other peers. CLI, gRPC and REST expose [a way to broadcast transactions](/docs/sdk/v0.50/transactions#broadcasting-the-transaction), but they all use these 3 CometBFT RPCs under the hood. +* `/broadcast_tx_{sync,async,commit}`: these 3 endpoints will broadcast a transaction to other peers. CLI, gRPC and REST expose [a way to broadcast transactions](/docs/sdk/v0.50/learn/advanced/transactions#broadcasting-the-transaction), but they all use these 3 CometBFT RPCs under the hood. ## Comparison Table diff --git a/docs/sdk/v0.50/learn/advanced/node.mdx b/docs/sdk/v0.50/learn/advanced/node.mdx index 83f3860d..3fd202f2 100644 --- a/docs/sdk/v0.50/learn/advanced/node.mdx +++ b/docs/sdk/v0.50/learn/advanced/node.mdx @@ -20,8 +20,8 @@ The full-node client of any Cosmos SDK application is built by running a `main` In general, developers will implement the `main.go` function with the following structure: -* First, an [`encodingCodec`](/docs/sdk/v0.50/encoding) is instantiated for the application. -* Then, the `config` is retrieved and config parameters are set. This mainly involves setting the Bech32 prefixes for [addresses](/docs/sdk/v0.50/beginner/accounts#addresses). +* First, an [`encodingCodec`](/docs/sdk/v0.50/learn/advanced/encoding) is instantiated for the application. +* Then, the `config` is retrieved and config parameters are set. This mainly involves setting the Bech32 prefixes for [addresses](/docs/sdk/v0.50/learn/beginner/accounts#addresses). ```go expandable package types @@ -1422,7 +1422,7 @@ Application ) ``` -In practice, the [constructor of the application](/docs/sdk/v0.50/beginner/app-anatomy#constructor-function) is passed as the `appCreator`. +In practice, the [constructor of the application](/docs/sdk/v0.50/learn/beginner/app-anatomy#constructor-function) is passed as the `appCreator`. ```go expandable //go:build !app_v1 @@ -2496,7 +2496,7 @@ return app, cleanupFn, nil } ``` -The CometBFT node can be created with `app` because the latter satisfies the [`abci.Application` interface](https://github.com/cometbft/cometbft/blob/v0.37.0/abci/types/application.go#L9-L35) (given that `app` extends [`baseapp`](/docs/sdk/v0.50/baseapp)). As part of the `node.New` method, CometBFT makes sure that the height of the application (i.e. number of blocks since genesis) is equal to the height of the CometBFT 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 CometBFT node. Finally, if the height of the application is `0`, the CometBFT node will call [`InitChain`](/docs/sdk/v0.50/baseapp#initchain) on the application to initialize the state from the genesis file. +The CometBFT node can be created with `app` because the latter satisfies the [`abci.Application` interface](https://github.com/cometbft/cometbft/blob/v0.37.0/abci/types/application.go#L9-L35) (given that `app` extends [`baseapp`](/docs/sdk/v0.50/learn/advanced/baseapp)). As part of the `node.New` method, CometBFT makes sure that the height of the application (i.e. number of blocks since genesis) is equal to the height of the CometBFT 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 CometBFT node. Finally, if the height of the application is `0`, the CometBFT node will call [`InitChain`](/docs/sdk/v0.50/learn/advanced/baseapp#initchain) on the application to initialize the state from the genesis file. Once the CometBFT node is instantiated and in sync with the application, the node can be started: diff --git a/docs/sdk/v0.50/learn/advanced/store.mdx b/docs/sdk/v0.50/learn/advanced/store.mdx index e30c5e5a..2367e049 100644 --- a/docs/sdk/v0.50/learn/advanced/store.mdx +++ b/docs/sdk/v0.50/learn/advanced/store.mdx @@ -10,7 +10,7 @@ A store is a data structure that holds the state of the application. **Pre-requisite Readings** -* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.50/learn/beginner/overview-app) +* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.50/learn/beginner/app-anatomy) @@ -1430,7 +1430,7 @@ return keys } ``` -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](/docs/sdk/v0.50/context#Store-branching) +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](/docs/sdk/v0.50/learn/advanced/context#Store-branching) ### Commit Store @@ -2804,7 +2804,7 @@ return keys } ``` -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](/docs/sdk/v0.50/ocap) 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`. +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](/docs/sdk/v0.50/learn/advanced/ocap) 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`. The Cosmos SDK comes with many types of stores, the most used being [`CommitMultiStore`](#multistore), [`KVStore`](#kvstore) and [`GasKv` store](#gaskv-store). [Other types of stores](#other-stores) include `Transient` and `TraceKV` stores. @@ -5685,7 +5685,7 @@ batch.Set([]byte(latestVersionKey), bz) } ``` -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`](/docs/sdk/v0.50/baseapp). +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`](/docs/sdk/v0.50/learn/advanced/baseapp). ### CacheMultiStore @@ -5934,7 +5934,7 @@ A `KVStore` is a simple key-value store used to store and retrieve data. A `Comm Individual `KVStore`s are used by modules to manage a subset of the global state. `KVStores` can be accessed by objects that hold a specific key. This `key` should only be exposed to the [`keeper`](/docs/sdk/v0.50//build/building-modules/keeper) of the module that defines the store. -`CommitKVStore`s are declared by proxy of their respective `key` and mounted on the application's [multistore](#multistore) in the [main application file](/docs/sdk/v0.50/beginner/app-anatomy#core-application-file). In the same file, the `key` is also passed to the module's `keeper` that is responsible for managing the store. +`CommitKVStore`s are declared by proxy of their respective `key` and mounted on the application's [multistore](#multistore) in the [main application file](/docs/sdk/v0.50/learn/beginner/app-anatomy#core-application-file). In the same file, the `key` is also passed to the module's `keeper` that is responsible for managing the store. ```go expandable package types @@ -8101,7 +8101,7 @@ string { } ``` -Transient stores are typically accessed via the [`context`](/docs/sdk/v0.50/context) via the `TransientStore()` method: +Transient stores are typically accessed via the [`context`](/docs/sdk/v0.50/learn/advanced/context) via the `TransientStore()` method: ```go expandable package types @@ -9352,7 +9352,7 @@ This is the type used whenever an IAVL Store needs to be branched to create an i ### `GasKv` Store -Cosmos SDK applications use [`gas`](/docs/sdk/v0.50/beginner/gas-fees) to track resources usage and prevent spam. [`GasKv.Store`](https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.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. +Cosmos SDK applications use [`gas`](/docs/sdk/v0.50/learn/beginner/gas-fees) to track resources usage and prevent spam. [`GasKv.Store`](https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.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. ```go expandable package gaskv @@ -9968,7 +9968,7 @@ GasConfig { } ``` -By default, all `KVStores` are wrapped in `GasKv.Stores` when retrieved. This is done in the `KVStore()` method of the [`context`](/docs/sdk/v0.50/context): +By default, all `KVStores` are wrapped in `GasKv.Stores` when retrieved. This is done in the `KVStore()` method of the [`context`](/docs/sdk/v0.50/learn/advanced/context): ```go expandable package types diff --git a/docs/sdk/v0.50/learn/advanced/transactions.mdx b/docs/sdk/v0.50/learn/advanced/transactions.mdx index f756764e..8feda10f 100644 --- a/docs/sdk/v0.50/learn/advanced/transactions.mdx +++ b/docs/sdk/v0.50/learn/advanced/transactions.mdx @@ -16,9 +16,9 @@ title: Transactions ## Transactions -Transactions are comprised of metadata held in [contexts](/docs/sdk/v0.50/context) and [`sdk.Msg`s](/docs/sdk/v0.50//build/building-modules/messages-and-queries) that trigger state changes within a module through the module's Protobuf [`Msg` service](/docs/sdk/v0.50//build/building-modules/msg-services). +Transactions are comprised of metadata held in [contexts](/docs/sdk/v0.50/learn/advanced/context) and [`sdk.Msg`s](/docs/sdk/v0.50//build/building-modules/messages-and-queries) that trigger state changes within a module through the module's Protobuf [`Msg` service](/docs/sdk/v0.50//build/building-modules/msg-services). -When users want to interact with an application and make state changes (e.g. sending coins), they create transactions. Each of a transaction's `sdk.Msg` must be signed using the private key associated with the appropriate account(s), before the transaction is broadcasted to the network. A transaction must then be included in a block, validated, and approved by the network through the consensus process. To read more about the lifecycle of a transaction, click [here](/docs/sdk/v0.50/beginner/tx-lifecycle). +When users want to interact with an application and make state changes (e.g. sending coins), they create transactions. Each of a transaction's `sdk.Msg` must be signed using the private key associated with the appropriate account(s), before the transaction is broadcasted to the network. A transaction must then be included in a block, validated, and approved by the network through the consensus process. To read more about the lifecycle of a transaction, click [here](/docs/sdk/v0.50/learn/beginner/tx-lifecycle). ## Type Definition @@ -187,10 +187,10 @@ return "" It contains the following methods: * **GetMsgs:** unwraps the transaction and returns a list of contained `sdk.Msg`s - one transaction may have one or multiple messages, which are defined by module developers. -* **ValidateBasic:** lightweight, [*stateless*](/docs/sdk/v0.50/beginner/tx-lifecycle#types-of-checks) checks used by ABCI messages [`CheckTx`](/docs/sdk/v0.50/baseapp#checktx) and [`DeliverTx`](/docs/sdk/v0.50/baseapp#delivertx) to make sure transactions are not invalid. For example, the [`auth`](https://github.com/cosmos/cosmos-sdk/tree/main/x/auth) module's `ValidateBasic` function checks that its transactions are signed by the correct number of signers and that the fees do not exceed what the user's maximum. When [`runTx`](/docs/sdk/v0.50/baseapp#runtx) is checking a transaction created from the [`auth`](https://github.com/cosmos/cosmos-sdk/tree/main/x/auth/spec) module, it first runs `ValidateBasic` on each message, then runs the `auth` module AnteHandler which calls `ValidateBasic` for the transaction itself. +* **ValidateBasic:** lightweight, [*stateless*](/docs/sdk/v0.50/learn/beginner/tx-lifecycle#types-of-checks) checks used by ABCI messages [`CheckTx`](/docs/sdk/v0.50/learn/advanced/baseapp#checktx) and [`DeliverTx`](/docs/sdk/v0.50/learn/advanced/baseapp#delivertx) to make sure transactions are not invalid. For example, the [`auth`](https://github.com/cosmos/cosmos-sdk/tree/main/x/auth) module's `ValidateBasic` function checks that its transactions are signed by the correct number of signers and that the fees do not exceed what the user's maximum. When [`runTx`](/docs/sdk/v0.50/learn/advanced/baseapp#runtx) is checking a transaction created from the [`auth`](https://github.com/cosmos/cosmos-sdk/tree/main/x/auth/spec) module, it first runs `ValidateBasic` on each message, then runs the `auth` module AnteHandler which calls `ValidateBasic` for the transaction itself. -This function is different from the deprecated `sdk.Msg` [`ValidateBasic`](/docs/sdk/v0.50/beginner/tx-lifecycle#ValidateBasic) methods, which was performing basic validity checks on messages only. +This function is different from the deprecated `sdk.Msg` [`ValidateBasic`](/docs/sdk/v0.50/learn/beginner/tx-lifecycle#ValidateBasic) methods, which was performing basic validity checks on messages only. As a developer, you should rarely manipulate `Tx` directly, as `Tx` is really an intermediate type used for transaction generation. Instead, developers should prefer the `TxBuilder` interface, which you can learn more about [below](#transaction-generation). @@ -972,7 +972,7 @@ Once the transaction bytes are generated, there are currently three ways of broa #### CLI -Application developers create entry points to the application by creating a [command-line interface](/docs/sdk/v0.50/cli), [gRPC and/or REST interface](/docs/sdk/v0.50/grpc_rest), typically found in the application's `./cmd` folder. These interfaces allow users to interact with the application through command-line. +Application developers create entry points to the application by creating a [command-line interface](/docs/sdk/v0.50/learn/advanced/cli), [gRPC and/or REST interface](/docs/sdk/v0.50/learn/advanced/grpc_rest), typically found in the application's `./cmd` folder. These interfaces allow users to interact with the application through command-line. For the [command-line interface](/docs/sdk/v0.50//build/building-modules/module-interfaces#cli), module developers create subcommands to add as children to the application top-level transaction command `TxCmd`. CLI commands actually bundle all the steps of transaction processing into one simple command: creating messages, generating transactions and broadcasting. For concrete examples, see the [Interacting with a Node](/docs/sdk/v0.50//user/run-node/interact-node) section. An example transaction made using CLI looks like: diff --git a/docs/sdk/v0.50/learn/beginner/app-anatomy.mdx b/docs/sdk/v0.50/learn/beginner/app-anatomy.mdx index f19eeaa2..b5b29ea1 100644 --- a/docs/sdk/v0.50/learn/beginner/app-anatomy.mdx +++ b/docs/sdk/v0.50/learn/beginner/app-anatomy.mdx @@ -3006,7 +3006,7 @@ The Cosmos SDK offers developers the possibility to implement automatic executio In general, the `BeginBlocker` and `EndBlocker` functions are mostly composed of the [`BeginBlock` and `EndBlock`](/docs/sdk/v0.50//build/building-modules/beginblock-endblock) functions of each of the application's modules. This is done by calling the `BeginBlock` and `EndBlock` functions of the module manager, which in turn calls the `BeginBlock` and `EndBlock` functions of each of the modules it contains. Note that the order in which the modules' `BeginBlock` and `EndBlock` functions must be called has to be set in the module manager using the `SetOrderBeginBlockers` and `SetOrderEndBlockers` methods, respectively. This is done via the [module manager](/docs/sdk/v0.50//build/building-modules/module-manager) in the [application's constructor](#application-constructor), and the `SetOrderBeginBlockers` and `SetOrderEndBlockers` methods have to be called before the `SetBeginBlocker` and `SetEndBlocker` functions. -As a sidenote, it is important to remember that application-specific blockchains are deterministic. Developers must be careful not to introduce non-determinism in `BeginBlocker` or `EndBlocker`, and must also be careful not to make them too computationally expensive, as [gas](/docs/sdk/v0.50/gas-fees) does not constrain the cost of `BeginBlocker` and `EndBlocker` execution. +As a sidenote, it is important to remember that application-specific blockchains are deterministic. Developers must be careful not to introduce non-determinism in `BeginBlocker` or `EndBlocker`, and must also be careful not to make them too computationally expensive, as [gas](/docs/sdk/v0.50/learn/beginner/gas-fees) does not constrain the cost of `BeginBlocker` and `EndBlocker` execution. See an example of `BeginBlocker` and `EndBlocker` functions from `simapp` @@ -4013,11 +4013,11 @@ Note that `sdk.Msg`s are bundled in [transactions](/docs/sdk/v0.50/learn/advance When a valid block of transactions is received by the full-node, CometBFT relays each one to the application via [`DeliverTx`](https://docs.cometbft.com/v0.37/spec/abci/abci++_app_requirements#specifics-of-responsedelivertx). Then, the application handles the transaction: 1. Upon receiving the transaction, the application first unmarshalls it from `[]byte`. -2. Then, it verifies a few things about the transaction like [fee payment and signatures](/docs/sdk/v0.50/gas-fees#antehandler) before extracting the `Msg`(s) contained in the transaction. +2. Then, it verifies a few things about the transaction like [fee payment and signatures](/docs/sdk/v0.50/learn/beginner/gas-fees#antehandler) before extracting the `Msg`(s) contained in the transaction. 3. `sdk.Msg`s are encoded using Protobuf [`Any`s](#register-codec). By analyzing each `Any`'s `type_url`, baseapp's `msgServiceRouter` routes the `sdk.Msg` to the corresponding module's `Msg` service. 4. If the message is successfully processed, the state is updated. -For more details, see [transaction lifecycle](/docs/sdk/v0.50/tx-lifecycle). +For more details, see [transaction lifecycle](/docs/sdk/v0.50/learn/beginner/tx-lifecycle). 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: diff --git a/docs/sdk/v0.50/learn/beginner/query-lifecycle.mdx b/docs/sdk/v0.50/learn/beginner/query-lifecycle.mdx index 3e028a59..8644876c 100644 --- a/docs/sdk/v0.50/learn/beginner/query-lifecycle.mdx +++ b/docs/sdk/v0.50/learn/beginner/query-lifecycle.mdx @@ -15,7 +15,7 @@ This document describes the lifecycle of a query in a Cosmos SDK application, fr ## Query Creation -A [**query**](/docs/sdk/v0.50//build/building-modules/messages-and-queries#queries) is a request for information made by end-users of applications through an interface and processed by a full-node. Users can query information about the network, the application itself, and application state directly from the application's stores or modules. Note that queries are different from [transactions](/docs/sdk/v0.50/learn/advanced/transactions) (view the lifecycle [here](/docs/sdk/v0.50/tx-lifecycle)), particularly in that they do not require consensus to be processed (as they do not trigger state-transitions); they can be fully handled by one full-node. +A [**query**](/docs/sdk/v0.50//build/building-modules/messages-and-queries#queries) is a request for information made by end-users of applications through an interface and processed by a full-node. Users can query information about the network, the application itself, and application state directly from the application's stores or modules. Note that queries are different from [transactions](/docs/sdk/v0.50/learn/advanced/transactions) (view the lifecycle [here](/docs/sdk/v0.50/learn/beginner/tx-lifecycle)), particularly in that they do not require consensus to be processed (as they do not trigger state-transitions); they can be fully handled by one full-node. For the purpose of explaining the query lifecycle, let's say the query, `MyQuery`, is requesting a list of delegations made by a certain delegator address in the application called `simapp`. As is to be expected, the [`staking`](/docs/sdk/v0.50//build/modules/staking/README) module handles this query. But first, there are a few ways `MyQuery` can be created by users. @@ -689,7 +689,7 @@ At this point in the lifecycle, the user has created a CLI command with all of t #### Encoding -In our case (querying an address's delegations), `MyQuery` contains an [address](/docs/sdk/v0.50/accounts#addresses) `delegatorAddress` as its only argument. However, the request can only contain `[]byte`s, as it is ultimately relayed to a consensus engine (e.g. CometBFT) of a full-node that has no inherent knowledge of the application types. Thus, the `codec` of `client.Context` is used to marshal the address. +In our case (querying an address's delegations), `MyQuery` contains an [address](/docs/sdk/v0.50/learn/beginner/accounts#addresses) `delegatorAddress` as its only argument. However, the request can only contain `[]byte`s, as it is ultimately relayed to a consensus engine (e.g. CometBFT) of a full-node that has no inherent knowledge of the application types. Thus, the `codec` of `client.Context` is used to marshal the address. Here is what the code looks like for the CLI command: diff --git a/docs/sdk/v0.50/learn/beginner/tx-lifecycle.mdx b/docs/sdk/v0.50/learn/beginner/tx-lifecycle.mdx index aec1d403..f6833205 100644 --- a/docs/sdk/v0.50/learn/beginner/tx-lifecycle.mdx +++ b/docs/sdk/v0.50/learn/beginner/tx-lifecycle.mdx @@ -25,13 +25,13 @@ One of the main application interfaces is the command-line interface. The transa This command automatically **creates** the transaction, **signs** it using the account's private key, and **broadcasts** it to the specified peer node. -There are several required and optional flags for transaction creation. The `--from` flag specifies which [account](/docs/sdk/v0.50/accounts) the transaction is originating from. For example, if the transaction is sending coins, the funds are drawn from the specified `from` address. +There are several required and optional flags for transaction creation. The `--from` flag specifies which [account](/docs/sdk/v0.50/learn/beginner/accounts) the transaction is originating from. For example, if the transaction is sending coins, the funds are drawn from the specified `from` address. #### Gas and Fees -Additionally, there are several [flags](/docs/sdk/v0.50/learn/advanced/cli) users can use to indicate how much they are willing to pay in [fees](/docs/sdk/v0.50/gas-fees): +Additionally, there are several [flags](/docs/sdk/v0.50/learn/advanced/cli) users can use to indicate how much they are willing to pay in [fees](/docs/sdk/v0.50/learn/beginner/gas-fees): -* `--gas` refers to how much [gas](/docs/sdk/v0.50/gas-fees), which represents computational resources, `Tx` consumes. Gas is dependent on the transaction and is not precisely calculated until execution, but can be estimated by providing `auto` as the value for `--gas`. +* `--gas` refers to how much [gas](/docs/sdk/v0.50/learn/beginner/gas-fees), which represents computational resources, `Tx` consumes. Gas is dependent on the transaction and is not precisely calculated until execution, but can be estimated by providing `auto` as the value for `--gas`. * `--gas-adjustment` (optional) can be used to scale `gas` up in order to avoid underestimating. For example, users can specify their gas adjustment as 1.5 to use 1.5 times the estimated gas. * `--gas-prices` specifies how much the user is willing to pay per unit of gas, which can be one or multiple denominations of tokens. For example, `--gas-prices=0.025uatom, 0.025upho` means the user is willing to pay 0.025uatom AND 0.025upho per unit of gas. * `--fees` specifies how much in fees the user is willing to pay in total. @@ -214,7 +214,7 @@ to during consensus. Under the hood, transaction execution is almost identical t Instead of using their `checkState`, full-nodes use `finalizeblock`: * **Decoding:** Since `FinalizeBlock` is an ABCI call, `Tx` is received in the encoded `[]byte` form. - Nodes first unmarshal the transaction, using the [`TxConfig`](/docs/sdk/v0.50/app-anatomy#register-codec) defined in the app, then call `runTx` in `execModeFinalize`, which is very similar to `CheckTx` but also executes and writes state changes. + Nodes first unmarshal the transaction, using the [`TxConfig`](/docs/sdk/v0.50/learn/beginner/app-anatomy#register-codec) defined in the app, then call `runTx` in `execModeFinalize`, which is very similar to `CheckTx` but also executes and writes state changes. * **Checks and `AnteHandler`:** Full-nodes call `validateBasicMsgs` and `AnteHandler` again. This second check happens because they may not have seen the same transactions during the addition to Mempool stage diff --git a/docs/sdk/v0.50/learn/intro/sdk-design.mdx b/docs/sdk/v0.50/learn/intro/sdk-design.mdx index 411489c9..4d19423a 100644 --- a/docs/sdk/v0.50/learn/intro/sdk-design.mdx +++ b/docs/sdk/v0.50/learn/intro/sdk-design.mdx @@ -13,7 +13,7 @@ Here is a simplified view of how transactions are handled by an application buil ## `baseapp` -`baseapp` is the boilerplate implementation of a Cosmos SDK application. It comes with an implementation of the ABCI to handle the connection with the underlying consensus engine. Typically, a Cosmos SDK application extends `baseapp` by embedding it in [`app.go`](/docs/sdk/v0.50/beginner/app-anatomy#core-application-file). +`baseapp` is the boilerplate implementation of a Cosmos SDK application. It comes with an implementation of the ABCI to handle the connection with the underlying consensus engine. Typically, a Cosmos SDK application extends `baseapp` by embedding it in [`app.go`](/docs/sdk/v0.50/learn/beginner/app-anatomy#core-application-file). Here is an example of this from `simapp`, the Cosmos SDK demonstration app: diff --git a/docs/sdk/v0.53/build/architecture/PROCESS.mdx b/docs/sdk/v0.53/build/architecture/PROCESS.mdx index 29917c4f..a5ac8fdc 100644 --- a/docs/sdk/v0.53/build/architecture/PROCESS.mdx +++ b/docs/sdk/v0.53/build/architecture/PROCESS.mdx @@ -5,7 +5,7 @@ title: ADR Creation Process 1. Copy the `adr-template.md` file. Use the following filename pattern: `adr-next_number-title.md` 2. Create a draft Pull Request if you want to get early feedback. 3. Make sure the context and solution are clear and well documented. -4. Add an entry to the list in the [README](/docs/sdk/v0.53/README) file. +4. Add an entry to the list in the [README](/docs/sdk/v0.53/build/architecture/README) file. 5. Create a Pull Request to propose a new ADR. ## What is an ADR? diff --git a/docs/sdk/v0.53/build/architecture/README.mdx b/docs/sdk/v0.53/build/architecture/README.mdx index 37f175e3..a17036ba 100644 --- a/docs/sdk/v0.53/build/architecture/README.mdx +++ b/docs/sdk/v0.53/build/architecture/README.mdx @@ -33,7 +33,7 @@ If recorded decisions turned out to be lacking, convene a discussion, record the ## Creating new ADR -Read about the [PROCESS](/docs/sdk/v0.53/PROCESS). +Read about the [PROCESS](/docs/sdk/v0.53/build/architecture/PROCESS). ### Use RFC 2119 Keywords diff --git a/docs/sdk/v0.53/build/building-apps/app-go-di.mdx b/docs/sdk/v0.53/build/building-apps/app-go-di.mdx index 32edca3a..f335bc9e 100644 --- a/docs/sdk/v0.53/build/building-apps/app-go-di.mdx +++ b/docs/sdk/v0.53/build/building-apps/app-go-di.mdx @@ -377,7 +377,7 @@ The `app_config.go` file is the single place to configure all modules parameters ) ``` - Where the `appConfig` combines the [runtime](/docs/sdk/v0.53/runtime) configuration and the (extra) modules configuration. + Where the `appConfig` combines the [runtime](/docs/sdk/v0.53/build/building-apps/runtime) configuration and the (extra) modules configuration. ```go expandable //go:build !app_v1 diff --git a/docs/sdk/v0.53/build/building-apps/runtime.mdx b/docs/sdk/v0.53/build/building-apps/runtime.mdx index 874c5853..60f44cd3 100644 --- a/docs/sdk/v0.53/build/building-apps/runtime.mdx +++ b/docs/sdk/v0.53/build/building-apps/runtime.mdx @@ -866,7 +866,7 @@ The configuration of the module manager and other core components is handled int ### 2. Module Registration -Runtime has built-in support for [`depinject`-enabled modules](/docs/sdk/v0.53/building-modules/depinject). +Runtime has built-in support for [`depinject`-enabled modules](/docs/sdk/v0.53/build/building-modules/depinject). Such modules can be registered through the configuration file (often named `app_config.go`), with no additional code required. ```go expandable @@ -1858,7 +1858,7 @@ return a.app } ``` -More information on building applications can be found in the [next section](/docs/sdk/v0.53/02-app-building). +More information on building applications can be found in the [next section](/docs/sdk/v0.53/build/building-apps/app-go). ## Best Practices diff --git a/docs/sdk/v0.53/build/rfc.mdx b/docs/sdk/v0.53/build/rfc.mdx index 66d7c9cc..805f58ee 100644 --- a/docs/sdk/v0.53/build/rfc.mdx +++ b/docs/sdk/v0.53/build/rfc.mdx @@ -5,7 +5,7 @@ description: "Version: v0.53" A Request for Comments (RFC) is a record of discussion on an open-ended topic related to the design and implementation of the Cosmos SDK, for which no immediate decision is required. -The purpose of an RFC is to serve as a historical record of a high-level discussion that might otherwise only be recorded in an ad-hoc way (for example, via gists or Google docs) that are difficult to discover for someone after the fact. An RFC *may* give rise to more specific architectural *decisions* for the Cosmos SDK, but those decisions must be recorded separately in [Architecture Decision Records (ADR)](/docs/sdk/v0.53/architecture). +The purpose of an RFC is to serve as a historical record of a high-level discussion that might otherwise only be recorded in an ad-hoc way (for example, via gists or Google docs) that are difficult to discover for someone after the fact. An RFC *may* give rise to more specific architectural *decisions* for the Cosmos SDK, but those decisions must be recorded separately in [Architecture Decision Records (ADR)](/docs/sdk/v0.53/build/architecture/README). As a rule of thumb, if you can articulate a specific question that needs to be answered, write an ADR. If you need to explore the topic and get input from others to know what questions need to be answered, an RFC may be appropriate. diff --git a/docs/sdk/v0.53/learn/advanced/baseapp.mdx b/docs/sdk/v0.53/learn/advanced/baseapp.mdx index 6642df01..f38b6b24 100644 --- a/docs/sdk/v0.53/learn/advanced/baseapp.mdx +++ b/docs/sdk/v0.53/learn/advanced/baseapp.mdx @@ -10,7 +10,7 @@ This document describes `BaseApp`, the abstraction that implements the core func **Pre-requisite Readings** -* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.53/beginner/app-anatomy) +* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.53/learn/beginner/app-anatomy) * [Lifecycle of a Cosmos SDK transaction](/docs/sdk/v0.53/beginner/tx-lifecycle) @@ -1523,7 +1523,7 @@ First, the important parameters that are initialized during the bootstrapping of * [`AnteHandler`](#antehandler): This handler is used to handle signature verification, fee payment, and other pre-message execution checks when a transaction is received. It's executed during [`CheckTx/RecheckTx`](#checktx) and [`FinalizeBlock`](#finalizeblock). -* [`InitChainer`](/docs/sdk/v0.53/beginner/app-anatomy#initchainer), [`PreBlocker`](/docs/sdk/v0.53/beginner/app-anatomy#preblocker), [`BeginBlocker` and `EndBlocker`](/docs/sdk/v0.53/beginner/app-anatomy#beginblocker-and-endblocker): These are +* [`InitChainer`](/docs/sdk/v0.53/learn/beginner/app-anatomy#initchainer), [`PreBlocker`](/docs/sdk/v0.53/learn/beginner/app-anatomy#preblocker), [`BeginBlocker` and `EndBlocker`](/docs/sdk/v0.53/learn/beginner/app-anatomy#beginblocker-and-endblocker): These are the functions executed when the application receives the `InitChain` and `FinalizeBlock` ABCI messages from the underlying CometBFT engine. @@ -1549,7 +1549,7 @@ Finally, a few more important parameters: `minGasPrices` (e.g. if `minGasPrices == 1uatom,1photon`, the `gas-price` of the transaction must be greater than `1uatom` OR `1photon`). * `appVersion`: Version of the application. It is set in the - [application's constructor function](/docs/sdk/v0.53/beginner/app-anatomy#constructor-function). + [application's constructor function](/docs/sdk/v0.53/learn/beginner/app-anatomy#constructor-function). ## Constructor @@ -1665,13 +1665,13 @@ When messages and queries are received by the application, they must be routed t The [default `msgServiceRouter` included in `BaseApp`](https://github.com/cosmos/cosmos-sdk/blob/v0.53.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.53.0/baseapp/msg_service_router.go#L35-L36). 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](/docs/sdk/v0.53//build/building-modules/module-manager#manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.53/beginner/app-anatomy#constructor-function). +The application's `msgServiceRouter` is initialized with all the routes using the application's [module manager](/docs/sdk/v0.53//build/building-modules/module-manager#manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.53/learn/beginner/app-anatomy#constructor-function). ### gRPC Query Router Similar to `sdk.Msg`s, [`queries`](/docs/sdk/v0.53//build/building-modules/messages-and-queries#queries) need to be routed to the appropriate module's [`Query` service](/docs/sdk/v0.53//build/building-modules/query-services). To do so, `BaseApp` holds a `grpcQueryRouter`, which maps modules' fully-qualified service methods (`string`, defined in their Protobuf `Query` gRPC) to their `QueryServer` implementation. The `grpcQueryRouter` is called during the initial stages of query processing, which can be either by directly sending a gRPC query to the gRPC endpoint, or via the [`Query` ABCI message](#query) on the CometBFT RPC endpoint. -Just like the `msgServiceRouter`, the `grpcQueryRouter` is initialized with all the query routes using the application's [module manager](/docs/sdk/v0.53//build/building-modules/module-manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.53/beginner/app-anatomy#app-constructor). +Just like the `msgServiceRouter`, the `grpcQueryRouter` is initialized with all the query routes using the application's [module manager](/docs/sdk/v0.53//build/building-modules/module-manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.53/learn/beginner/app-anatomy#app-constructor). ## Main ABCI 2.0 Messages @@ -3665,7 +3665,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](/docs/sdk/v0.53/beginner/app-anatomy#application-constructor). The most widely used `anteHandler` is the [`auth` module](https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/x/auth/ante/ante.go). +`BaseApp` holds an `anteHandler` as parameter that is initialized in the [application's constructor](/docs/sdk/v0.53/learn/beginner/app-anatomy#application-constructor). The most widely used `anteHandler` is the [`auth` module](https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/x/auth/ante/ante.go). Click [here](/docs/sdk/v0.53/beginner/gas-fees#antehandler) for more on the `anteHandler`. @@ -3716,7 +3716,7 @@ The [`InitChain` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x * [`checkState` and `finalizeBlockState`](#state-updates) via `setState`. * The [block gas meter](/docs/sdk/v0.53/beginner/gas-fees#block-gas-meter), with infinite gas to process genesis transactions. -Finally, the `InitChain(req abci.RequestInitChain)` method of `BaseApp` calls the [`initChainer()`](/docs/sdk/v0.53/beginner/app-anatomy#initchainer) of the application in order to initialize the main state of the application from the `genesis file` and, if defined, call the [`InitGenesis`](/docs/sdk/v0.53//build/building-modules/genesis#initgenesis) function of each of the application's modules. +Finally, the `InitChain(req abci.RequestInitChain)` method of `BaseApp` calls the [`initChainer()`](/docs/sdk/v0.53/learn/beginner/app-anatomy#initchainer) of the application in order to initialize the main state of the application from the `genesis file` and, if defined, call the [`InitGenesis`](/docs/sdk/v0.53//build/building-modules/genesis#initgenesis) function of each of the application's modules. ### FinalizeBlock @@ -5279,7 +5279,7 @@ return legacyVotes #### PreBlock -* Run the application's [`preBlocker()`](/docs/sdk/v0.53/beginner/app-anatomy#preblocker), which mainly runs the [`PreBlocker()`](/docs/sdk/v0.53//build/building-modules/preblock#preblock) method of each of the modules. +* Run the application's [`preBlocker()`](/docs/sdk/v0.53/learn/beginner/app-anatomy#preblocker), which mainly runs the [`PreBlocker()`](/docs/sdk/v0.53//build/building-modules/preblock#preblock) method of each of the modules. #### BeginBlock @@ -6738,7 +6738,7 @@ return legacyVotes * Initialize the [block gas meter](/docs/sdk/v0.53/beginner/gas-fees#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()`](/docs/sdk/v0.53/beginner/app-anatomy#beginblocker-and-endblocker), which mainly runs the [`BeginBlocker()`](/docs/sdk/v0.53//build/building-modules/beginblock-endblock#beginblock) method of each of the modules. +* Run the application's [`beginBlocker()`](/docs/sdk/v0.53/learn/beginner/app-anatomy#beginblocker-and-endblocker), which mainly runs the [`BeginBlocker()`](/docs/sdk/v0.53//build/building-modules/beginblock-endblock#beginblock) method of each of the modules. * Set the [`VoteInfos`](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_methods.md#voteinfo) of the application, i.e. the list of validators whose *precommit* for the previous block was included by the proposer of the current block. This information is carried into the [`Context`](/docs/sdk/v0.53/context) so that it can be used during transaction execution and EndBlock. diff --git a/docs/sdk/v0.53/learn/advanced/node.mdx b/docs/sdk/v0.53/learn/advanced/node.mdx index e6e72711..7dcdd491 100644 --- a/docs/sdk/v0.53/learn/advanced/node.mdx +++ b/docs/sdk/v0.53/learn/advanced/node.mdx @@ -1876,7 +1876,7 @@ Application ) ``` -In practice, the [constructor of the application](/docs/sdk/v0.53/beginner/app-anatomy#constructor-function) is passed as the `appCreator`. +In practice, the [constructor of the application](/docs/sdk/v0.53/learn/beginner/app-anatomy#constructor-function) is passed as the `appCreator`. ```go // Reference: https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/simapp/simd/cmd/root_v2.go#L294-L308 diff --git a/docs/sdk/v0.53/learn/advanced/store.mdx b/docs/sdk/v0.53/learn/advanced/store.mdx index 4a6c8253..27ef4580 100644 --- a/docs/sdk/v0.53/learn/advanced/store.mdx +++ b/docs/sdk/v0.53/learn/advanced/store.mdx @@ -5931,7 +5931,7 @@ A `KVStore` is a simple key-value store used to store and retrieve data. A `Comm Individual `KVStore`s are used by modules to manage a subset of the global state. `KVStores` can be accessed by objects that hold a specific key. This `key` should only be exposed to the [`keeper`](/docs/sdk/v0.53//build/building-modules/keeper) of the module that defines the store. -`CommitKVStore`s are declared by proxy of their respective `key` and mounted on the application's [multistore](#multistore) in the [main application file](/docs/sdk/v0.53/beginner/app-anatomy#core-application-file). In the same file, the `key` is also passed to the module's `keeper` that is responsible for managing the store. +`CommitKVStore`s are declared by proxy of their respective `key` and mounted on the application's [multistore](#multistore) in the [main application file](/docs/sdk/v0.53/learn/beginner/app-anatomy#core-application-file). In the same file, the `key` is also passed to the module's `keeper` that is responsible for managing the store. ```go expandable package types diff --git a/docs/sdk/v0.53/learn/intro/sdk-design.mdx b/docs/sdk/v0.53/learn/intro/sdk-design.mdx index ed487f48..7fb01124 100644 --- a/docs/sdk/v0.53/learn/intro/sdk-design.mdx +++ b/docs/sdk/v0.53/learn/intro/sdk-design.mdx @@ -13,7 +13,7 @@ Here is a simplified view of how transactions are handled by an application buil ## `baseapp` -`baseapp` is the boilerplate implementation of a Cosmos SDK application. It comes with an implementation of the ABCI to handle the connection with the underlying consensus engine. Typically, a Cosmos SDK application extends `baseapp` by embedding it in [`app.go`](/docs/sdk/v0.53/beginner/app-anatomy#core-application-file). +`baseapp` is the boilerplate implementation of a Cosmos SDK application. It comes with an implementation of the ABCI to handle the connection with the underlying consensus engine. Typically, a Cosmos SDK application extends `baseapp` by embedding it in [`app.go`](/docs/sdk/v0.53/learn/beginner/app-anatomy#core-application-file). Here is an example of this from `simapp`, the Cosmos SDK demonstration app: From 204e67e7b18668b2e22d299e98bf4285cf24eea4 Mon Sep 17 00:00:00 2001 From: Cordt Date: Fri, 24 Oct 2025 07:26:16 -0600 Subject: [PATCH 02/10] fix: resolve 500+ broken internal links - ADR paths, module refs, cross-version links MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Fix SDK ADR paths: add missing /build/architecture/ prefix (v0.47, v0.50, v0.53) - Fix SDK module paths: add /build/modules/ prefix for auth, staking, gov, etc - Fix short paths: add /learn/advanced/ and /learn/beginner/ prefixes - Fix building-modules paths: add /build/ prefix for app-go-v2, keeper, etc - Fix cross-version references: v0.47 -> v0.50, v0.50 -> v0.53 corrections - Convert proto/github links to external URLs instead of broken doc links - Fix spec, ICS, and architecture reference paths - Remove audit report files (not docs) 104 files changed, 332 insertions(+), 865 deletions(-) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude --- COSMOS_EVM_CONFIG_AUDIT_CORRECTED.md | 251 ------------------ COSMOS_EVM_CONFIG_AUDIT_REPORT.md | 194 -------------- docs.json | 2 - .../next/documentation/concepts/accounts.mdx | 2 +- .../concepts/predeployed-contracts.mdx | 2 +- .../concepts/replay-protection.mdx | 2 +- .../cosmos-sdk/modules/erc20.mdx | 2 +- .../cosmos-sdk/modules/feemarket.mdx | 2 +- .../cosmos-sdk/modules/precisebank.mdx | 2 +- .../documentation/cosmos-sdk/protocol.mdx | 2 +- .../predeployed-contracts.mdx | 2 +- .../build-a-chain/build-a-chain_v.mdx | 2 +- .../build-a-chain/quick-start.mdx | 2 +- .../build-a-chain/using-local-node.mdx | 2 +- .../documentation/getting-started/faq.mdx | 6 +- .../documentation/getting-started/index.mdx | 21 +- docs/evm/next/documentation/overview.mdx | 32 +-- .../predeployed-contracts.mdx | 2 +- .../build-a-chain/quick-start.mdx | 2 +- .../build-a-chain/using-local-node.mdx | 2 +- .../documentation/getting-started/faq.mdx | 6 +- .../documentation/getting-started/index.mdx | 19 -- docs/evm/v0.5.0/documentation/overview.mdx | 24 +- docs/ibc/next/index.mdx | 2 +- .../adr-054-semver-compatible-modules.mdx | 2 +- .../build/architecture/adr-057-app-wiring.mdx | 6 +- .../architecture/adr-063-core-module-api.mdx | 4 +- .../build/building-modules/depinject.mdx | 2 +- .../building-modules/module-interfaces.mdx | 2 +- .../build/building-modules/structure.mdx | 2 +- .../v0.47/build/modules/evidence/README.mdx | 2 +- .../v0.47/build/modules/feegrant/README.mdx | 2 +- docs/sdk/v0.47/build/modules/gov/README.mdx | 4 +- docs/sdk/v0.47/build/modules/group/README.mdx | 4 +- .../v0.47/build/modules/slashing/README.mdx | 2 +- docs/sdk/v0.47/learn/advanced/grpc_rest.mdx | 2 +- docs/sdk/v0.47/learn/intro/overview.mdx | 2 +- docs/sdk/v0.47/learn/intro/sdk-design.mdx | 2 +- .../v0.47/user/run-node/run-production.mdx | 2 +- docs/sdk/v0.50/build/architecture/README.mdx | 88 +++--- .../adr-007-specialization-groups.mdx | 2 +- .../architecture/adr-008-dCERT-group.mdx | 4 +- .../adr-020-protobuf-transaction-encoding.mdx | 8 +- .../adr-021-protobuf-query-encoding.mdx | 6 +- ...7-deterministic-protobuf-serialization.mdx | 2 +- .../architecture/adr-030-authz-module.mdx | 2 +- .../architecture/adr-031-msg-service.mdx | 10 +- .../adr-033-protobuf-inter-module-comm.mdx | 22 +- .../architecture/adr-042-group-module.mdx | 2 +- .../adr-044-protobuf-updates-guidelines.mdx | 2 +- .../adr-045-check-delivertx-middlewares.mdx | 4 +- .../adr-050-sign-mode-textual-annex1.mdx | 4 +- .../adr-050-sign-mode-textual.mdx | 12 +- .../adr-054-semver-compatible-modules.mdx | 30 +-- .../build/architecture/adr-057-app-wiring.mdx | 12 +- .../architecture/adr-063-core-module-api.mdx | 22 +- .../build/architecture/adr-065-store-v2.mdx | 6 +- .../build/building-modules/structure.mdx | 2 +- docs/sdk/v0.50/build/spec/README.mdx | 2 +- docs/sdk/v0.50/build/spec/_ics/README.mdx | 2 +- .../sdk/v0.50/learn/beginner/tx-lifecycle.mdx | 2 +- docs/sdk/v0.50/learn/intro/sdk-design.mdx | 2 +- .../auction-frontrunning/getting-started.mdx | 2 +- .../v0.50/user/run-node/run-production.mdx | 2 +- docs/sdk/v0.53/build/architecture/README.mdx | 90 +++---- .../adr-054-semver-compatible-modules.mdx | 2 +- .../build/architecture/adr-057-app-wiring.mdx | 12 +- .../architecture/adr-063-core-module-api.mdx | 22 +- .../v0.53/build/architecture/adr-template.mdx | 2 +- .../v0.53/build/building-apps/app-mempool.mdx | 2 +- .../building-modules/beginblock-endblock.mdx | 6 +- .../v0.53/build/building-modules/genesis.mdx | 6 +- .../v0.53/build/building-modules/intro.mdx | 2 +- .../build/building-modules/invariants.mdx | 2 +- .../building-modules/messages-and-queries.mdx | 8 +- .../building-modules/module-interfaces.mdx | 4 +- .../build/building-modules/module-manager.mdx | 6 +- .../build/building-modules/msg-services.mdx | 6 +- .../v0.53/build/building-modules/preblock.mdx | 2 +- .../building-modules/protobuf-annotations.mdx | 2 +- .../build/building-modules/query-services.mdx | 2 +- .../build/building-modules/structure.mdx | 2 +- docs/sdk/v0.53/build/migrations/intro.mdx | 2 +- docs/sdk/v0.53/build/modules/authz/README.mdx | 2 +- .../build/modules/distribution/README.mdx | 2 +- .../v0.53/build/modules/evidence/README.mdx | 2 +- docs/sdk/v0.53/build/modules/gov/README.mdx | 4 +- docs/sdk/v0.53/build/modules/group/README.mdx | 4 +- .../v0.53/build/modules/slashing/README.mdx | 2 +- docs/sdk/v0.53/build/rfc/PROCESS.mdx | 2 +- docs/sdk/v0.53/build/rfc/README.mdx | 6 +- docs/sdk/v0.53/build/spec/README.mdx | 4 +- docs/sdk/v0.53/build/spec/_ics/README.mdx | 2 +- docs/sdk/v0.53/learn/advanced/baseapp.mdx | 40 +-- docs/sdk/v0.53/learn/advanced/cli.mdx | 8 +- docs/sdk/v0.53/learn/advanced/context.mdx | 14 +- docs/sdk/v0.53/learn/advanced/encoding.mdx | 4 +- docs/sdk/v0.53/learn/advanced/events.mdx | 6 +- docs/sdk/v0.53/learn/advanced/grpc_rest.mdx | 4 +- docs/sdk/v0.53/learn/advanced/node.mdx | 4 +- docs/sdk/v0.53/learn/advanced/store.mdx | 10 +- .../sdk/v0.53/learn/advanced/transactions.mdx | 4 +- docs/sdk/v0.53/learn/beginner/app-anatomy.mdx | 14 +- .../sdk/v0.53/learn/beginner/tx-lifecycle.mdx | 2 +- 104 files changed, 332 insertions(+), 865 deletions(-) delete mode 100644 COSMOS_EVM_CONFIG_AUDIT_CORRECTED.md delete mode 100644 COSMOS_EVM_CONFIG_AUDIT_REPORT.md diff --git a/COSMOS_EVM_CONFIG_AUDIT_CORRECTED.md b/COSMOS_EVM_CONFIG_AUDIT_CORRECTED.md deleted file mode 100644 index aa52a8d4..00000000 --- a/COSMOS_EVM_CONFIG_AUDIT_CORRECTED.md +++ /dev/null @@ -1,251 +0,0 @@ -# Cosmos EVM Configuration Documentation - Corrected Understanding - -## The Fundamental Issue - -The current documentation incorrectly instructs users to modify core module code in the `github.com/cosmos/evm` repository. This is wrong. Users should: - -1. **Import the evm modules** as dependencies (don't modify them) -2. **Create their own application** using `evmd` as a template/example -3. **Configure through standard Cosmos SDK methods** (genesis, config files, app construction) - -## Correct Configuration Approach - -### 1. Creating Your Own Chain Application - -**What the docs say:** Modify files in `config/`, `crypto/hd/`, etc. - -**What you should actually do:** - -```bash -# 1. Create your own application directory -mkdir mychain -cd mychain - -# 2. Copy evmd as a template -cp -r $GOPATH/src/github.com/cosmos/evm/evmd/* . - -# 3. Rename and customize -# - Rename package from "evmd" to "mychain" -# - Update import paths -# - Modify app.go to configure your chain -``` - -### 2. Pre-Build Configuration (Your App Code) - -These changes should be made in **YOUR** application code, not the evm module: - -#### Chain Identity -```go -// mychain/cmd/mychaind/main.go -func main() { - setupSDKConfig() - rootCmd := cmd.NewRootCmd() - if err := svrcmd.Execute(rootCmd, "mychaind", config.MustGetDefaultNodeHome()); err != nil { - // ... - } -} - -func setupSDKConfig() { - cfg := sdk.GetConfig() - // Set YOUR chain's bech32 prefix - cfg.SetBech32PrefixForAccount("mychain", "mychainpub") - cfg.SetBech32PrefixForValidator("mychainvaloper", "mychainvaloperpub") - cfg.SetBech32PrefixForConsensusNode("mychainvalcons", "mychainvalconspub") - cfg.Seal() -} -``` - -#### Module Selection and Configuration -```go -// mychain/app.go -func NewApp(...) *App { - // Configure which modules to include - // Configure module account permissions - // Set up custom precompiles - // Configure ante handlers - - // Example: Select specific precompiles - precompiles := NewAvailableStaticPrecompiles( - ctx, - app.StakingKeeper, - app.DistributionKeeper, - app.BankKeeper, - app.Erc20Keeper, - app.AuthzKeeper, - app.TransferKeeper, - app.IBCKeeper.ChannelKeeper, - // Only include the precompiles you want - precompile.WithStaking(), - precompile.WithDistribution(), - precompile.WithICS20(), - // Don't include: WithBech32(), WithP256(), etc. - ) -} -``` - -### 3. Genesis Configuration - -**Correct approach:** Modify genesis.json after initialization, don't change module code - -```bash -# Initialize your chain -mychaind init mymoniker --chain-id mychain-1 - -# Modify genesis.json -cat genesis.json | jq '.app_state["evm"]["params"]["evm_denom"]="umycoin"' > tmp && mv tmp genesis.json -cat genesis.json | jq '.app_state["evm"]["params"]["active_static_precompiles"]=["0x0000000000000000000000000000000000000800","0x0000000000000000000000000000000000000801"]' > tmp && mv tmp genesis.json -cat genesis.json | jq '.app_state["feemarket"]["params"]["base_fee"]="1000000000"' > tmp && mv tmp genesis.json -``` - -Or programmatically in your app's `DefaultGenesis()`: - -```go -// mychain/genesis.go -func DefaultGenesis() map[string]json.RawMessage { - genesis := evmd.ModuleBasics.DefaultGenesis(cdc) - - // Customize EVM parameters - var evmGenState evmtypes.GenesisState - cdc.MustUnmarshalJSON(genesis[evmtypes.ModuleName], &evmGenState) - evmGenState.Params.EvmDenom = "umycoin" - evmGenState.Params.ActiveStaticPrecompiles = []string{ - precompiles.StakingAddress, - precompiles.DistributionAddress, - } - genesis[evmtypes.ModuleName] = cdc.MustMarshalJSON(&evmGenState) - - // Customize fee market - var feeGenState feemarkettypes.GenesisState - cdc.MustUnmarshalJSON(genesis[feemarkettypes.ModuleName], &feeGenState) - feeGenState.Params.BaseFee = math.LegacyNewDec(100_000_000) - feeGenState.Params.MinGasPrice = math.LegacyNewDec(10_000_000) - genesis[feemarkettypes.ModuleName] = cdc.MustMarshalJSON(&feeGenState) - - return genesis -} -``` - -### 4. Runtime Configuration - -#### app.toml -```toml -# EVM Configuration -[evm] -# HTTP-RPC address -http-address = "0.0.0.0:8545" -# WebSocket address -ws-address = "0.0.0.0:8546" -# API namespaces -api = "eth,net,web3,txpool,debug" -# Block gas limit -block-gas-limit = "30000000" -# EVM chain ID (overrides genesis if set) -evm-chain-id = 9001 - -[json-rpc] -# Enable JSON-RPC server -enable = true -# API namespaces -api = "eth,net,web3" -# Gas cap -gas-cap = 50000000 -# EVM timeout -evm-timeout = "5s" -# TX fee cap -tx-fee-cap = 1 -``` - -#### config.toml (CometBFT) -```toml -# Standard CometBFT configuration -[consensus] -timeout_propose = "3s" -timeout_prevote = "1s" -timeout_precommit = "1s" -timeout_commit = "2s" -``` - -### 5. What NOT to Modify - -Never modify these files in the `github.com/cosmos/evm` repository: -- ❌ `config/config.go` - Use your own config package -- ❌ `crypto/hd/hdpath.go` - This is standard Ethereum HD path -- ❌ `x/vm/types/params.go` - Override in genesis/app.go -- ❌ `x/feemarket/types/params.go` - Override in genesis/app.go -- ❌ Any core module code - -## Correct Documentation Structure - -The documentation should be restructured as: - -### 1. Quick Start Guide -```markdown -1. Install dependencies -2. Clone evmd as template: `cp -r .../evmd mychain` -3. Customize app.go -4. Build: `make install` -5. Initialize: `mychaind init` -6. Configure genesis.json -7. Start: `mychaind start` -``` - -### 2. Application Development -- How to structure your app -- Importing evm modules -- Configuring module manager -- Setting up ante handlers -- Custom precompiles - -### 3. Configuration Reference -- Genesis parameters (modifiable) -- App.toml settings -- Config.toml settings -- Environment variables - -### 4. Advanced Customization -- Writing custom precompiles -- Extending modules -- Upgrade handlers -- IBC integration - -## Example: Complete Custom Chain - -```bash -# 1. Create your chain app (not modifying evm module) -mkdir ~/mychain && cd ~/mychain -go mod init github.com/myorg/mychain -go get github.com/cosmos/evm@latest - -# 2. Copy evmd as template -cp -r $GOPATH/pkg/mod/github.com/cosmos/evm@*/evmd/* . - -# 3. Update imports and package names -find . -type f -name "*.go" -exec sed -i 's/package evmd/package mychain/g' {} \; -find . -type f -name "*.go" -exec sed -i 's|github.com/cosmos/evm/evmd|github.com/myorg/mychain|g' {} \; - -# 4. Customize your app.go -# - Set your chain's denomination -# - Choose your precompiles -# - Configure your modules - -# 5. Build -make build - -# 6. Initialize -./build/mychaind init mynode --chain-id mychain-1 - -# 7. Configure genesis -# Edit ~/.mychain/config/genesis.json - -# 8. Start -./build/mychaind start -``` - -## Key Takeaways - -1. **evmd is an EXAMPLE** - Copy it, don't modify the evm module -2. **Configuration happens in YOUR app** - Not in the core modules -3. **Genesis and config files** - Primary way to configure behavior -4. **Import modules as libraries** - Don't edit library code - -The current documentation completely misses this architecture and incorrectly tells users to modify library code instead of creating their own application. \ No newline at end of file diff --git a/COSMOS_EVM_CONFIG_AUDIT_REPORT.md b/COSMOS_EVM_CONFIG_AUDIT_REPORT.md deleted file mode 100644 index 381c8615..00000000 --- a/COSMOS_EVM_CONFIG_AUDIT_REPORT.md +++ /dev/null @@ -1,194 +0,0 @@ -# Cosmos EVM Configuration Documentation Audit Report - -## Executive Summary - -This audit reveals that while the configuration documentation contains mostly accurate file paths and line numbers, there are significant omissions, misleading information, and missing critical context that make the documentation difficult to use effectively. The documentation needs restructuring to better reflect the actual configuration workflow and include many missing configuration options. - -## Audit Findings - -### Pre-Genesis Configuration - -#### ✅ Accurate Information - -1. **Bech32 Address Prefix** (`config/config.go:62`) - - Documentation correctly identifies the location - - Actual code: `Bech32Prefix = "cosmos"` on line 62 - -2. **BIP44 Coin Type** (`crypto/hd/hdpath.go:9`) - - Documentation correctly identifies the location - - Actual code: `Bip44CoinType uint32 = 60` on line 9 - -3. **EVM Chain ID** (`config/config.go:78`) - - Documentation correctly identifies the location - - Actual code: `EVMChainID = 262144` on line 78 - -#### ❌ Issues and Omissions - -1. **Chain Name Configuration** - - Documentation suggests changing directory names and package names - - Reality: The binary name is controlled by the build process and main.go, not directory names - - Missing: Clear explanation that "evmd" is just an example implementation - -2. **Token Decimal Precision** - - Documentation mentions but doesn't clearly explain the decimal system - - Missing: The complete decimal support (1-18 decimals) found in `x/vm/types/denom.go` - - Missing: Explanation of conversion factors and how they work - - Missing: PreciseBank module's role in handling 6-decimal tokens - -3. **Default Denomination** - - Documentation vaguely references multiple files - - Reality: Defaults are in `x/vm/types/params.go` (lines 21-25) - - Missing: Clear explanation of the three-tier denomination system (base, extended, display) - -4. **Module Configuration** - - Completely missing: Module account permissions configuration in `config/evmd_config.go` - - Missing: Blocked addresses configuration - - Missing: How to configure which modules to include - -### Genesis Configuration - -#### ❌ Critical Issues - -1. **Precompiles Configuration** - - Documentation shows enabling all precompiles with a simple list - - Reality: Precompiles are defined in `x/vm/types/precompiles.go` with `AvailableStaticPrecompiles` - - Missing: Precompile addresses and their specific purposes - - Missing: How to selectively enable/disable precompiles - - Missing: Security implications of enabling certain precompiles - -2. **Fee Market Configuration** - - Documentation mentions basic parameters - - Missing: Default values from `x/feemarket/types/params.go`: - - `DefaultBaseFee = 1_000_000_000` - - `DefaultMinGasMultiplier = 0.5` - - `BaseFeeChangeDenominator` from go-ethereum params - - `ElasticityMultiplier` from go-ethereum params - - Missing: Explanation of EIP-1559 implementation details - -3. **Single Token Representation v2 (STRv2)** - - Documentation mentions it exists - - Missing: How to configure ERC20 module - - Missing: Token pairs configuration - - Missing: Contract owner settings - -4. **Consensus Parameters** - - Missing: Block size limits - - Missing: Evidence parameters - - Missing: Validator set updates - -### Runtime and Launch Configuration - -#### ❌ Critical Omissions - -1. **Local Node Script** - - Documentation doesn't reference the comprehensive `local_node.sh` script - - Missing: All the configuration done in the script: - - Chain ID configuration (line 3: `CHAINID="${CHAIN_ID:-9001}"`) - - Keyring backend setup - - Genesis modifications for denominations - - Account funding - - Validator setup - -2. **App.toml Configuration** - - Missing: EVM-specific configuration options - - Missing: JSON-RPC configuration - - Missing: TLS configuration - - Missing: Mempool configuration - -3. **Config.toml Configuration** - - Missing: CometBFT specific settings - - Missing: P2P configuration - - Missing: Consensus timeouts - -### Missing Sections Entirely - -1. **Upgrade Handlers** - - No mention of `evmd/upgrades.go` - - No guidance on handling breaking changes - -2. **IBC Configuration** - - No mention of EVM channels configuration - - Missing: IBC transfer module settings - -3. **Access Control** - - No documentation of the access control system for EVM - - Missing: Create/Call permissions - - Missing: Allowlist configuration - -4. **History Serve Window** - - Not mentioned but important for archive nodes - - Default: 8192 blocks (same as EIP-2935) - -5. **Extended Denom Options** - - Not documented but present in the code - - Important for token representation - -## Recommendations - -### 1. Restructure Documentation - -Create three clear sections: -- **Pre-Compilation Configuration**: Code changes before building -- **Genesis Configuration**: Chain initialization parameters -- **Runtime Configuration**: Node operation settings - -### 2. Add Missing Configuration Examples - -Include complete examples for: -- Custom chain with 6-decimal token -- Permissioned EVM deployment -- Archive node configuration -- IBC-enabled EVM chain - -### 3. Include Configuration Reference - -Create a comprehensive table of all configuration parameters with: -- Parameter name -- File location -- Default value -- Description -- Example values -- Dependencies - -### 4. Add Validation Checklist - -Provide a checklist to verify configuration: -- [ ] Chain ID is unique -- [ ] Denomination is consistent across modules -- [ ] Precompiles don't conflict -- [ ] Fee market parameters are reasonable -- [ ] Genesis accounts are funded - -### 5. Reference Actual Code - -Update all file references to include: -- Exact file paths -- Line numbers (with version tags) -- Code snippets showing context - -### 6. Include Migration Guide - -Add section on migrating from: -- Ethereum to Cosmos EVM -- Previous Cosmos EVM versions -- Other Cosmos chains - -### 7. Add Troubleshooting Section - -Include common configuration errors: -- Mismatched decimals -- Invalid chain ID -- Missing precompiles -- Incorrect fee configuration - -## Conclusion - -While the documentation contains some accurate information, it is insufficient for users to successfully configure a Cosmos EVM chain. The missing information, particularly around precompiles, fee market, access control, and the actual configuration workflow, makes the documentation "unusable" as the user stated. A comprehensive rewrite focusing on completeness and practical examples is needed. - -## Files Requiring Updates - -1. `pre-genesis-and-genesis-setup.mdx` - Major revision needed -2. `runtime-and-launch.mdx` - Complete rewrite needed -3. New file needed: `configuration-reference.mdx` -4. New file needed: `configuration-examples.mdx` -5. New file needed: `troubleshooting-configuration.mdx` \ No newline at end of file diff --git a/docs.json b/docs.json index 59cc37e7..005f6d34 100644 --- a/docs.json +++ b/docs.json @@ -71,7 +71,6 @@ } ] }, - "docs/evm/v0.5.0/documentation/getting-started/index", "docs/evm/v0.5.0/documentation/getting-started/faq" ] }, @@ -371,7 +370,6 @@ } ] }, - "docs/evm/next/documentation/getting-started/index", "docs/evm/next/documentation/getting-started/faq" ] }, diff --git a/docs/evm/next/documentation/concepts/accounts.mdx b/docs/evm/next/documentation/concepts/accounts.mdx index 5617bc45..90b0d1bd 100644 --- a/docs/evm/next/documentation/concepts/accounts.mdx +++ b/docs/evm/next/documentation/concepts/accounts.mdx @@ -62,7 +62,7 @@ type EthAccountI interface { **EIP-7702 Support**: Cosmos EVM supports [EIP-7702 code delegation](/docs/evm/next/documentation/evm-compatibility/eip-7702), allowing EOAs to temporarily delegate code execution to smart contracts through the `SetCodeHash` functionality. -For more information on Ethereum accounts head over to the [x/vm module](/docs/evm/next/documentation/cosmos-sdk/modules/vm). +For more information on Ethereum accounts head over to the [x/vm module](/docs//docs/evm/next/documentation/cosmos-sdk/modules/vm). ### Addresses and Public Keys diff --git a/docs/evm/next/documentation/concepts/predeployed-contracts.mdx b/docs/evm/next/documentation/concepts/predeployed-contracts.mdx index d44aa179..dd5729c9 100644 --- a/docs/evm/next/documentation/concepts/predeployed-contracts.mdx +++ b/docs/evm/next/documentation/concepts/predeployed-contracts.mdx @@ -107,7 +107,7 @@ For comprehensive information on each contract including usage examples and inte ## Related Concepts - [Precompiles](/docs/evm/next/documentation/smart-contracts/precompiles/overview) - Native chain implementations exposed as smart contracts -- [VM Module](/docs/evm/next/documentation/cosmos-sdk/modules/vm) - Core EVM module configuration including preinstalls +- [VM Module](/docs//docs/evm/next/documentation/cosmos-sdk/modules/vm) - Core EVM module configuration including preinstalls - [Building Your Chain](/docs/evm/next/documentation/getting-started/build-a-chain/overview) - Complete guide to chain setup ## Implementation Guides diff --git a/docs/evm/next/documentation/concepts/replay-protection.mdx b/docs/evm/next/documentation/concepts/replay-protection.mdx index 3b439035..f2e145b7 100644 --- a/docs/evm/next/documentation/concepts/replay-protection.mdx +++ b/docs/evm/next/documentation/concepts/replay-protection.mdx @@ -162,4 +162,4 @@ grep allow-unprotected-txs $HOME/.evmd/config/config.toml - [EIP-155 Specification](https://eips.ethereum.org/EIPS/eip-155) - [Chain ID Configuration](/docs/evm/next/documentation/concepts/chain-id) - [Transaction Types](/docs/evm/next/documentation/concepts/transactions#ethereum-tx-type) -- [EVM Module Parameters](/docs/evm/next/documentation/cosmos-sdk/modules/vm#parameters) \ No newline at end of file +- [EVM Module Parameters](/docs//docs/evm/next/documentation/cosmos-sdk/modules/vm#parameters) \ No newline at end of file diff --git a/docs/evm/next/documentation/cosmos-sdk/modules/erc20.mdx b/docs/evm/next/documentation/cosmos-sdk/modules/erc20.mdx index 27bfc4ca..2e148445 100644 --- a/docs/evm/next/documentation/cosmos-sdk/modules/erc20.mdx +++ b/docs/evm/next/documentation/cosmos-sdk/modules/erc20.mdx @@ -523,7 +523,7 @@ evmd tx erc20 register-coin --from mykey ## Related Documentation - [Building Your Chain Guide](/docs/evm/next/documentation/getting-started/build-a-chain/overview) - Main configuration walkthrough -- [VM Module](/docs/evm/next/documentation/cosmos-sdk/modules/vm) - EVM configuration +- [VM Module](/docs//docs/evm/next/documentation/cosmos-sdk/modules/vm) - EVM configuration - [IBC Module](/docs/evm/next/documentation/cosmos-sdk/modules/ibc) - IBC token handling --- diff --git a/docs/evm/next/documentation/cosmos-sdk/modules/feemarket.mdx b/docs/evm/next/documentation/cosmos-sdk/modules/feemarket.mdx index 985c8d93..1c408891 100644 --- a/docs/evm/next/documentation/cosmos-sdk/modules/feemarket.mdx +++ b/docs/evm/next/documentation/cosmos-sdk/modules/feemarket.mdx @@ -848,7 +848,7 @@ evmd tx gov submit-proposal param-change proposal.json --from validator --chain- ## Related Documentation - [Building Your Chain Guide](/docs/evm/next/documentation/getting-started/build-a-chain/overview) - Main configuration walkthrough -- [VM Module](/docs/evm/next/documentation/cosmos-sdk/modules/vm) - EVM configuration +- [VM Module](/docs//docs/evm/next/documentation/cosmos-sdk/modules/vm) - EVM configuration - [EIP-1559 Specification](https://eips.ethereum.org/EIPS/eip-1559) - Original Ethereum proposal --- diff --git a/docs/evm/next/documentation/cosmos-sdk/modules/precisebank.mdx b/docs/evm/next/documentation/cosmos-sdk/modules/precisebank.mdx index c02450bc..aea32d9d 100644 --- a/docs/evm/next/documentation/cosmos-sdk/modules/precisebank.mdx +++ b/docs/evm/next/documentation/cosmos-sdk/modules/precisebank.mdx @@ -640,7 +640,7 @@ REMAINDER=$(evmd query precisebank remainder -o json | jq -r '.remainder') ## Related Documentation - [Building Your Chain Guide](/docs/evm/next/documentation/getting-started/build-a-chain/overview) - Main configuration walkthrough -- [VM Module](/docs/evm/next/documentation/cosmos-sdk/modules/vm) - extended_denom_options setup +- [VM Module](/docs//docs/evm/next/documentation/cosmos-sdk/modules/vm) - extended_denom_options setup - [ERC20 Module](/docs/evm/next/documentation/cosmos-sdk/modules/erc20) - Token pair configuration --- diff --git a/docs/evm/next/documentation/cosmos-sdk/protocol.mdx b/docs/evm/next/documentation/cosmos-sdk/protocol.mdx index 1ba7efbf..a3fa1c08 100644 --- a/docs/evm/next/documentation/cosmos-sdk/protocol.mdx +++ b/docs/evm/next/documentation/cosmos-sdk/protocol.mdx @@ -35,7 +35,7 @@ Cosmos EVM enables EVM compatibility by implementing various components that tog * `StateDB` interface for state updates and queries * [JSON-RPC](/docs/evm/next/api-reference/ethereum-json-rpc) client for interacting with the EVM -Most components are implemented in the [VM module](/docs/evm/next/documentation/cosmos-sdk/modules/vm). However, to achieve a seamless developer experience, some components are implemented outside of the module. +Most components are implemented in the [VM module](/docs//docs/evm/next/documentation/cosmos-sdk/modules/vm). However, to achieve a seamless developer experience, some components are implemented outside of the module. To learn more about how Cosmos EVM achieves EVM compatibility as a Cosmos chain, explore the following concepts: diff --git a/docs/evm/next/documentation/getting-started/build-a-chain/additional-configuration/predeployed-contracts.mdx b/docs/evm/next/documentation/getting-started/build-a-chain/additional-configuration/predeployed-contracts.mdx index 83104565..a9b62409 100644 --- a/docs/evm/next/documentation/getting-started/build-a-chain/additional-configuration/predeployed-contracts.mdx +++ b/docs/evm/next/documentation/getting-started/build-a-chain/additional-configuration/predeployed-contracts.mdx @@ -365,4 +365,4 @@ preinstalls := append(evmtypes.DefaultPreinstalls, customPreinstall) - [Safe Contracts](https://github.com/safe-global/safe-contracts) - Safe multisig implementation ### Cosmos EVM Resources -- [VM Module Reference](/docs/evm/next/documentation/cosmos-sdk/modules/vm) - Complete VM module configuration \ No newline at end of file +- [VM Module Reference](/docs//docs/evm/next/documentation/cosmos-sdk/modules/vm) - Complete VM module configuration \ No newline at end of file diff --git a/docs/evm/next/documentation/getting-started/build-a-chain/build-a-chain_v.mdx b/docs/evm/next/documentation/getting-started/build-a-chain/build-a-chain_v.mdx index c3b0b537..5ee29b7f 100644 --- a/docs/evm/next/documentation/getting-started/build-a-chain/build-a-chain_v.mdx +++ b/docs/evm/next/documentation/getting-started/build-a-chain/build-a-chain_v.mdx @@ -195,7 +195,7 @@ After adding the network: ### Recommended Reading - + EVM execution and parameter configuration diff --git a/docs/evm/next/documentation/getting-started/build-a-chain/quick-start.mdx b/docs/evm/next/documentation/getting-started/build-a-chain/quick-start.mdx index 1a07bc56..6fc3bdfe 100644 --- a/docs/evm/next/documentation/getting-started/build-a-chain/quick-start.mdx +++ b/docs/evm/next/documentation/getting-started/build-a-chain/quick-start.mdx @@ -228,7 +228,7 @@ For detailed setup and configuration instructions, see the comprehensive guides ### Recommended Reading - + EVM execution and parameter configuration diff --git a/docs/evm/next/documentation/getting-started/build-a-chain/using-local-node.mdx b/docs/evm/next/documentation/getting-started/build-a-chain/using-local-node.mdx index f5c913fb..a43d44e4 100644 --- a/docs/evm/next/documentation/getting-started/build-a-chain/using-local-node.mdx +++ b/docs/evm/next/documentation/getting-started/build-a-chain/using-local-node.mdx @@ -256,7 +256,7 @@ Deploy standard contracts at genesis for Create2, Multicall3, Permit2, and Safe ### Recommended Reading - + EVM execution and parameter configuration diff --git a/docs/evm/next/documentation/getting-started/faq.mdx b/docs/evm/next/documentation/getting-started/faq.mdx index c2b2132d..f7fdd66f 100644 --- a/docs/evm/next/documentation/getting-started/faq.mdx +++ b/docs/evm/next/documentation/getting-started/faq.mdx @@ -2,13 +2,11 @@ title: "Frequently Asked Questions" --- -## Concepts[​](#concepts "Direct link to Concepts") - We're working on a migration guide for this and will have it posted up here as soon as possible! - + secp256k1 and ed25519 are both popular cryptographic algorithms used for digital signatures and key generation, but they have some differences in terms of security, performance, and compatibility with different systems. secp256k1 is an elliptic curve algorithm that is widely used in Bitcoin and many other cryptocurrencies. It provides 128-bit security, which is considered sufficient for most practical purposes. secp256k1 is relatively fast and efficient, making it a good choice for applications that require high performance. It is widely supported by most cryptographic libraries and software, which makes it a good choice for cross-platform applications. @@ -21,7 +19,7 @@ title: "Frequently Asked Questions" - Head over to Cosmos's [Buf](https://buf.build/cosmos). + Please go to the Cosmos [Buf](https://buf.build/cosmos) project page. diff --git a/docs/evm/next/documentation/getting-started/index.mdx b/docs/evm/next/documentation/getting-started/index.mdx index 5135e478..4637dced 100644 --- a/docs/evm/next/documentation/getting-started/index.mdx +++ b/docs/evm/next/documentation/getting-started/index.mdx @@ -2,23 +2,4 @@ title: "Overview" description: "Start building with Cosmos EVM." mode: "wide" ---- - -### Frontend Applications and Smart Contracts - -Set up your development environment and deploy your first application: - - - Configure your IDE and install essential development tools for optimal productivity. - Setup Environment → - - - -### Infrastructure & Integration - -For teams building or adding evm support to their chains: - - - Integrate Cosmos EVM into new or existing Cosmos SDK chains with step-by-step guidance. - Integrate EVM → - \ No newline at end of file +--- \ No newline at end of file diff --git a/docs/evm/next/documentation/overview.mdx b/docs/evm/next/documentation/overview.mdx index f5719cbd..453b17c3 100644 --- a/docs/evm/next/documentation/overview.mdx +++ b/docs/evm/next/documentation/overview.mdx @@ -7,16 +7,16 @@ mode: "wide" import { EthereumOutlineIcon, CosmosOutlineIcon } from '/snippets/icons.mdx' - } href="/docs/evm/next/documentation/evm-compatibility/overview"> + } href="/docs/evm/v0.5.0/documentation/evm-compatibility/overview"> Deploy existing Solidity contracts, use familiar tools like MetaMask, Hardhat, and Foundry - } href="/docs/evm/next/documentation/smart-contracts/precompiles/overview"> + } href="/docs/evm/v0.5.0/documentation/smart-contracts/precompiles/overview"> Access staking, governance, IBC, and other Cosmos SDK modules directly from smart contracts - + 1-2 second block times with instant finality via 'CometBFT' consensus - + Built-in IBC support for interoperability across a growing list of ecosystems @@ -34,26 +34,4 @@ From a developer's perspective, chains built with Cosmos EVM are **indistinguish - **Use standard libraries** such as ethers.js, viem, and web3.js with zero changes - **AI tools work seamlessly** - Claude, ChatGPT, and other AI assistants treat your local testnet as if it's Ethereum mainnet, deploying contracts and interacting with them using standard Ethereum patterns -All user-facing components are identical. The difference lies in what happens under the hood: instant finality, native IBC interoperability, and direct access to Cosmos SDK modules from your smart contracts. - -## The Easiest Way To Launch an EVM Layer 1 - -### Advantages of Starting with Cosmos-EVM - -Building with `Cosmos-EVM` comes with numerous benefits:: - -- **Greater compatibility** - Direct alignment with the module's development ensures configurations work as intended -- **Improved troubleshooting** - Similarity to the base project simplifies diagnosing and resolving issues -- **Proven architecture** - At the core of Cosmos-SDK is `go-ethereum` (Geth), the most widely used and battle-tested Ethereum client -- **Production ready** - Fully audited codebase [(read our audit)](#audits) -- **Active ecosystem** - Join a growing number of projects already running Cosmos EVM and be part of the shift to more efficient, affordable networks -- **Faster go-to-market** - Launch your EVM-compatible chain in weeks, not months by using `evmd` as a foundation - - -Use our `evmd` reference network as a starting point for bootstrapping your own blockchain with full EVM compatibility, from start to finish. - - -## Audits - -The [Cosmos/EVM](https://github.com/cosmos/evm) codebase has undergone comprehensive third-party security audits and a full internal review by [Cosmos Labs](https://cosmoslabs.io) most experienced senior engineers: -[Read the full audit reports here.](https://github.com/cosmos/evm/blob/main/docs/audits/sherlock_2025_07_28_final.pdf) +All user-facing components are identical. The difference lies in what happens under the hood: instant finality, native IBC interoperability, and direct access to Cosmos SDK modules from your smart contracts. \ No newline at end of file diff --git a/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/additional-configuration/predeployed-contracts.mdx b/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/additional-configuration/predeployed-contracts.mdx index f8286036..87e3604e 100644 --- a/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/additional-configuration/predeployed-contracts.mdx +++ b/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/additional-configuration/predeployed-contracts.mdx @@ -367,4 +367,4 @@ preinstalls := append(evmtypes.DefaultPreinstalls, customPreinstall) ### Cosmos EVM Resources - [VM Module Reference](/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/vm) - Complete VM module configuration - [Chain Customization Checklist](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start) - Step-by-step setup guide -- [Configuration Parameters](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/configuration-parameters) - All genesis parameters explained \ No newline at end of file +- [Configuration Parameters](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start) - All genesis parameters explained \ No newline at end of file diff --git a/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start.mdx b/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start.mdx index 8b3d4be0..f0c021b5 100644 --- a/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start.mdx +++ b/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start.mdx @@ -277,7 +277,7 @@ Deploy standard contracts at genesis for Create2, Multicall3, Permit2, and Safe ### Recommended Reading - + EVM execution and parameter configuration diff --git a/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/using-local-node.mdx b/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/using-local-node.mdx index 1890a7fc..a2cd70f2 100644 --- a/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/using-local-node.mdx +++ b/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/using-local-node.mdx @@ -256,7 +256,7 @@ Deploy standard contracts at genesis for Create2, Multicall3, Permit2, and Safe ### Recommended Reading - + EVM execution and parameter configuration diff --git a/docs/evm/v0.5.0/documentation/getting-started/faq.mdx b/docs/evm/v0.5.0/documentation/getting-started/faq.mdx index c2b2132d..f7fdd66f 100644 --- a/docs/evm/v0.5.0/documentation/getting-started/faq.mdx +++ b/docs/evm/v0.5.0/documentation/getting-started/faq.mdx @@ -2,13 +2,11 @@ title: "Frequently Asked Questions" --- -## Concepts[​](#concepts "Direct link to Concepts") - We're working on a migration guide for this and will have it posted up here as soon as possible! - + secp256k1 and ed25519 are both popular cryptographic algorithms used for digital signatures and key generation, but they have some differences in terms of security, performance, and compatibility with different systems. secp256k1 is an elliptic curve algorithm that is widely used in Bitcoin and many other cryptocurrencies. It provides 128-bit security, which is considered sufficient for most practical purposes. secp256k1 is relatively fast and efficient, making it a good choice for applications that require high performance. It is widely supported by most cryptographic libraries and software, which makes it a good choice for cross-platform applications. @@ -21,7 +19,7 @@ title: "Frequently Asked Questions" - Head over to Cosmos's [Buf](https://buf.build/cosmos). + Please go to the Cosmos [Buf](https://buf.build/cosmos) project page. diff --git a/docs/evm/v0.5.0/documentation/getting-started/index.mdx b/docs/evm/v0.5.0/documentation/getting-started/index.mdx index 88eb94bd..03662f22 100644 --- a/docs/evm/v0.5.0/documentation/getting-started/index.mdx +++ b/docs/evm/v0.5.0/documentation/getting-started/index.mdx @@ -3,22 +3,3 @@ title: "Overview" description: "Start building with Cosmos EVM." mode: "wide" --- - -### Frontend Applications and Smart Contracts - -Set up your development environment and deploy your first application: - - - Configure your IDE and install essential development tools for optimal productivity. - Setup Environment → - - - -### Infrastructure & Integration - -For teams building or adding evm support to their chains: - - - Integrate Cosmos EVM into new or existing Cosmos SDK chains with step-by-step guidance. - Integrate EVM → - \ No newline at end of file diff --git a/docs/evm/v0.5.0/documentation/overview.mdx b/docs/evm/v0.5.0/documentation/overview.mdx index 548ec415..453b17c3 100644 --- a/docs/evm/v0.5.0/documentation/overview.mdx +++ b/docs/evm/v0.5.0/documentation/overview.mdx @@ -34,26 +34,4 @@ From a developer's perspective, chains built with Cosmos EVM are **indistinguish - **Use standard libraries** such as ethers.js, viem, and web3.js with zero changes - **AI tools work seamlessly** - Claude, ChatGPT, and other AI assistants treat your local testnet as if it's Ethereum mainnet, deploying contracts and interacting with them using standard Ethereum patterns -All user-facing components are identical. The difference lies in what happens under the hood: instant finality, native IBC interoperability, and direct access to Cosmos SDK modules from your smart contracts. - -## The Easiest Way To Launch an EVM Layer 1 - -### Advantages of Starting with Cosmos-EVM - -Building with `Cosmos-EVM` comes with numerous benefits:: - -- **Greater compatibility** - Direct alignment with the module's development ensures configurations work as intended -- **Improved troubleshooting** - Similarity to the base project simplifies diagnosing and resolving issues -- **Proven architecture** - At the core of Cosmos-SDK is `go-ethereum` (Geth), the most widely used and battle-tested Ethereum client -- **Production ready** - Fully audited codebase [(read our audit)](#audits) -- **Active ecosystem** - Join a growing number of projects already running Cosmos EVM and be part of the shift to more efficient, affordable networks -- **Faster go-to-market** - Launch your EVM-compatible chain in weeks, not months by using `evmd` as a foundation - - -Use our `evmd` reference network as a starting point for bootstrapping your own blockchain with full EVM compatibility, from start to finish. - - -## Audits - -The [Cosmos/EVM](https://github.com/cosmos/evm) codebase has undergone comprehensive third-party security audits and a full internal review by [Cosmos Labs](https://cosmoslabs.io) most experienced senior engineers: -[Read the full audit reports here.](https://github.com/cosmos/evm/blob/main/docs/audits/sherlock_2025_07_28_final.pdf) +All user-facing components are identical. The difference lies in what happens under the hood: instant finality, native IBC interoperability, and direct access to Cosmos SDK modules from your smart contracts. \ No newline at end of file diff --git a/docs/ibc/next/index.mdx b/docs/ibc/next/index.mdx index 97bfbba2..a6899a77 100644 --- a/docs/ibc/next/index.mdx +++ b/docs/ibc/next/index.mdx @@ -29,7 +29,7 @@ Documentation for IBC is currently being developed. For the latest information, ## Resources - [GitHub Repository](https://github.com/cosmos/ibc-go) -- [Release Notes](/docs/ibc/next/changelog/release-notes) +- [Release Notes](/docs/ibc/next/index) --- diff --git a/docs/sdk/v0.47/build/architecture/adr-054-semver-compatible-modules.mdx b/docs/sdk/v0.47/build/architecture/adr-054-semver-compatible-modules.mdx index 711d09c5..2e4f221a 100644 --- a/docs/sdk/v0.47/build/architecture/adr-054-semver-compatible-modules.mdx +++ b/docs/sdk/v0.47/build/architecture/adr-054-semver-compatible-modules.mdx @@ -476,7 +476,7 @@ languages, possibly executed within a WASM VM. ### Minor API Revisions To declare minor API revisions of proto files, we propose the following guidelines (which were already documented -in [cosmos.app.v1alpha module options](/docs/sdk/v0.47/proto/cosmos/app/v1alpha1/module.proto)): +in [cosmos.app.v1alpha module options](/https://github.com/cosmos/cosmos-sdk/blob/v0.47/proto/cosmos/app/v1alpha1/module.proto)): * proto packages which are revised from their initial version (considered revision `0`) should include a `package` * comment in some .proto file containing the test `Revision N` at the start of a comment line where `N` is the current diff --git a/docs/sdk/v0.47/build/architecture/adr-057-app-wiring.mdx b/docs/sdk/v0.47/build/architecture/adr-057-app-wiring.mdx index bb8bd55c..a9f8fa54 100644 --- a/docs/sdk/v0.47/build/architecture/adr-057-app-wiring.mdx +++ b/docs/sdk/v0.47/build/architecture/adr-057-app-wiring.mdx @@ -229,7 +229,7 @@ In cases where required modules are not loaded at runtime, it may be possible to through a global Cosmos SDK module registry. The `*appmodule.Handler` type referenced above is a replacement for the legacy `AppModule` framework, and -described in [ADR 063: Core Module API](/docs/sdk/v0.47/adr-063-core-module-api). +described in [ADR 063: Core Module API](/docs/sdk/v0.47/build/architecture/adr-063-core-module-api). ### New `app.go` @@ -260,7 +260,7 @@ func main() { So far we have described a system which is largely agnostic to the specifics of the SDK such as store keys, `AppModule`, `BaseApp`, etc. Improvements to these parts of the framework that integrate with the general app wiring framework -defined here are described in [ADR 061: Core Module API](/docs/sdk/v0.47/adr-063-core-module-api). +defined here are described in [ADR 061: Core Module API](/docs/sdk/v0.47/build/architecture/adr-063-core-module-api). ### Registration of Inter-Module Hooks @@ -355,4 +355,4 @@ light of code generation. It may be better to do this type registration with a D * [Link](https://github.com/google/wire) * [Link](https://pkg.go.dev/github.com/cosmos/cosmos-sdk/container) * [Link](https://github.com/cosmos/cosmos-sdk/pull/11802) -* [ADR 063](/docs/sdk/v0.47/adr-063-core-module-api) +* [ADR 063](/docs/sdk/v0.47/build/architecture/adr-063-core-module-api) diff --git a/docs/sdk/v0.47/build/architecture/adr-063-core-module-api.mdx b/docs/sdk/v0.47/build/architecture/adr-063-core-module-api.mdx index d4d83d39..56166ba3 100644 --- a/docs/sdk/v0.47/build/architecture/adr-063-core-module-api.mdx +++ b/docs/sdk/v0.47/build/architecture/adr-063-core-module-api.mdx @@ -410,7 +410,7 @@ Additional `AppModule` extension interfaces either inside or outside of core wil these concerns. In the case of gogo proto and amino interfaces, the registration of these generally should happen as early -as possible during initialization and in [ADR 057: App Wiring](/docs/sdk/v0.47/adr-057-app-wiring), protobuf type registration\ +as possible during initialization and in [ADR 057: App Wiring](/docs/sdk/v0.47/build/architecture/adr-057-app-wiring), protobuf type registration\ happens before dependency injection (although this could alternatively be done dedicated DI providers). gRPC gateway registration should probably be handled by the runtime module, but the core API shouldn't depend on gRPC @@ -550,7 +550,7 @@ as by providing service implementations by wrapping `sdk.Context`. ## References * [ADR 033: Protobuf-based Inter-Module Communication](/docs/sdk/v0.47/build/architecture/adr-033-protobuf-inter-module-comm) -* [ADR 057: App Wiring](/docs/sdk/v0.47/adr-057-app-wiring) +* [ADR 057: App Wiring](/docs/sdk/v0.47/build/architecture/adr-057-app-wiring) * [ADR 055: ORM](/docs/sdk/v0.47/build/architecture/adr-055-orm) * [ADR 028: Public Key Addresses](/docs/sdk/v0.47/build/architecture/adr-028-public-key-addresses) * [Keeping Your Modules Compatible](https://go.dev/blog/module-compatibility) diff --git a/docs/sdk/v0.47/build/building-modules/depinject.mdx b/docs/sdk/v0.47/build/building-modules/depinject.mdx index 6af607a3..97eb04aa 100644 --- a/docs/sdk/v0.47/build/building-modules/depinject.mdx +++ b/docs/sdk/v0.47/build/building-modules/depinject.mdx @@ -3534,4 +3534,4 @@ The module is now ready to be used with `depinject` by a chain developer. ## Integrate in an application -The App Wiring is done in `app_config.go` / `app.yaml` and `app_v2.go` and is explained in detail in the [overview of `app_v2.go`](/docs/sdk/v0.47/building-apps/app-go-v2). +The App Wiring is done in `app_config.go` / `app.yaml` and `app_v2.go` and is explained in detail in the [overview of `app_v2.go`](/docs/sdk/v0.47/build/building-apps/app-go-v2). diff --git a/docs/sdk/v0.47/build/building-modules/module-interfaces.mdx b/docs/sdk/v0.47/build/building-modules/module-interfaces.mdx index 60b63f49..16b9942f 100644 --- a/docs/sdk/v0.47/build/building-modules/module-interfaces.mdx +++ b/docs/sdk/v0.47/build/building-modules/module-interfaces.mdx @@ -192,7 +192,7 @@ In general, the getter function does the following: * **RunE:** Defines a function that can return an error. This is the function that is called when the command is executed. This function encapsulates all of the logic to create a new transaction. * The function typically starts by getting the `clientCtx`, which can be done with `client.GetClientTxContext(cmd)`. The `clientCtx` contains information relevant to transaction handling, including information about the user. In this example, the `clientCtx` is used to retrieve the address of the sender by calling `clientCtx.GetFromAddress()`. * If applicable, the command's arguments are parsed. In this example, the arguments `[to_address]` and `[amount]` are both parsed. - * A [message](/docs/sdk/v0.47/build/building-modules/messages-and-queries) is created using the parsed arguments and information from the `clientCtx`. The constructor function of the message type is called directly. In this case, `types.NewMsgSend(fromAddr, toAddr, amount)`. Its good practice to call, if possible, the necessary [message validation methods](/docs/sdk/v0.47/build/building-modules/Validation) before broadcasting the message. + * A [message](/docs/sdk/v0.47/build/building-modules/messages-and-queries) is created using the parsed arguments and information from the `clientCtx`. The constructor function of the message type is called directly. In this case, `types.NewMsgSend(fromAddr, toAddr, amount)`. Its good practice to call, if possible, the necessary [message validation methods](/docs/sdk/v0.47/build/building-modules/messages-and-queries) before broadcasting the message. * Depending on what the user wants, the transaction is either generated offline or signed and broadcasted to the preconfigured node using `tx.GenerateOrBroadcastTxCLI(clientCtx, flags, msg)`. * **Adds transaction flags:** All transaction commands must add a set of transaction [flags](#flags). The transaction flags are used to collect additional information from the user (e.g. the amount of fees the user is willing to pay). The transaction flags are added to the constructed command using `AddTxFlagsToCmd(cmd)`. * **Returns the command:** Finally, the transaction command is returned. diff --git a/docs/sdk/v0.47/build/building-modules/structure.mdx b/docs/sdk/v0.47/build/building-modules/structure.mdx index 96043d12..e773353f 100644 --- a/docs/sdk/v0.47/build/building-modules/structure.mdx +++ b/docs/sdk/v0.47/build/building-modules/structure.mdx @@ -81,7 +81,7 @@ x/{module_name} * `abci.go`: The module's `BeginBlocker` and `EndBlocker` implementations (this file is only required if `BeginBlocker` and/or `EndBlocker` need to be defined). * `autocli.go`: The module [autocli](/docs/sdk/v0.47/build/tooling/autocli) options. * `simulation/`: The module's [simulation](/docs/sdk/v0.47/build/building-modules/simulator) package defines functions used by the blockchain simulator application (`simapp`). -* `REAMDE.md`: The module's specification documents outlining important concepts, state storage structure, and message and event type definitions. Learn more how to write module specs in the [spec guidelines](/docs/sdk/v0.47/spec/SPEC_MODULE). +* `REAMDE.md`: The module's specification documents outlining important concepts, state storage structure, and message and event type definitions. Learn more how to write module specs in the [spec guidelines](/docs/sdk/v0.47/build/spec/SPEC_MODULE). * The root directory includes type definitions for messages, events, and genesis state, including the type definitions generated by Protocol Buffers. * `codec.go`: The module's registry methods for interface types. * `errors.go`: The module's sentinel errors. diff --git a/docs/sdk/v0.47/build/modules/evidence/README.mdx b/docs/sdk/v0.47/build/modules/evidence/README.mdx index 0aef0973..b55e8ab8 100644 --- a/docs/sdk/v0.47/build/modules/evidence/README.mdx +++ b/docs/sdk/v0.47/build/modules/evidence/README.mdx @@ -412,7 +412,7 @@ k.SetEvidence(ctx, evidence) **Note:** The slashing, jailing, and tombstoning calls are delegated through the `x/slashing` module that emits informative events and finally delegates calls to the `x/staking` module. See documentation -on slashing and jailing in [State Transitions](/docs/sdk/v0.47/staking/README#state-transitions). +on slashing and jailing in [State Transitions](/docs/sdk/v0.47/build/modules/staking/README#state-transitions). ## Client diff --git a/docs/sdk/v0.47/build/modules/feegrant/README.mdx b/docs/sdk/v0.47/build/modules/feegrant/README.mdx index b7cdb1f7..dbd28ea4 100644 --- a/docs/sdk/v0.47/build/modules/feegrant/README.mdx +++ b/docs/sdk/v0.47/build/modules/feegrant/README.mdx @@ -1597,7 +1597,7 @@ Example cmd: ### Granted Fee Deductions -Fees are deducted from grants in the `x/auth` ante handler. To learn more about how ante handlers work, read the [Auth Module AnteHandlers Guide](/docs/sdk/v0.47/auth/README#antehandlers). +Fees are deducted from grants in the `x/auth` ante handler. To learn more about how ante handlers work, read the [Auth Module AnteHandlers Guide](/docs/sdk/v0.47/build/modules/auth/aut#antehandlers). ### Gas diff --git a/docs/sdk/v0.47/build/modules/gov/README.mdx b/docs/sdk/v0.47/build/modules/gov/README.mdx index 12786be9..3d659024 100644 --- a/docs/sdk/v0.47/build/modules/gov/README.mdx +++ b/docs/sdk/v0.47/build/modules/gov/README.mdx @@ -2615,7 +2615,7 @@ The gov module has two locations for metadata where users can provide further co ### Proposal -Location: off-chain as json object stored on IPFS (mirrors [group proposal](/docs/sdk/v0.47/group/README#metadata)) +Location: off-chain as json object stored on IPFS (mirrors [group proposal](/docs/sdk/v0.47/build/modules/group/README#metadata)) ```json { @@ -2635,7 +2635,7 @@ In v0.46, the `authors` field is a comma-separated string. Frontends are encoura ### Vote -Location: on-chain as json within 255 character limit (mirrors [group vote](/docs/sdk/v0.47/group/README#metadata)) +Location: on-chain as json within 255 character limit (mirrors [group vote](/docs/sdk/v0.47/build/modules/group/README#metadata)) ```json { diff --git a/docs/sdk/v0.47/build/modules/group/README.mdx b/docs/sdk/v0.47/build/modules/group/README.mdx index cf7c1da2..dce5abda 100644 --- a/docs/sdk/v0.47/build/modules/group/README.mdx +++ b/docs/sdk/v0.47/build/modules/group/README.mdx @@ -8953,7 +8953,7 @@ The group module has four locations for metadata where users can provide further ### Proposal -Location: off-chain as json object stored on IPFS (mirrors [gov proposal](/docs/sdk/v0.47/gov/README#metadata)) +Location: off-chain as json object stored on IPFS (mirrors [gov proposal](/docs/sdk/v0.47/build/modules/gov/README#metadata)) ```json { @@ -8973,7 +8973,7 @@ In v0.46, the `authors` field is a comma-separated string. Frontends are encoura ### Vote -Location: on-chain as json within 255 character limit (mirrors [gov vote](/docs/sdk/v0.47/gov/README#metadata)) +Location: on-chain as json within 255 character limit (mirrors [gov vote](/docs/sdk/v0.47/build/modules/gov/README#metadata)) ```json { diff --git a/docs/sdk/v0.47/build/modules/slashing/README.mdx b/docs/sdk/v0.47/build/modules/slashing/README.mdx index c2baa9ec..bba37692 100644 --- a/docs/sdk/v0.47/build/modules/slashing/README.mdx +++ b/docs/sdk/v0.47/build/modules/slashing/README.mdx @@ -107,7 +107,7 @@ long as it contains precommits from +2/3 of total voting power. Proposers are incentivized to include precommits from all validators in the CometBFT `LastCommitInfo` by receiving additional fees proportional to the difference between the voting -power included in the `LastCommitInfo` and +2/3 (see [fee distribution](/docs/sdk/v0.47/distribution/README#begin-block)). +power included in the `LastCommitInfo` and +2/3 (see [fee distribution](/docs/sdk/v0.47/build/modules/distribution/README#begin-block)). ```go type LastCommitInfo struct { diff --git a/docs/sdk/v0.47/learn/advanced/grpc_rest.mdx b/docs/sdk/v0.47/learn/advanced/grpc_rest.mdx index e1fa9df0..8bacff8d 100644 --- a/docs/sdk/v0.47/learn/advanced/grpc_rest.mdx +++ b/docs/sdk/v0.47/learn/advanced/grpc_rest.mdx @@ -21,7 +21,7 @@ The node also exposes some other endpoints, such as the CometBFT P2P endpoint, o ## gRPC Server -In the Cosmos SDK, Protobuf is the main [encoding](/docs/sdk/v0.47/encoding) library. This brings a wide range of Protobuf-based tools that can be plugged into the Cosmos SDK. One such tool is [gRPC](https://grpc.io), a modern open-source high performance RPC framework that has decent client support in several languages. +In the Cosmos SDK, Protobuf is the main [encoding](/docs/sdk/v0.47/learn/advanced/encoding) library. This brings a wide range of Protobuf-based tools that can be plugged into the Cosmos SDK. One such tool is [gRPC](https://grpc.io), a modern open-source high performance RPC framework that has decent client support in several languages. Each module exposes a [Protobuf `Query` service](/docs/sdk/v0.47//build/building-modules/messages-and-queries#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: diff --git a/docs/sdk/v0.47/learn/intro/overview.mdx b/docs/sdk/v0.47/learn/intro/overview.mdx index 91456da1..c83d6d9d 100644 --- a/docs/sdk/v0.47/learn/intro/overview.mdx +++ b/docs/sdk/v0.47/learn/intro/overview.mdx @@ -4,7 +4,7 @@ title: What is the Cosmos SDK The [Cosmos SDK](https://github.com/cosmos/cosmos-sdk) is an open-source framework for building multi-asset public Proof-of-Stake (PoS) blockchains, like the Cosmos Hub, as well as permissioned Proof-of-Authority (PoA) blockchains. Blockchains built with the Cosmos SDK are generally referred to as **application-specific blockchains**. -The goal of the Cosmos SDK is to allow developers to easily create custom blockchains from scratch that can natively interoperate with other blockchains. We envision the Cosmos SDK as the npm-like framework to build secure blockchain applications on top of [CometBFT](https://github.com/cometbft/cometbft). SDK-based blockchains are built out of composable [modules](/docs/sdk/v0.47//build/building-modules/intro), most of which are open-source and readily available for any developers to use. Anyone can create a module for the Cosmos SDK, and integrating already-built modules is as simple as importing them into your blockchain application. What's more, the Cosmos SDK is a capabilities-based system that allows developers to better reason about the security of interactions between modules. For a deeper look at capabilities, jump to [Object-Capability Model](/docs/sdk/v0.47/advanced/ocap). +The goal of the Cosmos SDK is to allow developers to easily create custom blockchains from scratch that can natively interoperate with other blockchains. We envision the Cosmos SDK as the npm-like framework to build secure blockchain applications on top of [CometBFT](https://github.com/cometbft/cometbft). SDK-based blockchains are built out of composable [modules](/docs/sdk/v0.47//build/building-modules/intro), most of which are open-source and readily available for any developers to use. Anyone can create a module for the Cosmos SDK, and integrating already-built modules is as simple as importing them into your blockchain application. What's more, the Cosmos SDK is a capabilities-based system that allows developers to better reason about the security of interactions between modules. For a deeper look at capabilities, jump to [Object-Capability Model](/docs/sdk/v0.47/learn/advanced/ocap). ## What are Application-Specific Blockchains diff --git a/docs/sdk/v0.47/learn/intro/sdk-design.mdx b/docs/sdk/v0.47/learn/intro/sdk-design.mdx index 7fc3a30c..ecbbb546 100644 --- a/docs/sdk/v0.47/learn/intro/sdk-design.mdx +++ b/docs/sdk/v0.47/learn/intro/sdk-design.mdx @@ -902,7 +902,7 @@ For more on `baseapp`, please click [here](/docs/sdk/v0.47/learn/advanced/baseap ## Multistore -The Cosmos SDK provides a [`multistore`](/docs/sdk/v0.47/learn/advanced/store#multistore) for persisting state. The multistore allows developers to declare any number of [`KVStores`](/docs/sdk/v0.47/learn/advanced/store#base-layer-kvstores). These `KVStores` only accept the `[]byte` type as value and therefore any custom structure needs to be marshalled using [a codec](/docs/sdk/v0.47/advanced/encoding) before being stored. +The Cosmos SDK provides a [`multistore`](/docs/sdk/v0.47/learn/advanced/store#multistore) for persisting state. The multistore allows developers to declare any number of [`KVStores`](/docs/sdk/v0.47/learn/advanced/store#base-layer-kvstores). These `KVStores` only accept the `[]byte` type as value and therefore any custom structure needs to be marshalled using [a codec](/docs/sdk/v0.47/learn/advanced/encoding) before being stored. The multistore abstraction is used to divide the state in distinct compartments, each managed by its own module. For more on the multistore, click [here](/docs/sdk/v0.47/learn/advanced/store#multistore) diff --git a/docs/sdk/v0.47/user/run-node/run-production.mdx b/docs/sdk/v0.47/user/run-node/run-production.mdx index 8a454116..674eb690 100644 --- a/docs/sdk/v0.47/user/run-node/run-production.mdx +++ b/docs/sdk/v0.47/user/run-node/run-production.mdx @@ -47,7 +47,7 @@ In the past, validators [have had issues](https://github.com/cosmos/cosmos-sdk/i ### Firewall -Nodes should not have all ports open to the public, this is a simple way to get DDOS'd. Secondly it is recommended by [CometBFT](/docs/sdk/v0.47/user/run-node/github.com/cometbft/cometbft) to never expose ports that are not required to operate a node. +Nodes should not have all ports open to the public, this is a simple way to get DDOS'd. Secondly it is recommended by [CometBFT](/https://github.com/cometbft/cometbft) to never expose ports that are not required to operate a node. When setting up a firewall there are a few ports that can be open when operating a Cosmos SDK node. There is the CometBFT json-RPC, prometheus, p2p, remote signer and Cosmos SDK GRPC and REST. If the node is being operated as a node that does not offer endpoints to be used for submission or querying then a max of three endpoints are needed. diff --git a/docs/sdk/v0.50/build/architecture/README.mdx b/docs/sdk/v0.50/build/architecture/README.mdx index eaa40f0e..2878c309 100644 --- a/docs/sdk/v0.50/build/architecture/README.mdx +++ b/docs/sdk/v0.50/build/architecture/README.mdx @@ -43,54 +43,54 @@ When writing ADRs, follow the same best practices for writing RFCs. When writing ### Accepted -* [ADR 002: SDK Documentation Structure](/docs/sdk/v0.50/adr-002-docs-structure) -* [ADR 004: Split Denomination Keys](/docs/sdk/v0.50/adr-004-split-denomination-keys) -* [ADR 006: Secret Store Replacement](/docs/sdk/v0.50/adr-006-secret-store-replacement) -* [ADR 009: Evidence Module](/docs/sdk/v0.50/adr-009-evidence-module) -* [ADR 010: Modular AnteHandler](/docs/sdk/v0.50/adr-010-modular-antehandler) -* [ADR 019: Protocol Buffer State Encoding](/docs/sdk/v0.50/adr-019-protobuf-state-encoding) -* [ADR 020: Protocol Buffer Transaction Encoding](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding) -* [ADR 021: Protocol Buffer Query Encoding](/docs/sdk/v0.50/adr-021-protobuf-query-encoding) -* [ADR 023: Protocol Buffer Naming and Versioning](/docs/sdk/v0.50/adr-023-protobuf-naming) -* [ADR 029: Fee Grant Module](/docs/sdk/v0.50/adr-029-fee-grant-module) -* [ADR 030: Message Authorization Module](/docs/sdk/v0.50/adr-030-authz-module) -* [ADR 031: Protobuf Msg Services](/docs/sdk/v0.50/adr-031-msg-service) -* [ADR 055: ORM](/docs/sdk/v0.50/adr-055-orm) -* [ADR 058: Auto-Generated CLI](/docs/sdk/v0.50/adr-058-auto-generated-cli) +* [ADR 002: SDK Documentation Structure](/docs/sdk/v0.50/build/architecture/adr-002-docs-structure) +* [ADR 004: Split Denomination Keys](/docs/sdk/v0.50/build/architecture/adr-004-split-denomination-keys) +* [ADR 006: Secret Store Replacement](/docs/sdk/v0.50/build/architecture/adr-006-secret-store-replacement) +* [ADR 009: Evidence Module](/docs/sdk/v0.50/build/architecture/adr-009-evidence-module) +* [ADR 010: Modular AnteHandler](/docs/sdk/v0.50/build/architecture/adr-010-modular-antehandler) +* [ADR 019: Protocol Buffer State Encoding](/docs/sdk/v0.50/build/architecture/adr-019-protobuf-state-encoding) +* [ADR 020: Protocol Buffer Transaction Encoding](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding) +* [ADR 021: Protocol Buffer Query Encoding](/docs/sdk/v0.50/build/architecture/adr-021-protobuf-query-encoding) +* [ADR 023: Protocol Buffer Naming and Versioning](/docs/sdk/v0.50/build/architecture/adr-023-protobuf-naming) +* [ADR 029: Fee Grant Module](/docs/sdk/v0.50/build/architecture/adr-029-fee-grant-module) +* [ADR 030: Message Authorization Module](/docs/sdk/v0.50/build/architecture/adr-030-authz-module) +* [ADR 031: Protobuf Msg Services](/docs/sdk/v0.50/build/architecture/adr-031-msg-service) +* [ADR 055: ORM](/docs/sdk/v0.50/build/architecture/adr-055-orm) +* [ADR 058: Auto-Generated CLI](/docs/sdk/v0.50/build/architecture/adr-058-auto-generated-cli) * [ADR 060: ABCI 1.0 (Phase I)](/docs/sdk/v0.50/build/architecture/adr-060-abci-1.0) -* [ADR 061: Liquid Staking](/docs/sdk/v0.50/adr-061-liquid-staking) +* [ADR 061: Liquid Staking](/docs/sdk/v0.50/build/architecture/adr-061-liquid-staking) ### Proposed -* [ADR 003: Dynamic Capability Store](/docs/sdk/v0.50/adr-003-dynamic-capability-store) -* [ADR 011: Generalize Genesis Accounts](/docs/sdk/v0.50/adr-011-generalize-genesis-accounts) -* [ADR 012: State Accessors](/docs/sdk/v0.50/adr-012-state-accessors) -* [ADR 013: Metrics](/docs/sdk/v0.50/adr-013-metrics) -* [ADR 016: Validator Consensus Key Rotation](/docs/sdk/v0.50/adr-016-validator-consensus-key-rotation) -* [ADR 017: Historical Header Module](/docs/sdk/v0.50/adr-017-historical-header-module) -* [ADR 018: Extendable Voting Periods](/docs/sdk/v0.50/adr-018-extendable-voting-period) -* [ADR 022: Custom baseapp panic handling](/docs/sdk/v0.50/adr-022-custom-panic-handling) -* [ADR 024: Coin Metadata](/docs/sdk/v0.50/adr-024-coin-metadata) -* [ADR 027: Deterministic Protobuf Serialization](/docs/sdk/v0.50/adr-027-deterministic-protobuf-serialization) -* [ADR 028: Public Key Addresses](/docs/sdk/v0.50/adr-028-public-key-addresses) -* [ADR 032: Typed Events](/docs/sdk/v0.50/adr-032-typed-events) -* [ADR 033: Inter-module RPC](/docs/sdk/v0.50/adr-033-protobuf-inter-module-comm) -* [ADR 035: Rosetta API Support](/docs/sdk/v0.50/adr-035-rosetta-api-support) -* [ADR 037: Governance Split Votes](/docs/sdk/v0.50/adr-037-gov-split-vote) -* [ADR 038: State Listening](/docs/sdk/v0.50/adr-038-state-listening) -* [ADR 039: Epoched Staking](/docs/sdk/v0.50/adr-039-epoched-staking) -* [ADR 040: Storage and SMT State Commitments](/docs/sdk/v0.50/adr-040-storage-and-smt-state-commitments) -* [ADR 046: Module Params](/docs/sdk/v0.50/adr-046-module-params) -* [ADR 054: Semver Compatible SDK Modules](/docs/sdk/v0.50/adr-054-semver-compatible-modules) -* [ADR 057: App Wiring](/docs/sdk/v0.50/adr-057-app-wiring) -* [ADR 059: Test Scopes](/docs/sdk/v0.50/adr-059-test-scopes) -* [ADR 062: Collections State Layer](/docs/sdk/v0.50/adr-062-collections-state-layer) -* [ADR 063: Core Module API](/docs/sdk/v0.50/adr-063-core-module-api) -* [ADR 065: Store V2](/docs/sdk/v0.50/adr-065-store-v2) +* [ADR 003: Dynamic Capability Store](/docs/sdk/v0.50/build/architecture/adr-003-dynamic-capability-store) +* [ADR 011: Generalize Genesis Accounts](/docs/sdk/v0.50/build/architecture/adr-011-generalize-genesis-accounts) +* [ADR 012: State Accessors](/docs/sdk/v0.50/build/architecture/adr-012-state-accessors) +* [ADR 013: Metrics](/docs/sdk/v0.50/build/architecture/adr-013-metrics) +* [ADR 016: Validator Consensus Key Rotation](/docs/sdk/v0.50/build/architecture/adr-016-validator-consensus-key-rotation) +* [ADR 017: Historical Header Module](/docs/sdk/v0.50/build/architecture/adr-017-historical-header-module) +* [ADR 018: Extendable Voting Periods](/docs/sdk/v0.50/build/architecture/adr-018-extendable-voting-period) +* [ADR 022: Custom baseapp panic handling](/docs/sdk/v0.50/build/architecture/adr-022-custom-panic-handling) +* [ADR 024: Coin Metadata](/docs/sdk/v0.50/build/architecture/adr-024-coin-metadata) +* [ADR 027: Deterministic Protobuf Serialization](/docs/sdk/v0.50/build/architecture/adr-027-deterministic-protobuf-serialization) +* [ADR 028: Public Key Addresses](/docs/sdk/v0.50/build/architecture/adr-028-public-key-addresses) +* [ADR 032: Typed Events](/docs/sdk/v0.50/build/architecture/adr-032-typed-events) +* [ADR 033: Inter-module RPC](/docs/sdk/v0.50/build/architecture/adr-033-protobuf-inter-module-comm) +* [ADR 035: Rosetta API Support](/docs/sdk/v0.50/build/architecture/adr-035-rosetta-api-support) +* [ADR 037: Governance Split Votes](/docs/sdk/v0.50/build/architecture/adr-037-gov-split-vote) +* [ADR 038: State Listening](/docs/sdk/v0.50/build/architecture/adr-038-state-listening) +* [ADR 039: Epoched Staking](/docs/sdk/v0.50/build/architecture/adr-039-epoched-staking) +* [ADR 040: Storage and SMT State Commitments](/docs/sdk/v0.50/build/architecture/adr-040-storage-and-smt-state-commitments) +* [ADR 046: Module Params](/docs/sdk/v0.50/build/architecture/adr-046-module-params) +* [ADR 054: Semver Compatible SDK Modules](/docs/sdk/v0.50/build/architecture/adr-054-semver-compatible-modules) +* [ADR 057: App Wiring](/docs/sdk/v0.50/build/architecture/adr-057-app-wiring) +* [ADR 059: Test Scopes](/docs/sdk/v0.50/build/architecture/adr-059-test-scopes) +* [ADR 062: Collections State Layer](/docs/sdk/v0.50/build/architecture/adr-062-collections-state-layer) +* [ADR 063: Core Module API](/docs/sdk/v0.50/build/architecture/adr-063-core-module-api) +* [ADR 065: Store V2](/docs/sdk/v0.50/build/architecture/adr-065-store-v2) ### Draft -* [ADR 044: Guidelines for Updating Protobuf Definitions](/docs/sdk/v0.50/adr-044-protobuf-updates-guidelines) -* [ADR 047: Extend Upgrade Plan](/docs/sdk/v0.50/adr-047-extend-upgrade-plan) -* [ADR 053: Go Module Refactoring](/docs/sdk/v0.50/adr-053-go-module-refactoring) -* [ADR 068: Preblock](/docs/sdk/v0.50/adr-068-preblock) +* [ADR 044: Guidelines for Updating Protobuf Definitions](/docs/sdk/v0.50/build/architecture/adr-044-protobuf-updates-guidelines) +* [ADR 047: Extend Upgrade Plan](/docs/sdk/v0.50/build/architecture/adr-047-extend-upgrade-plan) +* [ADR 053: Go Module Refactoring](/docs/sdk/v0.50/build/architecture/adr-053-go-module-refactoring) +* [ADR 068: Preblock](/docs/sdk/v0.50/build/architecture/adr-068-preblock) diff --git a/docs/sdk/v0.50/build/architecture/adr-007-specialization-groups.mdx b/docs/sdk/v0.50/build/architecture/adr-007-specialization-groups.mdx index b8c4be4c..f37a4e85 100644 --- a/docs/sdk/v0.50/build/architecture/adr-007-specialization-groups.mdx +++ b/docs/sdk/v0.50/build/architecture/adr-007-specialization-groups.mdx @@ -195,4 +195,4 @@ sdk.Result ## References -* [dCERT ADR](/docs/sdk/v0.50/adr-008-dCERT-group) +* [dCERT ADR](/docs/sdk/v0.50/build/architecture/adr-008-dCERT-group) diff --git a/docs/sdk/v0.50/build/architecture/adr-008-dCERT-group.mdx b/docs/sdk/v0.50/build/architecture/adr-008-dCERT-group.mdx index 23b9b7c2..916846f3 100644 --- a/docs/sdk/v0.50/build/architecture/adr-008-dCERT-group.mdx +++ b/docs/sdk/v0.50/build/architecture/adr-008-dCERT-group.mdx @@ -35,7 +35,7 @@ vulnerability being patched on the live network. ## Decision The dCERT group is proposed to include an implementation of a `SpecializationGroup` -as defined in [ADR 007](/docs/sdk/v0.50/adr-007-specialization-groups). This will include the +as defined in [ADR 007](/docs/sdk/v0.50/build/architecture/adr-007-specialization-groups). This will include the implementation of: * continuous voting @@ -171,4 +171,4 @@ they should all be severely slashed. ## References -[Specialization Groups ADR](/docs/sdk/v0.50/adr-007-specialization-groups) +[Specialization Groups ADR](/docs/sdk/v0.50/build/architecture/adr-007-specialization-groups) diff --git a/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding.mdx b/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding.mdx index 00681e4c..372282dc 100644 --- a/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding.mdx +++ b/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding.mdx @@ -25,7 +25,7 @@ Accepted ## Context This ADR is a continuation of the motivation, design, and context established in -[ADR 019](/docs/sdk/v0.50/adr-019-protobuf-state-encoding), namely, we aim to design the +[ADR 019](/docs/sdk/v0.50/build/architecture/adr-019-protobuf-state-encoding), namely, we aim to design the Protocol Buffer migration path for the client-side of the Cosmos SDK. Specifically, the client-side migration path primarily includes tx generation and @@ -207,7 +207,7 @@ message SignDoc { In order to sign in the default mode, clients take the following steps: 1. Serialize `TxBody` and `AuthInfo` using any valid protobuf implementation. -2. Create a `SignDoc` and serialize it using [ADR 027](/docs/sdk/v0.50/adr-027-deterministic-protobuf-serialization). +2. Create a `SignDoc` and serialize it using [ADR 027](/docs/sdk/v0.50/build/architecture/adr-027-deterministic-protobuf-serialization). 3. Sign the encoded `SignDoc` bytes. 4. Build a `TxRaw` and serialize it for broadcasting. @@ -223,7 +223,7 @@ Signature verifiers do: 3. For each required signer: * Pull account number and sequence from the state. * Obtain the public key either from state or `AuthInfo`'s `signer_infos`. - * Create a `SignDoc` and serialize it using [ADR 027](/docs/sdk/v0.50/adr-027-deterministic-protobuf-serialization). + * Create a `SignDoc` and serialize it using [ADR 027](/docs/sdk/v0.50/build/architecture/adr-027-deterministic-protobuf-serialization). * Verify the signature at the same list position against the serialized `SignDoc`. #### `SIGN_MODE_LEGACY_AMINO` @@ -314,7 +314,7 @@ enforce this. Currently, the REST and CLI handlers encode and decode types and txs via Amino JSON encoding using a concrete Amino codec. Being that some of the types dealt with -in the client can be interfaces, similar to how we described in [ADR 019](/docs/sdk/v0.50/adr-019-protobuf-state-encoding), +in the client can be interfaces, similar to how we described in [ADR 019](/docs/sdk/v0.50/build/architecture/adr-019-protobuf-state-encoding), the client logic will now need to take a codec interface that knows not only how to handle all the types, but also knows how to generate transactions, signatures, and messages. diff --git a/docs/sdk/v0.50/build/architecture/adr-021-protobuf-query-encoding.mdx b/docs/sdk/v0.50/build/architecture/adr-021-protobuf-query-encoding.mdx index 0f48f65e..60ef9659 100644 --- a/docs/sdk/v0.50/build/architecture/adr-021-protobuf-query-encoding.mdx +++ b/docs/sdk/v0.50/build/architecture/adr-021-protobuf-query-encoding.mdx @@ -14,11 +14,11 @@ Accepted ## Context This ADR is a continuation of the motivation, design, and context established in -[ADR 019](/docs/sdk/v0.50/adr-019-protobuf-state-encoding) and -[ADR 020](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding), namely, we aim to design the +[ADR 019](/docs/sdk/v0.50/build/architecture/adr-019-protobuf-state-encoding) and +[ADR 020](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding), namely, we aim to design the Protocol Buffer migration path for the client-side of the Cosmos SDK. -This ADR continues from [ADD 020](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding) +This ADR continues from [ADD 020](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding) to specify the encoding of queries. ## Decision diff --git a/docs/sdk/v0.50/build/architecture/adr-027-deterministic-protobuf-serialization.mdx b/docs/sdk/v0.50/build/architecture/adr-027-deterministic-protobuf-serialization.mdx index 93f53ddd..6ea24298 100644 --- a/docs/sdk/v0.50/build/architecture/adr-027-deterministic-protobuf-serialization.mdx +++ b/docs/sdk/v0.50/build/architecture/adr-027-deterministic-protobuf-serialization.mdx @@ -30,7 +30,7 @@ other cases as well. For signature verification in Cosmos SDK, the signer and verifier need to agree on the same serialization of a `SignDoc` as defined in -[ADR-020](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding) without transmitting the +[ADR-020](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding) without transmitting the serialization. Currently, for block signatures we are using a workaround: we create a new [TxRaw](https://github.com/cosmos/cosmos-sdk/blob/9e85e81e0e8140067dd893421290c191529c148c/proto/cosmos/tx/v1beta1/tx.proto#L30) diff --git a/docs/sdk/v0.50/build/architecture/adr-030-authz-module.mdx b/docs/sdk/v0.50/build/architecture/adr-030-authz-module.mdx index 08bb3af4..af548262 100644 --- a/docs/sdk/v0.50/build/architecture/adr-030-authz-module.mdx +++ b/docs/sdk/v0.50/build/architecture/adr-030-authz-module.mdx @@ -27,7 +27,7 @@ The concrete use cases which motivated this module include: delegated stake * "sub-keys" functionality, as originally proposed in [#4480](https://github.com/cosmos/cosmos-sdk/issues/4480) which is a term used to describe the functionality provided by this module together with - the `fee_grant` module from [ADR 029](/docs/sdk/v0.50/adr-029-fee-grant-module) and the [group module](https://github.com/cosmos/cosmos-sdk/tree/main/x/group). + the `fee_grant` module from [ADR 029](/docs/sdk/v0.50/build/architecture/adr-029-fee-grant-module) and the [group module](https://github.com/cosmos/cosmos-sdk/tree/main/x/group). The "sub-keys" functionality roughly refers to the ability for one account to grant some subset of its capabilities to other accounts with possibly less robust, but easier to use security measures. For instance, a master account representing diff --git a/docs/sdk/v0.50/build/architecture/adr-031-msg-service.mdx b/docs/sdk/v0.50/build/architecture/adr-031-msg-service.mdx index 5ce8ced2..2987f754 100644 --- a/docs/sdk/v0.50/build/architecture/adr-031-msg-service.mdx +++ b/docs/sdk/v0.50/build/architecture/adr-031-msg-service.mdx @@ -111,12 +111,12 @@ One consequence of this convention is that each `Msg` type can be the request pa ### Encoding -Encoding of transactions generated with `Msg` services do not differ from current Protobuf transaction encoding as defined in [ADR-020](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding). We are encoding `Msg` types (which are exactly `Msg` service methods' request parameters) as `Any` in `Tx`s which involves packing the +Encoding of transactions generated with `Msg` services do not differ from current Protobuf transaction encoding as defined in [ADR-020](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding). We are encoding `Msg` types (which are exactly `Msg` service methods' request parameters) as `Any` in `Tx`s which involves packing the binary-encoded `Msg` with its type URL. ### Decoding -Since `Msg` types are packed into `Any`, decoding transactions messages are done by unpacking `Any`s into `Msg` types. For more information, please refer to [ADR-020](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding#transactions). +Since `Msg` types are packed into `Any`, decoding transactions messages are done by unpacking `Any`s into `Msg` types. For more information, please refer to [ADR-020](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding#transactions). ### Routing @@ -128,7 +128,7 @@ For backward compatability, the old handlers are not removed yet. If BaseApp rec ### Module Configuration -In [ADR 021](/docs/sdk/v0.50/adr-021-protobuf-query-encoding), we introduced a method `RegisterQueryService` +In [ADR 021](/docs/sdk/v0.50/build/architecture/adr-021-protobuf-query-encoding), we introduced a method `RegisterQueryService` to `AppModule` which allows for modules to register gRPC queriers. To register `Msg` services, we attempt a more extensible approach by converting `RegisterQueryService` @@ -213,5 +213,5 @@ Finally, closing a module to client API opens desirable OCAP patterns discussed * [Initial Github Issue #7122](https://github.com/cosmos/cosmos-sdk/issues/7122) * [proto 3 Language Guide: Defining Services](https://developers.google.com/protocol-buffers/docs/proto3#services) * [Initial pre-`Any` `Msg` designs](https://docs.google.com/document/d/1eEgYgvgZqLE45vETjhwIw4VOqK-5hwQtZtjVbiXnIGc) -* [ADR 020](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding) -* [ADR 021](/docs/sdk/v0.50/adr-021-protobuf-query-encoding) +* [ADR 020](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding) +* [ADR 021](/docs/sdk/v0.50/build/architecture/adr-021-protobuf-query-encoding) diff --git a/docs/sdk/v0.50/build/architecture/adr-033-protobuf-inter-module-comm.mdx b/docs/sdk/v0.50/build/architecture/adr-033-protobuf-inter-module-comm.mdx index 043b3d84..90daebd3 100644 --- a/docs/sdk/v0.50/build/architecture/adr-033-protobuf-inter-module-comm.mdx +++ b/docs/sdk/v0.50/build/architecture/adr-033-protobuf-inter-module-comm.mdx @@ -14,8 +14,8 @@ Proposed ## Abstract This ADR introduces a system for permissioned inter-module communication leveraging the protobuf `Query` and `Msg` -service definitions defined in [ADR 021](/docs/sdk/v0.50/adr-021-protobuf-query-encoding) and -[ADR 031](/docs/sdk/v0.50/adr-031-msg-service) which provides: +service definitions defined in [ADR 021](/docs/sdk/v0.50/build/architecture/adr-021-protobuf-query-encoding) and +[ADR 031](/docs/sdk/v0.50/build/architecture/adr-031-msg-service) which provides: * stable protobuf based module interfaces to potentially later replace the keeper paradigm * stronger inter-module object capabilities (OCAPs) guarantees @@ -51,7 +51,7 @@ just a simple string. So the `x/upgrade` module could mint tokens for the `x/sta ## Decision -Based on [ADR-021](/docs/sdk/v0.50/adr-021-protobuf-query-encoding) and [ADR-031](/docs/sdk/v0.50/adr-031-msg-service), we introduce the +Based on [ADR-021](/docs/sdk/v0.50/build/architecture/adr-021-protobuf-query-encoding) and [ADR-031](/docs/sdk/v0.50/build/architecture/adr-031-msg-service), we introduce the Inter-Module Communication framework for secure module authorization and OCAPs. When implemented, this could also serve as an alternative to the existing paradigm of passing keepers between modules. The approach outlined here-in is intended to form the basis of a Cosmos SDK v1.0 that provides the necessary @@ -63,8 +63,8 @@ addressed as amendments to this ADR. ### New "Keeper" Paradigm -In [ADR 021](/docs/sdk/v0.50/adr-021-protobuf-query-encoding), a mechanism for using protobuf service definitions to define queriers -was introduced and in [ADR 31](/docs/sdk/v0.50/adr-031-msg-service), a mechanism for using protobuf service to define `Msg`s was added. +In [ADR 021](/docs/sdk/v0.50/build/architecture/adr-021-protobuf-query-encoding), a mechanism for using protobuf service definitions to define queriers +was introduced and in [ADR 31](/docs/sdk/v0.50/build/architecture/adr-031-msg-service), a mechanism for using protobuf service to define `Msg`s was added. Protobuf service definitions generate two golang interfaces representing the client and server sides of a service plus some helper code. Here is a minimal example for the bank `cosmos.bank.Msg/Send` message type: @@ -80,7 +80,7 @@ type MsgServer interface { } ``` -[ADR 021](/docs/sdk/v0.50/adr-021-protobuf-query-encoding) and [ADR 31](/docs/sdk/v0.50/adr-031-msg-service) specifies how modules can implement the generated `QueryServer` +[ADR 021](/docs/sdk/v0.50/build/architecture/adr-021-protobuf-query-encoding) and [ADR 31](/docs/sdk/v0.50/build/architecture/adr-031-msg-service) specifies how modules can implement the generated `QueryServer` and `MsgServer` interfaces as replacements for the legacy queriers and `Msg` handlers respectively. In this ADR we explain how modules can make queries and send `Msg`s to other modules using the generated `QueryClient` @@ -172,7 +172,7 @@ denom prefix being restricted to certain modules (as discussed in ### `ModuleKey`s and `ModuleID`s A `ModuleKey` can be thought of as a "private key" for a module account and a `ModuleID` can be thought of as the -corresponding "public key". From the [ADR 028](/docs/sdk/v0.50/adr-028-public-key-addresses), modules can have both a root module account and any number of sub-accounts +corresponding "public key". From the [ADR 028](/docs/sdk/v0.50/build/architecture/adr-028-public-key-addresses), modules can have both a root module account and any number of sub-accounts or derived accounts that can be used for different pools (ex. staking pools) or managed accounts (ex. group accounts). We can also think of module sub-accounts as similar to derived keys - there is a root key and then some derivation path. `ModuleID` is a simple struct which contains the module name and optional "derivation" path, @@ -287,7 +287,7 @@ return f(ctx, args, reply) ### `AppModule` Wiring and Requirements -In [ADR 031](/docs/sdk/v0.50/adr-031-msg-service), the `AppModule.RegisterService(Configurator)` method was introduced. To support +In [ADR 031](/docs/sdk/v0.50/build/architecture/adr-031-msg-service), the `AppModule.RegisterService(Configurator)` method was introduced. To support inter-module communication, we extend the `Configurator` interface to pass in the `ModuleKey` and to allow modules to specify their dependencies on other modules using `RequireServer()`: @@ -448,8 +448,8 @@ replacing `Keeper` interfaces altogether. ## References -* [ADR 021](/docs/sdk/v0.50/adr-021-protobuf-query-encoding) -* [ADR 031](/docs/sdk/v0.50/adr-031-msg-service) -* [ADR 028](/docs/sdk/v0.50/adr-028-public-key-addresses) +* [ADR 021](/docs/sdk/v0.50/build/architecture/adr-021-protobuf-query-encoding) +* [ADR 031](/docs/sdk/v0.50/build/architecture/adr-031-msg-service) +* [ADR 028](/docs/sdk/v0.50/build/architecture/adr-028-public-key-addresses) * [ADR 030 draft](https://github.com/cosmos/cosmos-sdk/pull/7105) * [Object-Capability Model](https://docs.network.com/main/core/ocap) diff --git a/docs/sdk/v0.50/build/architecture/adr-042-group-module.mdx b/docs/sdk/v0.50/build/architecture/adr-042-group-module.mdx index 4841141e..4e081ddd 100644 --- a/docs/sdk/v0.50/build/architecture/adr-042-group-module.mdx +++ b/docs/sdk/v0.50/build/architecture/adr-042-group-module.mdx @@ -25,7 +25,7 @@ The legacy amino multi-signature mechanism of the Cosmos SDK has certain limitat * It requires `legacy_amino` sign mode ([#8141](https://github.com/cosmos/cosmos-sdk/issues/8141)). While the group module is not meant to be a total replacement for the current multi-signature accounts, it provides a solution to the limitations described above, with a more flexible key management system where keys can be added, updated or removed, as well as configurable thresholds. -It's meant to be used with other access control modules such as [`x/feegrant`](/docs/sdk/v0.50/adr-029-fee-grant-module) ans [`x/authz`](/docs/sdk/v0.50/build/architecture/adr-030-authz-module) to simplify key management for individuals and organizations. +It's meant to be used with other access control modules such as [`x/feegrant`](/docs/sdk/v0.50/build/architecture/adr-029-fee-grant-module) ans [`x/authz`](/docs/sdk/v0.50/build/architecture/adr-030-authz-module) to simplify key management for individuals and organizations. The proof of concept of the group module can be found in [Link](https://github.com/regen-network/regen-ledger/tree/master/proto/regen/group/v1alpha1) and [Link](https://github.com/regen-network/regen-ledger/tree/master/x/group). diff --git a/docs/sdk/v0.50/build/architecture/adr-044-protobuf-updates-guidelines.mdx b/docs/sdk/v0.50/build/architecture/adr-044-protobuf-updates-guidelines.mdx index 6efea04d..2fe59048 100644 --- a/docs/sdk/v0.50/build/architecture/adr-044-protobuf-updates-guidelines.mdx +++ b/docs/sdk/v0.50/build/architecture/adr-044-protobuf-updates-guidelines.mdx @@ -83,7 +83,7 @@ Protobuf supports the [`deprecated` field option](https://developers.google.com/ As an example, the Cosmos SDK v0.42 to v0.43 update contained two Protobuf-breaking changes, listed below. Instead of bumping the package versions from `v1beta1` to `v1`, the SDK team decided to follow this guideline, by reverting the breaking changes, marking those changes as deprecated, and modifying the node implementation when processing messages with deprecated fields. More specifically: * The Cosmos SDK recently removed support for [time-based software upgrades](https://github.com/cosmos/cosmos-sdk/pull/8849). As such, the `time` field has been marked as deprecated in `cosmos.upgrade.v1beta1.Plan`. Moreover, the node will reject any proposal containing an upgrade Plan whose `time` field is non-empty. -* The Cosmos SDK now supports [governance split votes](/docs/sdk/v0.50/adr-037-gov-split-vote). When querying for votes, the returned `cosmos.gov.v1beta1.Vote` message has its `option` field (used for 1 vote option) deprecated in favor of its `options` field (allowing multiple vote options). Whenever possible, the SDK still populates the deprecated `option` field, that is, if and only if the `len(options) == 1` and `options[0].Weight == 1.0`. +* The Cosmos SDK now supports [governance split votes](/docs/sdk/v0.50/build/architecture/adr-037-gov-split-vote). When querying for votes, the returned `cosmos.gov.v1beta1.Vote` message has its `option` field (used for 1 vote option) deprecated in favor of its `options` field (allowing multiple vote options). Whenever possible, the SDK still populates the deprecated `option` field, that is, if and only if the `len(options) == 1` and `options[0].Weight == 1.0`. #### 3. Fields MUST NOT be renamed diff --git a/docs/sdk/v0.50/build/architecture/adr-045-check-delivertx-middlewares.mdx b/docs/sdk/v0.50/build/architecture/adr-045-check-delivertx-middlewares.mdx index cf66e380..fb65919a 100644 --- a/docs/sdk/v0.50/build/architecture/adr-045-check-delivertx-middlewares.mdx +++ b/docs/sdk/v0.50/build/architecture/adr-045-check-delivertx-middlewares.mdx @@ -256,12 +256,12 @@ While the app developer can define and compose the middlewares of their choice, | TxDecoderMiddleware | This middleware takes in transaction raw bytes, and decodes them into a `sdk.Tx`. It replaces the `baseapp.txDecoder` field, so that BaseApp stays as thin as possible. Since most middlewares read the contents of the `sdk.Tx`, the TxDecoderMiddleware should be run first in the middleware stack. | | `{Antehandlers}` | Each antehandler is converted to its own middleware. These middlewares perform signature verification, fee deductions and other validations on the incoming transaction. | | IndexEventsTxMiddleware | This is a simple middleware that chooses which events to index in Tendermint. Replaces `baseapp.indexEvents` (which unfortunately still exists in baseapp too, because it's used to index Begin/EndBlock events) | -| RecoveryTxMiddleware | This index recovers from panics. It replaces baseapp.runTx's panic recovery described in [ADR-022](/docs/sdk/v0.50/adr-022-custom-panic-handling). | +| RecoveryTxMiddleware | This index recovers from panics. It replaces baseapp.runTx's panic recovery described in [ADR-022](/docs/sdk/v0.50/build/architecture/adr-022-custom-panic-handling). | | GasTxMiddleware | This replaces the [`Setup`](https://github.com/cosmos/cosmos-sdk/blob/v0.43.0/x/auth/ante/setup.go) Antehandler. It sets a GasMeter on sdk.Context. Note that before, GasMeter was set on sdk.Context inside the antehandlers, and there was some mess around the fact that antehandlers had their own panic recovery system so that the GasMeter could be read by baseapp's recovery system. Now, this mess is all removed: one middleware sets GasMeter, another one handles recovery. | ### Similarities and Differences between Antehandlers and Middlewares -The middleware-based design builds upon the existing antehandlers design described in [ADR-010](/docs/sdk/v0.50/adr-010-modular-antehandler). Even though the final decision of ADR-010 was to go with the "Simple Decorators" approach, the middleware design is actually very similar to the other [Decorator Pattern](/docs/sdk/v0.50/adr-010-modular-antehandler#decorator-pattern) proposal, also used in [weave](https://github.com/iov-one/weave). +The middleware-based design builds upon the existing antehandlers design described in [ADR-010](/docs/sdk/v0.50/build/architecture/adr-010-modular-antehandler). Even though the final decision of ADR-010 was to go with the "Simple Decorators" approach, the middleware design is actually very similar to the other [Decorator Pattern](/docs/sdk/v0.50/build/architecture/adr-010-modular-antehandler#decorator-pattern) proposal, also used in [weave](https://github.com/iov-one/weave). #### Similarities with Antehandlers diff --git a/docs/sdk/v0.50/build/architecture/adr-050-sign-mode-textual-annex1.mdx b/docs/sdk/v0.50/build/architecture/adr-050-sign-mode-textual-annex1.mdx index e41c0c42..489ecc13 100644 --- a/docs/sdk/v0.50/build/architecture/adr-050-sign-mode-textual-annex1.mdx +++ b/docs/sdk/v0.50/build/architecture/adr-050-sign-mode-textual-annex1.mdx @@ -65,7 +65,7 @@ Value Renderers describe how values of different Protobuf types should be encode ### `repeated` -* Applies to all `repeated` fields, except `cosmos.tx.v1beta1.TxBody#Messages`, which has a particular encoding (see [ADR-050](/docs/sdk/v0.50/adr-050-sign-mode-textual)). +* Applies to all `repeated` fields, except `cosmos.tx.v1beta1.TxBody#Messages`, which has a particular encoding (see [ADR-050](/docs/sdk/v0.50/build/architecture/adr-050-sign-mode-textual)). * A repeated type has the following template: ``` @@ -282,7 +282,7 @@ The number 35 was chosen because it is the longest length where the hashed-and-p * byte arrays starting from length 36 will be be hashed to 32 bytes, which is 64 hex characters plus 15 spaces, and with the `SHA-256=` prefix, it takes 87 characters. Also, secp256k1 public keys have length 33, so their Textual representation is not their hashed value, which we would like to avoid. -Note: Data longer than 35 bytes are not rendered in a way that can be inverted. See ADR-050's [section about invertability](/docs/sdk/v0.50/adr-050-sign-mode-textual#invertible-rendering) for a discussion. +Note: Data longer than 35 bytes are not rendered in a way that can be inverted. See ADR-050's [section about invertability](/docs/sdk/v0.50/build/architecture/adr-050-sign-mode-textual#invertible-rendering) for a discussion. #### Examples diff --git a/docs/sdk/v0.50/build/architecture/adr-050-sign-mode-textual.mdx b/docs/sdk/v0.50/build/architecture/adr-050-sign-mode-textual.mdx index e452978c..86b60a01 100644 --- a/docs/sdk/v0.50/build/architecture/adr-050-sign-mode-textual.mdx +++ b/docs/sdk/v0.50/build/architecture/adr-050-sign-mode-textual.mdx @@ -30,7 +30,7 @@ This ADR specifies SIGN\_MODE\_TEXTUAL, a new string-based sign mode that is tar ## Context -Protobuf-based SIGN\_MODE\_DIRECT was introduced in [ADR-020](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding) and is intended to replace SIGN\_MODE\_LEGACY\_AMINO\_JSON in most situations, such as mobile wallets and CLI keyrings. However, the [Ledger](https://www.ledger.com/) hardware wallet is still using SIGN\_MODE\_LEGACY\_AMINO\_JSON for displaying the sign bytes to the user. Hardware wallets cannot transition to SIGN\_MODE\_DIRECT as: +Protobuf-based SIGN\_MODE\_DIRECT was introduced in [ADR-020](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding) and is intended to replace SIGN\_MODE\_LEGACY\_AMINO\_JSON in most situations, such as mobile wallets and CLI keyrings. However, the [Ledger](https://www.ledger.com/) hardware wallet is still using SIGN\_MODE\_LEGACY\_AMINO\_JSON for displaying the sign bytes to the user. Hardware wallets cannot transition to SIGN\_MODE\_DIRECT as: * SIGN\_MODE\_DIRECT is binary-based and thus not suitable for display to end-users. Technically, hardware wallets could simply display the sign bytes to the user. But this would be considered as blind signing, and is a security concern. * hardware cannot decode the protobuf sign bytes due to memory constraints, as the Protobuf definitions would need to be embedded on the hardware device. @@ -56,7 +56,7 @@ or to introduce or conclude a larger grouping. The text can contain the full range of Unicode code points, including control characters and nul. The device is responsible for deciding how to display characters it cannot render natively. -See [annex 2](/docs/sdk/v0.50/adr-050-sign-mode-textual-annex2) for guidance. +See [annex 2](/docs/sdk/v0.50/build/architecture/adr-050-sign-mode-textual-annex2) for guidance. Screens have a non-negative indentation level to signal composite or nested structures. Indentation level zero is the top level. @@ -301,7 +301,7 @@ where: This is to prevent transaction hash malleability. The point #1 about invertiblity assures that transaction `body` and `auth_info` values are not malleable, but the transaction hash still might be malleable with point #1 only, because the SIGN\_MODE\_TEXTUAL strings don't follow the byte ordering defined in `body_bytes` and `auth_info_bytes`. Without this hash, a malicious validator or exchange could intercept a transaction, modify its transaction hash *after* the user signed it using SIGN\_MODE\_TEXTUAL (by tweaking the byte ordering inside `body_bytes` or `auth_info_bytes`), and then submit it to Tendermint. -By including this hash in the SIGN\_MODE\_TEXTUAL signing payload, we keep the same level of guarantees as [SIGN\_MODE\_DIRECT](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding). +By including this hash in the SIGN\_MODE\_TEXTUAL signing payload, we keep the same level of guarantees as [SIGN\_MODE\_DIRECT](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding). These bytes are only shown in expert mode, hence the leading `*`. @@ -322,7 +322,7 @@ The current spec version is defined in the "Status" section, on the top of this ## Additional Formatting by the Hardware Device -See [annex 2](/docs/sdk/v0.50/adr-050-sign-mode-textual-annex2). +See [annex 2](/docs/sdk/v0.50/build/architecture/adr-050-sign-mode-textual-annex2). ## Examples @@ -357,14 +357,14 @@ SIGN\_MODE\_TEXTUAL is purely additive, and doesn't break any backwards compatib ## Further Discussions -* Some details on value renderers need to be polished, see [Annex 1](/docs/sdk/v0.50/adr-050-sign-mode-textual-annex1). +* Some details on value renderers need to be polished, see [Annex 1](/docs/sdk/v0.50/build/architecture/adr-050-sign-mode-textual-annex1). * Are ledger apps able to support both SIGN\_MODE\_LEGACY\_AMINO\_JSON and SIGN\_MODE\_TEXTUAL at the same time? * Open question: should we add a Protobuf field option to allow app developers to overwrite the textual representation of certain Protobuf fields and message? This would be similar to Ethereum's [EIP4430](https://github.com/ethereum/EIPs/pull/4430), where the contract developer decides on the textual representation. * Internationalization. ## References -* [Annex 1](/docs/sdk/v0.50/adr-050-sign-mode-textual-annex1) +* [Annex 1](/docs/sdk/v0.50/build/architecture/adr-050-sign-mode-textual-annex1) * Initial discussion: [Link](https://github.com/cosmos/cosmos-sdk/issues/6513) diff --git a/docs/sdk/v0.50/build/architecture/adr-054-semver-compatible-modules.mdx b/docs/sdk/v0.50/build/architecture/adr-054-semver-compatible-modules.mdx index 5c7fb7c4..c998f963 100644 --- a/docs/sdk/v0.50/build/architecture/adr-054-semver-compatible-modules.mdx +++ b/docs/sdk/v0.50/build/architecture/adr-054-semver-compatible-modules.mdx @@ -40,7 +40,7 @@ In order to achieve this, we need to solve the following problems: many modules in the SDK independently 3. pernicious minor version incompatibilities introduced through correctly [evolving protobuf schemas](https://developers.google.com/protocol-buffers/docs/proto3#updating) - without correct [unknown field filtering](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding#unknown-field-filtering) + without correct [unknown field filtering](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding#unknown-field-filtering) Note that all the following discussion assumes that the proto file versioning and state machine versioning of a module are distinct in that: @@ -150,7 +150,7 @@ with this update and use that for `foo/v2`. But this change is state machine breaking for `v1`. It requires changing the `ValidateBasic` method to reject the case where `amount` is zero, and it adds the `condition` field which should be rejected based -on [ADR 020 unknown field filtering](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding#unknown-field-filtering). +on [ADR 020 unknown field filtering](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding#unknown-field-filtering). So adding these changes as a patch on `v1` is actually incorrect based on semantic versioning. Chains that want to stay on `v1` of `foo` should not be importing these changes because they are incorrect for `v1.` @@ -179,9 +179,9 @@ on `v1` or `v2` and dynamically, it could choose to only use `condition` when `foo/v2` is available. Even if `bar/v2` were able to perform this check, however, how do we know that it is always performing the check properly. Without some sort of -framework-level [unknown field filtering](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding#unknown-field-filtering), +framework-level [unknown field filtering](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding#unknown-field-filtering), it is hard to know whether these pernicious hard to detect bugs are getting into -our app and a client-server layer such as [ADR 033: Inter-Module Communication](/docs/sdk/v0.50/adr-033-protobuf-inter-module-comm) +our app and a client-server layer such as [ADR 033: Inter-Module Communication](/docs/sdk/v0.50/build/architecture/adr-033-protobuf-inter-module-comm) may be needed to do this. ## Solutions @@ -274,9 +274,9 @@ of care to avoid these sorts of issues. This approach in and of itself does little to address any potential minor version incompatibilities and the -requisite [unknown field filtering](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding#unknown-field-filtering). +requisite [unknown field filtering](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding#unknown-field-filtering). Likely some sort of client-server routing layer which does this check such as -[ADR 033: Inter-Module communication](/docs/sdk/v0.50/adr-033-protobuf-inter-module-comm) +[ADR 033: Inter-Module communication](/docs/sdk/v0.50/build/architecture/adr-033-protobuf-inter-module-comm) is required to make sure that this is done properly. We could then allow modules to perform a runtime check given a `MsgClient`, ex: @@ -307,7 +307,7 @@ result in an undesirable performance hit depending on how complex this logic is. An alternate approach to solving the versioning problem is to change how protobuf code is generated and move modules mostly or completely in the direction of inter-module communication as described -in [ADR 033](/docs/sdk/v0.50/adr-033-protobuf-inter-module-comm). +in [ADR 033](/docs/sdk/v0.50/build/architecture/adr-033-protobuf-inter-module-comm). In this paradigm, a module could generate all the types it needs internally - including the API types of other modules - and talk to other modules via a client-server boundary. For instance, if `bar` needs to talk to `foo`, it could generate its own version of `MsgDoSomething` as `bar/internal/foo/v1.MsgDoSomething` and just pass this to the @@ -326,7 +326,7 @@ to `foo/internal.MsgDoSomething` would be marshaling and unmarshaling in the ADR we needed to expose protobuf types in `Keeper` interfaces because the whole point is to try to keep these types `internal/` so that we don't end up with all the import version incompatibilities we've described above. However, because of the issue with minor version incompatibilities and the need -for [unknown field filtering](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding#unknown-field-filtering), +for [unknown field filtering](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding#unknown-field-filtering), sticking with the `Keeper` paradigm instead of ADR 033 may be unviable to begin with. A more performant solution (that could maybe be adapted to work with `Keeper` interfaces) would be to only expose @@ -412,7 +412,7 @@ and would also need to use special tags and replace directives to make sure that versions. Note, however, that all of these ad-hoc approaches, would be vulnerable to the minor version compatibility issues -described above unless [unknown field filtering](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding#unknown-field-filtering) +described above unless [unknown field filtering](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding#unknown-field-filtering) is properly addressed. ### Approach D) Avoid protobuf generated code in public APIs @@ -462,7 +462,7 @@ Other downsides to this approach are: The latest **DRAFT** proposal is: -1. we are alignment on adopting [ADR 033](/docs/sdk/v0.50/adr-033-protobuf-inter-module-comm) not just as an addition to the +1. we are alignment on adopting [ADR 033](/docs/sdk/v0.50/build/architecture/adr-033-protobuf-inter-module-comm) not just as an addition to the framework, but as a core replacement to the keeper paradigm entirely. 2. the ADR 033 inter-module router will accommodate any variation of approach (A) or (B) given the following rules: a. if the client type is the same as the server type then pass it directly through, @@ -476,7 +476,7 @@ languages, possibly executed within a WASM VM. ### Minor API Revisions To declare minor API revisions of proto files, we propose the following guidelines (which were already documented -in [cosmos.app.v1alpha module options](/docs/sdk/v0.50/proto/cosmos/app/v1alpha1/module.proto)): +in [cosmos.app.v1alpha module options](/https://github.com/cosmos/cosmos-sdk/blob/v0.50/proto/cosmos/app/v1alpha1/module.proto)): * proto packages which are revised from their initial version (considered revision `0`) should include a `package` * comment in some .proto file containing the test `Revision N` at the start of a comment line where `N` is the current @@ -525,7 +525,7 @@ uint64 ### Unknown Field Filtering -To correctly perform [unknown field filtering](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding#unknown-field-filtering), +To correctly perform [unknown field filtering](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding#unknown-field-filtering), the inter-module router can do one of the following: * use the `protoreflect` API for messages which support that @@ -588,7 +588,7 @@ We propose defining these dependencies in the proto options of the module config We will also need to define how interface methods are defined on types that are serialized as `google.protobuf.Any`'s. In light of the desire to support modules in other languages, we may want to think of solutions that will accommodate -other languages such as plugins described briefly in [ADR 033](/docs/sdk/v0.50/adr-033-protobuf-inter-module-comm#internal-methods). +other languages such as plugins described briefly in [ADR 033](/docs/sdk/v0.50/build/architecture/adr-033-protobuf-inter-module-comm#internal-methods). ### Testing @@ -795,5 +795,5 @@ Key outstanding discussions if we do adopt that direction are: * [Link](https://github.com/cosmos/cosmos-sdk/discussions/10368) * [Link](https://github.com/cosmos/cosmos-sdk/pull/11340) * [Link](https://github.com/cosmos/cosmos-sdk/issues/11899) -* [ADR 020](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding) -* [ADR 033](/docs/sdk/v0.50/adr-033-protobuf-inter-module-comm) +* [ADR 020](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding) +* [ADR 033](/docs/sdk/v0.50/build/architecture/adr-033-protobuf-inter-module-comm) diff --git a/docs/sdk/v0.50/build/architecture/adr-057-app-wiring.mdx b/docs/sdk/v0.50/build/architecture/adr-057-app-wiring.mdx index ed404c02..fd160f49 100644 --- a/docs/sdk/v0.50/build/architecture/adr-057-app-wiring.mdx +++ b/docs/sdk/v0.50/build/architecture/adr-057-app-wiring.mdx @@ -25,13 +25,13 @@ which contains almost 100 lines of imports and is otherwise over 600 lines of mo generally copied to each new project. (Not to mention the additional boilerplate which gets copied in `simapp/simd`.) The large amount of boilerplate needed to bootstrap an app has made it hard to release independently versioned go -modules for Cosmos SDK modules as described in [ADR 053: Go Module Refactoring](/docs/sdk/v0.50/adr-053-go-module-refactoring). +modules for Cosmos SDK modules as described in [ADR 053: Go Module Refactoring](/docs/sdk/v0.50/build/architecture/adr-053-go-module-refactoring). In addition to being very verbose and repetitive, `app.go` also exposes a large surface area for breaking changes as most modules instantiate themselves with positional parameters which forces breaking changes anytime a new parameter (even an optional one) is needed. -Several attempts were made to improve the current situation including [ADR 033: Internal-Module Communication](/docs/sdk/v0.50/adr-033-protobuf-inter-module-comm) +Several attempts were made to improve the current situation including [ADR 033: Internal-Module Communication](/docs/sdk/v0.50/build/architecture/adr-033-protobuf-inter-module-comm) and [a proof-of-concept of a new SDK](https://github.com/allinbits/cosmos-sdk-poc). The discussions around these designs led to the current solution described here. @@ -229,7 +229,7 @@ In cases where required modules are not loaded at runtime, it may be possible to through a global Cosmos SDK module registry. The `*appmodule.Handler` type referenced above is a replacement for the legacy `AppModule` framework, and -described in [ADR 063: Core Module API](/docs/sdk/v0.50/adr-063-core-module-api). +described in [ADR 063: Core Module API](/docs/sdk/v0.50/build/architecture/adr-063-core-module-api). ### New `app.go` @@ -260,7 +260,7 @@ func main() { So far we have described a system which is largely agnostic to the specifics of the SDK such as store keys, `AppModule`, `BaseApp`, etc. Improvements to these parts of the framework that integrate with the general app wiring framework -defined here are described in [ADR 063: Core Module API](/docs/sdk/v0.50/adr-063-core-module-api). +defined here are described in [ADR 063: Core Module API](/docs/sdk/v0.50/build/architecture/adr-063-core-module-api). ### Registration of Inter-Module Hooks @@ -341,7 +341,7 @@ versioned module config protobuf type, and major versioning bumps should occur w are made to a module. NOTE: SDK modules that are standalone go modules *should not* adopt semantic versioning until the concerns described in -[ADR 054: Module Semantic Versioning](/docs/sdk/v0.50/adr-054-semver-compatible-modules) are +[ADR 054: Module Semantic Versioning](/docs/sdk/v0.50/build/architecture/adr-054-semver-compatible-modules) are addressed. The short-term solution for this issue was left somewhat unresolved. However, the easiest tactic is likely to use a standalone API go module and follow the guidelines described in this comment: [Link](https://github.com/cosmos/cosmos-sdk/pull/11802#issuecomment-1406815181). For the time-being, it is recommended that Cosmos SDK modules continue to follow tried and true [0-based versioning](https://0ver.org) until an officially @@ -386,4 +386,4 @@ light of code generation. It may be better to do this type registration with a D * [Link](https://github.com/google/wire) * [Link](https://pkg.go.dev/github.com/cosmos/cosmos-sdk/container) * [Link](https://github.com/cosmos/cosmos-sdk/pull/11802) -* [ADR 063: Core Module API](/docs/sdk/v0.50/adr-063-core-module-api) +* [ADR 063: Core Module API](/docs/sdk/v0.50/build/architecture/adr-063-core-module-api) diff --git a/docs/sdk/v0.50/build/architecture/adr-063-core-module-api.mdx b/docs/sdk/v0.50/build/architecture/adr-063-core-module-api.mdx index 97455a55..9cb14b2a 100644 --- a/docs/sdk/v0.50/build/architecture/adr-063-core-module-api.mdx +++ b/docs/sdk/v0.50/build/architecture/adr-063-core-module-api.mdx @@ -23,7 +23,7 @@ A new core API is proposed as a way to develop cosmos-sdk applications that will * more stable than the current framework * enable deterministic events and queries, * support event listeners -* [ADR 033: Protobuf-based Inter-Module Communication](/docs/sdk/v0.50/adr-033-protobuf-inter-module-comm) clients. +* [ADR 033: Protobuf-based Inter-Module Communication](/docs/sdk/v0.50/build/architecture/adr-033-protobuf-inter-module-comm) clients. ## Context @@ -93,7 +93,7 @@ slower than more fast moving projects. ### Core Services The following "core services" are defined by the core API. All valid runtime module implementations should provide -implementations of these services to modules via both [dependency injection](/docs/sdk/v0.50/adr-057-app-wiring) and +implementations of these services to modules via both [dependency injection](/docs/sdk/v0.50/build/architecture/adr-057-app-wiring) and manual wiring. The individual services described below are all bundled in a convenient `appmodule.Service` "bundle service" so that for simplicity modules can declare a dependency on a single service. @@ -274,7 +274,7 @@ type GenesisTarget = func(field string) (io.WriteCloser, error) All genesis objects for a given module are expected to conform to the semantics of a JSON object. Each field in the JSON object should be read and written separately to support streaming genesis. -The [ORM](/docs/sdk/v0.50/adr-055-orm) and [collections](/docs/sdk/v0.50/adr-062-collections-state-layer) both support +The [ORM](/docs/sdk/v0.50/build/architecture/adr-055-orm) and [collections](/docs/sdk/v0.50/build/architecture/adr-062-collections-state-layer) both support streaming genesis and modules using these frameworks generally do not need to write any manual genesis code. @@ -423,7 +423,7 @@ Additional `AppModule` extension interfaces either inside or outside of core wil these concerns. In the case of gogo proto and amino interfaces, the registration of these generally should happen as early -as possible during initialization and in [ADR 057: App Wiring](/docs/sdk/v0.50/adr-057-app-wiring-1), protobuf type registration\ +as possible during initialization and in [ADR 057: App Wiring](/docs/sdk/v0.50/build/architecture/adr-057-app-wiring-1), protobuf type registration\ happens before dependency injection (although this could alternatively be done dedicated DI providers). gRPC gateway registration should probably be handled by the runtime module, but the core API shouldn't depend on gRPC @@ -460,11 +460,11 @@ Crisis module invariants and simulations are subject to potential redesign and s defined in the crisis and simulation modules respectively. Extension interface for CLI commands will be provided via the `cosmossdk.io/client/v2` module and its -[autocli](/docs/sdk/v0.50/adr-058-auto-generated-cli) framework. +[autocli](/docs/sdk/v0.50/build/architecture/adr-058-auto-generated-cli) framework. #### Example Usage -Here is an example of setting up a hypothetical `foo` v2 module which uses the [ORM](/docs/sdk/v0.50/adr-055-orm) for its state +Here is an example of setting up a hypothetical `foo` v2 module which uses the [ORM](/docs/sdk/v0.50/build/architecture/adr-055-orm) for its state management and genesis. ```go expandable @@ -524,7 +524,7 @@ These runtime modules should attempt to be semantically versioned even if the un because a runtime module is also a first class Cosmos SDK module, it should have a protobuf module config type. A new semantically versioned module config type should be created for each of these runtime module such that there is a 1:1 correspondence between the go module and module config type. This is the same practice should be followed for every -semantically versioned Cosmos SDK module as described in [ADR 057: App Wiring](/docs/sdk/v0.50/adr-057-app-wiring). +semantically versioned Cosmos SDK module as described in [ADR 057: App Wiring](/docs/sdk/v0.50/build/architecture/adr-057-app-wiring). Currently, `github.com/cosmos/cosmos-sdk/runtime` uses the protobuf config type `cosmos.app.runtime.v1alpha1.Module`. When we have a standalone v1 comet runtime, we should use a dedicated protobuf module config type such as @@ -608,8 +608,8 @@ as by providing service implementations by wrapping `sdk.Context`. ## References -* [ADR 033: Protobuf-based Inter-Module Communication](/docs/sdk/v0.50/adr-033-protobuf-inter-module-comm) -* [ADR 057: App Wiring](/docs/sdk/v0.50/adr-057-app-wiring-1) -* [ADR 055: ORM](/docs/sdk/v0.50/adr-055-orm) -* [ADR 028: Public Key Addresses](/docs/sdk/v0.50/adr-028-public-key-addresses) +* [ADR 033: Protobuf-based Inter-Module Communication](/docs/sdk/v0.50/build/architecture/adr-033-protobuf-inter-module-comm) +* [ADR 057: App Wiring](/docs/sdk/v0.50/build/architecture/adr-057-app-wiring-1) +* [ADR 055: ORM](/docs/sdk/v0.50/build/architecture/adr-055-orm) +* [ADR 028: Public Key Addresses](/docs/sdk/v0.50/build/architecture/adr-028-public-key-addresses) * [Keeping Your Modules Compatible](https://go.dev/blog/module-compatibility) diff --git a/docs/sdk/v0.50/build/architecture/adr-065-store-v2.mdx b/docs/sdk/v0.50/build/architecture/adr-065-store-v2.mdx index c97f2b48..431a1843 100644 --- a/docs/sdk/v0.50/build/architecture/adr-065-store-v2.mdx +++ b/docs/sdk/v0.50/build/architecture/adr-065-store-v2.mdx @@ -67,9 +67,9 @@ See the [Storage Discussion](https://github.com/cosmos/cosmos-sdk/discussions/13 ## Alternatives -There was a previous attempt to refactor the storage layer described in [ADR-040](/docs/sdk/v0.50/adr-040-storage-and-smt-state-commitments). +There was a previous attempt to refactor the storage layer described in [ADR-040](/docs/sdk/v0.50/build/architecture/adr-040-storage-and-smt-state-commitments). However, this approach mainly stems on the short comings of IAVL and various performance -issues around it. While there was a (partial) implementation of [ADR-040](/docs/sdk/v0.50/adr-040-storage-and-smt-state-commitments), +issues around it. While there was a (partial) implementation of [ADR-040](/docs/sdk/v0.50/build/architecture/adr-040-storage-and-smt-state-commitments), it was never adopted for a variety of reasons, such as the reliance on using an SMT, which was more in a research phase, and some design choices that couldn't be fully agreed upon, such as the snap-shotting mechanism that would result in @@ -77,7 +77,7 @@ massive state bloat. ## Decision -We propose to build upon some of the great ideas introduced in [ADR-040](/docs/sdk/v0.50/adr-040-storage-and-smt-state-commitments), +We propose to build upon some of the great ideas introduced in [ADR-040](/docs/sdk/v0.50/build/architecture/adr-040-storage-and-smt-state-commitments), while being a bit more flexible with the underlying implementations and overall less intrusive. Specifically, we propose to: diff --git a/docs/sdk/v0.50/build/building-modules/structure.mdx b/docs/sdk/v0.50/build/building-modules/structure.mdx index 3d0e6328..68b31b0a 100644 --- a/docs/sdk/v0.50/build/building-modules/structure.mdx +++ b/docs/sdk/v0.50/build/building-modules/structure.mdx @@ -81,7 +81,7 @@ x/{module_name} * `abci.go`: The module's `BeginBlocker` and `EndBlocker` implementations (this file is only required if `BeginBlocker` and/or `EndBlocker` need to be defined). * `autocli.go`: The module [autocli](https://docs.cosmos.network/main/core/autocli) options. * `simulation/`: The module's [simulation](/docs/sdk/v0.50/build/building-modules/simulator) package defines functions used by the blockchain simulator application (`simapp`). -* `REAMDE.md`: The module's specification documents outlining important concepts, state storage structure, and message and event type definitions. Learn more how to write module specs in the [spec guidelines](/docs/sdk/v0.50/spec/SPEC_MODULE). +* `REAMDE.md`: The module's specification documents outlining important concepts, state storage structure, and message and event type definitions. Learn more how to write module specs in the [spec guidelines](/docs/sdk/v0.50/build/spec/SPEC_MODULE). * The root directory includes type definitions for messages, events, and genesis state, including the type definitions generated by Protocol Buffers. * `codec.go`: The module's registry methods for interface types. * `errors.go`: The module's sentinel errors. diff --git a/docs/sdk/v0.50/build/spec/README.mdx b/docs/sdk/v0.50/build/spec/README.mdx index a649334c..7e2a6de9 100644 --- a/docs/sdk/v0.50/build/spec/README.mdx +++ b/docs/sdk/v0.50/build/spec/README.mdx @@ -14,7 +14,7 @@ block. ## Cosmos SDK specifications * [Store](/docs/sdk/v0.50/learn/advanced/store) - The core Merkle store that holds the state. -* [Bech32](/docs/sdk/v0.50/addresses/bech32) - Address format for Cosmos SDK applications. +* [Bech32](/docs/sdk/v0.50/build/spec/addresses/bech32) - Address format for Cosmos SDK applications. ## Modules specifications diff --git a/docs/sdk/v0.50/build/spec/_ics/README.mdx b/docs/sdk/v0.50/build/spec/_ics/README.mdx index a34f2312..cde957c4 100644 --- a/docs/sdk/v0.50/build/spec/_ics/README.mdx +++ b/docs/sdk/v0.50/build/spec/_ics/README.mdx @@ -3,4 +3,4 @@ title: Cosmos ICS description: ICS030 - Signed Messages --- -* [ICS030 - Signed Messages](/docs/sdk/v0.50/ics-030-signed-messages) +* [ICS030 - Signed Messages](/docs/sdk/v0.50/build/spec/_ics/ics-030-signed-messages) diff --git a/docs/sdk/v0.50/learn/beginner/tx-lifecycle.mdx b/docs/sdk/v0.50/learn/beginner/tx-lifecycle.mdx index f6833205..b0032d75 100644 --- a/docs/sdk/v0.50/learn/beginner/tx-lifecycle.mdx +++ b/docs/sdk/v0.50/learn/beginner/tx-lifecycle.mdx @@ -10,7 +10,7 @@ This document describes the lifecycle of a transaction from creation to committe **Pre-requisite Readings** -* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.53/learn/beginner/app-anatomy) +* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.50/learn/beginner/app-anatomy) ## Creation diff --git a/docs/sdk/v0.50/learn/intro/sdk-design.mdx b/docs/sdk/v0.50/learn/intro/sdk-design.mdx index 4d19423a..e6817dae 100644 --- a/docs/sdk/v0.50/learn/intro/sdk-design.mdx +++ b/docs/sdk/v0.50/learn/intro/sdk-design.mdx @@ -2,7 +2,7 @@ title: Main Components of the Cosmos SDK --- -The Cosmos SDK is a framework that facilitates the development of secure state-machines on top of CometBFT. At its core, the Cosmos SDK is a boilerplate implementation of the [ABCI](/docs/sdk/v0.50/sdk-app-architecture#abci) in Golang. It comes with a [`multistore`](/docs/sdk/v0.50/learn/advanced/store#multistore) to persist data and a [`router`](/docs/sdk/v0.50/learn/advanced/baseapp#routing) to handle transactions. +The Cosmos SDK is a framework that facilitates the development of secure state-machines on top of CometBFT. At its core, the Cosmos SDK is a boilerplate implementation of the [ABCI](/docs/sdk/v0.50/learn/intro/sdk-app-architecture#abci) in Golang. It comes with a [`multistore`](/docs/sdk/v0.50/learn/advanced/store#multistore) to persist data and a [`router`](/docs/sdk/v0.50/learn/advanced/baseapp#routing) to handle transactions. Here is a simplified view of how transactions are handled by an application built on top of the Cosmos SDK when transferred from CometBFT via `DeliverTx`: diff --git a/docs/sdk/v0.50/tutorials/vote-extensions/auction-frontrunning/getting-started.mdx b/docs/sdk/v0.50/tutorials/vote-extensions/auction-frontrunning/getting-started.mdx index 0e583656..68be17d2 100644 --- a/docs/sdk/v0.50/tutorials/vote-extensions/auction-frontrunning/getting-started.mdx +++ b/docs/sdk/v0.50/tutorials/vote-extensions/auction-frontrunning/getting-started.mdx @@ -22,7 +22,7 @@ This tutorial outlines the development of a module designed to mitigate front-ru * `PrepareProposal`: Processes the vote extensions from the previous block, creating a special transaction that encapsulates bids to be included in the current proposal. * `ProcessProposal`: Validates that the first transaction in the proposal is the special transaction containing the vote extensions and ensures the integrity of the bids. -In this advanced tutorial, we will be working with an example application that facilitates the auctioning of nameservices. To see what frontrunning and nameservices are [here](/docs/sdk/v0.50/understanding-frontrunning) This application provides a practical use case to explore the prevention of auction front-running, also known as "bid sniping", where a validator takes advantage of seeing a bid in the mempool to place their own higher bid before the original bid is processed. +In this advanced tutorial, we will be working with an example application that facilitates the auctioning of nameservices. To see what frontrunning and nameservices are [here](/docs/sdk/v0.50/tutorials/vote-extensions/auction-frontrunning) This application provides a practical use case to explore the prevention of auction front-running, also known as "bid sniping", where a validator takes advantage of seeing a bid in the mempool to place their own higher bid before the original bid is processed. The tutorial will guide you through using the Cosmos SDK to mitigate front-running using vote extensions. The module will be built on top of the base blockchain provided in the `tutorials/base` directory and will use the `auction` module as a foundation. By the end of this tutorial, you will have a better understanding of how to prevent front-running in blockchain auctions, specifically in the context of nameservice auctioning. diff --git a/docs/sdk/v0.50/user/run-node/run-production.mdx b/docs/sdk/v0.50/user/run-node/run-production.mdx index 7c10c14a..227d2275 100644 --- a/docs/sdk/v0.50/user/run-node/run-production.mdx +++ b/docs/sdk/v0.50/user/run-node/run-production.mdx @@ -47,7 +47,7 @@ In the past, validators [have had issues](https://github.com/cosmos/cosmos-sdk/i ### Firewall -Nodes should not have all ports open to the public, this is a simple way to get DDOS'd. Secondly it is recommended by [CometBFT](/docs/sdk/v0.50/user/run-node/github.com/cometbft/cometbft) to never expose ports that are not required to operate a node. +Nodes should not have all ports open to the public, this is a simple way to get DDOS'd. Secondly it is recommended by [CometBFT](/https://github.com/cometbft/cometbft) to never expose ports that are not required to operate a node. When setting up a firewall there are a few ports that can be open when operating a Cosmos SDK node. There is the CometBFT json-RPC, prometheus, p2p, remote signer and Cosmos SDK GRPC and REST. If the node is being operated as a node that does not offer endpoints to be used for submission or querying then a max of three endpoints are needed. diff --git a/docs/sdk/v0.53/build/architecture/README.mdx b/docs/sdk/v0.53/build/architecture/README.mdx index a17036ba..5da18771 100644 --- a/docs/sdk/v0.53/build/architecture/README.mdx +++ b/docs/sdk/v0.53/build/architecture/README.mdx @@ -43,55 +43,55 @@ When writing ADRs, follow the same best practices for writing RFCs. When writing ### Accepted -* [ADR 002: SDK Documentation Structure](/docs/sdk/v0.53/adr-002-docs-structure) -* [ADR 004: Split Denomination Keys](/docs/sdk/v0.53/adr-004-split-denomination-keys) -* [ADR 006: Secret Store Replacement](/docs/sdk/v0.53/adr-006-secret-store-replacement) -* [ADR 009: Evidence Module](/docs/sdk/v0.53/adr-009-evidence-module) -* [ADR 010: Modular AnteHandler](/docs/sdk/v0.53/adr-010-modular-antehandler) -* [ADR 019: Protocol Buffer State Encoding](/docs/sdk/v0.53/adr-019-protobuf-state-encoding) -* [ADR 020: Protocol Buffer Transaction Encoding](/docs/sdk/v0.53/adr-020-protobuf-transaction-encoding) -* [ADR 021: Protocol Buffer Query Encoding](/docs/sdk/v0.53/adr-021-protobuf-query-encoding) -* [ADR 023: Protocol Buffer Naming and Versioning](/docs/sdk/v0.53/adr-023-protobuf-naming) -* [ADR 029: Fee Grant Module](/docs/sdk/v0.53/adr-029-fee-grant-module) -* [ADR 030: Message Authorization Module](/docs/sdk/v0.53/adr-030-authz-module) -* [ADR 031: Protobuf Msg Services](/docs/sdk/v0.53/adr-031-msg-service) -* [ADR 055: ORM](/docs/sdk/v0.53/adr-055-orm) -* [ADR 058: Auto-Generated CLI](/docs/sdk/v0.53/adr-058-auto-generated-cli) +* [ADR 002: SDK Documentation Structure](/docs/sdk/v0.53/build/architecture/adr-002-docs-structure) +* [ADR 004: Split Denomination Keys](/docs/sdk/v0.53/build/architecture/adr-004-split-denomination-keys) +* [ADR 006: Secret Store Replacement](/docs/sdk/v0.53/build/architecture/adr-006-secret-store-replacement) +* [ADR 009: Evidence Module](/docs/sdk/v0.53/build/architecture/adr-009-evidence-module) +* [ADR 010: Modular AnteHandler](/docs/sdk/v0.53/build/architecture/adr-010-modular-antehandler) +* [ADR 019: Protocol Buffer State Encoding](/docs/sdk/v0.53/build/architecture/adr-019-protobuf-state-encoding) +* [ADR 020: Protocol Buffer Transaction Encoding](/docs/sdk/v0.53/build/architecture/adr-020-protobuf-transaction-encoding) +* [ADR 021: Protocol Buffer Query Encoding](/docs/sdk/v0.53/build/architecture/adr-021-protobuf-query-encoding) +* [ADR 023: Protocol Buffer Naming and Versioning](/docs/sdk/v0.53/build/architecture/adr-023-protobuf-naming) +* [ADR 029: Fee Grant Module](/docs/sdk/v0.53/build/architecture/adr-029-fee-grant-module) +* [ADR 030: Message Authorization Module](/docs/sdk/v0.53/build/architecture/adr-030-authz-module) +* [ADR 031: Protobuf Msg Services](/docs/sdk/v0.53/build/architecture/adr-031-msg-service) +* [ADR 055: ORM](/docs/sdk/v0.53/build/architecture/adr-055-orm) +* [ADR 058: Auto-Generated CLI](/docs/sdk/v0.53/build/architecture/adr-058-auto-generated-cli) * [ADR 060: ABCI 1.0 (Phase I)](/docs/sdk/v0.53/build/architecture/adr-060-abci-1.0) -* [ADR 061: Liquid Staking](/docs/sdk/v0.53/adr-061-liquid-staking) +* [ADR 061: Liquid Staking](/docs/sdk/v0.53/build/architecture/adr-061-liquid-staking) ### Proposed -* [ADR 003: Dynamic Capability Store](/docs/sdk/v0.53/adr-003-dynamic-capability-store) -* [ADR 011: Generalize Genesis Accounts](/docs/sdk/v0.53/adr-011-generalize-genesis-accounts) -* [ADR 012: State Accessors](/docs/sdk/v0.53/adr-012-state-accessors) -* [ADR 013: Metrics](/docs/sdk/v0.53/adr-013-metrics) -* [ADR 016: Validator Consensus Key Rotation](/docs/sdk/v0.53/adr-016-validator-consensus-key-rotation) -* [ADR 017: Historical Header Module](/docs/sdk/v0.53/adr-017-historical-header-module) -* [ADR 018: Extendable Voting Periods](/docs/sdk/v0.53/adr-018-extendable-voting-period) -* [ADR 022: Custom baseapp panic handling](/docs/sdk/v0.53/adr-022-custom-panic-handling) -* [ADR 024: Coin Metadata](/docs/sdk/v0.53/adr-024-coin-metadata) -* [ADR 027: Deterministic Protobuf Serialization](/docs/sdk/v0.53/adr-027-deterministic-protobuf-serialization) -* [ADR 028: Public Key Addresses](/docs/sdk/v0.53/adr-028-public-key-addresses) -* [ADR 032: Typed Events](/docs/sdk/v0.53/adr-032-typed-events) -* [ADR 033: Inter-module RPC](/docs/sdk/v0.53/adr-033-protobuf-inter-module-comm) -* [ADR 035: Rosetta API Support](/docs/sdk/v0.53/adr-035-rosetta-api-support) -* [ADR 037: Governance Split Votes](/docs/sdk/v0.53/adr-037-gov-split-vote) -* [ADR 038: State Listening](/docs/sdk/v0.53/adr-038-state-listening) -* [ADR 039: Epoched Staking](/docs/sdk/v0.53/adr-039-epoched-staking) -* [ADR 040: Storage and SMT State Commitments](/docs/sdk/v0.53/adr-040-storage-and-smt-state-commitments) -* [ADR 046: Module Params](/docs/sdk/v0.53/adr-046-module-params) -* [ADR 054: Semver Compatible SDK Modules](/docs/sdk/v0.53/adr-054-semver-compatible-modules) -* [ADR 057: App Wiring](/docs/sdk/v0.53/adr-057-app-wiring) -* [ADR 059: Test Scopes](/docs/sdk/v0.53/adr-059-test-scopes) -* [ADR 062: Collections State Layer](/docs/sdk/v0.53/adr-062-collections-state-layer) -* [ADR 063: Core Module API](/docs/sdk/v0.53/adr-063-core-module-api) -* [ADR 065: Store V2](/docs/sdk/v0.53/adr-065-store-v2) -* [ADR 076: Transaction Malleability Risk Review and Recommendations](/docs/sdk/v0.53/adr-076-tx-malleability) +* [ADR 003: Dynamic Capability Store](/docs/sdk/v0.53/build/architecture/adr-003-dynamic-capability-store) +* [ADR 011: Generalize Genesis Accounts](/docs/sdk/v0.53/build/architecture/adr-011-generalize-genesis-accounts) +* [ADR 012: State Accessors](/docs/sdk/v0.53/build/architecture/adr-012-state-accessors) +* [ADR 013: Metrics](/docs/sdk/v0.53/build/architecture/adr-013-metrics) +* [ADR 016: Validator Consensus Key Rotation](/docs/sdk/v0.53/build/architecture/adr-016-validator-consensus-key-rotation) +* [ADR 017: Historical Header Module](/docs/sdk/v0.53/build/architecture/adr-017-historical-header-module) +* [ADR 018: Extendable Voting Periods](/docs/sdk/v0.53/build/architecture/adr-018-extendable-voting-period) +* [ADR 022: Custom baseapp panic handling](/docs/sdk/v0.53/build/architecture/adr-022-custom-panic-handling) +* [ADR 024: Coin Metadata](/docs/sdk/v0.53/build/architecture/adr-024-coin-metadata) +* [ADR 027: Deterministic Protobuf Serialization](/docs/sdk/v0.53/build/architecture/adr-027-deterministic-protobuf-serialization) +* [ADR 028: Public Key Addresses](/docs/sdk/v0.53/build/architecture/adr-028-public-key-addresses) +* [ADR 032: Typed Events](/docs/sdk/v0.53/build/architecture/adr-032-typed-events) +* [ADR 033: Inter-module RPC](/docs/sdk/v0.53/build/architecture/adr-033-protobuf-inter-module-comm) +* [ADR 035: Rosetta API Support](/docs/sdk/v0.53/build/architecture/adr-035-rosetta-api-support) +* [ADR 037: Governance Split Votes](/docs/sdk/v0.53/build/architecture/adr-037-gov-split-vote) +* [ADR 038: State Listening](/docs/sdk/v0.53/build/architecture/adr-038-state-listening) +* [ADR 039: Epoched Staking](/docs/sdk/v0.53/build/architecture/adr-039-epoched-staking) +* [ADR 040: Storage and SMT State Commitments](/docs/sdk/v0.53/build/architecture/adr-040-storage-and-smt-state-commitments) +* [ADR 046: Module Params](/docs/sdk/v0.53/build/architecture/adr-046-module-params) +* [ADR 054: Semver Compatible SDK Modules](/docs/sdk/v0.53/build/architecture/adr-054-semver-compatible-modules) +* [ADR 057: App Wiring](/docs/sdk/v0.53/build/architecture/adr-057-app-wiring) +* [ADR 059: Test Scopes](/docs/sdk/v0.53/build/architecture/adr-059-test-scopes) +* [ADR 062: Collections State Layer](/docs/sdk/v0.53/build/architecture/adr-062-collections-state-layer) +* [ADR 063: Core Module API](/docs/sdk/v0.53/build/architecture/adr-063-core-module-api) +* [ADR 065: Store V2](/docs/sdk/v0.53/build/architecture/adr-065-store-v2) +* [ADR 076: Transaction Malleability Risk Review and Recommendations](/docs/sdk/v0.53/build/architecture/adr-076-tx-malleability) ### Draft -* [ADR 044: Guidelines for Updating Protobuf Definitions](/docs/sdk/v0.53/adr-044-protobuf-updates-guidelines) -* [ADR 047: Extend Upgrade Plan](/docs/sdk/v0.53/adr-047-extend-upgrade-plan) -* [ADR 053: Go Module Refactoring](/docs/sdk/v0.53/adr-053-go-module-refactoring) -* [ADR 068: Preblock](/docs/sdk/v0.53/adr-068-preblock) +* [ADR 044: Guidelines for Updating Protobuf Definitions](/docs/sdk/v0.53/build/architecture/adr-044-protobuf-updates-guidelines) +* [ADR 047: Extend Upgrade Plan](/docs/sdk/v0.53/build/architecture/adr-047-extend-upgrade-plan) +* [ADR 053: Go Module Refactoring](/docs/sdk/v0.53/build/architecture/adr-053-go-module-refactoring) +* [ADR 068: Preblock](/docs/sdk/v0.53/build/architecture/adr-068-preblock) diff --git a/docs/sdk/v0.53/build/architecture/adr-054-semver-compatible-modules.mdx b/docs/sdk/v0.53/build/architecture/adr-054-semver-compatible-modules.mdx index 5c7fb7c4..e16824b6 100644 --- a/docs/sdk/v0.53/build/architecture/adr-054-semver-compatible-modules.mdx +++ b/docs/sdk/v0.53/build/architecture/adr-054-semver-compatible-modules.mdx @@ -476,7 +476,7 @@ languages, possibly executed within a WASM VM. ### Minor API Revisions To declare minor API revisions of proto files, we propose the following guidelines (which were already documented -in [cosmos.app.v1alpha module options](/docs/sdk/v0.50/proto/cosmos/app/v1alpha1/module.proto)): +in [cosmos.app.v1alpha module options](/https://github.com/cosmos/cosmos-sdk/blob/v0.50/proto/cosmos/app/v1alpha1/module.proto)): * proto packages which are revised from their initial version (considered revision `0`) should include a `package` * comment in some .proto file containing the test `Revision N` at the start of a comment line where `N` is the current diff --git a/docs/sdk/v0.53/build/architecture/adr-057-app-wiring.mdx b/docs/sdk/v0.53/build/architecture/adr-057-app-wiring.mdx index 8f58f5fd..f915953f 100644 --- a/docs/sdk/v0.53/build/architecture/adr-057-app-wiring.mdx +++ b/docs/sdk/v0.53/build/architecture/adr-057-app-wiring.mdx @@ -25,13 +25,13 @@ which contains almost 100 lines of imports and is otherwise over 600 lines of mo generally copied to each new project. (Not to mention the additional boilerplate which gets copied in `simapp/simd`.) The large amount of boilerplate needed to bootstrap an app has made it hard to release independently versioned go -modules for Cosmos SDK modules as described in [ADR 053: Go Module Refactoring](/docs/sdk/v0.53/adr-053-go-module-refactoring). +modules for Cosmos SDK modules as described in [ADR 053: Go Module Refactoring](/docs/sdk/v0.53/build/architecture/adr-053-go-module-refactoring). In addition to being very verbose and repetitive, `app.go` also exposes a large surface area for breaking changes as most modules instantiate themselves with positional parameters which forces breaking changes anytime a new parameter (even an optional one) is needed. -Several attempts were made to improve the current situation including [ADR 033: Internal-Module Communication](/docs/sdk/v0.53/adr-033-protobuf-inter-module-comm) +Several attempts were made to improve the current situation including [ADR 033: Internal-Module Communication](/docs/sdk/v0.53/build/architecture/adr-033-protobuf-inter-module-comm) and [a proof-of-concept of a new SDK](https://github.com/allinbits/cosmos-sdk-poc). The discussions around these designs led to the current solution described here. @@ -229,7 +229,7 @@ In cases where required modules are not loaded at runtime, it may be possible to through a global Cosmos SDK module registry. The `*appmodule.Handler` type referenced above is a replacement for the legacy `AppModule` framework, and -described in [ADR 063: Core Module API](/docs/sdk/v0.53/adr-063-core-module-api). +described in [ADR 063: Core Module API](/docs/sdk/v0.53/build/architecture/adr-063-core-module-api). ### New `app.go` @@ -260,7 +260,7 @@ func main() { So far we have described a system which is largely agnostic to the specifics of the SDK such as store keys, `AppModule`, `BaseApp`, etc. Improvements to these parts of the framework that integrate with the general app wiring framework -defined here are described in [ADR 063: Core Module API](/docs/sdk/v0.53/adr-063-core-module-api). +defined here are described in [ADR 063: Core Module API](/docs/sdk/v0.53/build/architecture/adr-063-core-module-api). ### Registration of Inter-Module Hooks @@ -341,7 +341,7 @@ versioned module config protobuf type, and major versioning bumps should occur w are made to a module. NOTE: SDK modules that are standalone go modules *should not* adopt semantic versioning until the concerns described in -[ADR 054: Module Semantic Versioning](/docs/sdk/v0.53/adr-054-semver-compatible-modules) are +[ADR 054: Module Semantic Versioning](/docs/sdk/v0.53/build/architecture/adr-054-semver-compatible-modules) are addressed. The short-term solution for this issue was left somewhat unresolved. However, the easiest tactic is likely to use a standalone API go module and follow the guidelines described in this comment: [Link](https://github.com/cosmos/cosmos-sdk/pull/11802#issuecomment-1406815181). For the time-being, it is recommended that Cosmos SDK modules continue to follow tried and true [0-based versioning](https://0ver.org) until an officially @@ -386,4 +386,4 @@ light of code generation. It may be better to do this type registration with a D * [Link](https://github.com/google/wire) * [Link](https://pkg.go.dev/github.com/cosmos/cosmos-sdk/container) * [Link](https://github.com/cosmos/cosmos-sdk/pull/11802) -* [ADR 063: Core Module API](/docs/sdk/v0.53/adr-063-core-module-api) +* [ADR 063: Core Module API](/docs/sdk/v0.53/build/architecture/adr-063-core-module-api) diff --git a/docs/sdk/v0.53/build/architecture/adr-063-core-module-api.mdx b/docs/sdk/v0.53/build/architecture/adr-063-core-module-api.mdx index 6c5c9730..9b042485 100644 --- a/docs/sdk/v0.53/build/architecture/adr-063-core-module-api.mdx +++ b/docs/sdk/v0.53/build/architecture/adr-063-core-module-api.mdx @@ -23,7 +23,7 @@ A new core API is proposed as a way to develop cosmos-sdk applications that will * more stable than the current framework * enable deterministic events and queries, * support event listeners -* [ADR 033: Protobuf-based Inter-Module Communication](/docs/sdk/v0.53/adr-033-protobuf-inter-module-comm) clients. +* [ADR 033: Protobuf-based Inter-Module Communication](/docs/sdk/v0.53/build/architecture/adr-033-protobuf-inter-module-comm) clients. ## Context @@ -93,7 +93,7 @@ slower than more fast moving projects. ### Core Services The following "core services" are defined by the core API. All valid runtime module implementations should provide -implementations of these services to modules via both [dependency injection](/docs/sdk/v0.53/adr-057-app-wiring) and +implementations of these services to modules via both [dependency injection](/docs/sdk/v0.53/build/architecture/adr-057-app-wiring) and manual wiring. The individual services described below are all bundled in a convenient `appmodule.Service` "bundle service" so that for simplicity modules can declare a dependency on a single service. @@ -274,7 +274,7 @@ type GenesisTarget = func(field string) (io.WriteCloser, error) All genesis objects for a given module are expected to conform to the semantics of a JSON object. Each field in the JSON object should be read and written separately to support streaming genesis. -The [ORM](/docs/sdk/v0.53/adr-055-orm) and [collections](/docs/sdk/v0.53/adr-062-collections-state-layer) both support +The [ORM](/docs/sdk/v0.53/build/architecture/adr-055-orm) and [collections](/docs/sdk/v0.53/build/architecture/adr-062-collections-state-layer) both support streaming genesis and modules using these frameworks generally do not need to write any manual genesis code. @@ -423,7 +423,7 @@ Additional `AppModule` extension interfaces either inside or outside of core wil these concerns. In the case of gogo proto and amino interfaces, the registration of these generally should happen as early -as possible during initialization and in [ADR 057: App Wiring](/docs/sdk/v0.53/adr-057-app-wiring-1), protobuf type registration\ +as possible during initialization and in [ADR 057: App Wiring](/docs/sdk/v0.53/build/architecture/adr-057-app-wiring-1), protobuf type registration\ happens before dependency injection (although this could alternatively be done dedicated DI providers). gRPC gateway registration should probably be handled by the runtime module, but the core API shouldn't depend on gRPC @@ -460,11 +460,11 @@ Crisis module invariants and simulations are subject to potential redesign and s defined in the crisis and simulation modules respectively. Extension interface for CLI commands will be provided via the `cosmossdk.io/client/v2` module and its -[autocli](/docs/sdk/v0.53/adr-058-auto-generated-cli) framework. +[autocli](/docs/sdk/v0.53/build/architecture/adr-058-auto-generated-cli) framework. #### Example Usage -Here is an example of setting up a hypothetical `foo` v2 module which uses the [ORM](/docs/sdk/v0.53/adr-055-orm) for its state +Here is an example of setting up a hypothetical `foo` v2 module which uses the [ORM](/docs/sdk/v0.53/build/architecture/adr-055-orm) for its state management and genesis. ```go expandable @@ -524,7 +524,7 @@ These runtime modules should attempt to be semantically versioned even if the un because a runtime module is also a first class Cosmos SDK module, it should have a protobuf module config type. A new semantically versioned module config type should be created for each of these runtime module such that there is a 1:1 correspondence between the go module and module config type. This is the same practice should be followed for every -semantically versioned Cosmos SDK module as described in [ADR 057: App Wiring](/docs/sdk/v0.53/adr-057-app-wiring). +semantically versioned Cosmos SDK module as described in [ADR 057: App Wiring](/docs/sdk/v0.53/build/architecture/adr-057-app-wiring). Currently, `github.com/cosmos/cosmos-sdk/runtime` uses the protobuf config type `cosmos.app.runtime.v1alpha1.Module`. When we have a standalone v1 comet runtime, we should use a dedicated protobuf module config type such as @@ -608,8 +608,8 @@ as by providing service implementations by wrapping `sdk.Context`. ## References -* [ADR 033: Protobuf-based Inter-Module Communication](/docs/sdk/v0.53/adr-033-protobuf-inter-module-comm) -* [ADR 057: App Wiring](/docs/sdk/v0.53/adr-057-app-wiring-1) -* [ADR 055: ORM](/docs/sdk/v0.53/adr-055-orm) -* [ADR 028: Public Key Addresses](/docs/sdk/v0.53/adr-028-public-key-addresses) +* [ADR 033: Protobuf-based Inter-Module Communication](/docs/sdk/v0.53/build/architecture/adr-033-protobuf-inter-module-comm) +* [ADR 057: App Wiring](/docs/sdk/v0.53/build/architecture/adr-057-app-wiring-1) +* [ADR 055: ORM](/docs/sdk/v0.53/build/architecture/adr-055-orm) +* [ADR 028: Public Key Addresses](/docs/sdk/v0.53/build/architecture/adr-028-public-key-addresses) * [Keeping Your Modules Compatible](https://go.dev/blog/module-compatibility) diff --git a/docs/sdk/v0.53/build/architecture/adr-template.mdx b/docs/sdk/v0.53/build/architecture/adr-template.mdx index c4ea3c92..705ced2d 100644 --- a/docs/sdk/v0.53/build/architecture/adr-template.mdx +++ b/docs/sdk/v0.53/build/architecture/adr-template.mdx @@ -6,7 +6,7 @@ {DRAFT | PROPOSED} Not Implemented -> Please have a look at the [PROCESS](/docs/sdk/v0.50/PROCESS#adr-status) page. +> Please have a look at the [PROCESS](/docs/sdk/v0.50/build/rfc/PROCESS#adr-status) page. > Use DRAFT if the ADR is in a draft stage (draft PR) or PROPOSED if it's in review. ## Abstract diff --git a/docs/sdk/v0.53/build/building-apps/app-mempool.mdx b/docs/sdk/v0.53/build/building-apps/app-mempool.mdx index 6b08b08d..7e4374b7 100644 --- a/docs/sdk/v0.53/build/building-apps/app-mempool.mdx +++ b/docs/sdk/v0.53/build/building-apps/app-mempool.mdx @@ -29,7 +29,7 @@ Namely, the SDK provides the following mempools: * [Sender Nonce Mempool](#sender-nonce-mempool) * [Priority Nonce Mempool](#priority-nonce-mempool) -By default, the SDK uses the [No-op Mempool](#no-op-mempool), but it can be replaced by the application developer in [`app.go`](/docs/sdk/v0.53/app-go-di): +By default, the SDK uses the [No-op Mempool](#no-op-mempool), but it can be replaced by the application developer in [`app.go`](/docs/sdk/v0.53/build/building-apps/app-go-di): ```go nonceMempool := mempool.NewSenderNonceMempool() diff --git a/docs/sdk/v0.53/build/building-modules/beginblock-endblock.mdx b/docs/sdk/v0.53/build/building-modules/beginblock-endblock.mdx index 33e44a7b..553a5328 100644 --- a/docs/sdk/v0.53/build/building-modules/beginblock-endblock.mdx +++ b/docs/sdk/v0.53/build/building-modules/beginblock-endblock.mdx @@ -11,7 +11,7 @@ title: BeginBlocker and EndBlocker **Pre-requisite Readings** -* [Module Manager](/docs/sdk/v0.53/build/building-modules/module-manager) +* [Module Manager](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) @@ -21,7 +21,7 @@ title: BeginBlocker and EndBlocker In 0.47.0, Prepare and Process Proposal were added that allow app developers to do arbitrary work at those phases, but they do not influence the work that will be done in BeginBlock. If an application required `BeginBlock` to execute prior to any sort of work is done then this is not possible today (0.50.0). -When needed, `BeginBlocker` and `EndBlocker` are implemented as part of the [`HasBeginBlocker`, `HasABCIEndBlocker` and `EndBlocker` interfaces](/docs/sdk/v0.53/build/building-modules/module-manager#appmodule). This means either can be left-out if not required. The `BeginBlock` and `EndBlock` methods of the interface implemented in `module.go` generally defer to `BeginBlocker` and `EndBlocker` methods respectively, which are usually implemented in `abci.go`. +When needed, `BeginBlocker` and `EndBlocker` are implemented as part of the [`HasBeginBlocker`, `HasABCIEndBlocker` and `EndBlocker` interfaces](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#appmodule). This means either can be left-out if not required. The `BeginBlock` and `EndBlock` methods of the interface implemented in `module.go` generally defer to `BeginBlocker` and `EndBlocker` methods respectively, which are usually implemented in `abci.go`. The actual implementation of `BeginBlocker` and `EndBlocker` in `abci.go` are very similar to that of a [`Msg` service](/docs/sdk/v0.53/build/building-modules/msg-services): @@ -31,7 +31,7 @@ The actual implementation of `BeginBlocker` and `EndBlocker` in `abci.go` are ve A specific type of `EndBlocker` is available to return validator updates to the underlying consensus engine in the form of an [`[]abci.ValidatorUpdates`](https://docs.cometbft.com/v0.37/spec/abci/abci++_methods#endblock). This is the preferred way to implement custom validator changes. -It is possible for developers to define the order of execution between the `BeginBlocker`/`EndBlocker` functions of each of their application's modules via the module's manager `SetOrderBeginBlocker`/`SetOrderEndBlocker` methods. For more on the module manager, click [here](/docs/sdk/v0.53/build/building-modules/module-manager). +It is possible for developers to define the order of execution between the `BeginBlocker`/`EndBlocker` functions of each of their application's modules via the module's manager `SetOrderBeginBlocker`/`SetOrderEndBlocker` methods. For more on the module manager, click [here](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager). See an example implementation of `BeginBlocker` from the `distribution` module: diff --git a/docs/sdk/v0.53/build/building-modules/genesis.mdx b/docs/sdk/v0.53/build/building-modules/genesis.mdx index 34b07540..00bc6ca6 100644 --- a/docs/sdk/v0.53/build/building-modules/genesis.mdx +++ b/docs/sdk/v0.53/build/building-modules/genesis.mdx @@ -11,7 +11,7 @@ Modules generally handle a subset of the state and, as such, they need to define **Pre-requisite Readings** -* [Module Manager](/docs/sdk/v0.53/build/building-modules/module-manager) +* [Module Manager](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) * [Keepers](/docs/sdk/v0.53/build/building-modules/keeper) @@ -608,13 +608,13 @@ return accounts, nil ## Other Genesis Methods -Other than the methods related directly to `GenesisState`, module developers are expected to implement two other methods as part of the [`AppModuleGenesis` interface](/docs/sdk/v0.53/build/building-modules/module-manager#appmodulegenesis) (only if the module needs to initialize a subset of state in genesis). These methods are [`InitGenesis`](#initgenesis) and [`ExportGenesis`](#exportgenesis). +Other than the methods related directly to `GenesisState`, module developers are expected to implement two other methods as part of the [`AppModuleGenesis` interface](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#appmodulegenesis) (only if the module needs to initialize a subset of state in genesis). These methods are [`InitGenesis`](#initgenesis) and [`ExportGenesis`](#exportgenesis). ### `InitGenesis` The `InitGenesis` method is executed during [`InitChain`](/docs/sdk/v0.53//learn/advanced/baseapp#initchain) when the application is first started. Given a `GenesisState`, it initializes the subset of the state managed by the module by using the module's [`keeper`](/docs/sdk/v0.53/build/building-modules/keeper) setter function on each parameter within the `GenesisState`. -The [module manager](/docs/sdk/v0.53/build/building-modules/module-manager) of the application is responsible for calling the `InitGenesis` method of each of the application's modules in order. This order is set by the application developer via the manager's `SetOrderGenesisMethod`, which is called in the [application's constructor function](/docs/sdk/v0.53//learn/beginner/app-anatomy#constructor-function). +The [module manager](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) of the application is responsible for calling the `InitGenesis` method of each of the application's modules in order. This order is set by the application developer via the manager's `SetOrderGenesisMethod`, which is called in the [application's constructor function](/docs/sdk/v0.53//learn/beginner/app-anatomy#constructor-function). See an example of `InitGenesis` from the `auth` module: diff --git a/docs/sdk/v0.53/build/building-modules/intro.mdx b/docs/sdk/v0.53/build/building-modules/intro.mdx index 7e478c8d..5dc7fd1e 100644 --- a/docs/sdk/v0.53/build/building-modules/intro.mdx +++ b/docs/sdk/v0.53/build/building-modules/intro.mdx @@ -299,6 +299,6 @@ Modules are by convention defined in the `./x/` subfolder (e.g. the `bank` modul * A [query service](/docs/sdk/v0.53/build/building-modules/query-services), used to process user queries when they are routed to the module by [`BaseApp`](/docs/sdk/v0.53/learn/advanced/baseapp#query-routing). * Interfaces, for end users to query the subset of the state defined by the module and create `message`s of the custom types defined in the module. -In addition to these components, modules implement the `AppModule` interface in order to be managed by the [`module manager`](/docs/sdk/v0.53/build/building-modules/module-manager). +In addition to these components, modules implement the `AppModule` interface in order to be managed by the [`module manager`](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager). Please refer to the [structure document](/docs/sdk/v0.53/build/building-modules/structure) to learn about the recommended structure of a module's directory. diff --git a/docs/sdk/v0.53/build/building-modules/invariants.mdx b/docs/sdk/v0.53/build/building-modules/invariants.mdx index abffd924..675fd867 100644 --- a/docs/sdk/v0.53/build/building-modules/invariants.mdx +++ b/docs/sdk/v0.53/build/building-modules/invariants.mdx @@ -82,7 +82,7 @@ return DepositsInvariant(k)(ctx) } ``` -Finally, module developers need to implement the `RegisterInvariants` method as part of the [`AppModule` interface](/docs/sdk/v0.53/build/building-modules/module-manager#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): +Finally, module developers need to implement the `RegisterInvariants` method as part of the [`AppModule` interface](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#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): ```go expandable package keeper diff --git a/docs/sdk/v0.53/build/building-modules/messages-and-queries.mdx b/docs/sdk/v0.53/build/building-modules/messages-and-queries.mdx index 44f054a8..367274c5 100644 --- a/docs/sdk/v0.53/build/building-modules/messages-and-queries.mdx +++ b/docs/sdk/v0.53/build/building-modules/messages-and-queries.mdx @@ -240,9 +240,9 @@ The Cosmos SDK uses Protobuf definitions to generate client and server code: * `MsgServer` interface defines the server API for the `Msg` service and its implementation is described as part of the [`Msg` services](/docs/sdk/v0.53/build/building-modules/msg-services) documentation. * Structures are generated for all RPC request and response types. -A `RegisterMsgServer` method is also generated and should be used to register the module's `MsgServer` implementation in `RegisterServices` method from the [`AppModule` interface](/docs/sdk/v0.53/build/building-modules/module-manager#appmodule). +A `RegisterMsgServer` method is also generated and should be used to register the module's `MsgServer` implementation in `RegisterServices` method from the [`AppModule` interface](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#appmodule). -In order for clients (CLI and grpc-gateway) to have these URLs registered, the Cosmos SDK provides the function `RegisterMsgServiceDesc(registry codectypes.InterfaceRegistry, sd *grpc.ServiceDesc)` that should be called inside module's [`RegisterInterfaces`](module-manager#appmodulebasic) method, using the proto-generated `&_Msg_serviceDesc` as `*grpc.ServiceDesc` argument. +In order for clients (CLI and grpc-gateway) to have these URLs registered, the Cosmos SDK provides the function `RegisterMsgServiceDesc(registry codectypes.InterfaceRegistry, sd *grpc.ServiceDesc)` that should be called inside module's [`RegisterInterfaces`](docs/sdk/v0.53/build/building-modules/module-manager#appmodulebasic) method, using the proto-generated `&_Msg_serviceDesc` as `*grpc.ServiceDesc` argument. ## Queries @@ -260,7 +260,7 @@ Here's an example of such a `Query` service definition: As `proto.Message`s, generated `Response` types implement by default `String()` method of [`fmt.Stringer`](https://pkg.go.dev/fmt#Stringer). -A `RegisterQueryServer` method is also generated and should be used to register the module's query server in the `RegisterServices` method from the [`AppModule` interface](/docs/sdk/v0.53/build/building-modules/module-manager#appmodule). +A `RegisterQueryServer` method is also generated and should be used to register the module's query server in the `RegisterServices` method from the [`AppModule` interface](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#appmodule). ### Legacy Queries @@ -279,7 +279,7 @@ where: The `path` for each `query` must be defined by the module developer in the module's [command-line interface file](/docs/sdk/v0.53/build/building-modules/module-interfaces#query-commands).Overall, there are 3 mains components module developers need to implement in order to make the subset of the state defined by their module queryable: -* A [`querier`](/docs/sdk/v0.53/query-services#legacy-queriers), to process the `query` once it has been [routed to the module](/docs/sdk/v0.53//learn/advanced/baseapp#query-routing). +* A [`querier`](/docs/sdk/v0.53/build/building-modules/query-services#legacy-queriers), to process the `query` once it has been [routed to the module](/docs/sdk/v0.53//learn/advanced/baseapp#query-routing). * [Query commands](/docs/sdk/v0.53/build/building-modules/module-interfaces#query-commands) in the module's CLI file, where the `path` for each `query` is specified. * `query` return types. Typically defined in a file `types/querier.go`, they specify the result type of each of the module's `queries`. These custom types must implement the `String()` method of [`fmt.Stringer`](https://pkg.go.dev/fmt#Stringer). diff --git a/docs/sdk/v0.53/build/building-modules/module-interfaces.mdx b/docs/sdk/v0.53/build/building-modules/module-interfaces.mdx index 728f6e13..08695b9a 100644 --- a/docs/sdk/v0.53/build/building-modules/module-interfaces.mdx +++ b/docs/sdk/v0.53/build/building-modules/module-interfaces.mdx @@ -1077,6 +1077,6 @@ Modules that want to expose REST queries should add `google.api.http` annotation // Reference: https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/proto/cosmos/auth/v1beta1/query.proto#L14-L89 ``` -gRPC gateway is started in-process along with the application and CometBFT. It can be enabled or disabled by setting gRPC Configuration `enable` in [`app.toml`](/docs/sdk/v0.50/run-node/run-node#configuring-the-node-using-apptoml-and-configtoml). +gRPC gateway is started in-process along with the application and CometBFT. It can be enabled or disabled by setting gRPC Configuration `enable` in [`app.toml`](/docs/sdk/v0.50/user/run-node/run-node#configuring-the-node-using-apptoml-and-configtoml). -The Cosmos SDK provides a command for generating [Swagger](https://swagger.io/) documentation (`protoc-gen-swagger`). Setting `swagger` in [`app.toml`](/docs/sdk/v0.50/run-node/run-node#configuring-the-node-using-apptoml-and-configtoml) defines if swagger documentation should be automatically registered. +The Cosmos SDK provides a command for generating [Swagger](https://swagger.io/) documentation (`protoc-gen-swagger`). Setting `swagger` in [`app.toml`](/docs/sdk/v0.50/user/run-node/run-node#configuring-the-node-using-apptoml-and-configtoml) defines if swagger documentation should be automatically registered. diff --git a/docs/sdk/v0.53/build/building-modules/module-manager.mdx b/docs/sdk/v0.53/build/building-modules/module-manager.mdx index 2a904b6e..617c231d 100644 --- a/docs/sdk/v0.53/build/building-modules/module-manager.mdx +++ b/docs/sdk/v0.53/build/building-modules/module-manager.mdx @@ -5,7 +5,7 @@ title: Module Manager **Synopsis** -Cosmos SDK modules need to implement the [`AppModule` interfaces](#application-module-interfaces), in order to be managed by the application's [module manager](#module-manager). The module manager plays an important role in [`message` and `query` routing](/docs/sdk/v0.53/learn/advanced/baseapp#routing), and allows application developers to set the order of execution of a variety of functions like [`PreBlocker`](/docs/sdk/v0.53/learn/beginner/app-anatomy#preblocker) and [`BeginBlocker` and `EndBlocker`](/docs/sdk/v0.53/learn/beginner/app-anatomy#begingblocker-and-endblocker). +Cosmos SDK modules need to implement the [`AppModule` interfaces](#application-module-interfaces), in order to be managed by the application's [module manager](#docs/sdk/v0.53/build/building-modules/module-manager). The module manager plays an important role in [`message` and `query` routing](/docs/sdk/v0.53/learn/advanced/baseapp#routing), and allows application developers to set the order of execution of a variety of functions like [`PreBlocker`](/docs/sdk/v0.53/learn/beginner/app-anatomy#preblocker) and [`BeginBlocker` and `EndBlocker`](/docs/sdk/v0.53/learn/beginner/app-anatomy#begingblocker-and-endblocker). @@ -14437,8 +14437,8 @@ The module manager is used throughout the application whenever an action on a co * `InitGenesis(ctx context.Context, cdc codec.JSONCodec, genesisData map[string]json.RawMessage)`: Calls the [`InitGenesis`](/docs/sdk/v0.53/build/building-modules/genesis#initgenesis) function of each module when the application is first started, in the order defined in `OrderInitGenesis`. Returns an `abci.ResponseInitChain` to the underlying consensus engine, which can contain validator updates. * `ExportGenesis(ctx context.Context, cdc codec.JSONCodec)`: Calls the [`ExportGenesis`](/docs/sdk/v0.53/build/building-modules/genesis#exportgenesis) function of each module, in the order defined in `OrderExportGenesis`. The export constructs a genesis file from a previously existing state, and is mainly used when a hard-fork upgrade of the chain is required. * `ExportGenesisForModules(ctx context.Context, cdc codec.JSONCodec, modulesToExport []string)`: Behaves the same as `ExportGenesis`, except takes a list of modules to export. -* `BeginBlock(ctx context.Context) error`: At the beginning of each block, this function is called from [`BaseApp`](/docs/sdk/v0.53//learn/advanced/baseapp#beginblock) and, in turn, calls the [`BeginBlock`](/docs/sdk/v0.53/beginblock-endblock) function of each modules implementing the `appmodule.HasBeginBlocker` interface, in the order defined in `OrderBeginBlockers`. It creates a child [context](/docs/sdk/v0.53//learn/advanced/context) with an event manager to aggregate [events](/docs/sdk/v0.53//learn/advanced/events) emitted from each modules. -* `EndBlock(ctx context.Context) error`: At the end of each block, this function is called from [`BaseApp`](/docs/sdk/v0.53//learn/advanced/baseapp#endblock) and, in turn, calls the [`EndBlock`](/docs/sdk/v0.53/beginblock-endblock) function of each modules implementing the `appmodule.HasEndBlocker` interface, in the order defined in `OrderEndBlockers`. It creates a child [context](/docs/sdk/v0.53//learn/advanced/context) with an event manager to aggregate [events](/docs/sdk/v0.53//learn/advanced/events) emitted from all modules. The function returns an `abci` which contains the aforementioned events, as well as validator set updates (if any). +* `BeginBlock(ctx context.Context) error`: At the beginning of each block, this function is called from [`BaseApp`](/docs/sdk/v0.53//learn/advanced/baseapp#beginblock) and, in turn, calls the [`BeginBlock`](/docs/sdk/v0.53/build/building-modules/beginblock-endblock) function of each modules implementing the `appmodule.HasBeginBlocker` interface, in the order defined in `OrderBeginBlockers`. It creates a child [context](/docs/sdk/v0.53//learn/advanced/context) with an event manager to aggregate [events](/docs/sdk/v0.53//learn/advanced/events) emitted from each modules. +* `EndBlock(ctx context.Context) error`: At the end of each block, this function is called from [`BaseApp`](/docs/sdk/v0.53//learn/advanced/baseapp#endblock) and, in turn, calls the [`EndBlock`](/docs/sdk/v0.53/build/building-modules/beginblock-endblock) function of each modules implementing the `appmodule.HasEndBlocker` interface, in the order defined in `OrderEndBlockers`. It creates a child [context](/docs/sdk/v0.53//learn/advanced/context) with an event manager to aggregate [events](/docs/sdk/v0.53//learn/advanced/events) emitted from all modules. The function returns an `abci` which contains the aforementioned events, as well as validator set updates (if any). * `EndBlock(context.Context) ([]abci.ValidatorUpdate, error)`: At the end of each block, this function is called from [`BaseApp`](/docs/sdk/v0.53//learn/advanced/baseapp#endblock) and, in turn, calls the [`EndBlock`](/docs/sdk/v0.53/build/building-modules/beginblock-endblock) function of each modules implementing the `module.HasABCIEndBlock` interface, in the order defined in `OrderEndBlockers`. It creates a child [context](/docs/sdk/v0.53//learn/advanced/context) with an event manager to aggregate [events](/docs/sdk/v0.53//learn/advanced/events) emitted from all modules. The function returns an `abci` which contains the aforementioned events, as well as validator set updates (if any). * `Precommit(ctx context.Context)`: During [`Commit`](/docs/sdk/v0.53//learn/advanced/baseapp#commit), this function is called from `BaseApp` immediately before the [`deliverState`](/docs/sdk/v0.53//learn/advanced/baseapp#state-updates) is written to the underlying [`rootMultiStore`](/docs/sdk/v0.53//learn/advanced/store#commitmultistore) and, in turn calls the `Precommit` function of each modules implementing the `HasPrecommit` interface, in the order defined in `OrderPrecommiters`. It creates a child [context](/docs/sdk/v0.53//learn/advanced/context) where the underlying `CacheMultiStore` is that of the newly committed block's [`finalizeblockstate`](/docs/sdk/v0.53//learn/advanced/baseapp#state-updates). * `PrepareCheckState(ctx context.Context)`: During [`Commit`](/docs/sdk/v0.53//learn/advanced/baseapp#commit), this function is called from `BaseApp` immediately after the [`deliverState`](/docs/sdk/v0.53//learn/advanced/baseapp#state-updates) is written to the underlying [`rootMultiStore`](/docs/sdk/v0.53//learn/advanced/store#commitmultistore) and, in turn calls the `PrepareCheckState` function of each module implementing the `HasPrepareCheckState` interface, in the order defined in `OrderPrepareCheckStaters`. It creates a child [context](/docs/sdk/v0.53//learn/advanced/context) where the underlying `CacheMultiStore` is that of the next block's [`checkState`](/docs/sdk/v0.53//learn/advanced/baseapp#state-updates). Writes to this state will be present in the [`checkState`](/docs/sdk/v0.53//learn/advanced/baseapp#state-updates) of the next block, and therefore this method can be used to prepare the `checkState` for the next block. diff --git a/docs/sdk/v0.53/build/building-modules/msg-services.mdx b/docs/sdk/v0.53/build/building-modules/msg-services.mdx index 61d1fdaf..92dcff9b 100644 --- a/docs/sdk/v0.53/build/building-modules/msg-services.mdx +++ b/docs/sdk/v0.53/build/building-modules/msg-services.mdx @@ -11,7 +11,7 @@ A Protobuf `Msg` service processes [messages](/docs/sdk/v0.53/build/building-mod **Pre-requisite Readings** -* [Module Manager](/docs/sdk/v0.53/build/building-modules/module-manager) +* [Module Manager](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) * [Messages and Queries](/docs/sdk/v0.53/build/building-modules/messages-and-queries) @@ -2657,7 +2657,7 @@ ErrUnexpectedEndOfGroupTx = fmt.Errorf("proto: unexpected end of group") ) ``` -When possible, the existing module's [`Keeper`](/docs/sdk/v0.50/keeper) should implement `MsgServer`, otherwise a `msgServer` struct that embeds the `Keeper` can be created, typically in `./keeper/msg_server.go`: +When possible, the existing module's [`Keeper`](/docs/sdk/v0.50/build/building-modules/keeper) should implement `MsgServer`, otherwise a `msgServer` struct that embeds the `Keeper` can be created, typically in `./keeper/msg_server.go`: ```go expandable package keeper @@ -3097,7 +3097,7 @@ This way of validating is deprecated, this means the `msgServer` must perform al ### State Transition -After the validation is successful, the `msgServer` method uses the [`keeper`](/docs/sdk/v0.50/keeper) functions to access the state and perform a state transition. +After the validation is successful, the `msgServer` method uses the [`keeper`](/docs/sdk/v0.50/build/building-modules/keeper) functions to access the state and perform a state transition. ### Events diff --git a/docs/sdk/v0.53/build/building-modules/preblock.mdx b/docs/sdk/v0.53/build/building-modules/preblock.mdx index 6fe0b859..a2dbc902 100644 --- a/docs/sdk/v0.53/build/building-modules/preblock.mdx +++ b/docs/sdk/v0.53/build/building-modules/preblock.mdx @@ -10,7 +10,7 @@ title: PreBlocker **Pre-requisite Readings** -* [Module Manager](/docs/sdk/v0.53/build/building-modules/module-manager) +* [Module Manager](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) diff --git a/docs/sdk/v0.53/build/building-modules/protobuf-annotations.mdx b/docs/sdk/v0.53/build/building-modules/protobuf-annotations.mdx index cf39cf68..fe3a640b 100644 --- a/docs/sdk/v0.53/build/building-modules/protobuf-annotations.mdx +++ b/docs/sdk/v0.53/build/building-modules/protobuf-annotations.mdx @@ -11,7 +11,7 @@ This document explains the various protobuf scalars that have been added to make Signer specifies which field should be used to determine the signer of a message for the Cosmos SDK. This field can be used for clients as well to infer which field should be used to determine the signer of a message. -Read more about the signer field [here](/docs/sdk/v0.50/messages-and-queries). +Read more about the signer field [here](/docs/sdk/v0.50/build/building-modules/messages-and-queries). ```protobuf // Reference: https://github.com/cosmos/cosmos-sdk/blob/e6848d99b55a65d014375b295bdd7f9641aac95e/proto/cosmos/bank/v1beta1/tx.proto#L40 diff --git a/docs/sdk/v0.53/build/building-modules/query-services.mdx b/docs/sdk/v0.53/build/building-modules/query-services.mdx index 33ff76f0..c1abdccf 100644 --- a/docs/sdk/v0.53/build/building-modules/query-services.mdx +++ b/docs/sdk/v0.53/build/building-modules/query-services.mdx @@ -11,7 +11,7 @@ A Protobuf Query service processes [`queries`](/docs/sdk/v0.53/build/building-mo **Pre-requisite Readings** -* [Module Manager](/docs/sdk/v0.53/build/building-modules/module-manager) +* [Module Manager](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) * [Messages and Queries](/docs/sdk/v0.53/build/building-modules/messages-and-queries) diff --git a/docs/sdk/v0.53/build/building-modules/structure.mdx b/docs/sdk/v0.53/build/building-modules/structure.mdx index a5b56aa2..34cab753 100644 --- a/docs/sdk/v0.53/build/building-modules/structure.mdx +++ b/docs/sdk/v0.53/build/building-modules/structure.mdx @@ -81,7 +81,7 @@ x/{module_name} * `abci.go`: The module's `BeginBlocker` and `EndBlocker` implementations (this file is only required if `BeginBlocker` and/or `EndBlocker` need to be defined). * `autocli.go`: The module [autocli](https://docs.cosmos.network/main/core/autocli) options. * `simulation/`: The module's [simulation](/docs/sdk/v0.53/build/building-modules/simulator) package defines functions used by the blockchain simulator application (`simapp`). -* `REAMDE.md`: The module's specification documents outlining important concepts, state storage structure, and message and event type definitions. Learn more how to write module specs in the [spec guidelines](/docs/sdk/v0.50/spec/SPEC_MODULE). +* `REAMDE.md`: The module's specification documents outlining important concepts, state storage structure, and message and event type definitions. Learn more how to write module specs in the [spec guidelines](/docs/sdk/v0.50/build/spec/SPEC_MODULE). * The root directory includes type definitions for messages, events, and genesis state, including the type definitions generated by Protocol Buffers. * `codec.go`: The module's registry methods for interface types. * `errors.go`: The module's sentinel errors. diff --git a/docs/sdk/v0.53/build/migrations/intro.mdx b/docs/sdk/v0.53/build/migrations/intro.mdx index 0c7d8a5c..501af8cd 100644 --- a/docs/sdk/v0.53/build/migrations/intro.mdx +++ b/docs/sdk/v0.53/build/migrations/intro.mdx @@ -10,4 +10,4 @@ Additionally, the SDK includes in-place migrations for its core modules. These i Migration from a version older than the last two major releases is not supported. -When migrating from a previous version, refer to the [`UPGRADING.md`](/docs/sdk/v0.50/upgrading) and the `CHANGELOG.md` of the version you are migrating to. +When migrating from a previous version, refer to the [`UPGRADING.md`](/docs/sdk/v0.53/build/migrations/upgrading) and the `CHANGELOG.md` of the version you are migrating to. diff --git a/docs/sdk/v0.53/build/modules/authz/README.mdx b/docs/sdk/v0.53/build/modules/authz/README.mdx index ede07e01..d4edc222 100644 --- a/docs/sdk/v0.53/build/modules/authz/README.mdx +++ b/docs/sdk/v0.53/build/modules/authz/README.mdx @@ -36,7 +36,7 @@ on behalf of one account to other accounts. The design is defined in the [ADR 03 A *grant* is an allowance to execute a Msg by the grantee on behalf of the granter. Authorization is an interface that must be implemented by a concrete authorization logic to validate and execute grants. Authorizations are extensible and can be defined for any Msg service method even outside of the module where the Msg method is defined. See the `SendAuthorization` example in the next section for more details. -**Note:** The authz module is different from the [auth (authentication)](/docs/sdk/v0.53/modules/auth/) module that is responsible for specifying the base transaction and account types. +**Note:** The authz module is different from the [auth (authentication)](/docs/sdk/v0.53/build/modules/auth/auth/) module that is responsible for specifying the base transaction and account types. ```go expandable package authz diff --git a/docs/sdk/v0.53/build/modules/distribution/README.mdx b/docs/sdk/v0.53/build/modules/distribution/README.mdx index 0b35ae04..2f98aa90 100644 --- a/docs/sdk/v0.53/build/modules/distribution/README.mdx +++ b/docs/sdk/v0.53/build/modules/distribution/README.mdx @@ -150,7 +150,7 @@ error By default, the distribution module will use a community pool implementation that is internal. An external community pool can be provided to the module which will have funds be diverted to it instead of the internal implementation. The reference -external community pool maintained by the Cosmos SDK is [`x/protocolpool`](/docs/sdk/v0.53/protocolpool/README). +external community pool maintained by the Cosmos SDK is [`x/protocolpool`](/docs/sdk/v0.53/build/modules/protocolpool/README). ## State diff --git a/docs/sdk/v0.53/build/modules/evidence/README.mdx b/docs/sdk/v0.53/build/modules/evidence/README.mdx index a9abfc46..84926e04 100644 --- a/docs/sdk/v0.53/build/modules/evidence/README.mdx +++ b/docs/sdk/v0.53/build/modules/evidence/README.mdx @@ -269,7 +269,7 @@ The `Equivocation` evidence is handled as follows: **Note:** The slashing, jailing, and tombstoning calls are delegated through the `x/slashing` module that emits informative events and finally delegates calls to the `x/staking` module. See documentation -on slashing and jailing in [State Transitions](/docs/sdk/v0.53/staking/README#state-transitions). +on slashing and jailing in [State Transitions](/docs/sdk/v0.53/build/modules/staking/README#state-transitions). ## Client diff --git a/docs/sdk/v0.53/build/modules/gov/README.mdx b/docs/sdk/v0.53/build/modules/gov/README.mdx index b9b41f14..448fe1b4 100644 --- a/docs/sdk/v0.53/build/modules/gov/README.mdx +++ b/docs/sdk/v0.53/build/modules/gov/README.mdx @@ -2761,7 +2761,7 @@ The gov module has two locations for metadata where users can provide further co ### Proposal -Location: off-chain as json object stored on IPFS (mirrors [group proposal](/docs/sdk/v0.53/group/README#metadata)) +Location: off-chain as json object stored on IPFS (mirrors [group proposal](/docs/sdk/v0.53/build/modules/group/README#metadata)) ```json { @@ -2781,7 +2781,7 @@ In v0.46, the `authors` field is a comma-separated string. Frontends are encoura ### Vote -Location: on-chain as json within 255 character limit (mirrors [group vote](/docs/sdk/v0.53/group/README#metadata)) +Location: on-chain as json within 255 character limit (mirrors [group vote](/docs/sdk/v0.53/build/modules/group/README#metadata)) ```json { diff --git a/docs/sdk/v0.53/build/modules/group/README.mdx b/docs/sdk/v0.53/build/modules/group/README.mdx index 127907d5..16d35a61 100644 --- a/docs/sdk/v0.53/build/modules/group/README.mdx +++ b/docs/sdk/v0.53/build/modules/group/README.mdx @@ -2111,7 +2111,7 @@ The group module has four locations for metadata where users can provide further ### Proposal -Location: off-chain as json object stored on IPFS (mirrors [gov proposal](/docs/sdk/v0.53/gov/README#metadata)) +Location: off-chain as json object stored on IPFS (mirrors [gov proposal](/docs/sdk/v0.53/build/modules/gov/README#metadata)) ```json { @@ -2131,7 +2131,7 @@ In v0.46, the `authors` field is a comma-separated string. Frontends are encoura ### Vote -Location: on-chain as json within 255 character limit (mirrors [gov vote](/docs/sdk/v0.53/gov/README#metadata)) +Location: on-chain as json within 255 character limit (mirrors [gov vote](/docs/sdk/v0.53/build/modules/gov/README#metadata)) ```json { diff --git a/docs/sdk/v0.53/build/modules/slashing/README.mdx b/docs/sdk/v0.53/build/modules/slashing/README.mdx index c2baa9ec..bba37692 100644 --- a/docs/sdk/v0.53/build/modules/slashing/README.mdx +++ b/docs/sdk/v0.53/build/modules/slashing/README.mdx @@ -107,7 +107,7 @@ long as it contains precommits from +2/3 of total voting power. Proposers are incentivized to include precommits from all validators in the CometBFT `LastCommitInfo` by receiving additional fees proportional to the difference between the voting -power included in the `LastCommitInfo` and +2/3 (see [fee distribution](/docs/sdk/v0.47/distribution/README#begin-block)). +power included in the `LastCommitInfo` and +2/3 (see [fee distribution](/docs/sdk/v0.47/build/modules/distribution/README#begin-block)). ```go type LastCommitInfo struct { diff --git a/docs/sdk/v0.53/build/rfc/PROCESS.mdx b/docs/sdk/v0.53/build/rfc/PROCESS.mdx index 334b8388..c66d31e4 100644 --- a/docs/sdk/v0.53/build/rfc/PROCESS.mdx +++ b/docs/sdk/v0.53/build/rfc/PROCESS.mdx @@ -5,7 +5,7 @@ title: RFC Creation Process 1. Copy the `rfc-template.md` file. Use the following filename pattern: `rfc-next_number-title.md` 2. Create a draft Pull Request if you want to get an early feedback. 3. Make sure the context and a solution is clear and well documented. -4. Add an entry to a list in the [README](/docs/sdk/v0.50/README) file. +4. Add an entry to a list in the [README](/docs/sdk/v0.50/build/rfc/README) file. 5. Create a Pull Request to propose a new ADR. ## What is an RFC? diff --git a/docs/sdk/v0.53/build/rfc/README.mdx b/docs/sdk/v0.53/build/rfc/README.mdx index 66037852..99dac583 100644 --- a/docs/sdk/v0.53/build/rfc/README.mdx +++ b/docs/sdk/v0.53/build/rfc/README.mdx @@ -15,7 +15,7 @@ discussion that might otherwise only be recorded in an ad-hoc way (for example, via gists or Google docs) that are difficult to discover for someone after the fact. An RFC *may* give rise to more specific architectural *decisions* for the Cosmos SDK, but those decisions must be recorded separately in -[Architecture Decision Records (ADR)](/docs/sdk/v0.50/architecture). +[Architecture Decision Records (ADR)](/docs/sdk/v0.53/build/architecture/README). As a rule of thumb, if you can articulate a specific question that needs to be answered, write an ADR. If you need to explore the topic and get input from @@ -32,9 +32,9 @@ An RFC should provide: substance of the discussion (links to other documents are fine here). * The **discussion**, the primary content of the document. -The [rfc-template.md](/docs/sdk/v0.50/rfc-template) file includes placeholders for these +The [rfc-template.md](/docs/sdk/v0.50/build/rfc/rfc-template) file includes placeholders for these sections. ## Table of Contents -* [RFC-001: Tx Validation](/docs/sdk/v0.50/rfc-001-tx-validation) +* [RFC-001: Tx Validation](/docs/sdk/v0.50/build/rfc/rfc-001-tx-validation) diff --git a/docs/sdk/v0.53/build/spec/README.mdx b/docs/sdk/v0.53/build/spec/README.mdx index 2153b35e..7e2a6de9 100644 --- a/docs/sdk/v0.53/build/spec/README.mdx +++ b/docs/sdk/v0.53/build/spec/README.mdx @@ -13,8 +13,8 @@ block. ## Cosmos SDK specifications -* [Store](/docs/sdk/v0.50/store) - The core Merkle store that holds the state. -* [Bech32](/docs/sdk/v0.50/addresses/bech32) - Address format for Cosmos SDK applications. +* [Store](/docs/sdk/v0.50/learn/advanced/store) - The core Merkle store that holds the state. +* [Bech32](/docs/sdk/v0.50/build/spec/addresses/bech32) - Address format for Cosmos SDK applications. ## Modules specifications diff --git a/docs/sdk/v0.53/build/spec/_ics/README.mdx b/docs/sdk/v0.53/build/spec/_ics/README.mdx index a34f2312..cde957c4 100644 --- a/docs/sdk/v0.53/build/spec/_ics/README.mdx +++ b/docs/sdk/v0.53/build/spec/_ics/README.mdx @@ -3,4 +3,4 @@ title: Cosmos ICS description: ICS030 - Signed Messages --- -* [ICS030 - Signed Messages](/docs/sdk/v0.50/ics-030-signed-messages) +* [ICS030 - Signed Messages](/docs/sdk/v0.50/build/spec/_ics/ics-030-signed-messages) diff --git a/docs/sdk/v0.53/learn/advanced/baseapp.mdx b/docs/sdk/v0.53/learn/advanced/baseapp.mdx index f38b6b24..9fbb4946 100644 --- a/docs/sdk/v0.53/learn/advanced/baseapp.mdx +++ b/docs/sdk/v0.53/learn/advanced/baseapp.mdx @@ -11,7 +11,7 @@ This document describes `BaseApp`, the abstraction that implements the core func **Pre-requisite Readings** * [Anatomy of a Cosmos SDK application](/docs/sdk/v0.53/learn/beginner/app-anatomy) -* [Lifecycle of a Cosmos SDK transaction](/docs/sdk/v0.53/beginner/tx-lifecycle) +* [Lifecycle of a Cosmos SDK transaction](/docs/sdk/v0.53/learn/beginner/tx-lifecycle) @@ -1505,7 +1505,7 @@ Let us go through the most important components. First, the important parameters that are initialized during the bootstrapping of the application: -* [`CommitMultiStore`](/docs/sdk/v0.53/store#commitmultistore): This is the main store of the application, +* [`CommitMultiStore`](/docs/sdk/v0.53/learn/advanced/store#commitmultistore): This is the main store of the application, which holds the canonical state that is committed at the [end of each block](#commit). This store is **not** cached, meaning it is not used to update the application's volatile (un-committed) states. The `CommitMultiStore` is a multi-store, meaning a store of stores. Each module of the application @@ -1539,7 +1539,7 @@ Finally, a few more important parameters: * `voteInfos`: This parameter carries the list of validators whose precommit is missing, either because they did not vote or because the proposer did not include their vote. This information is - carried by the [Context](/docs/sdk/v0.53/context) and can be used by the application for various things like + carried by the [Context](/docs/sdk/v0.53/learn/advanced/context) and can be used by the application for various things like punishing absent validators. * `minGasPrices`: This parameter defines the minimum gas prices accepted by the node. This is a **local** parameter, meaning each full-node can set a different `minGasPrices`. It is used in the @@ -1665,13 +1665,13 @@ When messages and queries are received by the application, they must be routed t The [default `msgServiceRouter` included in `BaseApp`](https://github.com/cosmos/cosmos-sdk/blob/v0.53.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.53.0/baseapp/msg_service_router.go#L35-L36). 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](/docs/sdk/v0.53//build/building-modules/module-manager#manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.53/learn/beginner/app-anatomy#constructor-function). +The application's `msgServiceRouter` is initialized with all the routes using the application's [module manager](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.53/learn/beginner/app-anatomy#constructor-function). ### gRPC Query Router Similar to `sdk.Msg`s, [`queries`](/docs/sdk/v0.53//build/building-modules/messages-and-queries#queries) need to be routed to the appropriate module's [`Query` service](/docs/sdk/v0.53//build/building-modules/query-services). To do so, `BaseApp` holds a `grpcQueryRouter`, which maps modules' fully-qualified service methods (`string`, defined in their Protobuf `Query` gRPC) to their `QueryServer` implementation. The `grpcQueryRouter` is called during the initial stages of query processing, which can be either by directly sending a gRPC query to the gRPC endpoint, or via the [`Query` ABCI message](#query) on the CometBFT RPC endpoint. -Just like the `msgServiceRouter`, the `grpcQueryRouter` is initialized with all the query routes using the application's [module manager](/docs/sdk/v0.53//build/building-modules/module-manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.53/learn/beginner/app-anatomy#app-constructor). +Just like the `msgServiceRouter`, the `grpcQueryRouter` is initialized with all the query routes using the application's [module manager](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.53/learn/beginner/app-anatomy#app-constructor). ## Main ABCI 2.0 Messages @@ -1751,7 +1751,7 @@ Unconfirmed transactions are relayed to peers only if they pass `CheckTx`. `CheckTx()` can perform both *stateful* and *stateless* checks, but developers should strive to make the checks **lightweight** because gas fees are not charged for the resources (CPU, data load...) used during the `CheckTx`. -In the Cosmos SDK, after [decoding transactions](/docs/sdk/v0.53/encoding), `CheckTx()` is implemented +In the Cosmos SDK, after [decoding transactions](/docs/sdk/v0.53/learn/advanced/encoding), `CheckTx()` is implemented to do the following checks: 1. Extract the `sdk.Msg`s from the transaction. @@ -1759,16 +1759,16 @@ to do the following checks: first, as *stateless* checks are less computationally expensive than *stateful* checks. If `ValidateBasic()` fail, `CheckTx` returns before running *stateful* checks, which saves resources. This check is still performed for messages that have not yet migrated to the new message validation mechanism defined in [RFC 001](https://docs.cosmos.network/main/rfc/rfc-001-tx-validation) and still have a `ValidateBasic()` method. -3. Perform non-module related *stateful* checks on the [account](/docs/sdk/v0.53/beginner/accounts). This step is mainly about checking +3. Perform non-module related *stateful* checks on the [account](/docs/sdk/v0.53/learn/beginner/accounts). This step is mainly about checking that the `sdk.Msg` signatures are valid, that enough fees are provided and that the sending account - has enough funds to pay for said fees. Note that no precise [`gas`](/docs/sdk/v0.53/beginner/gas-fees) counting occurs here, - as `sdk.Msg`s are not processed. Usually, the [`AnteHandler`](/docs/sdk/v0.53/beginner/gas-fees#antehandler) will check that the `gas` provided + has enough funds to pay for said fees. Note that no precise [`gas`](/docs/sdk/v0.53/learn/beginner/gas-fees) counting occurs here, + as `sdk.Msg`s are not processed. Usually, the [`AnteHandler`](/docs/sdk/v0.53/learn/beginner/gas-fees#antehandler) will check that the `gas` provided with the transaction is superior to a minimum reference gas amount based on the raw transaction size, in order to avoid spam with transactions that provide 0 gas. `CheckTx` does **not** process `sdk.Msg`s - they only need to be processed when the canonical state needs to be updated, which happens during `FinalizeBlock`. -Steps 2. and 3. are performed by the [`AnteHandler`](/docs/sdk/v0.53/beginner/gas-fees#antehandler) in the [`RunTx()`](#runtx-antehandler-and-runmsgs) +Steps 2. and 3. are performed by the [`AnteHandler`](/docs/sdk/v0.53/learn/beginner/gas-fees#antehandler) in the [`RunTx()`](#runtx-antehandler-and-runmsgs) function, which `CheckTx()` calls with the `runTxModeCheck` mode. During each step of `CheckTx()`, a special [volatile state](#state-updates) called `checkState` is updated. This state is used to keep track of the temporary changes triggered by the `CheckTx()` calls of each transaction without modifying @@ -2047,7 +2047,7 @@ return next(ctx, tx, simulate) } ``` -* `Events ([]cmn.KVPair)`: Key-Value tags for filtering and indexing transactions (eg. by account). See [`event`s](/docs/sdk/v0.53/events) for more. +* `Events ([]cmn.KVPair)`: Key-Value tags for filtering and indexing transactions (eg. by account). See [`event`s](/docs/sdk/v0.53/learn/advanced/events) for more. * `Codespace (string)`: Namespace for the Code. #### RecheckTx @@ -2065,7 +2065,7 @@ This allows certain checks like signature verification can be skipped during `Ch `RunTx` is called from `CheckTx`/`Finalizeblock` to handle the transaction, with `execModeCheck` or `execModeFinalize` as parameter to differentiate between the two modes of execution. Note that when `RunTx` receives a transaction, it has already been decoded. -The first thing `RunTx` does upon being called is to retrieve the `context`'s `CacheMultiStore` by calling the `getContextForTx()` function with the appropriate mode (either `runTxModeCheck` or `execModeFinalize`). This `CacheMultiStore` is a branch of the main store, with cache functionality (for query requests), instantiated during `FinalizeBlock` for transaction execution and during the `Commit` of the previous block for `CheckTx`. After that, two `defer func()` are called for [`gas`](/docs/sdk/v0.53/beginner/gas-fees) management. They are executed when `runTx` returns and make sure `gas` is actually consumed, and will throw errors, if any. +The first thing `RunTx` does upon being called is to retrieve the `context`'s `CacheMultiStore` by calling the `getContextForTx()` function with the appropriate mode (either `runTxModeCheck` or `execModeFinalize`). This `CacheMultiStore` is a branch of the main store, with cache functionality (for query requests), instantiated during `FinalizeBlock` for transaction execution and during the `Commit` of the previous block for `CheckTx`. After that, two `defer func()` are called for [`gas`](/docs/sdk/v0.53/learn/beginner/gas-fees) management. They are executed when `runTx` returns and make sure `gas` is actually consumed, and will throw errors, if any. After that, `RunTx()` calls `ValidateBasic()`, when available and for backward compatibility, on each `sdk.Msg`in the `Tx`, which runs preliminary *stateless* validity checks. If any `sdk.Msg` fails to pass `ValidateBasic()`, `RunTx()` returns with an error. @@ -3520,7 +3520,7 @@ GetBaseApp() *BaseApp { } ``` -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](/docs/sdk/v0.53/ocap) of the Cosmos SDK. +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](/docs/sdk/v0.53/learn/advanced/ocap) of the Cosmos SDK. Finally, the [`RunMsgs()`](#runmsgs) function is called to process the `sdk.Msg`s in the `Tx`. In preparation of this step, just like with the `anteHandler`, both the `checkState`/`finalizeBlockState`'s `context` and `context`'s `CacheMultiStore` are branched using the `cacheTxContext()` function. @@ -3661,13 +3661,13 @@ PostHandle(ctx Context, _ Tx, _, _ bool, _ PostHandler) (Context, error) { The `AnteHandler` is theoretically optional, but still a very important component of public blockchain networks. It serves 3 primary purposes: -* Be a primary line of defense against spam and second line of defense (the first one being the mempool) against transaction replay with fees deduction and [`sequence`](/docs/sdk/v0.53/transactions#transaction-generation) checking. +* Be a primary line of defense against spam and second line of defense (the first one being the mempool) against transaction replay with fees deduction and [`sequence`](/docs/sdk/v0.53/learn/advanced/transactions#transaction-generation) checking. * 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](/docs/sdk/v0.53/learn/beginner/app-anatomy#application-constructor). The most widely used `anteHandler` is the [`auth` module](https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/x/auth/ante/ante.go). -Click [here](/docs/sdk/v0.53/beginner/gas-fees#antehandler) for more on the `anteHandler`. +Click [here](/docs/sdk/v0.53/learn/beginner/gas-fees#antehandler) for more on the `anteHandler`. ### RunMsgs @@ -3714,7 +3714,7 @@ The [`InitChain` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x * [Consensus Parameters](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_app_requirements.md#consensus-parameters) via `setConsensusParams`. * [`checkState` and `finalizeBlockState`](#state-updates) via `setState`. -* The [block gas meter](/docs/sdk/v0.53/beginner/gas-fees#block-gas-meter), with infinite gas to process genesis transactions. +* The [block gas meter](/docs/sdk/v0.53/learn/beginner/gas-fees#block-gas-meter), with infinite gas to process genesis transactions. Finally, the `InitChain(req abci.RequestInitChain)` method of `BaseApp` calls the [`initChainer()`](/docs/sdk/v0.53/learn/beginner/app-anatomy#initchainer) of the application in order to initialize the main state of the application from the `genesis file` and, if defined, call the [`InitGenesis`](/docs/sdk/v0.53//build/building-modules/genesis#initgenesis) function of each of the application's modules. @@ -6734,13 +6734,13 @@ return legacyVotes } ``` - This function also resets the [main gas meter](/docs/sdk/v0.53/beginner/gas-fees#main-gas-meter). + This function also resets the [main gas meter](/docs/sdk/v0.53/learn/beginner/gas-fees#main-gas-meter). -* Initialize the [block gas meter](/docs/sdk/v0.53/beginner/gas-fees#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. +* Initialize the [block gas meter](/docs/sdk/v0.53/learn/beginner/gas-fees#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()`](/docs/sdk/v0.53/learn/beginner/app-anatomy#beginblocker-and-endblocker), which mainly runs the [`BeginBlocker()`](/docs/sdk/v0.53//build/building-modules/beginblock-endblock#beginblock) method of each of the modules. -* Set the [`VoteInfos`](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_methods.md#voteinfo) of the application, i.e. the list of validators whose *precommit* for the previous block was included by the proposer of the current block. This information is carried into the [`Context`](/docs/sdk/v0.53/context) so that it can be used during transaction execution and EndBlock. +* Set the [`VoteInfos`](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_methods.md#voteinfo) of the application, i.e. the list of validators whose *precommit* for the previous block was included by the proposer of the current block. This information is carried into the [`Context`](/docs/sdk/v0.53/learn/advanced/context) so that it can be used during transaction execution and EndBlock. #### Transaction Execution @@ -8572,7 +8572,7 @@ Each transactions returns a response to the underlying consensus engine of type * `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 transaction execution, this value is computed by multiplying the standard cost of a transaction byte by the size of the raw transaction, and by adding gas each time a read/write to the store occurs. -* `Events ([]cmn.KVPair)`: Key-Value tags for filtering and indexing transactions (eg. by account). See [`event`s](/docs/sdk/v0.53/events) for more. +* `Events ([]cmn.KVPair)`: Key-Value tags for filtering and indexing transactions (eg. by account). See [`event`s](/docs/sdk/v0.53/learn/advanced/events) for more. * `Codespace (string)`: Namespace for the Code. #### EndBlock diff --git a/docs/sdk/v0.53/learn/advanced/cli.mdx b/docs/sdk/v0.53/learn/advanced/cli.mdx index 20e8a58f..ee018881 100644 --- a/docs/sdk/v0.53/learn/advanced/cli.mdx +++ b/docs/sdk/v0.53/learn/advanced/cli.mdx @@ -36,7 +36,7 @@ The `main.go` file needs to have a `main()` function that creates a root command * **setting configurations** by reading in configuration files (e.g. the Cosmos SDK config file). * **adding any flags** to it, such as `--chain-id`. -* **instantiating the `codec`** by injecting the application codecs. The [`codec`](/docs/sdk/v0.53/encoding) is used to encode and decode data structures for the application - stores can only persist `[]byte`s so the developer must define a serialization format for their data structures or use the default, Protobuf. +* **instantiating the `codec`** by injecting the application codecs. The [`codec`](/docs/sdk/v0.53/learn/advanced/encoding) is used to encode and decode data structures for the application - stores can only persist `[]byte`s so the developer must define a serialization format for their data structures or use the default, Protobuf. * **adding subcommand** for all the possible user interactions, including [transaction commands](#transaction-commands) and [query commands](#query-commands). 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: @@ -113,7 +113,7 @@ The root-level `status` and `keys` subcommands are common across most applicatio ### Transaction Commands -[Transactions](/docs/sdk/v0.53/transactions) are objects wrapping [`Msg`s](/docs/sdk/v0.53//build/building-modules/messages-and-queries#messages) that trigger state changes. To enable the creation of transactions using the CLI interface, a function `txCommand` is generally added to the `rootCmd`: +[Transactions](/docs/sdk/v0.53/learn/advanced/transactions) are objects wrapping [`Msg`s](/docs/sdk/v0.53//build/building-modules/messages-and-queries#messages) that trigger state changes. To enable the creation of transactions using the CLI interface, a function `txCommand` is generally added to the `rootCmd`: ```go // Reference: https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/simapp/simd/cmd/root_v2.go#L222-L229 @@ -123,7 +123,7 @@ This `txCommand` function adds all the transaction available to end-users for th * **Sign command** from the [`auth`](/docs/sdk/v0.53//build/modules/auth/README) module that signs messages in a transaction. To enable multisig, add the `auth` module's `MultiSign` command. Since every transaction requires some sort of signature in order to be valid, the signing command is necessary for every application. * **Broadcast command** from the Cosmos SDK client tools, to broadcast transactions. -* **All [module transaction commands](/docs/sdk/v0.53//build/building-modules/module-interfaces#transaction-commands)** the application is dependent on, retrieved by using the [basic module manager's](/docs/sdk/v0.53//build/building-modules/module-manager#basic-manager) `AddTxCommands()` function, or enhanced by [AutoCLI](https://docs.cosmos.network/main/core/autocli). +* **All [module transaction commands](/docs/sdk/v0.53//build/building-modules/module-interfaces#transaction-commands)** the application is dependent on, retrieved by using the [basic module manager's](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#basic-manager) `AddTxCommands()` function, or enhanced by [AutoCLI](https://docs.cosmos.network/main/core/autocli). Here is an example of a `txCommand` aggregating these subcommands from the `simapp` application: @@ -150,7 +150,7 @@ This `queryCommand` function adds all the queries available to end-users for the * **Account command** from the `auth` module, which displays the state (e.g. account balance) of an account given an address. * **Validator command** from the Cosmos SDK rpc client tools, which displays the validator set of a given height. * **Block command** from the Cosmos SDK RPC client tools, which displays the block data for a given height. -* **All [module query commands](/docs/sdk/v0.53//build/building-modules/module-interfaces#query-commands)** the application is dependent on, retrieved by using the [basic module manager's](/docs/sdk/v0.53//build/building-modules/module-manager#basic-manager) `AddQueryCommands()` function, or enhanced by [AutoCLI](https://docs.cosmos.network/main/core/autocli). +* **All [module query commands](/docs/sdk/v0.53//build/building-modules/module-interfaces#query-commands)** the application is dependent on, retrieved by using the [basic module manager's](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#basic-manager) `AddQueryCommands()` function, or enhanced by [AutoCLI](https://docs.cosmos.network/main/core/autocli). Here is an example of a `queryCommand` aggregating subcommands from the `simapp` application: diff --git a/docs/sdk/v0.53/learn/advanced/context.mdx b/docs/sdk/v0.53/learn/advanced/context.mdx index f2a61a8a..2b27ba73 100644 --- a/docs/sdk/v0.53/learn/advanced/context.mdx +++ b/docs/sdk/v0.53/learn/advanced/context.mdx @@ -17,7 +17,7 @@ The `context` is a data structure intended to be passed from function to functio ## Context Definition -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](/docs/sdk/v0.53/store#base-layer-kvstores) in the [`multistore`](/docs/sdk/v0.53/store#multistore) and retrieve transactional context such as the block header and gas meter. +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](/docs/sdk/v0.53/learn/advanced/store#base-layer-kvstores) in the [`multistore`](/docs/sdk/v0.53/learn/advanced/store#multistore) and retrieve transactional context such as the block header and gas meter. ```go expandable package types @@ -741,18 +741,18 @@ return ctx.Value(SdkContextKey).(Context) ``` * **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`](/docs/sdk/v0.53/store#multistore) which is provided when a `Context` is created. Calling the `KVStore()` and `TransientStore()` methods allows modules to fetch their respective [`KVStore`](/docs/sdk/v0.53/store#base-layer-kvstores) using their unique `StoreKey`. +* **Multistore:** Every application's `BaseApp` contains a [`CommitMultiStore`](/docs/sdk/v0.53/learn/advanced/store#multistore) which is provided when a `Context` is created. Calling the `KVStore()` and `TransientStore()` methods allows modules to fetch their respective [`KVStore`](/docs/sdk/v0.53/learn/advanced/store#base-layer-kvstores) using their unique `StoreKey`. * **Header:** The [header](https://docs.cometbft.com/v0.37/spec/core/data_structures#header) is a Blockchain type. It carries important information about the state of the blockchain, such as block height and proposer of the current block. * **Header Hash:** The current block header hash, obtained during `abci.FinalizeBlock`. * **Chain ID:** The unique identification number of the blockchain a block pertains to. -* **Transaction Bytes:** The `[]byte` representation of a transaction being processed using the context. Every transaction is processed by various parts of the Cosmos SDK and consensus engine (e.g. CometBFT) throughout its [lifecycle](/docs/sdk/v0.53/beginner/tx-lifecycle), some of which do not have any understanding of transaction types. Thus, transactions are marshaled into the generic `[]byte` type using some kind of [encoding format](/docs/sdk/v0.53/encoding) such as [Amino](/docs/sdk/v0.53/encoding). +* **Transaction Bytes:** The `[]byte` representation of a transaction being processed using the context. Every transaction is processed by various parts of the Cosmos SDK and consensus engine (e.g. CometBFT) throughout its [lifecycle](/docs/sdk/v0.53/learn/beginner/tx-lifecycle), some of which do not have any understanding of transaction types. Thus, transactions are marshaled into the generic `[]byte` type using some kind of [encoding format](/docs/sdk/v0.53/learn/advanced/encoding) such as [Amino](/docs/sdk/v0.53/learn/advanced/encoding). * **Logger:** A `logger` from the CometBFT libraries. Learn more about logs [here](https://docs.cometbft.com/v0.37/core/configuration). Modules call this method to create their own unique module-specific logger. * **VoteInfo:** A list of the ABCI type [`VoteInfo`](https://docs.cometbft.com/master/spec/abci/abci.html#voteinfo), which includes the name of a validator and a boolean indicating whether they have signed the block. -* **Gas Meters:** Specifically, a [`gasMeter`](/docs/sdk/v0.53/beginner/gas-fees#main-gas-meter) for the transaction currently being processed using the context and a [`blockGasMeter`](/docs/sdk/v0.53/beginner/gas-fees#block-gas-meter) for the entire block it belongs to. Users specify how much in fees they wish to pay for the execution of their transaction; these gas meters keep track of how much [gas](/docs/sdk/v0.53/beginner/gas-fees) has been used in the transaction or block so far. If the gas meter runs out, execution halts. +* **Gas Meters:** Specifically, a [`gasMeter`](/docs/sdk/v0.53/learn/beginner/gas-fees#main-gas-meter) for the transaction currently being processed using the context and a [`blockGasMeter`](/docs/sdk/v0.53/learn/beginner/gas-fees#block-gas-meter) for the entire block it belongs to. Users specify how much in fees they wish to pay for the execution of their transaction; these gas meters keep track of how much [gas](/docs/sdk/v0.53/learn/beginner/gas-fees) has been used in the transaction or block so far. If the gas meter runs out, execution halts. * **CheckTx Mode:** A boolean value indicating whether a transaction should be processed in `CheckTx` or `DeliverTx` mode. -* **Min Gas Price:** The minimum [gas](/docs/sdk/v0.53/beginner/gas-fees) price a node is willing to take in order to include a transaction in its block. This price is a local value configured by each node individually, and should therefore **not be used in any functions used in sequences leading to state-transitions**. +* **Min Gas Price:** The minimum [gas](/docs/sdk/v0.53/learn/beginner/gas-fees) price a node is willing to take in order to include a transaction in its block. This price is a local value configured by each node individually, and should therefore **not be used in any functions used in sequences leading to state-transitions**. * **Consensus Params:** The ABCI type [Consensus Parameters](https://docs.cometbft.com/master/spec/abci/apps.html#consensus-parameters), which specify certain limits for the blockchain, such as maximum gas for a block. -* **Event Manager:** The event manager allows any caller with access to a `Context` to emit [`Events`](/docs/sdk/v0.53/events). Modules may define module specific +* **Event Manager:** The event manager allows any caller with access to a `Context` to emit [`Events`](/docs/sdk/v0.53/learn/advanced/events). Modules may define module specific `Events` by defining various `Types` and `Attributes` or use the common definitions found in `types/`. Clients can subscribe or query for these `Events`. These `Events` are collected throughout `FinalizeBlock` and are returned to CometBFT for indexing. * **Priority:** The transaction priority, only relevant in `CheckTx`. * **KV `GasConfig`:** Enables applications to set a custom `GasConfig` for the `KVStore`. @@ -788,7 +788,7 @@ goes wrong. The pattern of usage for a Context is as follows: 1. A process receives a Context `ctx` from its parent process, which provides information needed to perform the process. -2. The `ctx.ms` is a **branched store**, i.e. a branch of the [multistore](/docs/sdk/v0.53/store#multistore) is made so that the process can make changes to the state as it executes, without changing the original`ctx.ms`. This is useful to protect the underlying multistore in case the changes need to be reverted at some point in the execution. +2. The `ctx.ms` is a **branched store**, i.e. a branch of the [multistore](/docs/sdk/v0.53/learn/advanced/store#multistore) is made so that the process can make changes to the state as it executes, without changing the original`ctx.ms`. This is useful to protect the underlying multistore in case the changes need to be reverted at some point in the execution. 3. The process may read and write from `ctx` as it is executing. It may call a subprocess and pass `ctx` to it as needed. 4. When a subprocess returns, it checks if the result is a success or failure. If a failure, nothing diff --git a/docs/sdk/v0.53/learn/advanced/encoding.mdx b/docs/sdk/v0.53/learn/advanced/encoding.mdx index 65d19fe8..0b630aaa 100644 --- a/docs/sdk/v0.53/learn/advanced/encoding.mdx +++ b/docs/sdk/v0.53/learn/advanced/encoding.mdx @@ -69,7 +69,7 @@ Code generators can then match the `accepts_interface` and `implements_interface ### Transaction Encoding Another important use of Protobuf is the encoding and decoding of -[transactions](/docs/sdk/v0.53/transactions). Transactions are defined by the application or +[transactions](/docs/sdk/v0.53/learn/advanced/transactions). Transactions are defined by the application or the Cosmos SDK but are then passed to the underlying consensus engine to be relayed to other peers. Since the underlying consensus engine is agnostic to the application, the consensus engine accepts only transactions in the form of raw bytes. @@ -489,7 +489,7 @@ See [ADR-020](https://github.com/cosmos/cosmos-sdk/blob/release/v0.53.x/docs/arc ### Interface Encoding and Usage of `Any` -The Protobuf DSL is strongly typed, which can make inserting variable-typed fields difficult. Imagine we want to create a `Profile` protobuf message that serves as a wrapper over [an account](/docs/sdk/v0.53/beginner/accounts): +The Protobuf DSL is strongly typed, which can make inserting variable-typed fields difficult. Imagine we want to create a `Profile` protobuf message that serves as a wrapper over [an account](/docs/sdk/v0.53/learn/beginner/accounts): ```protobuf message Profile { diff --git a/docs/sdk/v0.53/learn/advanced/events.mdx b/docs/sdk/v0.53/learn/advanced/events.mdx index 1c4f6f43..1f3bb986 100644 --- a/docs/sdk/v0.53/learn/advanced/events.mdx +++ b/docs/sdk/v0.53/learn/advanced/events.mdx @@ -952,7 +952,7 @@ return updatedEvents Module developers should handle Event emission via the `EventManager#EmitTypedEvent` or `EventManager#EmitEvent` in each message `Handler` and in each `BeginBlock`/`EndBlock` handler. The `EventManager` is accessed via -the [`Context`](/docs/sdk/v0.53/context), where Event should be already registered, and emitted like this: +the [`Context`](/docs/sdk/v0.53/learn/advanced/context), where Event should be already registered, and emitted like this: **Typed events:** @@ -2273,7 +2273,7 @@ ctx.EventManager().EmitEvent( ) ``` -Where the `EventManager` is accessed via the [`Context`](/docs/sdk/v0.53/context). +Where the `EventManager` is accessed via the [`Context`](/docs/sdk/v0.53/learn/advanced/context). See the [`Msg` services](/docs/sdk/v0.53//build/building-modules/msg-services) concept doc for a more detailed view on how to typically implement Events and use the `EventManager` in modules. @@ -2317,7 +2317,7 @@ Subscribing to this Event would be done like so: } ``` -where `ownerAddress` is an address following the [`AccAddress`](/docs/sdk/v0.53/beginner/accounts#addresses) format. +where `ownerAddress` is an address following the [`AccAddress`](/docs/sdk/v0.53/learn/beginner/accounts#addresses) format. The same way can be used to subscribe to [legacy events](https://github.com/cosmos/cosmos-sdk/blob/v0.53.0-rc.2/x/bank/types/events.go). diff --git a/docs/sdk/v0.53/learn/advanced/grpc_rest.mdx b/docs/sdk/v0.53/learn/advanced/grpc_rest.mdx index 666b585a..e1cd0b8b 100644 --- a/docs/sdk/v0.53/learn/advanced/grpc_rest.mdx +++ b/docs/sdk/v0.53/learn/advanced/grpc_rest.mdx @@ -25,7 +25,7 @@ All endpoints are defaulted to localhost and must be modified to be exposed to t ## gRPC Server -In the Cosmos SDK, Protobuf is the main [encoding](/docs/sdk/v0.53/encoding) library. This brings a wide range of Protobuf-based tools that can be plugged into the Cosmos SDK. One such tool is [gRPC](https://grpc.io), a modern open-source high performance RPC framework that has decent client support in several languages. +In the Cosmos SDK, Protobuf is the main [encoding](/docs/sdk/v0.53/learn/advanced/encoding) library. This brings a wide range of Protobuf-based tools that can be plugged into the Cosmos SDK. One such tool is [gRPC](https://grpc.io), a modern open-source high performance RPC framework that has decent client support in several languages. Each module exposes a [Protobuf `Query` service](/docs/sdk/v0.53//build/building-modules/messages-and-queries#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: @@ -200,7 +200,7 @@ Some CometBFT RPC endpoints are directly related to the Cosmos SDK: * `/store/{storeName}/subspace`: this will directly query the named store for key/value pairs in which the key has the value of the `data` parameter as a prefix. * `/p2p/filter/addr/{port}`: this will return a filtered list of the node's P2P peers by address port. * `/p2p/filter/id/{id}`: this will return a filtered list of the node's P2P peers by ID. -* `/broadcast_tx_{sync,async,commit}`: these 3 endpoints will broadcast a transaction to other peers. CLI, gRPC and REST expose [a way to broadcast transactions](/docs/sdk/v0.53/transactions#broadcasting-the-transaction), but they all use these 3 CometBFT RPCs under the hood. +* `/broadcast_tx_{sync,async,commit}`: these 3 endpoints will broadcast a transaction to other peers. CLI, gRPC and REST expose [a way to broadcast transactions](/docs/sdk/v0.53/learn/advanced/transactions#broadcasting-the-transaction), but they all use these 3 CometBFT RPCs under the hood. ## Comparison Table diff --git a/docs/sdk/v0.53/learn/advanced/node.mdx b/docs/sdk/v0.53/learn/advanced/node.mdx index 7dcdd491..7b2d4cec 100644 --- a/docs/sdk/v0.53/learn/advanced/node.mdx +++ b/docs/sdk/v0.53/learn/advanced/node.mdx @@ -20,8 +20,8 @@ The full-node client of any Cosmos SDK application is built by running a `main` In general, developers will implement the `main.go` function with the following structure: -* First, an [`encodingCodec`](/docs/sdk/v0.53/encoding) is instantiated for the application. -* Then, the `config` is retrieved and config parameters are set. This mainly involves setting the Bech32 prefixes for [addresses](/docs/sdk/v0.53/beginner/accounts#addresses). +* First, an [`encodingCodec`](/docs/sdk/v0.53/learn/advanced/encoding) is instantiated for the application. +* Then, the `config` is retrieved and config parameters are set. This mainly involves setting the Bech32 prefixes for [addresses](/docs/sdk/v0.53/learn/beginner/accounts#addresses). ```go expandable package types diff --git a/docs/sdk/v0.53/learn/advanced/store.mdx b/docs/sdk/v0.53/learn/advanced/store.mdx index 27ef4580..29b99835 100644 --- a/docs/sdk/v0.53/learn/advanced/store.mdx +++ b/docs/sdk/v0.53/learn/advanced/store.mdx @@ -1418,7 +1418,7 @@ return keys } ``` -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](/docs/sdk/v0.53/context#Store-branching) +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](/docs/sdk/v0.53/learn/advanced/context#Store-branching) ### Commit Store @@ -2780,7 +2780,7 @@ return keys } ``` -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](/docs/sdk/v0.53/ocap) 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`. +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](/docs/sdk/v0.53/learn/advanced/ocap) 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`. The Cosmos SDK comes with many types of stores, the most used being [`CommitMultiStore`](#multistore), [`KVStore`](#kvstore) and [`GasKv` store](#gaskv-store). [Other types of stores](#other-stores) include `Transient` and `TraceKV` stores. @@ -8105,7 +8105,7 @@ string { } ``` -Transient stores are typically accessed via the [`context`](/docs/sdk/v0.53/context) via the `TransientStore()` method: +Transient stores are typically accessed via the [`context`](/docs/sdk/v0.53/learn/advanced/context) via the `TransientStore()` method: ```go expandable package types @@ -9373,7 +9373,7 @@ This is the type used whenever an IAVL Store needs to be branched to create an i ### `GasKv` Store -Cosmos SDK applications use [`gas`](/docs/sdk/v0.53/beginner/gas-fees) to track resources usage and prevent spam. [`GasKv.Store`](https://github.com/cosmos/cosmos-sdk/blob/v0.53.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. +Cosmos SDK applications use [`gas`](/docs/sdk/v0.53/learn/beginner/gas-fees) to track resources usage and prevent spam. [`GasKv.Store`](https://github.com/cosmos/cosmos-sdk/blob/v0.53.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. ```go expandable package gaskv @@ -9989,7 +9989,7 @@ GasConfig { } ``` -By default, all `KVStores` are wrapped in `GasKv.Stores` when retrieved. This is done in the `KVStore()` method of the [`context`](/docs/sdk/v0.53/context): +By default, all `KVStores` are wrapped in `GasKv.Stores` when retrieved. This is done in the `KVStore()` method of the [`context`](/docs/sdk/v0.53/learn/advanced/context): ```go expandable package types diff --git a/docs/sdk/v0.53/learn/advanced/transactions.mdx b/docs/sdk/v0.53/learn/advanced/transactions.mdx index ec4912ac..8b67267d 100644 --- a/docs/sdk/v0.53/learn/advanced/transactions.mdx +++ b/docs/sdk/v0.53/learn/advanced/transactions.mdx @@ -16,9 +16,9 @@ title: Transactions ## Transactions -Transactions are comprised of metadata held in [contexts](/docs/sdk/v0.53/context) and [`sdk.Msg`s](/docs/sdk/v0.53//build/building-modules/messages-and-queries) that trigger state changes within a module through the module's Protobuf [`Msg` service](/docs/sdk/v0.53//build/building-modules/msg-services). +Transactions are comprised of metadata held in [contexts](/docs/sdk/v0.53/learn/advanced/context) and [`sdk.Msg`s](/docs/sdk/v0.53//build/building-modules/messages-and-queries) that trigger state changes within a module through the module's Protobuf [`Msg` service](/docs/sdk/v0.53//build/building-modules/msg-services). -When users want to interact with an application and make state changes (e.g. sending coins), they create transactions. Each of a transaction's `sdk.Msg` must be signed using the private key associated with the appropriate account(s), before the transaction is broadcasted to the network. A transaction must then be included in a block, validated, and approved by the network through the consensus process. To read more about the lifecycle of a transaction, click [here](/docs/sdk/v0.53/beginner/tx-lifecycle). +When users want to interact with an application and make state changes (e.g. sending coins), they create transactions. Each of a transaction's `sdk.Msg` must be signed using the private key associated with the appropriate account(s), before the transaction is broadcasted to the network. A transaction must then be included in a block, validated, and approved by the network through the consensus process. To read more about the lifecycle of a transaction, click [here](/docs/sdk/v0.53/learn/beginner/tx-lifecycle). ## Type Definition diff --git a/docs/sdk/v0.53/learn/beginner/app-anatomy.mdx b/docs/sdk/v0.53/learn/beginner/app-anatomy.mdx index 24341e1b..9aeaebaa 100644 --- a/docs/sdk/v0.53/learn/beginner/app-anatomy.mdx +++ b/docs/sdk/v0.53/learn/beginner/app-anatomy.mdx @@ -51,7 +51,7 @@ The first thing defined in `app.go` is the `type` of the application. It is gene * **Embeding [runtime.App](/docs/sdk/v0.53//build/building-apps/runtime)** The runtime package manages the application's core components and modules through dependency injection. It provides declarative configuration for module management, state storage, and ABCI handling. * `Runtime` wraps `BaseApp`, meaning when a transaction is relayed by CometBFT to the application, `app` uses `runtime`'s methods to route them to the appropriate module. `BaseApp` implements all the [ABCI methods](https://docs.cometbft.com/v0.38/spec/abci/) and the [routing logic](/docs/sdk/v0.53/learn/advanced/baseapp#service-routers). - * It automatically configures the **[module manager](/docs/sdk/v0.53//build/building-modules/module-manager#manager)** based on the app wiring configuration. The module manager facilitates operations related to these modules, like registering their [`Msg` service](/docs/sdk/v0.53//build/building-modules/msg-services) and [gRPC `Query` service](#grpc-query-services), or setting the order of execution between modules for various functions like [`InitChainer`](#initchainer), [`PreBlocker`](#preblocker) and [`BeginBlocker` and `EndBlocker`](#beginblocker-and-endblocker). + * It automatically configures the **[module manager](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#manager)** based on the app wiring configuration. The module manager facilitates operations related to these modules, like registering their [`Msg` service](/docs/sdk/v0.53//build/building-modules/msg-services) and [gRPC `Query` service](#grpc-query-services), or setting the order of execution between modules for various functions like [`InitChainer`](#initchainer), [`PreBlocker`](#preblocker) and [`BeginBlocker` and `EndBlocker`](#beginblocker-and-endblocker). * [**An App Wiring configuration file**](/docs/sdk/v0.53//build/building-apps/runtime) The app wiring configuration file contains the list of application's modules that `runtime` must instantiate. The instantiation of the modules are done using `depinject`. It also contains the order in which all module's `InitGenesis` and `Pre/Begin/EndBlocker` methods should be executed. * **A reference to an [`appCodec`](/docs/sdk/v0.53/learn/advanced/encoding).** The application's `appCodec` is used to serialize and deserialize data structures in order to store them, as stores can only persist `[]bytes`. The default codec is [Protocol Buffers](/docs/sdk/v0.53/learn/advanced/encoding). * **A reference to a [`legacyAmino`](/docs/sdk/v0.53/learn/advanced/encoding) codec.** Some parts of the Cosmos SDK have not been migrated to use the `appCodec` above, and are still hardcoded to use Amino. Other parts explicitly use Amino for backwards compatibility. For these reasons, the application still holds a reference to the legacy Amino codec. Please note that the Amino codec will be removed from the SDK in the upcoming releases. @@ -619,10 +619,10 @@ Application Here are the main actions performed by this function: -* Instantiate a new [`codec`](/docs/sdk/v0.53/learn/advanced/encoding) and initialize the `codec` of each of the application's modules using the [basic manager](/docs/sdk/v0.53//build/building-modules/module-manager#basicmanager). +* Instantiate a new [`codec`](/docs/sdk/v0.53/learn/advanced/encoding) and initialize the `codec` of each of the application's modules using the [basic manager](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#basicmanager). * Instantiate a new application with a reference to a `baseapp` instance, a codec, and all the appropriate store keys. * Instantiate all the [`keeper`](#keeper) objects defined in the application's `type` using the `NewKeeper` function of each of the application's modules. Note that keepers must be instantiated in the correct order, as the `NewKeeper` of one module might require a reference to another module's `keeper`. -* Instantiate the application's [module manager](/docs/sdk/v0.53//build/building-modules/module-manager#manager) with the [`AppModule`](#application-module-interface) object of each of the application's modules. +* Instantiate the application's [module manager](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#manager) with the [`AppModule`](#application-module-interface) object of each of the application's modules. * With the module manager, initialize the application's [`Msg` services](/docs/sdk/v0.53/learn/advanced/baseapp#msg-services), [gRPC `Query` services](/docs/sdk/v0.53/learn/advanced/baseapp#grpc-query-services), [legacy `Msg` routes](/docs/sdk/v0.53/learn/advanced/baseapp#routing), and [legacy query routes](/docs/sdk/v0.53/learn/advanced/baseapp#query-routing). When a transaction is relayed to the application by CometBFT via the ABCI, it is routed to the appropriate module's [`Msg` service](#msg-services) using the routes defined here. Likewise, when a gRPC query request is received by the application, it is routed to the appropriate module's [`gRPC query service`](#grpc-query-services) using the gRPC routes defined here. The Cosmos SDK still supports legacy `Msg`s and legacy CometBFT queries, which are routed using the legacy `Msg` routes and the legacy query routes, respectively. * With the module manager, register the [application's modules' invariants](/docs/sdk/v0.53//build/building-modules/invariants). Invariants are variables (e.g. total supply of a token) that are evaluated at the end of each block. The process of checking invariants is done via a special module called the [`InvariantsRegistry`](/docs/sdk/v0.53//build/building-modules/invariants#invariant-registry). The value of the invariant should be equal to a predicted value defined in the module. Should the value be different than the predicted one, special logic defined in the invariant registry is triggered (usually the chain is halted). This is useful to make sure that no critical bug goes unnoticed, producing long-lasting effects that are hard to fix. * With the module manager, set the order of execution between the `InitGenesis`, `PreBlocker`, `BeginBlocker`, and `EndBlocker` functions of each of the [application's modules](#application-module-interface). Note that not all modules implement these functions. @@ -1655,7 +1655,7 @@ return modAccAddrs The `InitChainer` is a function that initializes the state of the application from a genesis file (i.e. token balances of genesis accounts). It is called when the application receives the `InitChain` message from the CometBFT engine, which happens when the node is started at `appBlockHeight == 0` (i.e. on genesis). The application must set the `InitChainer` in its [constructor](#constructor-function) via the [`SetInitChainer`](https://pkg.go.dev/github.com/cosmos/cosmos-sdk/baseapp#BaseApp.SetInitChainer) method. -In general, the `InitChainer` is mostly composed of the [`InitGenesis`](/docs/sdk/v0.53//build/building-modules/genesis#initgenesis) function of each of the application's modules. This is done by calling the `InitGenesis` function of the module manager, which in turn calls the `InitGenesis` function of each of the modules it contains. Note that the order in which the modules' `InitGenesis` functions must be called has to be set in the module manager using the [module manager's](/docs/sdk/v0.53//build/building-modules/module-manager) `SetOrderInitGenesis` method. This is done in the [application's constructor](#application-constructor), and the `SetOrderInitGenesis` has to be called before the `SetInitChainer`. +In general, the `InitChainer` is mostly composed of the [`InitGenesis`](/docs/sdk/v0.53//build/building-modules/genesis#initgenesis) function of each of the application's modules. This is done by calling the `InitGenesis` function of the module manager, which in turn calls the `InitGenesis` function of each of the modules it contains. Note that the order in which the modules' `InitGenesis` functions must be called has to be set in the module manager using the [module manager's](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) `SetOrderInitGenesis` method. This is done in the [application's constructor](#application-constructor), and the `SetOrderInitGenesis` has to be called before the `SetInitChainer`. See an example of an `InitChainer` from `simapp`: @@ -2691,7 +2691,7 @@ The new ctx must be passed to all the other lifecycle methods. The Cosmos SDK offers developers the possibility to implement automatic execution of code as part of their application. This is implemented through two functions called `BeginBlocker` and `EndBlocker`. They are called when the application receives the `FinalizeBlock` messages from the CometBFT consensus engine, which happens respectively at the beginning and at the end of each block. The application must set the `BeginBlocker` and `EndBlocker` in its [constructor](#constructor-function) via the [`SetBeginBlocker`](https://pkg.go.dev/github.com/cosmos/cosmos-sdk/baseapp#BaseApp.SetBeginBlocker) and [`SetEndBlocker`](https://pkg.go.dev/github.com/cosmos/cosmos-sdk/baseapp#BaseApp.SetEndBlocker) methods. -In general, the `BeginBlocker` and `EndBlocker` functions are mostly composed of the [`BeginBlock` and `EndBlock`](/docs/sdk/v0.53//build/building-modules/beginblock-endblock) functions of each of the application's modules. This is done by calling the `BeginBlock` and `EndBlock` functions of the module manager, which in turn calls the `BeginBlock` and `EndBlock` functions of each of the modules it contains. Note that the order in which the modules' `BeginBlock` and `EndBlock` functions must be called has to be set in the module manager using the `SetOrderBeginBlockers` and `SetOrderEndBlockers` methods, respectively. This is done via the [module manager](/docs/sdk/v0.53//build/building-modules/module-manager) in the [application's constructor](#application-constructor), and the `SetOrderBeginBlockers` and `SetOrderEndBlockers` methods have to be called before the `SetBeginBlocker` and `SetEndBlocker` functions. +In general, the `BeginBlocker` and `EndBlocker` functions are mostly composed of the [`BeginBlock` and `EndBlock`](/docs/sdk/v0.53//build/building-modules/beginblock-endblock) functions of each of the application's modules. This is done by calling the `BeginBlock` and `EndBlock` functions of the module manager, which in turn calls the `BeginBlock` and `EndBlock` functions of each of the modules it contains. Note that the order in which the modules' `BeginBlock` and `EndBlock` functions must be called has to be set in the module manager using the `SetOrderBeginBlockers` and `SetOrderEndBlockers` methods, respectively. This is done via the [module manager](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) in the [application's constructor](#application-constructor), and the `SetOrderBeginBlockers` and `SetOrderEndBlockers` methods have to be called before the `SetBeginBlocker` and `SetEndBlocker` functions. As a sidenote, it is important to remember that application-specific blockchains are deterministic. Developers must be careful not to introduce non-determinism in `BeginBlocker` or `EndBlocker`, and must also be careful not to make them too computationally expensive, as [gas](/docs/sdk/v0.53/gas-fees) does not constrain the cost of `BeginBlocker` and `EndBlocker` execution. @@ -3772,9 +3772,9 @@ type EncodingConfig struct { ### Application Module Interface -Modules must implement [interfaces](/docs/sdk/v0.53//build/building-modules/module-manager#application-module-interfaces) defined in the Cosmos SDK, [`AppModuleBasic`](/docs/sdk/v0.53//build/building-modules/module-manager#appmodulebasic) and [`AppModule`](/docs/sdk/v0.53//build/building-modules/module-manager#appmodule). The former implements basic non-dependent elements of the module, such as the `codec`, while the latter handles the bulk of the module methods (including methods that require references to other modules' `keeper`s). Both the `AppModule` and `AppModuleBasic` types are, by convention, defined in a file called `module.go`. +Modules must implement [interfaces](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#application-module-interfaces) defined in the Cosmos SDK, [`AppModuleBasic`](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#appmodulebasic) and [`AppModule`](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#appmodule). The former implements basic non-dependent elements of the module, such as the `codec`, while the latter handles the bulk of the module methods (including methods that require references to other modules' `keeper`s). Both the `AppModule` and `AppModuleBasic` types are, by convention, defined in a file called `module.go`. -`AppModule` exposes a collection of useful methods on the module that facilitates the composition of modules into a coherent application. These methods are called from the [`module manager`](/docs/sdk/v0.53//build/building-modules/module-manager#manager), which manages the application's collection of modules. +`AppModule` exposes a collection of useful methods on the module that facilitates the composition of modules into a coherent application. These methods are called from the [`module manager`](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#manager), which manages the application's collection of modules. ### `Msg` Services diff --git a/docs/sdk/v0.53/learn/beginner/tx-lifecycle.mdx b/docs/sdk/v0.53/learn/beginner/tx-lifecycle.mdx index cd17151d..f2f99df8 100644 --- a/docs/sdk/v0.53/learn/beginner/tx-lifecycle.mdx +++ b/docs/sdk/v0.53/learn/beginner/tx-lifecycle.mdx @@ -242,7 +242,7 @@ Instead of using their `checkState`, full-nodes use `finalizeblock`: [`runMsgs`](/docs/sdk/v0.53/learn/advanced/baseapp#runtx-antehandler-runmsgs-posthandler) to fully execute each `Msg` within the transaction. Since the transaction may have messages from different modules, `BaseApp` needs to know which module to find the appropriate handler. This is achieved using `BaseApp`'s `MsgServiceRouter` so that it can be processed by the module's Protobuf [`Msg` service](/docs/sdk/v0.53//build/building-modules/msg-services). - For `LegacyMsg` routing, the `Route` function is called via the [module manager](/docs/sdk/v0.53//build/building-modules/module-manager) to retrieve the route name and find the legacy [`Handler`](/docs/sdk/v0.53//build/building-modules/msg-services#handler-type) within the module. + For `LegacyMsg` routing, the `Route` function is called via the [module manager](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) to retrieve the route name and find the legacy [`Handler`](/docs/sdk/v0.53//build/building-modules/msg-services#handler-type) within the module. * **`Msg` service:** Protobuf `Msg` service is responsible for executing each message in the `Tx` and causes state transitions to persist in `finalizeBlockState`. From f7f6399a67733e2633af102dd0ec11c35709c111 Mon Sep 17 00:00:00 2001 From: Cordt Date: Fri, 24 Oct 2025 07:44:16 -0600 Subject: [PATCH 03/10] futther broken links fixes --- docs.json | 4 +-- .../build-a-chain/configuration-reference.mdx | 6 ++-- .../pre-genesis-and-genesis-setup.mdx | 10 +++---- .../build-a-chain/runtime-and-launch.mdx | 6 ++-- .../cosmos-sdk/modules/erc20.mdx | 2 +- .../cosmos-sdk/modules/feemarket.mdx | 2 +- .../cosmos-sdk/modules/precisebank.mdx | 4 +-- .../documentation/cosmos-sdk/modules/vm.mdx | 4 +-- .../build/modules/auth/{aut.mdx => auth.mdx} | 2 +- docs/sdk/v0.47/build/modules/authz/README.mdx | 2 +- docs/sdk/v0.47/learn.mdx | 2 +- docs/sdk/v0.47/learn/advanced/context.mdx | 2 +- docs/sdk/v0.47/learn/advanced/store.mdx | 2 +- docs/sdk/v0.47/learn/beginner/accounts.mdx | 2 +- docs/sdk/v0.47/learn/beginner/gas-fees.mdx | 2 +- .../sdk/v0.47/learn/beginner/tx-lifecycle.mdx | 8 +++--- docs/sdk/v0.50/build/modules.mdx | 2 +- .../modules/auth/{authre.mdx => auth.mdx} | 2 +- docs/sdk/v0.50/build/modules/authz/README.mdx | 2 +- .../v0.50/build/modules/feegrant/README.mdx | 2 +- docs/sdk/v0.50/build/modules/module.mdx | 2 +- .../v0.50/learn/beginner/query-lifecycle.mdx | 2 +- .../adr-007-specialization-groups.mdx | 2 +- .../architecture/adr-008-dCERT-group.mdx | 4 +-- .../adr-020-protobuf-transaction-encoding.mdx | 8 +++--- .../adr-021-protobuf-query-encoding.mdx | 6 ++-- ...7-deterministic-protobuf-serialization.mdx | 2 +- .../architecture/adr-030-authz-module.mdx | 2 +- .../architecture/adr-031-msg-service.mdx | 10 +++---- .../adr-033-protobuf-inter-module-comm.mdx | 22 +++++++-------- .../architecture/adr-042-group-module.mdx | 2 +- .../adr-044-protobuf-updates-guidelines.mdx | 2 +- .../adr-045-check-delivertx-middlewares.mdx | 4 +-- .../adr-050-sign-mode-textual-annex1.mdx | 4 +-- .../adr-050-sign-mode-textual.mdx | 12 ++++---- .../adr-054-semver-compatible-modules.mdx | 28 +++++++++---------- .../build/architecture/adr-065-store-v2.mdx | 6 ++-- .../building-modules/beginblock-endblock.mdx | 6 ++-- .../v0.53/build/building-modules/genesis.mdx | 6 ++-- .../v0.53/build/building-modules/intro.mdx | 4 +-- .../build/building-modules/invariants.mdx | 2 +- .../building-modules/messages-and-queries.mdx | 6 ++-- .../build/building-modules/module-manager.mdx | 8 +++--- .../build/building-modules/msg-services.mdx | 2 +- .../v0.53/build/building-modules/preblock.mdx | 2 +- .../build/building-modules/query-services.mdx | 2 +- .../v0.53/build/modules/feegrant/README.mdx | 2 +- docs/sdk/v0.53/learn/advanced/baseapp.mdx | 18 ++++++------ docs/sdk/v0.53/learn/advanced/cli.mdx | 2 +- docs/sdk/v0.53/learn/advanced/context.mdx | 2 +- docs/sdk/v0.53/learn/advanced/encoding.mdx | 2 +- docs/sdk/v0.53/learn/advanced/events.mdx | 2 +- docs/sdk/v0.53/learn/advanced/node.mdx | 4 +-- docs/sdk/v0.53/learn/advanced/store.mdx | 4 +-- .../sdk/v0.53/learn/advanced/transactions.mdx | 2 +- docs/sdk/v0.53/learn/beginner/accounts.mdx | 2 +- docs/sdk/v0.53/learn/beginner/gas-fees.mdx | 2 +- .../sdk/v0.53/learn/beginner/tx-lifecycle.mdx | 2 +- docs/sdk/v0.53/learn/intro/sdk-design.mdx | 2 +- 59 files changed, 135 insertions(+), 135 deletions(-) rename docs/sdk/v0.47/build/modules/auth/{aut.mdx => auth.mdx} (99%) rename docs/sdk/v0.50/build/modules/auth/{authre.mdx => auth.mdx} (99%) diff --git a/docs.json b/docs.json index 005f6d34..e7bbb16a 100644 --- a/docs.json +++ b/docs.json @@ -952,7 +952,7 @@ { "group": "x/auth", "pages": [ - "docs/sdk/v0.50/build/modules/auth/authre", + "docs/sdk/v0.50/build/modules/auth/auth", "docs/sdk/v0.50/build/modules/auth/vesting", "docs/sdk/v0.50/build/modules/auth/tx" ] @@ -1275,7 +1275,7 @@ { "group": "x/auth", "pages": [ - "docs/sdk/v0.47/build/modules/auth/aut", + "docs/sdk/v0.47/build/modules/auth/auth", "docs/sdk/v0.47/build/modules/auth/vesting", "docs/sdk/v0.47/build/modules/auth/tx" ] diff --git a/docs/evm/next/documentation/getting-started/build-a-chain/configuration-reference.mdx b/docs/evm/next/documentation/getting-started/build-a-chain/configuration-reference.mdx index 660b40ce..0ed39035 100644 --- a/docs/evm/next/documentation/getting-started/build-a-chain/configuration-reference.mdx +++ b/docs/evm/next/documentation/getting-started/build-a-chain/configuration-reference.mdx @@ -6,7 +6,7 @@ description: "Complete technical reference of all configurable parameters in Cos Technical reference for all Cosmos EVM chain parameters organized by configuration phase and module. -For step-by-step configuration guides, see [Pre-Genesis & Genesis Setup](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/pre-genesis-and-genesis-setup) and [Runtime Configuration & Launch](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/runtime-and-launch). +For step-by-step configuration guides, see [Pre-Genesis & Genesis Setup](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start) and [Runtime Configuration & Launch](/docs/evm/v0.5.0/documentation/getting-started/network-operators/node-configuration). --- @@ -1796,11 +1796,11 @@ CLI client configuration. Location: `~/.yourchain/config/client.toml` ## Related Documentation - + Configuration guide - + Launch procedures diff --git a/docs/evm/next/documentation/getting-started/build-a-chain/pre-genesis-and-genesis-setup.mdx b/docs/evm/next/documentation/getting-started/build-a-chain/pre-genesis-and-genesis-setup.mdx index e31dc1a8..c8e404b3 100644 --- a/docs/evm/next/documentation/getting-started/build-a-chain/pre-genesis-and-genesis-setup.mdx +++ b/docs/evm/next/documentation/getting-started/build-a-chain/pre-genesis-and-genesis-setup.mdx @@ -7,8 +7,8 @@ This guide covers all configuration steps from initial binary setup through gene **Related Documentation:** -- [Runtime Configuration & Launch](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/runtime-and-launch) - Network launch procedures -- [Configuration Reference](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/configuration-reference) - Commands, examples, and quick reference +- [Runtime Configuration & Launch](/docs/evm/v0.5.0/documentation/getting-started/network-operators/node-configuration) - Network launch procedures +- [Configuration Reference](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start) - Commands, examples, and quick reference ## Overview @@ -1176,7 +1176,7 @@ jq '.genesis_time' ~/.yourchain/config/genesis.json - **Local Dev**: Use past time (starts immediately) -**Network Launch Details**: For complete launch coordination procedures, validator startup instructions, and timing best practices, see [Coordinate Launch Time](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/runtime-and-launch#coordinate-launch-time) in the Runtime Configuration & Network Launch guide. +**Network Launch Details**: For complete launch coordination procedures, validator startup instructions, and timing best practices, see [Coordinate Launch Time](/docs/evm/v0.5.0/documentation/getting-started/network-operators/node-configuration#coordinate-launch-time) in the Runtime Configuration & Network Launch guide. **Important**: All validators must have identical `genesis_time` in their genesis files. @@ -2259,13 +2259,13 @@ Your genesis file is now complete! Next: 2. **Configure Runtime Settings** 3. **Launch Network** -Continue to [Runtime Configuration & Network Launch](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/runtime-and-launch) for full details. +Continue to [Runtime Configuration & Network Launch](/docs/evm/v0.5.0/documentation/getting-started/network-operators/node-configuration) for full details. ## Quick Reference -**See**: [Configuration Reference](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/configuration-reference) for: +**See**: [Configuration Reference](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start) for: - Command cheatsheets - Configuration examples - Default values table diff --git a/docs/evm/next/documentation/getting-started/build-a-chain/runtime-and-launch.mdx b/docs/evm/next/documentation/getting-started/build-a-chain/runtime-and-launch.mdx index d9c8e500..67d90a78 100644 --- a/docs/evm/next/documentation/getting-started/build-a-chain/runtime-and-launch.mdx +++ b/docs/evm/next/documentation/getting-started/build-a-chain/runtime-and-launch.mdx @@ -7,8 +7,8 @@ This guide covers runtime configuration (`app.toml`, `config.toml`) and network **Related Documentation:** -- [Pre-Genesis & Genesis Setup](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/pre-genesis-and-genesis-setup) - Initial configuration and genesis preparation -- [Configuration Reference](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/configuration-reference) - Commands, examples, and quick reference +- [Pre-Genesis & Genesis Setup](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start) - Initial configuration and genesis preparation +- [Configuration Reference](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start) - Commands, examples, and quick reference ## Overview @@ -1206,6 +1206,6 @@ yourchain start Your chain should now be launched and operational! If not, start the process over from the beginning, or [contact us](https://cosmos.network/contact)! **Further resources:** -- [Configuration Reference](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/configuration-reference) - Complete command reference and examples +- [Configuration Reference](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start) - Complete command reference and examples - [VM Module Documentation](/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/vm) - EVM configuration details - [Cosmos SDK Documentation](https://docs.cosmos.network) - General Cosmos SDK operations diff --git a/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/erc20.mdx b/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/erc20.mdx index 109ffbc3..f9ae40a2 100644 --- a/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/erc20.mdx +++ b/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/erc20.mdx @@ -524,7 +524,7 @@ evmd tx erc20 register-coin --from mykey - [Building Your Chain Guide](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/overview) - Main configuration walkthrough - [VM Module](/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/vm) - EVM configuration -- [Token Configuration Guide](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/pre-genesis-and-genesis-setup) - Token economics setup +- [Token Configuration Guide](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start) - Token economics setup - [IBC Module](/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/ibc) - IBC token handling --- diff --git a/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/feemarket.mdx b/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/feemarket.mdx index 28854bfc..f2960c57 100644 --- a/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/feemarket.mdx +++ b/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/feemarket.mdx @@ -850,7 +850,7 @@ evmd tx gov submit-proposal param-change proposal.json --from validator --chain- - [Building Your Chain Guide](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/overview) - Main configuration walkthrough - [Chain Customization Checklist](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start) - Complete parameter checklist - [VM Module](/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/vm) - EVM configuration -- [Token Configuration Guide](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/pre-genesis-and-genesis-setup) - Token economics setup +- [Token Configuration Guide](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start) - Token economics setup - [EIP-1559 Specification](https://eips.ethereum.org/EIPS/eip-1559) - Original Ethereum proposal --- diff --git a/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/precisebank.mdx b/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/precisebank.mdx index 135af491..021ca00c 100644 --- a/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/precisebank.mdx +++ b/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/precisebank.mdx @@ -220,7 +220,7 @@ When using PreciseBank, you **MUST** configure `extended_denom_options` in the V - `u` prefix (micro, 10^6) → `a` prefix (atto, 10^18): `ustake` → `astake` - Other prefixes → add `evm` prefix: `stake` → `evmstake` -**Source**: [Token Configuration Guide](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/pre-genesis-and-genesis-setup) +**Source**: [Token Configuration Guide](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start) --- @@ -641,7 +641,7 @@ REMAINDER=$(evmd query precisebank remainder -o json | jq -r '.remainder') ## Related Documentation - [Building Your Chain Guide](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/overview) - Main configuration walkthrough -- [Token Configuration Guide](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/pre-genesis-and-genesis-setup) - Decimal configuration +- [Token Configuration Guide](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start) - Decimal configuration - [VM Module](/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/vm) - extended_denom_options setup - [ERC20 Module](/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/erc20) - Token pair configuration diff --git a/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/vm.mdx b/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/vm.mdx index f48442df..c031dfd9 100644 --- a/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/vm.mdx +++ b/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/vm.mdx @@ -476,7 +476,7 @@ jq '.app_state["vm"]["params"]["active_static_precompiles"]=[ **Related Configuration**: Requires [PreciseBank Module](/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/precisebank) to be included in app.go -**See Also**: [Token Configuration Guide](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/pre-genesis-and-genesis-setup) for complete decimal configuration details +**See Also**: [Token Configuration Guide](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start) for complete decimal configuration details --- @@ -575,7 +575,7 @@ Or in genesis.json directly: - [Building Your Chain Guide](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/overview) - Main configuration walkthrough - [Chain Customization Checklist](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start) - Complete parameter checklist -- [Token Configuration Guide](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/pre-genesis-and-genesis-setup) - Token decimals and evm_denom setup +- [Token Configuration Guide](/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start) - Token decimals and evm_denom setup - [Fee Market Module](/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/feemarket) - EIP-1559 fee configuration - [local_node.sh](https://github.com/cosmos/evm/blob/main/local_node.sh) - Reference implementation diff --git a/docs/sdk/v0.47/build/modules/auth/aut.mdx b/docs/sdk/v0.47/build/modules/auth/auth.mdx similarity index 99% rename from docs/sdk/v0.47/build/modules/auth/aut.mdx rename to docs/sdk/v0.47/build/modules/auth/auth.mdx index a812021c..e05d385d 100644 --- a/docs/sdk/v0.47/build/modules/auth/aut.mdx +++ b/docs/sdk/v0.47/build/modules/auth/auth.mdx @@ -31,7 +31,7 @@ This module is used in the Cosmos Hub. ## Concepts -**Note:** The auth module is different from the [authz module](/docs/sdk/v0.47/build/modules/auth/authz/). +**Note:** The auth module is different from the [authz module](/docs/sdk/v0.47/build/modules/authz/README). The differences are: diff --git a/docs/sdk/v0.47/build/modules/authz/README.mdx b/docs/sdk/v0.47/build/modules/authz/README.mdx index c3dbdd21..0c0f9ba3 100644 --- a/docs/sdk/v0.47/build/modules/authz/README.mdx +++ b/docs/sdk/v0.47/build/modules/authz/README.mdx @@ -36,7 +36,7 @@ on behalf of one account to other accounts. The design is defined in the [ADR 03 A *grant* is an allowance to execute a Msg by the grantee on behalf of the granter. Authorization is an interface that must be implemented by a concrete authorization logic to validate and execute grants. Authorizations are extensible and can be defined for any Msg service method even outside of the module where the Msg method is defined. See the `SendAuthorization` example in the next section for more details. -**Note:** The authz module is different from the [auth (authentication)](/docs/sdk/v0.47/build/modules/auth/auth/) module that is responsible for specifying the base transaction and account types. +**Note:** The authz module is different from the [auth (authentication)](/docs/sdk/v0.47/build/modules/auth/aut/) module that is responsible for specifying the base transaction and account types. ```go expandable package authz diff --git a/docs/sdk/v0.47/learn.mdx b/docs/sdk/v0.47/learn.mdx index 96d055bf..e3fdf76c 100644 --- a/docs/sdk/v0.47/learn.mdx +++ b/docs/sdk/v0.47/learn.mdx @@ -4,5 +4,5 @@ description: "Version: v0.47" --- * [Introduction](/docs/sdk/v0.47/learn/intro/overview) - Dive into the fundamentals of Cosmos SDK with an insightful introduction, laying the groundwork for understanding blockchain development. In this section we provide a High-Level Overview of the SDK, then dive deeper into Core concepts such as Application-Specific Blockchains, Blockchain Architecture, and finally we begin to explore what are the main components of the SDK. -* [Beginner](/docs/sdk/v0.47/learn/beginner/overview-app) - Start your journey with beginner-friendly resources in the Cosmos SDK's "Learn" section, providing a gentle entry point for newcomers to blockchain development. Here we focus on a little more detail, covering the Anatomy of a Cosmos SDK Application, Transaction Lifecycles, Accounts and lastly, Gas and Fees. +* [Beginner](/docs/sdk/v0.47/learn/beginner/app-anatomy) - Start your journey with beginner-friendly resources in the Cosmos SDK's "Learn" section, providing a gentle entry point for newcomers to blockchain development. Here we focus on a little more detail, covering the Anatomy of a Cosmos SDK Application, Transaction Lifecycles, Accounts and lastly, Gas and Fees. * [Advanced](/docs/sdk/v0.47/learn/advanced/baseapp) - Level up your Cosmos SDK expertise with advanced topics, tailored for experienced developers diving into intricate blockchain application development. We cover the Cosmos SDK on a lower level as we dive into the core of the SDK with BaseApp, Transactions, Context, Node Client (Daemon), Store, Encoding, gRPC, REST, and CometBFT Endpoints, CLI, Events, Telementry, Object-Capability Model, RunTx recovery middleware, Cosmos Blockchain Simulator, Protobuf Documentation, In-Place Store Migrations, Configuration and AutoCLI. diff --git a/docs/sdk/v0.47/learn/advanced/context.mdx b/docs/sdk/v0.47/learn/advanced/context.mdx index 99d01d6c..1ec0dacc 100644 --- a/docs/sdk/v0.47/learn/advanced/context.mdx +++ b/docs/sdk/v0.47/learn/advanced/context.mdx @@ -11,7 +11,7 @@ The `context` is a data structure intended to be passed from function to functio ### Pre-requisites Readings -* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.47/learn/beginner/overview-app) +* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.47/learn/beginner/app-anatomy) * [Lifecycle of a Transaction](/docs/sdk/v0.47/learn/beginner/tx-lifecycle) diff --git a/docs/sdk/v0.47/learn/advanced/store.mdx b/docs/sdk/v0.47/learn/advanced/store.mdx index 81bb01ba..db4f7435 100644 --- a/docs/sdk/v0.47/learn/advanced/store.mdx +++ b/docs/sdk/v0.47/learn/advanced/store.mdx @@ -11,7 +11,7 @@ A store is a data structure that holds the state of the application. ### Pre-requisite Readings -* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.47/learn/beginner/overview-app) +* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.47/learn/beginner/app-anatomy) diff --git a/docs/sdk/v0.47/learn/beginner/accounts.mdx b/docs/sdk/v0.47/learn/beginner/accounts.mdx index 5a9fe29a..bc657e20 100644 --- a/docs/sdk/v0.47/learn/beginner/accounts.mdx +++ b/docs/sdk/v0.47/learn/beginner/accounts.mdx @@ -11,7 +11,7 @@ This document describes the in-built account and public key system of the Cosmos ### Pre-requisite Readings -* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.47/learn/beginner/overview-app) +* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.47/learn/beginner/app-anatomy) diff --git a/docs/sdk/v0.47/learn/beginner/gas-fees.mdx b/docs/sdk/v0.47/learn/beginner/gas-fees.mdx index b0707d79..740e10c3 100644 --- a/docs/sdk/v0.47/learn/beginner/gas-fees.mdx +++ b/docs/sdk/v0.47/learn/beginner/gas-fees.mdx @@ -11,7 +11,7 @@ This document describes the default strategies to handle gas and fees within a C ### Pre-requisite Readings -* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.47/learn/beginner/overview-app) +* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.47/learn/beginner/app-anatomy) diff --git a/docs/sdk/v0.47/learn/beginner/tx-lifecycle.mdx b/docs/sdk/v0.47/learn/beginner/tx-lifecycle.mdx index d8a96048..f1dd38ba 100644 --- a/docs/sdk/v0.47/learn/beginner/tx-lifecycle.mdx +++ b/docs/sdk/v0.47/learn/beginner/tx-lifecycle.mdx @@ -11,7 +11,7 @@ This document describes the lifecycle of a transaction from creation to committe ### Pre-requisite Readings -* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.47/learn/beginner/overview-app) +* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.47/learn/beginner/app-anatomy) ## Creation @@ -157,8 +157,8 @@ must be in this proposer's mempool. The next step of consensus is to execute the transactions to fully validate them. All full-nodes that receive a block proposal from the correct proposer execute the transactions by calling the ABCI functions -[`BeginBlock`](/docs/sdk/v0.47/learn/beginner/overview-app#beginblocker-and-endblocker), `DeliverTx` for each transaction, -and [`EndBlock`](/docs/sdk/v0.47/learn/beginner/overview-app#beginblocker-and-endblocker). While each full-node runs everything +[`BeginBlock`](/docs/sdk/v0.47/learn/beginner/app-anatomy#beginblocker-and-endblocker), `DeliverTx` for each transaction, +and [`EndBlock`](/docs/sdk/v0.47/learn/beginner/app-anatomy#beginblocker-and-endblocker). While each full-node runs everything locally, this process yields a single, unambiguous result, since the messages' state transitions are deterministic and transactions are explicitly ordered in the block proposal. @@ -208,7 +208,7 @@ to during consensus. Under the hood, `DeliverTx` is almost identical to `CheckTx Instead of using their `checkState`, full-nodes use `deliverState`: * **Decoding:** Since `DeliverTx` is an ABCI call, `Tx` is received in the encoded `[]byte` form. - Nodes first unmarshal the transaction, using the [`TxConfig`](/docs/sdk/v0.47/learn/beginner/overview-app#register-codec) defined in the app, then call `runTx` in `runTxModeDeliver`, which is very similar to `CheckTx` but also executes and writes state changes. + Nodes first unmarshal the transaction, using the [`TxConfig`](/docs/sdk/v0.47/learn/beginner/app-anatomy#register-codec) defined in the app, then call `runTx` in `runTxModeDeliver`, which is very similar to `CheckTx` but also executes and writes state changes. * **Checks and `AnteHandler`:** Full-nodes call `validateBasicMsgs` and `AnteHandler` again. This second check happens because they may not have seen the same transactions during the addition to Mempool stage diff --git a/docs/sdk/v0.50/build/modules.mdx b/docs/sdk/v0.50/build/modules.mdx index ddf35ece..be3c2d4e 100644 --- a/docs/sdk/v0.50/build/modules.mdx +++ b/docs/sdk/v0.50/build/modules.mdx @@ -9,7 +9,7 @@ Here are some production-grade modules that can be used in Cosmos SDK applicatio Essential modules include functionality that *must* be included in your Cosmos SDK blockchain. These modules provide the core behaviors that are needed for users and operators such as balance tracking, proof-of-stake capabilities and governance. -* [Auth](/docs/sdk/v0.50/build/modules/auth/authre) - Authentication of accounts and transactions for Cosmos SDK applications. +* [Auth](/docs/sdk/v0.50/build/modules/auth/auth) - Authentication of accounts and transactions for Cosmos SDK applications. * [Bank](/docs/sdk/v0.50/build/modules/bank/README) - Token transfer functionalities. * [Circuit](/docs/sdk/v0.50/build/modules/circuit/README) - Circuit breaker module for pausing messages. * [Consensus](/docs/sdk/v0.50/build/modules/consensus/README) - Consensus module for modifying CometBFT's ABCI consensus params. diff --git a/docs/sdk/v0.50/build/modules/auth/authre.mdx b/docs/sdk/v0.50/build/modules/auth/auth.mdx similarity index 99% rename from docs/sdk/v0.50/build/modules/auth/authre.mdx rename to docs/sdk/v0.50/build/modules/auth/auth.mdx index 2cc3759b..30a2bb36 100644 --- a/docs/sdk/v0.50/build/modules/auth/authre.mdx +++ b/docs/sdk/v0.50/build/modules/auth/auth.mdx @@ -31,7 +31,7 @@ This module is used in the Cosmos Hub. ## Concepts -**Note:** The auth module is different from the [authz module](/docs/sdk/v0.50/build/modules/auth/authrez/). +**Note:** The auth module is different from the [authz module](/docs/sdk/v0.50/build/modules/authz/README/). The differences are: diff --git a/docs/sdk/v0.50/build/modules/authz/README.mdx b/docs/sdk/v0.50/build/modules/authz/README.mdx index 75dcfe36..3bbe8597 100644 --- a/docs/sdk/v0.50/build/modules/authz/README.mdx +++ b/docs/sdk/v0.50/build/modules/authz/README.mdx @@ -36,7 +36,7 @@ on behalf of one account to other accounts. The design is defined in the [ADR 03 A *grant* is an allowance to execute a Msg by the grantee on behalf of the granter. Authorization is an interface that must be implemented by a concrete authorization logic to validate and execute grants. Authorizations are extensible and can be defined for any Msg service method even outside of the module where the Msg method is defined. See the `SendAuthorization` example in the next section for more details. -**Note:** The authz module is different from the [auth (authentication)](/docs/sdk/v0.50/build/modules/auth/authre/) module that is responsible for specifying the base transaction and account types. +**Note:** The authz module is different from the [auth (authentication)](/docs/sdk/v0.50/build/modules/auth/auth/) module that is responsible for specifying the base transaction and account types. ```go expandable package authz diff --git a/docs/sdk/v0.50/build/modules/feegrant/README.mdx b/docs/sdk/v0.50/build/modules/feegrant/README.mdx index d53c23f0..3bc80da6 100644 --- a/docs/sdk/v0.50/build/modules/feegrant/README.mdx +++ b/docs/sdk/v0.50/build/modules/feegrant/README.mdx @@ -1597,7 +1597,7 @@ Example cmd: ### Granted Fee Deductions -Fees are deducted from grants in the `x/auth` ante handler. To learn more about how ante handlers work, read the [Auth Module AnteHandlers Guide](/docs/sdk/v0.50/build/modules/auth/authre#antehandlers). +Fees are deducted from grants in the `x/auth` ante handler. To learn more about how ante handlers work, read the [Auth Module AnteHandlers Guide](/docs/sdk/v0.50/build/modules/auth/auth#antehandlers). ### Gas diff --git a/docs/sdk/v0.50/build/modules/module.mdx b/docs/sdk/v0.50/build/modules/module.mdx index 21dc4d28..31484499 100644 --- a/docs/sdk/v0.50/build/modules/module.mdx +++ b/docs/sdk/v0.50/build/modules/module.mdx @@ -13,7 +13,7 @@ Essential modules include functionality that *must* be included in your Cosmos S These modules provide the core behaviors that are needed for users and operators such as balance tracking, proof-of-stake capabilities and governance. -* [Auth](/docs/sdk/v0.50/build/modules/auth/authre) - Authentication of accounts and transactions for Cosmos SDK applications. +* [Auth](/docs/sdk/v0.50/build/modules/auth/auth) - Authentication of accounts and transactions for Cosmos SDK applications. * [Bank](/docs/sdk/v0.50/build/modules/bank/README) - Token transfer functionalities. * [Circuit](/docs/sdk/v0.50/build/modules/circuit/README) - Circuit breaker module for pausing messages. * [Consensus](/docs/sdk/v0.50/build/modules/consensus/README) - Consensus module for modifying CometBFT's ABCI consensus params. diff --git a/docs/sdk/v0.50/learn/beginner/query-lifecycle.mdx b/docs/sdk/v0.50/learn/beginner/query-lifecycle.mdx index 8644876c..eb5806e2 100644 --- a/docs/sdk/v0.50/learn/beginner/query-lifecycle.mdx +++ b/docs/sdk/v0.50/learn/beginner/query-lifecycle.mdx @@ -10,7 +10,7 @@ This document describes the lifecycle of a query in a Cosmos SDK application, fr **Pre-requisite Readings** -* [Transaction Lifecycle](/docs/sdk/v0.53/learn/beginner/tx-lifecycle) +* [Transaction Lifecycle](/docs/sdk/v0.50/learn/beginner/tx-lifecycle) ## Query Creation diff --git a/docs/sdk/v0.53/build/architecture/adr-007-specialization-groups.mdx b/docs/sdk/v0.53/build/architecture/adr-007-specialization-groups.mdx index b8c4be4c..f37a4e85 100644 --- a/docs/sdk/v0.53/build/architecture/adr-007-specialization-groups.mdx +++ b/docs/sdk/v0.53/build/architecture/adr-007-specialization-groups.mdx @@ -195,4 +195,4 @@ sdk.Result ## References -* [dCERT ADR](/docs/sdk/v0.50/adr-008-dCERT-group) +* [dCERT ADR](/docs/sdk/v0.50/build/architecture/adr-008-dCERT-group) diff --git a/docs/sdk/v0.53/build/architecture/adr-008-dCERT-group.mdx b/docs/sdk/v0.53/build/architecture/adr-008-dCERT-group.mdx index 23b9b7c2..916846f3 100644 --- a/docs/sdk/v0.53/build/architecture/adr-008-dCERT-group.mdx +++ b/docs/sdk/v0.53/build/architecture/adr-008-dCERT-group.mdx @@ -35,7 +35,7 @@ vulnerability being patched on the live network. ## Decision The dCERT group is proposed to include an implementation of a `SpecializationGroup` -as defined in [ADR 007](/docs/sdk/v0.50/adr-007-specialization-groups). This will include the +as defined in [ADR 007](/docs/sdk/v0.50/build/architecture/adr-007-specialization-groups). This will include the implementation of: * continuous voting @@ -171,4 +171,4 @@ they should all be severely slashed. ## References -[Specialization Groups ADR](/docs/sdk/v0.50/adr-007-specialization-groups) +[Specialization Groups ADR](/docs/sdk/v0.50/build/architecture/adr-007-specialization-groups) diff --git a/docs/sdk/v0.53/build/architecture/adr-020-protobuf-transaction-encoding.mdx b/docs/sdk/v0.53/build/architecture/adr-020-protobuf-transaction-encoding.mdx index ec1ec5f2..71a77f96 100644 --- a/docs/sdk/v0.53/build/architecture/adr-020-protobuf-transaction-encoding.mdx +++ b/docs/sdk/v0.53/build/architecture/adr-020-protobuf-transaction-encoding.mdx @@ -25,7 +25,7 @@ Accepted ## Context This ADR is a continuation of the motivation, design, and context established in -[ADR 019](/docs/sdk/v0.50/adr-019-protobuf-state-encoding), namely, we aim to design the +[ADR 019](/docs/sdk/v0.50/build/architecture/adr-019-protobuf-state-encoding), namely, we aim to design the Protocol Buffer migration path for the client-side of the Cosmos SDK. Specifically, the client-side migration path primarily includes tx generation and @@ -207,7 +207,7 @@ message SignDoc { In order to sign in the default mode, clients take the following steps: 1. Serialize `TxBody` and `AuthInfo` using any valid protobuf implementation. -2. Create a `SignDoc` and serialize it using [ADR 027](/docs/sdk/v0.50/adr-027-deterministic-protobuf-serialization). +2. Create a `SignDoc` and serialize it using [ADR 027](/docs/sdk/v0.50/build/architecture/adr-027-deterministic-protobuf-serialization). 3. Sign the encoded `SignDoc` bytes. 4. Build a `TxRaw` and serialize it for broadcasting. @@ -223,7 +223,7 @@ Signature verifiers do: 3. For each required signer: * Pull account number and sequence from the state. * Obtain the public key either from state or `AuthInfo`'s `signer_infos`. - * Create a `SignDoc` and serialize it using [ADR 027](/docs/sdk/v0.50/adr-027-deterministic-protobuf-serialization). + * Create a `SignDoc` and serialize it using [ADR 027](/docs/sdk/v0.50/build/architecture/adr-027-deterministic-protobuf-serialization). * Verify the signature at the same list position against the serialized `SignDoc`. #### `SIGN_MODE_LEGACY_AMINO` @@ -314,7 +314,7 @@ enforce this. Currently, the REST and CLI handlers encode and decode types and txs via Amino JSON encoding using a concrete Amino codec. Being that some of the types dealt with -in the client can be interfaces, similar to how we described in [ADR 019](/docs/sdk/v0.50/adr-019-protobuf-state-encoding), +in the client can be interfaces, similar to how we described in [ADR 019](/docs/sdk/v0.50/build/architecture/adr-019-protobuf-state-encoding), the client logic will now need to take a codec interface that knows not only how to handle all the types, but also knows how to generate transactions, signatures, and messages. diff --git a/docs/sdk/v0.53/build/architecture/adr-021-protobuf-query-encoding.mdx b/docs/sdk/v0.53/build/architecture/adr-021-protobuf-query-encoding.mdx index 0f48f65e..60ef9659 100644 --- a/docs/sdk/v0.53/build/architecture/adr-021-protobuf-query-encoding.mdx +++ b/docs/sdk/v0.53/build/architecture/adr-021-protobuf-query-encoding.mdx @@ -14,11 +14,11 @@ Accepted ## Context This ADR is a continuation of the motivation, design, and context established in -[ADR 019](/docs/sdk/v0.50/adr-019-protobuf-state-encoding) and -[ADR 020](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding), namely, we aim to design the +[ADR 019](/docs/sdk/v0.50/build/architecture/adr-019-protobuf-state-encoding) and +[ADR 020](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding), namely, we aim to design the Protocol Buffer migration path for the client-side of the Cosmos SDK. -This ADR continues from [ADD 020](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding) +This ADR continues from [ADD 020](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding) to specify the encoding of queries. ## Decision diff --git a/docs/sdk/v0.53/build/architecture/adr-027-deterministic-protobuf-serialization.mdx b/docs/sdk/v0.53/build/architecture/adr-027-deterministic-protobuf-serialization.mdx index 93f53ddd..6ea24298 100644 --- a/docs/sdk/v0.53/build/architecture/adr-027-deterministic-protobuf-serialization.mdx +++ b/docs/sdk/v0.53/build/architecture/adr-027-deterministic-protobuf-serialization.mdx @@ -30,7 +30,7 @@ other cases as well. For signature verification in Cosmos SDK, the signer and verifier need to agree on the same serialization of a `SignDoc` as defined in -[ADR-020](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding) without transmitting the +[ADR-020](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding) without transmitting the serialization. Currently, for block signatures we are using a workaround: we create a new [TxRaw](https://github.com/cosmos/cosmos-sdk/blob/9e85e81e0e8140067dd893421290c191529c148c/proto/cosmos/tx/v1beta1/tx.proto#L30) diff --git a/docs/sdk/v0.53/build/architecture/adr-030-authz-module.mdx b/docs/sdk/v0.53/build/architecture/adr-030-authz-module.mdx index 08bb3af4..af548262 100644 --- a/docs/sdk/v0.53/build/architecture/adr-030-authz-module.mdx +++ b/docs/sdk/v0.53/build/architecture/adr-030-authz-module.mdx @@ -27,7 +27,7 @@ The concrete use cases which motivated this module include: delegated stake * "sub-keys" functionality, as originally proposed in [#4480](https://github.com/cosmos/cosmos-sdk/issues/4480) which is a term used to describe the functionality provided by this module together with - the `fee_grant` module from [ADR 029](/docs/sdk/v0.50/adr-029-fee-grant-module) and the [group module](https://github.com/cosmos/cosmos-sdk/tree/main/x/group). + the `fee_grant` module from [ADR 029](/docs/sdk/v0.50/build/architecture/adr-029-fee-grant-module) and the [group module](https://github.com/cosmos/cosmos-sdk/tree/main/x/group). The "sub-keys" functionality roughly refers to the ability for one account to grant some subset of its capabilities to other accounts with possibly less robust, but easier to use security measures. For instance, a master account representing diff --git a/docs/sdk/v0.53/build/architecture/adr-031-msg-service.mdx b/docs/sdk/v0.53/build/architecture/adr-031-msg-service.mdx index 5ce8ced2..2987f754 100644 --- a/docs/sdk/v0.53/build/architecture/adr-031-msg-service.mdx +++ b/docs/sdk/v0.53/build/architecture/adr-031-msg-service.mdx @@ -111,12 +111,12 @@ One consequence of this convention is that each `Msg` type can be the request pa ### Encoding -Encoding of transactions generated with `Msg` services do not differ from current Protobuf transaction encoding as defined in [ADR-020](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding). We are encoding `Msg` types (which are exactly `Msg` service methods' request parameters) as `Any` in `Tx`s which involves packing the +Encoding of transactions generated with `Msg` services do not differ from current Protobuf transaction encoding as defined in [ADR-020](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding). We are encoding `Msg` types (which are exactly `Msg` service methods' request parameters) as `Any` in `Tx`s which involves packing the binary-encoded `Msg` with its type URL. ### Decoding -Since `Msg` types are packed into `Any`, decoding transactions messages are done by unpacking `Any`s into `Msg` types. For more information, please refer to [ADR-020](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding#transactions). +Since `Msg` types are packed into `Any`, decoding transactions messages are done by unpacking `Any`s into `Msg` types. For more information, please refer to [ADR-020](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding#transactions). ### Routing @@ -128,7 +128,7 @@ For backward compatability, the old handlers are not removed yet. If BaseApp rec ### Module Configuration -In [ADR 021](/docs/sdk/v0.50/adr-021-protobuf-query-encoding), we introduced a method `RegisterQueryService` +In [ADR 021](/docs/sdk/v0.50/build/architecture/adr-021-protobuf-query-encoding), we introduced a method `RegisterQueryService` to `AppModule` which allows for modules to register gRPC queriers. To register `Msg` services, we attempt a more extensible approach by converting `RegisterQueryService` @@ -213,5 +213,5 @@ Finally, closing a module to client API opens desirable OCAP patterns discussed * [Initial Github Issue #7122](https://github.com/cosmos/cosmos-sdk/issues/7122) * [proto 3 Language Guide: Defining Services](https://developers.google.com/protocol-buffers/docs/proto3#services) * [Initial pre-`Any` `Msg` designs](https://docs.google.com/document/d/1eEgYgvgZqLE45vETjhwIw4VOqK-5hwQtZtjVbiXnIGc) -* [ADR 020](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding) -* [ADR 021](/docs/sdk/v0.50/adr-021-protobuf-query-encoding) +* [ADR 020](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding) +* [ADR 021](/docs/sdk/v0.50/build/architecture/adr-021-protobuf-query-encoding) diff --git a/docs/sdk/v0.53/build/architecture/adr-033-protobuf-inter-module-comm.mdx b/docs/sdk/v0.53/build/architecture/adr-033-protobuf-inter-module-comm.mdx index 043b3d84..90daebd3 100644 --- a/docs/sdk/v0.53/build/architecture/adr-033-protobuf-inter-module-comm.mdx +++ b/docs/sdk/v0.53/build/architecture/adr-033-protobuf-inter-module-comm.mdx @@ -14,8 +14,8 @@ Proposed ## Abstract This ADR introduces a system for permissioned inter-module communication leveraging the protobuf `Query` and `Msg` -service definitions defined in [ADR 021](/docs/sdk/v0.50/adr-021-protobuf-query-encoding) and -[ADR 031](/docs/sdk/v0.50/adr-031-msg-service) which provides: +service definitions defined in [ADR 021](/docs/sdk/v0.50/build/architecture/adr-021-protobuf-query-encoding) and +[ADR 031](/docs/sdk/v0.50/build/architecture/adr-031-msg-service) which provides: * stable protobuf based module interfaces to potentially later replace the keeper paradigm * stronger inter-module object capabilities (OCAPs) guarantees @@ -51,7 +51,7 @@ just a simple string. So the `x/upgrade` module could mint tokens for the `x/sta ## Decision -Based on [ADR-021](/docs/sdk/v0.50/adr-021-protobuf-query-encoding) and [ADR-031](/docs/sdk/v0.50/adr-031-msg-service), we introduce the +Based on [ADR-021](/docs/sdk/v0.50/build/architecture/adr-021-protobuf-query-encoding) and [ADR-031](/docs/sdk/v0.50/build/architecture/adr-031-msg-service), we introduce the Inter-Module Communication framework for secure module authorization and OCAPs. When implemented, this could also serve as an alternative to the existing paradigm of passing keepers between modules. The approach outlined here-in is intended to form the basis of a Cosmos SDK v1.0 that provides the necessary @@ -63,8 +63,8 @@ addressed as amendments to this ADR. ### New "Keeper" Paradigm -In [ADR 021](/docs/sdk/v0.50/adr-021-protobuf-query-encoding), a mechanism for using protobuf service definitions to define queriers -was introduced and in [ADR 31](/docs/sdk/v0.50/adr-031-msg-service), a mechanism for using protobuf service to define `Msg`s was added. +In [ADR 021](/docs/sdk/v0.50/build/architecture/adr-021-protobuf-query-encoding), a mechanism for using protobuf service definitions to define queriers +was introduced and in [ADR 31](/docs/sdk/v0.50/build/architecture/adr-031-msg-service), a mechanism for using protobuf service to define `Msg`s was added. Protobuf service definitions generate two golang interfaces representing the client and server sides of a service plus some helper code. Here is a minimal example for the bank `cosmos.bank.Msg/Send` message type: @@ -80,7 +80,7 @@ type MsgServer interface { } ``` -[ADR 021](/docs/sdk/v0.50/adr-021-protobuf-query-encoding) and [ADR 31](/docs/sdk/v0.50/adr-031-msg-service) specifies how modules can implement the generated `QueryServer` +[ADR 021](/docs/sdk/v0.50/build/architecture/adr-021-protobuf-query-encoding) and [ADR 31](/docs/sdk/v0.50/build/architecture/adr-031-msg-service) specifies how modules can implement the generated `QueryServer` and `MsgServer` interfaces as replacements for the legacy queriers and `Msg` handlers respectively. In this ADR we explain how modules can make queries and send `Msg`s to other modules using the generated `QueryClient` @@ -172,7 +172,7 @@ denom prefix being restricted to certain modules (as discussed in ### `ModuleKey`s and `ModuleID`s A `ModuleKey` can be thought of as a "private key" for a module account and a `ModuleID` can be thought of as the -corresponding "public key". From the [ADR 028](/docs/sdk/v0.50/adr-028-public-key-addresses), modules can have both a root module account and any number of sub-accounts +corresponding "public key". From the [ADR 028](/docs/sdk/v0.50/build/architecture/adr-028-public-key-addresses), modules can have both a root module account and any number of sub-accounts or derived accounts that can be used for different pools (ex. staking pools) or managed accounts (ex. group accounts). We can also think of module sub-accounts as similar to derived keys - there is a root key and then some derivation path. `ModuleID` is a simple struct which contains the module name and optional "derivation" path, @@ -287,7 +287,7 @@ return f(ctx, args, reply) ### `AppModule` Wiring and Requirements -In [ADR 031](/docs/sdk/v0.50/adr-031-msg-service), the `AppModule.RegisterService(Configurator)` method was introduced. To support +In [ADR 031](/docs/sdk/v0.50/build/architecture/adr-031-msg-service), the `AppModule.RegisterService(Configurator)` method was introduced. To support inter-module communication, we extend the `Configurator` interface to pass in the `ModuleKey` and to allow modules to specify their dependencies on other modules using `RequireServer()`: @@ -448,8 +448,8 @@ replacing `Keeper` interfaces altogether. ## References -* [ADR 021](/docs/sdk/v0.50/adr-021-protobuf-query-encoding) -* [ADR 031](/docs/sdk/v0.50/adr-031-msg-service) -* [ADR 028](/docs/sdk/v0.50/adr-028-public-key-addresses) +* [ADR 021](/docs/sdk/v0.50/build/architecture/adr-021-protobuf-query-encoding) +* [ADR 031](/docs/sdk/v0.50/build/architecture/adr-031-msg-service) +* [ADR 028](/docs/sdk/v0.50/build/architecture/adr-028-public-key-addresses) * [ADR 030 draft](https://github.com/cosmos/cosmos-sdk/pull/7105) * [Object-Capability Model](https://docs.network.com/main/core/ocap) diff --git a/docs/sdk/v0.53/build/architecture/adr-042-group-module.mdx b/docs/sdk/v0.53/build/architecture/adr-042-group-module.mdx index 39db92e0..119e46b1 100644 --- a/docs/sdk/v0.53/build/architecture/adr-042-group-module.mdx +++ b/docs/sdk/v0.53/build/architecture/adr-042-group-module.mdx @@ -25,7 +25,7 @@ The legacy amino multi-signature mechanism of the Cosmos SDK has certain limitat * It requires `legacy_amino` sign mode ([#8141](https://github.com/cosmos/cosmos-sdk/issues/8141)). While the group module is not meant to be a total replacement for the current multi-signature accounts, it provides a solution to the limitations described above, with a more flexible key management system where keys can be added, updated or removed, as well as configurable thresholds. -It's meant to be used with other access control modules such as [`x/feegrant`](/docs/sdk/v0.50/adr-029-fee-grant-module) ans [`x/authz`](/docs/sdk/v0.53/build/architecture/adr-030-authz-module) to simplify key management for individuals and organizations. +It's meant to be used with other access control modules such as [`x/feegrant`](/docs/sdk/v0.50/build/architecture/adr-029-fee-grant-module) ans [`x/authz`](/docs/sdk/v0.53/build/architecture/adr-030-authz-module) to simplify key management for individuals and organizations. The proof of concept of the group module can be found in [Link](https://github.com/regen-network/regen-ledger/tree/master/proto/regen/group/v1alpha1) and [Link](https://github.com/regen-network/regen-ledger/tree/master/x/group). diff --git a/docs/sdk/v0.53/build/architecture/adr-044-protobuf-updates-guidelines.mdx b/docs/sdk/v0.53/build/architecture/adr-044-protobuf-updates-guidelines.mdx index 6efea04d..2fe59048 100644 --- a/docs/sdk/v0.53/build/architecture/adr-044-protobuf-updates-guidelines.mdx +++ b/docs/sdk/v0.53/build/architecture/adr-044-protobuf-updates-guidelines.mdx @@ -83,7 +83,7 @@ Protobuf supports the [`deprecated` field option](https://developers.google.com/ As an example, the Cosmos SDK v0.42 to v0.43 update contained two Protobuf-breaking changes, listed below. Instead of bumping the package versions from `v1beta1` to `v1`, the SDK team decided to follow this guideline, by reverting the breaking changes, marking those changes as deprecated, and modifying the node implementation when processing messages with deprecated fields. More specifically: * The Cosmos SDK recently removed support for [time-based software upgrades](https://github.com/cosmos/cosmos-sdk/pull/8849). As such, the `time` field has been marked as deprecated in `cosmos.upgrade.v1beta1.Plan`. Moreover, the node will reject any proposal containing an upgrade Plan whose `time` field is non-empty. -* The Cosmos SDK now supports [governance split votes](/docs/sdk/v0.50/adr-037-gov-split-vote). When querying for votes, the returned `cosmos.gov.v1beta1.Vote` message has its `option` field (used for 1 vote option) deprecated in favor of its `options` field (allowing multiple vote options). Whenever possible, the SDK still populates the deprecated `option` field, that is, if and only if the `len(options) == 1` and `options[0].Weight == 1.0`. +* The Cosmos SDK now supports [governance split votes](/docs/sdk/v0.50/build/architecture/adr-037-gov-split-vote). When querying for votes, the returned `cosmos.gov.v1beta1.Vote` message has its `option` field (used for 1 vote option) deprecated in favor of its `options` field (allowing multiple vote options). Whenever possible, the SDK still populates the deprecated `option` field, that is, if and only if the `len(options) == 1` and `options[0].Weight == 1.0`. #### 3. Fields MUST NOT be renamed diff --git a/docs/sdk/v0.53/build/architecture/adr-045-check-delivertx-middlewares.mdx b/docs/sdk/v0.53/build/architecture/adr-045-check-delivertx-middlewares.mdx index cf66e380..fb65919a 100644 --- a/docs/sdk/v0.53/build/architecture/adr-045-check-delivertx-middlewares.mdx +++ b/docs/sdk/v0.53/build/architecture/adr-045-check-delivertx-middlewares.mdx @@ -256,12 +256,12 @@ While the app developer can define and compose the middlewares of their choice, | TxDecoderMiddleware | This middleware takes in transaction raw bytes, and decodes them into a `sdk.Tx`. It replaces the `baseapp.txDecoder` field, so that BaseApp stays as thin as possible. Since most middlewares read the contents of the `sdk.Tx`, the TxDecoderMiddleware should be run first in the middleware stack. | | `{Antehandlers}` | Each antehandler is converted to its own middleware. These middlewares perform signature verification, fee deductions and other validations on the incoming transaction. | | IndexEventsTxMiddleware | This is a simple middleware that chooses which events to index in Tendermint. Replaces `baseapp.indexEvents` (which unfortunately still exists in baseapp too, because it's used to index Begin/EndBlock events) | -| RecoveryTxMiddleware | This index recovers from panics. It replaces baseapp.runTx's panic recovery described in [ADR-022](/docs/sdk/v0.50/adr-022-custom-panic-handling). | +| RecoveryTxMiddleware | This index recovers from panics. It replaces baseapp.runTx's panic recovery described in [ADR-022](/docs/sdk/v0.50/build/architecture/adr-022-custom-panic-handling). | | GasTxMiddleware | This replaces the [`Setup`](https://github.com/cosmos/cosmos-sdk/blob/v0.43.0/x/auth/ante/setup.go) Antehandler. It sets a GasMeter on sdk.Context. Note that before, GasMeter was set on sdk.Context inside the antehandlers, and there was some mess around the fact that antehandlers had their own panic recovery system so that the GasMeter could be read by baseapp's recovery system. Now, this mess is all removed: one middleware sets GasMeter, another one handles recovery. | ### Similarities and Differences between Antehandlers and Middlewares -The middleware-based design builds upon the existing antehandlers design described in [ADR-010](/docs/sdk/v0.50/adr-010-modular-antehandler). Even though the final decision of ADR-010 was to go with the "Simple Decorators" approach, the middleware design is actually very similar to the other [Decorator Pattern](/docs/sdk/v0.50/adr-010-modular-antehandler#decorator-pattern) proposal, also used in [weave](https://github.com/iov-one/weave). +The middleware-based design builds upon the existing antehandlers design described in [ADR-010](/docs/sdk/v0.50/build/architecture/adr-010-modular-antehandler). Even though the final decision of ADR-010 was to go with the "Simple Decorators" approach, the middleware design is actually very similar to the other [Decorator Pattern](/docs/sdk/v0.50/build/architecture/adr-010-modular-antehandler#decorator-pattern) proposal, also used in [weave](https://github.com/iov-one/weave). #### Similarities with Antehandlers diff --git a/docs/sdk/v0.53/build/architecture/adr-050-sign-mode-textual-annex1.mdx b/docs/sdk/v0.53/build/architecture/adr-050-sign-mode-textual-annex1.mdx index e41c0c42..489ecc13 100644 --- a/docs/sdk/v0.53/build/architecture/adr-050-sign-mode-textual-annex1.mdx +++ b/docs/sdk/v0.53/build/architecture/adr-050-sign-mode-textual-annex1.mdx @@ -65,7 +65,7 @@ Value Renderers describe how values of different Protobuf types should be encode ### `repeated` -* Applies to all `repeated` fields, except `cosmos.tx.v1beta1.TxBody#Messages`, which has a particular encoding (see [ADR-050](/docs/sdk/v0.50/adr-050-sign-mode-textual)). +* Applies to all `repeated` fields, except `cosmos.tx.v1beta1.TxBody#Messages`, which has a particular encoding (see [ADR-050](/docs/sdk/v0.50/build/architecture/adr-050-sign-mode-textual)). * A repeated type has the following template: ``` @@ -282,7 +282,7 @@ The number 35 was chosen because it is the longest length where the hashed-and-p * byte arrays starting from length 36 will be be hashed to 32 bytes, which is 64 hex characters plus 15 spaces, and with the `SHA-256=` prefix, it takes 87 characters. Also, secp256k1 public keys have length 33, so their Textual representation is not their hashed value, which we would like to avoid. -Note: Data longer than 35 bytes are not rendered in a way that can be inverted. See ADR-050's [section about invertability](/docs/sdk/v0.50/adr-050-sign-mode-textual#invertible-rendering) for a discussion. +Note: Data longer than 35 bytes are not rendered in a way that can be inverted. See ADR-050's [section about invertability](/docs/sdk/v0.50/build/architecture/adr-050-sign-mode-textual#invertible-rendering) for a discussion. #### Examples diff --git a/docs/sdk/v0.53/build/architecture/adr-050-sign-mode-textual.mdx b/docs/sdk/v0.53/build/architecture/adr-050-sign-mode-textual.mdx index e452978c..86b60a01 100644 --- a/docs/sdk/v0.53/build/architecture/adr-050-sign-mode-textual.mdx +++ b/docs/sdk/v0.53/build/architecture/adr-050-sign-mode-textual.mdx @@ -30,7 +30,7 @@ This ADR specifies SIGN\_MODE\_TEXTUAL, a new string-based sign mode that is tar ## Context -Protobuf-based SIGN\_MODE\_DIRECT was introduced in [ADR-020](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding) and is intended to replace SIGN\_MODE\_LEGACY\_AMINO\_JSON in most situations, such as mobile wallets and CLI keyrings. However, the [Ledger](https://www.ledger.com/) hardware wallet is still using SIGN\_MODE\_LEGACY\_AMINO\_JSON for displaying the sign bytes to the user. Hardware wallets cannot transition to SIGN\_MODE\_DIRECT as: +Protobuf-based SIGN\_MODE\_DIRECT was introduced in [ADR-020](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding) and is intended to replace SIGN\_MODE\_LEGACY\_AMINO\_JSON in most situations, such as mobile wallets and CLI keyrings. However, the [Ledger](https://www.ledger.com/) hardware wallet is still using SIGN\_MODE\_LEGACY\_AMINO\_JSON for displaying the sign bytes to the user. Hardware wallets cannot transition to SIGN\_MODE\_DIRECT as: * SIGN\_MODE\_DIRECT is binary-based and thus not suitable for display to end-users. Technically, hardware wallets could simply display the sign bytes to the user. But this would be considered as blind signing, and is a security concern. * hardware cannot decode the protobuf sign bytes due to memory constraints, as the Protobuf definitions would need to be embedded on the hardware device. @@ -56,7 +56,7 @@ or to introduce or conclude a larger grouping. The text can contain the full range of Unicode code points, including control characters and nul. The device is responsible for deciding how to display characters it cannot render natively. -See [annex 2](/docs/sdk/v0.50/adr-050-sign-mode-textual-annex2) for guidance. +See [annex 2](/docs/sdk/v0.50/build/architecture/adr-050-sign-mode-textual-annex2) for guidance. Screens have a non-negative indentation level to signal composite or nested structures. Indentation level zero is the top level. @@ -301,7 +301,7 @@ where: This is to prevent transaction hash malleability. The point #1 about invertiblity assures that transaction `body` and `auth_info` values are not malleable, but the transaction hash still might be malleable with point #1 only, because the SIGN\_MODE\_TEXTUAL strings don't follow the byte ordering defined in `body_bytes` and `auth_info_bytes`. Without this hash, a malicious validator or exchange could intercept a transaction, modify its transaction hash *after* the user signed it using SIGN\_MODE\_TEXTUAL (by tweaking the byte ordering inside `body_bytes` or `auth_info_bytes`), and then submit it to Tendermint. -By including this hash in the SIGN\_MODE\_TEXTUAL signing payload, we keep the same level of guarantees as [SIGN\_MODE\_DIRECT](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding). +By including this hash in the SIGN\_MODE\_TEXTUAL signing payload, we keep the same level of guarantees as [SIGN\_MODE\_DIRECT](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding). These bytes are only shown in expert mode, hence the leading `*`. @@ -322,7 +322,7 @@ The current spec version is defined in the "Status" section, on the top of this ## Additional Formatting by the Hardware Device -See [annex 2](/docs/sdk/v0.50/adr-050-sign-mode-textual-annex2). +See [annex 2](/docs/sdk/v0.50/build/architecture/adr-050-sign-mode-textual-annex2). ## Examples @@ -357,14 +357,14 @@ SIGN\_MODE\_TEXTUAL is purely additive, and doesn't break any backwards compatib ## Further Discussions -* Some details on value renderers need to be polished, see [Annex 1](/docs/sdk/v0.50/adr-050-sign-mode-textual-annex1). +* Some details on value renderers need to be polished, see [Annex 1](/docs/sdk/v0.50/build/architecture/adr-050-sign-mode-textual-annex1). * Are ledger apps able to support both SIGN\_MODE\_LEGACY\_AMINO\_JSON and SIGN\_MODE\_TEXTUAL at the same time? * Open question: should we add a Protobuf field option to allow app developers to overwrite the textual representation of certain Protobuf fields and message? This would be similar to Ethereum's [EIP4430](https://github.com/ethereum/EIPs/pull/4430), where the contract developer decides on the textual representation. * Internationalization. ## References -* [Annex 1](/docs/sdk/v0.50/adr-050-sign-mode-textual-annex1) +* [Annex 1](/docs/sdk/v0.50/build/architecture/adr-050-sign-mode-textual-annex1) * Initial discussion: [Link](https://github.com/cosmos/cosmos-sdk/issues/6513) diff --git a/docs/sdk/v0.53/build/architecture/adr-054-semver-compatible-modules.mdx b/docs/sdk/v0.53/build/architecture/adr-054-semver-compatible-modules.mdx index e16824b6..c998f963 100644 --- a/docs/sdk/v0.53/build/architecture/adr-054-semver-compatible-modules.mdx +++ b/docs/sdk/v0.53/build/architecture/adr-054-semver-compatible-modules.mdx @@ -40,7 +40,7 @@ In order to achieve this, we need to solve the following problems: many modules in the SDK independently 3. pernicious minor version incompatibilities introduced through correctly [evolving protobuf schemas](https://developers.google.com/protocol-buffers/docs/proto3#updating) - without correct [unknown field filtering](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding#unknown-field-filtering) + without correct [unknown field filtering](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding#unknown-field-filtering) Note that all the following discussion assumes that the proto file versioning and state machine versioning of a module are distinct in that: @@ -150,7 +150,7 @@ with this update and use that for `foo/v2`. But this change is state machine breaking for `v1`. It requires changing the `ValidateBasic` method to reject the case where `amount` is zero, and it adds the `condition` field which should be rejected based -on [ADR 020 unknown field filtering](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding#unknown-field-filtering). +on [ADR 020 unknown field filtering](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding#unknown-field-filtering). So adding these changes as a patch on `v1` is actually incorrect based on semantic versioning. Chains that want to stay on `v1` of `foo` should not be importing these changes because they are incorrect for `v1.` @@ -179,9 +179,9 @@ on `v1` or `v2` and dynamically, it could choose to only use `condition` when `foo/v2` is available. Even if `bar/v2` were able to perform this check, however, how do we know that it is always performing the check properly. Without some sort of -framework-level [unknown field filtering](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding#unknown-field-filtering), +framework-level [unknown field filtering](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding#unknown-field-filtering), it is hard to know whether these pernicious hard to detect bugs are getting into -our app and a client-server layer such as [ADR 033: Inter-Module Communication](/docs/sdk/v0.50/adr-033-protobuf-inter-module-comm) +our app and a client-server layer such as [ADR 033: Inter-Module Communication](/docs/sdk/v0.50/build/architecture/adr-033-protobuf-inter-module-comm) may be needed to do this. ## Solutions @@ -274,9 +274,9 @@ of care to avoid these sorts of issues. This approach in and of itself does little to address any potential minor version incompatibilities and the -requisite [unknown field filtering](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding#unknown-field-filtering). +requisite [unknown field filtering](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding#unknown-field-filtering). Likely some sort of client-server routing layer which does this check such as -[ADR 033: Inter-Module communication](/docs/sdk/v0.50/adr-033-protobuf-inter-module-comm) +[ADR 033: Inter-Module communication](/docs/sdk/v0.50/build/architecture/adr-033-protobuf-inter-module-comm) is required to make sure that this is done properly. We could then allow modules to perform a runtime check given a `MsgClient`, ex: @@ -307,7 +307,7 @@ result in an undesirable performance hit depending on how complex this logic is. An alternate approach to solving the versioning problem is to change how protobuf code is generated and move modules mostly or completely in the direction of inter-module communication as described -in [ADR 033](/docs/sdk/v0.50/adr-033-protobuf-inter-module-comm). +in [ADR 033](/docs/sdk/v0.50/build/architecture/adr-033-protobuf-inter-module-comm). In this paradigm, a module could generate all the types it needs internally - including the API types of other modules - and talk to other modules via a client-server boundary. For instance, if `bar` needs to talk to `foo`, it could generate its own version of `MsgDoSomething` as `bar/internal/foo/v1.MsgDoSomething` and just pass this to the @@ -326,7 +326,7 @@ to `foo/internal.MsgDoSomething` would be marshaling and unmarshaling in the ADR we needed to expose protobuf types in `Keeper` interfaces because the whole point is to try to keep these types `internal/` so that we don't end up with all the import version incompatibilities we've described above. However, because of the issue with minor version incompatibilities and the need -for [unknown field filtering](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding#unknown-field-filtering), +for [unknown field filtering](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding#unknown-field-filtering), sticking with the `Keeper` paradigm instead of ADR 033 may be unviable to begin with. A more performant solution (that could maybe be adapted to work with `Keeper` interfaces) would be to only expose @@ -412,7 +412,7 @@ and would also need to use special tags and replace directives to make sure that versions. Note, however, that all of these ad-hoc approaches, would be vulnerable to the minor version compatibility issues -described above unless [unknown field filtering](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding#unknown-field-filtering) +described above unless [unknown field filtering](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding#unknown-field-filtering) is properly addressed. ### Approach D) Avoid protobuf generated code in public APIs @@ -462,7 +462,7 @@ Other downsides to this approach are: The latest **DRAFT** proposal is: -1. we are alignment on adopting [ADR 033](/docs/sdk/v0.50/adr-033-protobuf-inter-module-comm) not just as an addition to the +1. we are alignment on adopting [ADR 033](/docs/sdk/v0.50/build/architecture/adr-033-protobuf-inter-module-comm) not just as an addition to the framework, but as a core replacement to the keeper paradigm entirely. 2. the ADR 033 inter-module router will accommodate any variation of approach (A) or (B) given the following rules: a. if the client type is the same as the server type then pass it directly through, @@ -525,7 +525,7 @@ uint64 ### Unknown Field Filtering -To correctly perform [unknown field filtering](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding#unknown-field-filtering), +To correctly perform [unknown field filtering](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding#unknown-field-filtering), the inter-module router can do one of the following: * use the `protoreflect` API for messages which support that @@ -588,7 +588,7 @@ We propose defining these dependencies in the proto options of the module config We will also need to define how interface methods are defined on types that are serialized as `google.protobuf.Any`'s. In light of the desire to support modules in other languages, we may want to think of solutions that will accommodate -other languages such as plugins described briefly in [ADR 033](/docs/sdk/v0.50/adr-033-protobuf-inter-module-comm#internal-methods). +other languages such as plugins described briefly in [ADR 033](/docs/sdk/v0.50/build/architecture/adr-033-protobuf-inter-module-comm#internal-methods). ### Testing @@ -795,5 +795,5 @@ Key outstanding discussions if we do adopt that direction are: * [Link](https://github.com/cosmos/cosmos-sdk/discussions/10368) * [Link](https://github.com/cosmos/cosmos-sdk/pull/11340) * [Link](https://github.com/cosmos/cosmos-sdk/issues/11899) -* [ADR 020](/docs/sdk/v0.50/adr-020-protobuf-transaction-encoding) -* [ADR 033](/docs/sdk/v0.50/adr-033-protobuf-inter-module-comm) +* [ADR 020](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding) +* [ADR 033](/docs/sdk/v0.50/build/architecture/adr-033-protobuf-inter-module-comm) diff --git a/docs/sdk/v0.53/build/architecture/adr-065-store-v2.mdx b/docs/sdk/v0.53/build/architecture/adr-065-store-v2.mdx index c97f2b48..431a1843 100644 --- a/docs/sdk/v0.53/build/architecture/adr-065-store-v2.mdx +++ b/docs/sdk/v0.53/build/architecture/adr-065-store-v2.mdx @@ -67,9 +67,9 @@ See the [Storage Discussion](https://github.com/cosmos/cosmos-sdk/discussions/13 ## Alternatives -There was a previous attempt to refactor the storage layer described in [ADR-040](/docs/sdk/v0.50/adr-040-storage-and-smt-state-commitments). +There was a previous attempt to refactor the storage layer described in [ADR-040](/docs/sdk/v0.50/build/architecture/adr-040-storage-and-smt-state-commitments). However, this approach mainly stems on the short comings of IAVL and various performance -issues around it. While there was a (partial) implementation of [ADR-040](/docs/sdk/v0.50/adr-040-storage-and-smt-state-commitments), +issues around it. While there was a (partial) implementation of [ADR-040](/docs/sdk/v0.50/build/architecture/adr-040-storage-and-smt-state-commitments), it was never adopted for a variety of reasons, such as the reliance on using an SMT, which was more in a research phase, and some design choices that couldn't be fully agreed upon, such as the snap-shotting mechanism that would result in @@ -77,7 +77,7 @@ massive state bloat. ## Decision -We propose to build upon some of the great ideas introduced in [ADR-040](/docs/sdk/v0.50/adr-040-storage-and-smt-state-commitments), +We propose to build upon some of the great ideas introduced in [ADR-040](/docs/sdk/v0.50/build/architecture/adr-040-storage-and-smt-state-commitments), while being a bit more flexible with the underlying implementations and overall less intrusive. Specifically, we propose to: diff --git a/docs/sdk/v0.53/build/building-modules/beginblock-endblock.mdx b/docs/sdk/v0.53/build/building-modules/beginblock-endblock.mdx index 553a5328..72bedf43 100644 --- a/docs/sdk/v0.53/build/building-modules/beginblock-endblock.mdx +++ b/docs/sdk/v0.53/build/building-modules/beginblock-endblock.mdx @@ -11,7 +11,7 @@ title: BeginBlocker and EndBlocker **Pre-requisite Readings** -* [Module Manager](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) +* [Module Manager](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) @@ -21,7 +21,7 @@ title: BeginBlocker and EndBlocker In 0.47.0, Prepare and Process Proposal were added that allow app developers to do arbitrary work at those phases, but they do not influence the work that will be done in BeginBlock. If an application required `BeginBlock` to execute prior to any sort of work is done then this is not possible today (0.50.0). -When needed, `BeginBlocker` and `EndBlocker` are implemented as part of the [`HasBeginBlocker`, `HasABCIEndBlocker` and `EndBlocker` interfaces](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#appmodule). This means either can be left-out if not required. The `BeginBlock` and `EndBlock` methods of the interface implemented in `module.go` generally defer to `BeginBlocker` and `EndBlocker` methods respectively, which are usually implemented in `abci.go`. +When needed, `BeginBlocker` and `EndBlocker` are implemented as part of the [`HasBeginBlocker`, `HasABCIEndBlocker` and `EndBlocker` interfaces](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#appmodule). This means either can be left-out if not required. The `BeginBlock` and `EndBlock` methods of the interface implemented in `module.go` generally defer to `BeginBlocker` and `EndBlocker` methods respectively, which are usually implemented in `abci.go`. The actual implementation of `BeginBlocker` and `EndBlocker` in `abci.go` are very similar to that of a [`Msg` service](/docs/sdk/v0.53/build/building-modules/msg-services): @@ -31,7 +31,7 @@ The actual implementation of `BeginBlocker` and `EndBlocker` in `abci.go` are ve A specific type of `EndBlocker` is available to return validator updates to the underlying consensus engine in the form of an [`[]abci.ValidatorUpdates`](https://docs.cometbft.com/v0.37/spec/abci/abci++_methods#endblock). This is the preferred way to implement custom validator changes. -It is possible for developers to define the order of execution between the `BeginBlocker`/`EndBlocker` functions of each of their application's modules via the module's manager `SetOrderBeginBlocker`/`SetOrderEndBlocker` methods. For more on the module manager, click [here](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager). +It is possible for developers to define the order of execution between the `BeginBlocker`/`EndBlocker` functions of each of their application's modules via the module's manager `SetOrderBeginBlocker`/`SetOrderEndBlocker` methods. For more on the module manager, click [here](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager). See an example implementation of `BeginBlocker` from the `distribution` module: diff --git a/docs/sdk/v0.53/build/building-modules/genesis.mdx b/docs/sdk/v0.53/build/building-modules/genesis.mdx index 00bc6ca6..b674751b 100644 --- a/docs/sdk/v0.53/build/building-modules/genesis.mdx +++ b/docs/sdk/v0.53/build/building-modules/genesis.mdx @@ -11,7 +11,7 @@ Modules generally handle a subset of the state and, as such, they need to define **Pre-requisite Readings** -* [Module Manager](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) +* [Module Manager](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) * [Keepers](/docs/sdk/v0.53/build/building-modules/keeper) @@ -608,13 +608,13 @@ return accounts, nil ## Other Genesis Methods -Other than the methods related directly to `GenesisState`, module developers are expected to implement two other methods as part of the [`AppModuleGenesis` interface](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#appmodulegenesis) (only if the module needs to initialize a subset of state in genesis). These methods are [`InitGenesis`](#initgenesis) and [`ExportGenesis`](#exportgenesis). +Other than the methods related directly to `GenesisState`, module developers are expected to implement two other methods as part of the [`AppModuleGenesis` interface](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#appmodulegenesis) (only if the module needs to initialize a subset of state in genesis). These methods are [`InitGenesis`](#initgenesis) and [`ExportGenesis`](#exportgenesis). ### `InitGenesis` The `InitGenesis` method is executed during [`InitChain`](/docs/sdk/v0.53//learn/advanced/baseapp#initchain) when the application is first started. Given a `GenesisState`, it initializes the subset of the state managed by the module by using the module's [`keeper`](/docs/sdk/v0.53/build/building-modules/keeper) setter function on each parameter within the `GenesisState`. -The [module manager](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) of the application is responsible for calling the `InitGenesis` method of each of the application's modules in order. This order is set by the application developer via the manager's `SetOrderGenesisMethod`, which is called in the [application's constructor function](/docs/sdk/v0.53//learn/beginner/app-anatomy#constructor-function). +The [module manager](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) of the application is responsible for calling the `InitGenesis` method of each of the application's modules in order. This order is set by the application developer via the manager's `SetOrderGenesisMethod`, which is called in the [application's constructor function](/docs/sdk/v0.53//learn/beginner/app-anatomy#constructor-function). See an example of `InitGenesis` from the `auth` module: diff --git a/docs/sdk/v0.53/build/building-modules/intro.mdx b/docs/sdk/v0.53/build/building-modules/intro.mdx index 5dc7fd1e..7b9165d7 100644 --- a/docs/sdk/v0.53/build/building-modules/intro.mdx +++ b/docs/sdk/v0.53/build/building-modules/intro.mdx @@ -10,7 +10,7 @@ Modules define most of the logic of Cosmos SDK applications. Developers compose **Pre-requisite Readings** -* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.53/learn/beginner/app-anatomy) +* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.53/learn/beginner/app-anatomyy) * [Lifecycle of a Cosmos SDK transaction](/docs/sdk/v0.53/learn/beginner/tx-lifecycle) @@ -299,6 +299,6 @@ Modules are by convention defined in the `./x/` subfolder (e.g. the `bank` modul * A [query service](/docs/sdk/v0.53/build/building-modules/query-services), used to process user queries when they are routed to the module by [`BaseApp`](/docs/sdk/v0.53/learn/advanced/baseapp#query-routing). * Interfaces, for end users to query the subset of the state defined by the module and create `message`s of the custom types defined in the module. -In addition to these components, modules implement the `AppModule` interface in order to be managed by the [`module manager`](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager). +In addition to these components, modules implement the `AppModule` interface in order to be managed by the [`module manager`](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager). Please refer to the [structure document](/docs/sdk/v0.53/build/building-modules/structure) to learn about the recommended structure of a module's directory. diff --git a/docs/sdk/v0.53/build/building-modules/invariants.mdx b/docs/sdk/v0.53/build/building-modules/invariants.mdx index 675fd867..08cca567 100644 --- a/docs/sdk/v0.53/build/building-modules/invariants.mdx +++ b/docs/sdk/v0.53/build/building-modules/invariants.mdx @@ -82,7 +82,7 @@ return DepositsInvariant(k)(ctx) } ``` -Finally, module developers need to implement the `RegisterInvariants` method as part of the [`AppModule` interface](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#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): +Finally, module developers need to implement the `RegisterInvariants` method as part of the [`AppModule` interface](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#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): ```go expandable package keeper diff --git a/docs/sdk/v0.53/build/building-modules/messages-and-queries.mdx b/docs/sdk/v0.53/build/building-modules/messages-and-queries.mdx index 367274c5..a43a93c2 100644 --- a/docs/sdk/v0.53/build/building-modules/messages-and-queries.mdx +++ b/docs/sdk/v0.53/build/building-modules/messages-and-queries.mdx @@ -240,9 +240,9 @@ The Cosmos SDK uses Protobuf definitions to generate client and server code: * `MsgServer` interface defines the server API for the `Msg` service and its implementation is described as part of the [`Msg` services](/docs/sdk/v0.53/build/building-modules/msg-services) documentation. * Structures are generated for all RPC request and response types. -A `RegisterMsgServer` method is also generated and should be used to register the module's `MsgServer` implementation in `RegisterServices` method from the [`AppModule` interface](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#appmodule). +A `RegisterMsgServer` method is also generated and should be used to register the module's `MsgServer` implementation in `RegisterServices` method from the [`AppModule` interface](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#appmodule). -In order for clients (CLI and grpc-gateway) to have these URLs registered, the Cosmos SDK provides the function `RegisterMsgServiceDesc(registry codectypes.InterfaceRegistry, sd *grpc.ServiceDesc)` that should be called inside module's [`RegisterInterfaces`](docs/sdk/v0.53/build/building-modules/module-manager#appmodulebasic) method, using the proto-generated `&_Msg_serviceDesc` as `*grpc.ServiceDesc` argument. +In order for clients (CLI and grpc-gateway) to have these URLs registered, the Cosmos SDK provides the function `RegisterMsgServiceDesc(registry codectypes.InterfaceRegistry, sd *grpc.ServiceDesc)` that should be called inside module's [`RegisterInterfaces`](docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#appmodulebasic) method, using the proto-generated `&_Msg_serviceDesc` as `*grpc.ServiceDesc` argument. ## Queries @@ -260,7 +260,7 @@ Here's an example of such a `Query` service definition: As `proto.Message`s, generated `Response` types implement by default `String()` method of [`fmt.Stringer`](https://pkg.go.dev/fmt#Stringer). -A `RegisterQueryServer` method is also generated and should be used to register the module's query server in the `RegisterServices` method from the [`AppModule` interface](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#appmodule). +A `RegisterQueryServer` method is also generated and should be used to register the module's query server in the `RegisterServices` method from the [`AppModule` interface](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#appmodule). ### Legacy Queries diff --git a/docs/sdk/v0.53/build/building-modules/module-manager.mdx b/docs/sdk/v0.53/build/building-modules/module-manager.mdx index 617c231d..b02097dc 100644 --- a/docs/sdk/v0.53/build/building-modules/module-manager.mdx +++ b/docs/sdk/v0.53/build/building-modules/module-manager.mdx @@ -5,7 +5,7 @@ title: Module Manager **Synopsis** -Cosmos SDK modules need to implement the [`AppModule` interfaces](#application-module-interfaces), in order to be managed by the application's [module manager](#docs/sdk/v0.53/build/building-modules/module-manager). The module manager plays an important role in [`message` and `query` routing](/docs/sdk/v0.53/learn/advanced/baseapp#routing), and allows application developers to set the order of execution of a variety of functions like [`PreBlocker`](/docs/sdk/v0.53/learn/beginner/app-anatomy#preblocker) and [`BeginBlocker` and `EndBlocker`](/docs/sdk/v0.53/learn/beginner/app-anatomy#begingblocker-and-endblocker). +Cosmos SDK modules need to implement the [`AppModule` interfaces](#application-module-interfaces), in order to be managed by the application's [module manager](#docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager). The module manager plays an important role in [`message` and `query` routing](/docs/sdk/v0.53/learn/advanced/baseapp#routing), and allows application developers to set the order of execution of a variety of functions like [`PreBlocker`](/docs/sdk/v0.53/learn/beginner/app-anatomyy#preblocker) and [`BeginBlocker` and `EndBlocker`](/docs/sdk/v0.53/learn/beginner/app-anatomyy#begingblocker-and-endblocker). @@ -47,7 +47,7 @@ The above interfaces are mostly embedding smaller interfaces (extension interfac * (legacy) [`module.HasInvariants`](#hasinvariants): The extension interface for registering invariants. * (legacy) [`module.HasConsensusVersion`](#hasconsensusversion): The extension interface for declaring a module consensus version. -The `AppModuleBasic` interface exists to define independent methods of the module, i.e. those that do not depend on other modules in the application. This allows for the construction of the basic application structure early in the application definition, generally in the `init()` function of the [main application file](/docs/sdk/v0.53/learn/beginner/app-anatomy#core-application-file). +The `AppModuleBasic` interface exists to define independent methods of the module, i.e. those that do not depend on other modules in the application. This allows for the construction of the basic application structure early in the application definition, generally in the `init()` function of the [main application file](/docs/sdk/v0.53/learn/beginner/app-anatomyy#core-application-file). The `AppModule` interface exists to define inter-dependent module methods. Many modules need to interact with other modules, typically through [`keeper`s](/docs/sdk/v0.53/build/building-modules/keeper), which means there is a need for an interface where modules list their `keeper`s and other methods that require a reference to another module's object. `AppModule` interface extension, such as `HasBeginBlocker` and `HasEndBlocker`, also enables the module manager to set the order of execution between module's methods like `BeginBlock` and `EndBlock`, which is important in cases where the order of execution between modules matters in the context of the application. @@ -13274,9 +13274,9 @@ return out It implements the following methods: -* `NewBasicManager(modules ...AppModuleBasic)`: Constructor function. It takes a list of the application's `AppModuleBasic` and builds a new `BasicManager`. This function is generally called in the `init()` function of [`app.go`](/docs/sdk/v0.53/learn/beginner/app-anatomy#core-application-file) to quickly initialize the independent elements of the application's modules (click [here](https://github.com/cosmos/gaia/blob/main/app/app.go#L59-L74) to see an example). +* `NewBasicManager(modules ...AppModuleBasic)`: Constructor function. It takes a list of the application's `AppModuleBasic` and builds a new `BasicManager`. This function is generally called in the `init()` function of [`app.go`](/docs/sdk/v0.53/learn/beginner/app-anatomyy#core-application-file) to quickly initialize the independent elements of the application's modules (click [here](https://github.com/cosmos/gaia/blob/main/app/app.go#L59-L74) to see an example). * `NewBasicManagerFromManager(manager *Manager, customModuleBasics map[string]AppModuleBasic)`: Contructor function. It creates a new `BasicManager` from a `Manager`. The `BasicManager` will contain all `AppModuleBasic` from the `AppModule` manager using `CoreAppModuleBasicAdaptor` whenever possible. Module's `AppModuleBasic` can be overridden by passing a custom AppModuleBasic map -* `RegisterLegacyAminoCodec(cdc *codec.LegacyAmino)`: Registers the [`codec.LegacyAmino`s](/docs/sdk/v0.53/learn/advanced/encoding#amino) of each of the application's `AppModuleBasic`. This function is usually called early on in the [application's construction](/docs/sdk/v0.53/learn/beginner/app-anatomy#constructor). +* `RegisterLegacyAminoCodec(cdc *codec.LegacyAmino)`: Registers the [`codec.LegacyAmino`s](/docs/sdk/v0.53/learn/advanced/encoding#amino) of each of the application's `AppModuleBasic`. This function is usually called early on in the [application's construction](/docs/sdk/v0.53/learn/beginner/app-anatomyy#constructor). * `RegisterInterfaces(registry codectypes.InterfaceRegistry)`: Registers interface types and implementations of each of the application's `AppModuleBasic`. * `DefaultGenesis(cdc codec.JSONCodec)`: Provides default genesis information for modules in the application by calling the [`DefaultGenesis(cdc codec.JSONCodec)`](/docs/sdk/v0.53/build/building-modules/genesis#defaultgenesis) function of each module. It only calls the modules that implements the `HasGenesisBasics` interfaces. * `ValidateGenesis(cdc codec.JSONCodec, txEncCfg client.TxEncodingConfig, genesis map[string]json.RawMessage)`: Validates the genesis information modules by calling the [`ValidateGenesis(codec.JSONCodec, client.TxEncodingConfig, json.RawMessage)`](/docs/sdk/v0.53/build/building-modules/genesis#validategenesis) function of modules implementing the `HasGenesisBasics` interface. diff --git a/docs/sdk/v0.53/build/building-modules/msg-services.mdx b/docs/sdk/v0.53/build/building-modules/msg-services.mdx index 92dcff9b..7104bd08 100644 --- a/docs/sdk/v0.53/build/building-modules/msg-services.mdx +++ b/docs/sdk/v0.53/build/building-modules/msg-services.mdx @@ -11,7 +11,7 @@ A Protobuf `Msg` service processes [messages](/docs/sdk/v0.53/build/building-mod **Pre-requisite Readings** -* [Module Manager](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) +* [Module Manager](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) * [Messages and Queries](/docs/sdk/v0.53/build/building-modules/messages-and-queries) diff --git a/docs/sdk/v0.53/build/building-modules/preblock.mdx b/docs/sdk/v0.53/build/building-modules/preblock.mdx index a2dbc902..459166ee 100644 --- a/docs/sdk/v0.53/build/building-modules/preblock.mdx +++ b/docs/sdk/v0.53/build/building-modules/preblock.mdx @@ -10,7 +10,7 @@ title: PreBlocker **Pre-requisite Readings** -* [Module Manager](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) +* [Module Manager](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) diff --git a/docs/sdk/v0.53/build/building-modules/query-services.mdx b/docs/sdk/v0.53/build/building-modules/query-services.mdx index c1abdccf..37d223c8 100644 --- a/docs/sdk/v0.53/build/building-modules/query-services.mdx +++ b/docs/sdk/v0.53/build/building-modules/query-services.mdx @@ -11,7 +11,7 @@ A Protobuf Query service processes [`queries`](/docs/sdk/v0.53/build/building-mo **Pre-requisite Readings** -* [Module Manager](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) +* [Module Manager](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) * [Messages and Queries](/docs/sdk/v0.53/build/building-modules/messages-and-queries) diff --git a/docs/sdk/v0.53/build/modules/feegrant/README.mdx b/docs/sdk/v0.53/build/modules/feegrant/README.mdx index e98ca2e3..dece75db 100644 --- a/docs/sdk/v0.53/build/modules/feegrant/README.mdx +++ b/docs/sdk/v0.53/build/modules/feegrant/README.mdx @@ -1597,7 +1597,7 @@ Example cmd: ### Granted Fee Deductions -Fees are deducted from grants in the `x/auth` ante handler. To learn more about how ante handlers work, read the [Auth Module AnteHandlers Guide](/docs/sdk/v0.50/auth/README#antehandlers). +Fees are deducted from grants in the `x/auth` ante handler. To learn more about how ante handlers work, read the [Auth Module AnteHandlers Guide](/docs/sdk/v0.53/build/modules/auth/auth#antehandlers). ### Gas diff --git a/docs/sdk/v0.53/learn/advanced/baseapp.mdx b/docs/sdk/v0.53/learn/advanced/baseapp.mdx index 9fbb4946..fc63ba12 100644 --- a/docs/sdk/v0.53/learn/advanced/baseapp.mdx +++ b/docs/sdk/v0.53/learn/advanced/baseapp.mdx @@ -10,7 +10,7 @@ This document describes `BaseApp`, the abstraction that implements the core func **Pre-requisite Readings** -* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.53/learn/beginner/app-anatomy) +* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.53/learn/beginner/app-anatomyy) * [Lifecycle of a Cosmos SDK transaction](/docs/sdk/v0.53/learn/beginner/tx-lifecycle) @@ -1523,7 +1523,7 @@ First, the important parameters that are initialized during the bootstrapping of * [`AnteHandler`](#antehandler): This handler is used to handle signature verification, fee payment, and other pre-message execution checks when a transaction is received. It's executed during [`CheckTx/RecheckTx`](#checktx) and [`FinalizeBlock`](#finalizeblock). -* [`InitChainer`](/docs/sdk/v0.53/learn/beginner/app-anatomy#initchainer), [`PreBlocker`](/docs/sdk/v0.53/learn/beginner/app-anatomy#preblocker), [`BeginBlocker` and `EndBlocker`](/docs/sdk/v0.53/learn/beginner/app-anatomy#beginblocker-and-endblocker): These are +* [`InitChainer`](/docs/sdk/v0.53/learn/beginner/app-anatomyy#initchainer), [`PreBlocker`](/docs/sdk/v0.53/learn/beginner/app-anatomyy#preblocker), [`BeginBlocker` and `EndBlocker`](/docs/sdk/v0.53/learn/beginner/app-anatomyy#beginblocker-and-endblocker): These are the functions executed when the application receives the `InitChain` and `FinalizeBlock` ABCI messages from the underlying CometBFT engine. @@ -1549,7 +1549,7 @@ Finally, a few more important parameters: `minGasPrices` (e.g. if `minGasPrices == 1uatom,1photon`, the `gas-price` of the transaction must be greater than `1uatom` OR `1photon`). * `appVersion`: Version of the application. It is set in the - [application's constructor function](/docs/sdk/v0.53/learn/beginner/app-anatomy#constructor-function). + [application's constructor function](/docs/sdk/v0.53/learn/beginner/app-anatomyy#constructor-function). ## Constructor @@ -1665,13 +1665,13 @@ When messages and queries are received by the application, they must be routed t The [default `msgServiceRouter` included in `BaseApp`](https://github.com/cosmos/cosmos-sdk/blob/v0.53.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.53.0/baseapp/msg_service_router.go#L35-L36). 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](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.53/learn/beginner/app-anatomy#constructor-function). +The application's `msgServiceRouter` is initialized with all the routes using the application's [module manager](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.53/learn/beginner/app-anatomyy#constructor-function). ### gRPC Query Router Similar to `sdk.Msg`s, [`queries`](/docs/sdk/v0.53//build/building-modules/messages-and-queries#queries) need to be routed to the appropriate module's [`Query` service](/docs/sdk/v0.53//build/building-modules/query-services). To do so, `BaseApp` holds a `grpcQueryRouter`, which maps modules' fully-qualified service methods (`string`, defined in their Protobuf `Query` gRPC) to their `QueryServer` implementation. The `grpcQueryRouter` is called during the initial stages of query processing, which can be either by directly sending a gRPC query to the gRPC endpoint, or via the [`Query` ABCI message](#query) on the CometBFT RPC endpoint. -Just like the `msgServiceRouter`, the `grpcQueryRouter` is initialized with all the query routes using the application's [module manager](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.53/learn/beginner/app-anatomy#app-constructor). +Just like the `msgServiceRouter`, the `grpcQueryRouter` is initialized with all the query routes using the application's [module manager](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.53/learn/beginner/app-anatomyy#app-constructor). ## Main ABCI 2.0 Messages @@ -3665,7 +3665,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](/docs/sdk/v0.53/learn/beginner/app-anatomy#application-constructor). The most widely used `anteHandler` is the [`auth` module](https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/x/auth/ante/ante.go). +`BaseApp` holds an `anteHandler` as parameter that is initialized in the [application's constructor](/docs/sdk/v0.53/learn/beginner/app-anatomyy#application-constructor). The most widely used `anteHandler` is the [`auth` module](https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/x/auth/ante/ante.go). Click [here](/docs/sdk/v0.53/learn/beginner/gas-fees#antehandler) for more on the `anteHandler`. @@ -3716,7 +3716,7 @@ The [`InitChain` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x * [`checkState` and `finalizeBlockState`](#state-updates) via `setState`. * The [block gas meter](/docs/sdk/v0.53/learn/beginner/gas-fees#block-gas-meter), with infinite gas to process genesis transactions. -Finally, the `InitChain(req abci.RequestInitChain)` method of `BaseApp` calls the [`initChainer()`](/docs/sdk/v0.53/learn/beginner/app-anatomy#initchainer) of the application in order to initialize the main state of the application from the `genesis file` and, if defined, call the [`InitGenesis`](/docs/sdk/v0.53//build/building-modules/genesis#initgenesis) function of each of the application's modules. +Finally, the `InitChain(req abci.RequestInitChain)` method of `BaseApp` calls the [`initChainer()`](/docs/sdk/v0.53/learn/beginner/app-anatomyy#initchainer) of the application in order to initialize the main state of the application from the `genesis file` and, if defined, call the [`InitGenesis`](/docs/sdk/v0.53//build/building-modules/genesis#initgenesis) function of each of the application's modules. ### FinalizeBlock @@ -5279,7 +5279,7 @@ return legacyVotes #### PreBlock -* Run the application's [`preBlocker()`](/docs/sdk/v0.53/learn/beginner/app-anatomy#preblocker), which mainly runs the [`PreBlocker()`](/docs/sdk/v0.53//build/building-modules/preblock#preblock) method of each of the modules. +* Run the application's [`preBlocker()`](/docs/sdk/v0.53/learn/beginner/app-anatomyy#preblocker), which mainly runs the [`PreBlocker()`](/docs/sdk/v0.53//build/building-modules/preblock#preblock) method of each of the modules. #### BeginBlock @@ -6738,7 +6738,7 @@ return legacyVotes * Initialize the [block gas meter](/docs/sdk/v0.53/learn/beginner/gas-fees#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()`](/docs/sdk/v0.53/learn/beginner/app-anatomy#beginblocker-and-endblocker), which mainly runs the [`BeginBlocker()`](/docs/sdk/v0.53//build/building-modules/beginblock-endblock#beginblock) method of each of the modules. +* Run the application's [`beginBlocker()`](/docs/sdk/v0.53/learn/beginner/app-anatomyy#beginblocker-and-endblocker), which mainly runs the [`BeginBlocker()`](/docs/sdk/v0.53//build/building-modules/beginblock-endblock#beginblock) method of each of the modules. * Set the [`VoteInfos`](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_methods.md#voteinfo) of the application, i.e. the list of validators whose *precommit* for the previous block was included by the proposer of the current block. This information is carried into the [`Context`](/docs/sdk/v0.53/learn/advanced/context) so that it can be used during transaction execution and EndBlock. diff --git a/docs/sdk/v0.53/learn/advanced/cli.mdx b/docs/sdk/v0.53/learn/advanced/cli.mdx index ee018881..e35e83c6 100644 --- a/docs/sdk/v0.53/learn/advanced/cli.mdx +++ b/docs/sdk/v0.53/learn/advanced/cli.mdx @@ -4,7 +4,7 @@ title: Command-Line Interface **Synopsis** -This document describes how command-line interface (CLI) works on a high-level, for an [**application**](/docs/sdk/v0.53/learn/beginner/app-anatomy). A separate document for implementing a CLI for a Cosmos SDK [**module**](/docs/sdk/v0.53//build/building-modules/intro) can be found [here](/docs/sdk/v0.53//build/building-modules/module-interfaces#cli). +This document describes how command-line interface (CLI) works on a high-level, for an [**application**](/docs/sdk/v0.53/learn/beginner/app-anatomyy). A separate document for implementing a CLI for a Cosmos SDK [**module**](/docs/sdk/v0.53//build/building-modules/intro) can be found [here](/docs/sdk/v0.53//build/building-modules/module-interfaces#cli). ## Command-Line Interface diff --git a/docs/sdk/v0.53/learn/advanced/context.mdx b/docs/sdk/v0.53/learn/advanced/context.mdx index 2b27ba73..b52c902a 100644 --- a/docs/sdk/v0.53/learn/advanced/context.mdx +++ b/docs/sdk/v0.53/learn/advanced/context.mdx @@ -10,7 +10,7 @@ The `context` is a data structure intended to be passed from function to functio **Pre-requisite Readings** -* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.53/learn/beginner/app-anatomy) +* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.53/learn/beginner/app-anatomyy) * [Lifecycle of a Transaction](/docs/sdk/v0.53/learn/beginner/tx-lifecycle) diff --git a/docs/sdk/v0.53/learn/advanced/encoding.mdx b/docs/sdk/v0.53/learn/advanced/encoding.mdx index 0b630aaa..8f7813b5 100644 --- a/docs/sdk/v0.53/learn/advanced/encoding.mdx +++ b/docs/sdk/v0.53/learn/advanced/encoding.mdx @@ -10,7 +10,7 @@ While encoding in the Cosmos SDK used to be mainly handled by `go-amino` codec, **Pre-requisite Readings** -* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.53/learn/beginner/app-anatomy) +* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.53/learn/beginner/app-anatomyy) diff --git a/docs/sdk/v0.53/learn/advanced/events.mdx b/docs/sdk/v0.53/learn/advanced/events.mdx index 1f3bb986..7508d3c2 100644 --- a/docs/sdk/v0.53/learn/advanced/events.mdx +++ b/docs/sdk/v0.53/learn/advanced/events.mdx @@ -10,7 +10,7 @@ title: Events **Pre-requisite Readings** -* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.53/learn/beginner/app-anatomy) +* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.53/learn/beginner/app-anatomyy) * [CometBFT Documentation on Events](https://docs.cometbft.com/v0.37/spec/abci/abci++_basic_concepts#events) diff --git a/docs/sdk/v0.53/learn/advanced/node.mdx b/docs/sdk/v0.53/learn/advanced/node.mdx index 7b2d4cec..65a3f060 100644 --- a/docs/sdk/v0.53/learn/advanced/node.mdx +++ b/docs/sdk/v0.53/learn/advanced/node.mdx @@ -10,7 +10,7 @@ The main endpoint of a Cosmos SDK application is the daemon client, otherwise kn **Pre-requisite Readings** -* [Anatomy of an SDK application](/docs/sdk/v0.53/learn/beginner/app-anatomy) +* [Anatomy of an SDK application](/docs/sdk/v0.53/learn/beginner/app-anatomyy) @@ -1876,7 +1876,7 @@ Application ) ``` -In practice, the [constructor of the application](/docs/sdk/v0.53/learn/beginner/app-anatomy#constructor-function) is passed as the `appCreator`. +In practice, the [constructor of the application](/docs/sdk/v0.53/learn/beginner/app-anatomyy#constructor-function) is passed as the `appCreator`. ```go // Reference: https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/simapp/simd/cmd/root_v2.go#L294-L308 diff --git a/docs/sdk/v0.53/learn/advanced/store.mdx b/docs/sdk/v0.53/learn/advanced/store.mdx index 29b99835..ff88fe7b 100644 --- a/docs/sdk/v0.53/learn/advanced/store.mdx +++ b/docs/sdk/v0.53/learn/advanced/store.mdx @@ -10,7 +10,7 @@ A store is a data structure that holds the state of the application. **Pre-requisite Readings** -* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.53/learn/beginner/app-anatomy) +* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.53/learn/beginner/app-anatomyy) @@ -5931,7 +5931,7 @@ A `KVStore` is a simple key-value store used to store and retrieve data. A `Comm Individual `KVStore`s are used by modules to manage a subset of the global state. `KVStores` can be accessed by objects that hold a specific key. This `key` should only be exposed to the [`keeper`](/docs/sdk/v0.53//build/building-modules/keeper) of the module that defines the store. -`CommitKVStore`s are declared by proxy of their respective `key` and mounted on the application's [multistore](#multistore) in the [main application file](/docs/sdk/v0.53/learn/beginner/app-anatomy#core-application-file). In the same file, the `key` is also passed to the module's `keeper` that is responsible for managing the store. +`CommitKVStore`s are declared by proxy of their respective `key` and mounted on the application's [multistore](#multistore) in the [main application file](/docs/sdk/v0.53/learn/beginner/app-anatomyy#core-application-file). In the same file, the `key` is also passed to the module's `keeper` that is responsible for managing the store. ```go expandable package types diff --git a/docs/sdk/v0.53/learn/advanced/transactions.mdx b/docs/sdk/v0.53/learn/advanced/transactions.mdx index 8b67267d..cb7cc941 100644 --- a/docs/sdk/v0.53/learn/advanced/transactions.mdx +++ b/docs/sdk/v0.53/learn/advanced/transactions.mdx @@ -10,7 +10,7 @@ title: Transactions **Pre-requisite Readings** -* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.53/learn/beginner/app-anatomy) +* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.53/learn/beginner/app-anatomyy) diff --git a/docs/sdk/v0.53/learn/beginner/accounts.mdx b/docs/sdk/v0.53/learn/beginner/accounts.mdx index e2d07947..da241e5e 100644 --- a/docs/sdk/v0.53/learn/beginner/accounts.mdx +++ b/docs/sdk/v0.53/learn/beginner/accounts.mdx @@ -10,7 +10,7 @@ This document describes the in-built account and public key system of the Cosmos **Pre-requisite Readings** -* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.53/learn/beginner/app-anatomy) +* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.53/learn/beginner/app-anatomyy) diff --git a/docs/sdk/v0.53/learn/beginner/gas-fees.mdx b/docs/sdk/v0.53/learn/beginner/gas-fees.mdx index c1e43c0c..7eba44e9 100644 --- a/docs/sdk/v0.53/learn/beginner/gas-fees.mdx +++ b/docs/sdk/v0.53/learn/beginner/gas-fees.mdx @@ -10,7 +10,7 @@ This document describes the default strategies to handle gas and fees within a C **Pre-requisite Readings** -* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.53/learn/beginner/app-anatomy) +* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.53/learn/beginner/app-anatomyy) diff --git a/docs/sdk/v0.53/learn/beginner/tx-lifecycle.mdx b/docs/sdk/v0.53/learn/beginner/tx-lifecycle.mdx index f2f99df8..af761985 100644 --- a/docs/sdk/v0.53/learn/beginner/tx-lifecycle.mdx +++ b/docs/sdk/v0.53/learn/beginner/tx-lifecycle.mdx @@ -10,7 +10,7 @@ This document describes the lifecycle of a transaction from creation to committe **Pre-requisite Readings** -* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.53/learn/beginner/app-anatomy) +* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.53/learn/beginner/app-anatomyy) ## Creation diff --git a/docs/sdk/v0.53/learn/intro/sdk-design.mdx b/docs/sdk/v0.53/learn/intro/sdk-design.mdx index 7fb01124..f29daf50 100644 --- a/docs/sdk/v0.53/learn/intro/sdk-design.mdx +++ b/docs/sdk/v0.53/learn/intro/sdk-design.mdx @@ -13,7 +13,7 @@ Here is a simplified view of how transactions are handled by an application buil ## `baseapp` -`baseapp` is the boilerplate implementation of a Cosmos SDK application. It comes with an implementation of the ABCI to handle the connection with the underlying consensus engine. Typically, a Cosmos SDK application extends `baseapp` by embedding it in [`app.go`](/docs/sdk/v0.53/learn/beginner/app-anatomy#core-application-file). +`baseapp` is the boilerplate implementation of a Cosmos SDK application. It comes with an implementation of the ABCI to handle the connection with the underlying consensus engine. Typically, a Cosmos SDK application extends `baseapp` by embedding it in [`app.go`](/docs/sdk/v0.53/learn/beginner/app-anatomyy#core-application-file). Here is an example of this from `simapp`, the Cosmos SDK demonstration app: From dd142a25b340f7d9ee5cfacb743aad48940d82d7 Mon Sep 17 00:00:00 2001 From: Cordt Date: Fri, 24 Oct 2025 07:51:17 -0600 Subject: [PATCH 04/10] more links --- docs/evm/next/documentation/concepts/accounts.mdx | 10 +++++----- .../documentation/concepts/predeployed-contracts.mdx | 2 +- .../next/documentation/concepts/replay-protection.mdx | 2 +- .../next/documentation/cosmos-sdk/modules/erc20.mdx | 2 +- .../documentation/cosmos-sdk/modules/feemarket.mdx | 2 +- .../documentation/cosmos-sdk/modules/precisebank.mdx | 2 +- docs/evm/next/documentation/cosmos-sdk/protocol.mdx | 2 +- .../additional-configuration/predeployed-contracts.mdx | 2 +- .../getting-started/build-a-chain/build-a-chain_v.mdx | 2 +- .../getting-started/build-a-chain/quick-start.mdx | 2 +- .../getting-started/build-a-chain/using-local-node.mdx | 2 +- 11 files changed, 15 insertions(+), 15 deletions(-) diff --git a/docs/evm/next/documentation/concepts/accounts.mdx b/docs/evm/next/documentation/concepts/accounts.mdx index 90b0d1bd..5418a000 100644 --- a/docs/evm/next/documentation/concepts/accounts.mdx +++ b/docs/evm/next/documentation/concepts/accounts.mdx @@ -45,16 +45,16 @@ The custom Cosmos EVM [EthAccount](https://github.com/cosmos/evm/blob/v0.4.1/typ // EthAccountI represents the interface of an EVM compatible account type EthAccountI interface { authtypes.AccountI - + // EthAddress returns the ethereum Address representation of the AccAddress EthAddress() common.Address - + // CodeHash is the keccak256 hash of the contract code (if any) GetCodeHash() common.Hash - + // SetCodeHash sets the code hash to the account fields SetCodeHash(code common.Hash) error - + // Type returns the type of Ethereum Account (EOA or Contract) Type() int8 } @@ -62,7 +62,7 @@ type EthAccountI interface { **EIP-7702 Support**: Cosmos EVM supports [EIP-7702 code delegation](/docs/evm/next/documentation/evm-compatibility/eip-7702), allowing EOAs to temporarily delegate code execution to smart contracts through the `SetCodeHash` functionality. -For more information on Ethereum accounts head over to the [x/vm module](/docs//docs/evm/next/documentation/cosmos-sdk/modules/vm). +For more information on Ethereum accounts head over to the [x/vm module](/docs/evm/next/documentation/cosmos-sdk/modules/vm). ### Addresses and Public Keys diff --git a/docs/evm/next/documentation/concepts/predeployed-contracts.mdx b/docs/evm/next/documentation/concepts/predeployed-contracts.mdx index dd5729c9..1a619b7d 100644 --- a/docs/evm/next/documentation/concepts/predeployed-contracts.mdx +++ b/docs/evm/next/documentation/concepts/predeployed-contracts.mdx @@ -107,7 +107,7 @@ For comprehensive information on each contract including usage examples and inte ## Related Concepts - [Precompiles](/docs/evm/next/documentation/smart-contracts/precompiles/overview) - Native chain implementations exposed as smart contracts -- [VM Module](/docs//docs/evm/next/documentation/cosmos-sdk/modules/vm) - Core EVM module configuration including preinstalls +- [VM Module](docs/evm/next/documentation/cosmos-sdk/modules/vm) - Core EVM module configuration including preinstalls - [Building Your Chain](/docs/evm/next/documentation/getting-started/build-a-chain/overview) - Complete guide to chain setup ## Implementation Guides diff --git a/docs/evm/next/documentation/concepts/replay-protection.mdx b/docs/evm/next/documentation/concepts/replay-protection.mdx index f2e145b7..6ec66310 100644 --- a/docs/evm/next/documentation/concepts/replay-protection.mdx +++ b/docs/evm/next/documentation/concepts/replay-protection.mdx @@ -162,4 +162,4 @@ grep allow-unprotected-txs $HOME/.evmd/config/config.toml - [EIP-155 Specification](https://eips.ethereum.org/EIPS/eip-155) - [Chain ID Configuration](/docs/evm/next/documentation/concepts/chain-id) - [Transaction Types](/docs/evm/next/documentation/concepts/transactions#ethereum-tx-type) -- [EVM Module Parameters](/docs//docs/evm/next/documentation/cosmos-sdk/modules/vm#parameters) \ No newline at end of file +- [EVM Module Parameters](docs/evm/next/documentation/cosmos-sdk/modules/vm#parameters) \ No newline at end of file diff --git a/docs/evm/next/documentation/cosmos-sdk/modules/erc20.mdx b/docs/evm/next/documentation/cosmos-sdk/modules/erc20.mdx index 2e148445..54db6618 100644 --- a/docs/evm/next/documentation/cosmos-sdk/modules/erc20.mdx +++ b/docs/evm/next/documentation/cosmos-sdk/modules/erc20.mdx @@ -523,7 +523,7 @@ evmd tx erc20 register-coin --from mykey ## Related Documentation - [Building Your Chain Guide](/docs/evm/next/documentation/getting-started/build-a-chain/overview) - Main configuration walkthrough -- [VM Module](/docs//docs/evm/next/documentation/cosmos-sdk/modules/vm) - EVM configuration +- [VM Module](docs/evm/next/documentation/cosmos-sdk/modules/vm) - EVM configuration - [IBC Module](/docs/evm/next/documentation/cosmos-sdk/modules/ibc) - IBC token handling --- diff --git a/docs/evm/next/documentation/cosmos-sdk/modules/feemarket.mdx b/docs/evm/next/documentation/cosmos-sdk/modules/feemarket.mdx index 1c408891..28d08087 100644 --- a/docs/evm/next/documentation/cosmos-sdk/modules/feemarket.mdx +++ b/docs/evm/next/documentation/cosmos-sdk/modules/feemarket.mdx @@ -848,7 +848,7 @@ evmd tx gov submit-proposal param-change proposal.json --from validator --chain- ## Related Documentation - [Building Your Chain Guide](/docs/evm/next/documentation/getting-started/build-a-chain/overview) - Main configuration walkthrough -- [VM Module](/docs//docs/evm/next/documentation/cosmos-sdk/modules/vm) - EVM configuration +- [VM Module](docs/evm/next/documentation/cosmos-sdk/modules/vm) - EVM configuration - [EIP-1559 Specification](https://eips.ethereum.org/EIPS/eip-1559) - Original Ethereum proposal --- diff --git a/docs/evm/next/documentation/cosmos-sdk/modules/precisebank.mdx b/docs/evm/next/documentation/cosmos-sdk/modules/precisebank.mdx index aea32d9d..c13693a2 100644 --- a/docs/evm/next/documentation/cosmos-sdk/modules/precisebank.mdx +++ b/docs/evm/next/documentation/cosmos-sdk/modules/precisebank.mdx @@ -640,7 +640,7 @@ REMAINDER=$(evmd query precisebank remainder -o json | jq -r '.remainder') ## Related Documentation - [Building Your Chain Guide](/docs/evm/next/documentation/getting-started/build-a-chain/overview) - Main configuration walkthrough -- [VM Module](/docs//docs/evm/next/documentation/cosmos-sdk/modules/vm) - extended_denom_options setup +- [VM Module](docs/evm/next/documentation/cosmos-sdk/modules/vm) - extended_denom_options setup - [ERC20 Module](/docs/evm/next/documentation/cosmos-sdk/modules/erc20) - Token pair configuration --- diff --git a/docs/evm/next/documentation/cosmos-sdk/protocol.mdx b/docs/evm/next/documentation/cosmos-sdk/protocol.mdx index a3fa1c08..decf0658 100644 --- a/docs/evm/next/documentation/cosmos-sdk/protocol.mdx +++ b/docs/evm/next/documentation/cosmos-sdk/protocol.mdx @@ -35,7 +35,7 @@ Cosmos EVM enables EVM compatibility by implementing various components that tog * `StateDB` interface for state updates and queries * [JSON-RPC](/docs/evm/next/api-reference/ethereum-json-rpc) client for interacting with the EVM -Most components are implemented in the [VM module](/docs//docs/evm/next/documentation/cosmos-sdk/modules/vm). However, to achieve a seamless developer experience, some components are implemented outside of the module. +Most components are implemented in the [VM module](docs/evm/next/documentation/cosmos-sdk/modules/vm). However, to achieve a seamless developer experience, some components are implemented outside of the module. To learn more about how Cosmos EVM achieves EVM compatibility as a Cosmos chain, explore the following concepts: diff --git a/docs/evm/next/documentation/getting-started/build-a-chain/additional-configuration/predeployed-contracts.mdx b/docs/evm/next/documentation/getting-started/build-a-chain/additional-configuration/predeployed-contracts.mdx index a9b62409..3c5aa2c1 100644 --- a/docs/evm/next/documentation/getting-started/build-a-chain/additional-configuration/predeployed-contracts.mdx +++ b/docs/evm/next/documentation/getting-started/build-a-chain/additional-configuration/predeployed-contracts.mdx @@ -365,4 +365,4 @@ preinstalls := append(evmtypes.DefaultPreinstalls, customPreinstall) - [Safe Contracts](https://github.com/safe-global/safe-contracts) - Safe multisig implementation ### Cosmos EVM Resources -- [VM Module Reference](/docs//docs/evm/next/documentation/cosmos-sdk/modules/vm) - Complete VM module configuration \ No newline at end of file +- [VM Module Reference](docs/evm/next/documentation/cosmos-sdk/modules/vm) - Complete VM module configuration \ No newline at end of file diff --git a/docs/evm/next/documentation/getting-started/build-a-chain/build-a-chain_v.mdx b/docs/evm/next/documentation/getting-started/build-a-chain/build-a-chain_v.mdx index 5ee29b7f..44e5e60a 100644 --- a/docs/evm/next/documentation/getting-started/build-a-chain/build-a-chain_v.mdx +++ b/docs/evm/next/documentation/getting-started/build-a-chain/build-a-chain_v.mdx @@ -195,7 +195,7 @@ After adding the network: ### Recommended Reading - + EVM execution and parameter configuration diff --git a/docs/evm/next/documentation/getting-started/build-a-chain/quick-start.mdx b/docs/evm/next/documentation/getting-started/build-a-chain/quick-start.mdx index 6fc3bdfe..35f41d2e 100644 --- a/docs/evm/next/documentation/getting-started/build-a-chain/quick-start.mdx +++ b/docs/evm/next/documentation/getting-started/build-a-chain/quick-start.mdx @@ -228,7 +228,7 @@ For detailed setup and configuration instructions, see the comprehensive guides ### Recommended Reading - + EVM execution and parameter configuration diff --git a/docs/evm/next/documentation/getting-started/build-a-chain/using-local-node.mdx b/docs/evm/next/documentation/getting-started/build-a-chain/using-local-node.mdx index a43d44e4..3d4749fc 100644 --- a/docs/evm/next/documentation/getting-started/build-a-chain/using-local-node.mdx +++ b/docs/evm/next/documentation/getting-started/build-a-chain/using-local-node.mdx @@ -256,7 +256,7 @@ Deploy standard contracts at genesis for Create2, Multicall3, Permit2, and Safe ### Recommended Reading - + EVM execution and parameter configuration From b83aa5276a95ab07918a3925e73f4910365d54ce Mon Sep 17 00:00:00 2001 From: Cordt Date: Fri, 24 Oct 2025 07:59:07 -0600 Subject: [PATCH 05/10] fix: correct auth module filename references from aut.mdx to auth.mdx MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Update v0.47 module references to use correct auth.mdx filename - Fix references in modules.mdx, modul.mdx, authz/README, feegrant/README - Aligns with renamed auth.mdx files (previously misspelled as aut/authre) 4 files changed 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude --- docs/sdk/v0.47/build/modules.mdx | 2 +- docs/sdk/v0.47/build/modules/authz/README.mdx | 2 +- docs/sdk/v0.47/build/modules/feegrant/README.mdx | 2 +- docs/sdk/v0.47/build/modules/modul.mdx | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/sdk/v0.47/build/modules.mdx b/docs/sdk/v0.47/build/modules.mdx index 45216c12..8016e177 100644 --- a/docs/sdk/v0.47/build/modules.mdx +++ b/docs/sdk/v0.47/build/modules.mdx @@ -5,7 +5,7 @@ description: "Version: v0.47" Here are some production-grade modules that can be used in Cosmos SDK applications, along with their respective documentation: -* [Auth](/docs/sdk/v0.47/build/modules/auth/aut) - Authentication of accounts and transactions for Cosmos SDK applications. +* [Auth](/docs/sdk/v0.47/build/modules/auth/auth) - Authentication of accounts and transactions for Cosmos SDK applications. * [Authz](/docs/sdk/v0.47/build/modules/authz/README) - Authorization for accounts to perform actions on behalf of other accounts. * [Bank](/docs/sdk/v0.47/build/modules/bank/README) - Token transfer functionalities. * [Crisis](/docs/sdk/v0.47/build/modules/crisis/README) - Halting the blockchain under certain circumstances (e.g. if an invariant is broken). diff --git a/docs/sdk/v0.47/build/modules/authz/README.mdx b/docs/sdk/v0.47/build/modules/authz/README.mdx index 0c0f9ba3..c3dbdd21 100644 --- a/docs/sdk/v0.47/build/modules/authz/README.mdx +++ b/docs/sdk/v0.47/build/modules/authz/README.mdx @@ -36,7 +36,7 @@ on behalf of one account to other accounts. The design is defined in the [ADR 03 A *grant* is an allowance to execute a Msg by the grantee on behalf of the granter. Authorization is an interface that must be implemented by a concrete authorization logic to validate and execute grants. Authorizations are extensible and can be defined for any Msg service method even outside of the module where the Msg method is defined. See the `SendAuthorization` example in the next section for more details. -**Note:** The authz module is different from the [auth (authentication)](/docs/sdk/v0.47/build/modules/auth/aut/) module that is responsible for specifying the base transaction and account types. +**Note:** The authz module is different from the [auth (authentication)](/docs/sdk/v0.47/build/modules/auth/auth/) module that is responsible for specifying the base transaction and account types. ```go expandable package authz diff --git a/docs/sdk/v0.47/build/modules/feegrant/README.mdx b/docs/sdk/v0.47/build/modules/feegrant/README.mdx index dbd28ea4..90570651 100644 --- a/docs/sdk/v0.47/build/modules/feegrant/README.mdx +++ b/docs/sdk/v0.47/build/modules/feegrant/README.mdx @@ -1597,7 +1597,7 @@ Example cmd: ### Granted Fee Deductions -Fees are deducted from grants in the `x/auth` ante handler. To learn more about how ante handlers work, read the [Auth Module AnteHandlers Guide](/docs/sdk/v0.47/build/modules/auth/aut#antehandlers). +Fees are deducted from grants in the `x/auth` ante handler. To learn more about how ante handlers work, read the [Auth Module AnteHandlers Guide](/docs/sdk/v0.47/build/modules/auth/auth#antehandlers). ### Gas diff --git a/docs/sdk/v0.47/build/modules/modul.mdx b/docs/sdk/v0.47/build/modules/modul.mdx index eedb7131..94c9cfae 100644 --- a/docs/sdk/v0.47/build/modules/modul.mdx +++ b/docs/sdk/v0.47/build/modules/modul.mdx @@ -7,7 +7,7 @@ description: >- Here are some production-grade modules that can be used in Cosmos SDK applications, along with their respective documentation: -* [Auth](/docs/sdk/v0.47/build/modules/auth/aut) - Authentication of accounts and transactions for Cosmos SDK applications. +* [Auth](/docs/sdk/v0.47/build/modules/auth/auth) - Authentication of accounts and transactions for Cosmos SDK applications. * [Authz](/docs/sdk/v0.47/build/modules/authz/README) - Authorization for accounts to perform actions on behalf of other accounts. * [Bank](/docs/sdk/v0.47/build/modules/bank/README) - Token transfer functionalities. * [Crisis](/docs/sdk/v0.47/build/modules/crisis/README) - Halting the blockchain under certain circumstances (e.g. if an invariant is broken). From 36295ff2d4617423db05667ff5172350030f6f2a Mon Sep 17 00:00:00 2001 From: Cordt Date: Fri, 24 Oct 2025 08:28:27 -0600 Subject: [PATCH 06/10] omre broken link patterns, duplication in paths --- .../build-a-chain/quick-start.mdx | 2 +- .../build-a-chain/using-local-node.mdx | 2 +- docs/ibc/next/migrations/v5-to-v6.mdx | 2 +- docs/ibc/v10.1.x/migrations/v5-to-v6.mdx | 2 +- docs/ibc/v6.3.x/migrations/v5-to-v6.mdx | 2 +- docs/ibc/v7.8.x/migrations/v5-to-v6.mdx | 2 +- docs/ibc/v8.5.x/migrations/v5-to-v6.mdx | 2 +- .../adr-033-protobuf-inter-module-comm.mdx | 2 +- .../v0.47/build/building-apps/app-mempool.mdx | 2 +- .../building-modules/beginblock-endblock.mdx | 6 +-- .../v0.47/build/building-modules/genesis.mdx | 6 +-- .../v0.47/build/building-modules/intro.mdx | 14 +++---- .../build/building-modules/invariants.mdx | 2 +- .../v0.47/build/building-modules/keeper.mdx | 12 +++--- .../building-modules/messages-and-queries.mdx | 14 +++---- .../building-modules/module-interfaces.mdx | 10 ++--- .../build/building-modules/module-manager.mdx | 34 ++++++++--------- .../build/building-modules/msg-services.mdx | 8 ++-- .../build/building-modules/query-services.mdx | 2 +- .../build/building-modules/simulator.mdx | 4 +- .../v0.47/build/building-modules/upgrade.mdx | 4 +- docs/sdk/v0.47/build/migrations/upgrading.mdx | 2 +- docs/sdk/v0.47/learn/advanced/baseapp.mdx | 20 +++++----- docs/sdk/v0.47/learn/advanced/cli.mdx | 20 +++++----- docs/sdk/v0.47/learn/advanced/encoding.mdx | 18 ++++----- docs/sdk/v0.47/learn/advanced/events.mdx | 10 ++--- docs/sdk/v0.47/learn/advanced/grpc_rest.mdx | 6 +-- docs/sdk/v0.47/learn/advanced/node.mdx | 2 +- .../v0.47/learn/advanced/runtx_middleware.mdx | 2 +- docs/sdk/v0.47/learn/advanced/simulation.mdx | 2 +- .../sdk/v0.47/learn/advanced/transactions.mdx | 18 ++++----- docs/sdk/v0.47/learn/advanced/upgrade.mdx | 6 +-- docs/sdk/v0.47/learn/beginner/accounts.mdx | 4 +- docs/sdk/v0.47/learn/beginner/gas-fees.mdx | 6 +-- .../sdk/v0.47/learn/beginner/overview-app.mdx | 32 ++++++++-------- .../v0.47/learn/beginner/query-lifecycle.mdx | 12 +++--- .../sdk/v0.47/learn/beginner/tx-lifecycle.mdx | 8 ++-- docs/sdk/v0.47/learn/intro/overview.mdx | 2 +- .../learn/intro/sdk-app-architecture.mdx | 2 +- .../sdk/v0.47/user/run-node/interact-node.mdx | 6 +-- docs/sdk/v0.47/user/run-node/keyring.mdx | 2 +- docs/sdk/v0.47/user/run-node/run-node.mdx | 4 +- docs/sdk/v0.47/user/run-node/txs.mdx | 2 +- .../adr-033-protobuf-inter-module-comm.mdx | 2 +- .../architecture/adr-076-tx-malleability.mdx | 6 +-- .../v0.50/build/building-apps/app-mempool.mdx | 2 +- .../building-modules/beginblock-endblock.mdx | 6 +-- .../v0.50/build/building-modules/genesis.mdx | 6 +-- .../build/building-modules/invariants.mdx | 2 +- .../v0.50/build/building-modules/keeper.mdx | 12 +++--- .../building-modules/messages-and-queries.mdx | 8 ++-- .../building-modules/module-interfaces.mdx | 4 +- .../build/building-modules/module-manager.mdx | 38 +++++++++---------- .../build/building-modules/msg-services.mdx | 8 ++-- .../v0.50/build/building-modules/preblock.mdx | 2 +- .../build/building-modules/query-services.mdx | 2 +- .../build/building-modules/simulator.mdx | 4 +- .../v0.50/build/building-modules/upgrade.mdx | 4 +- docs/sdk/v0.50/learn/advanced/baseapp.mdx | 20 +++++----- docs/sdk/v0.50/learn/advanced/cli.mdx | 20 +++++----- docs/sdk/v0.50/learn/advanced/encoding.mdx | 20 +++++----- docs/sdk/v0.50/learn/advanced/events.mdx | 10 ++--- docs/sdk/v0.50/learn/advanced/grpc_rest.mdx | 6 +-- docs/sdk/v0.50/learn/advanced/node.mdx | 2 +- .../v0.50/learn/advanced/runtx_middleware.mdx | 2 +- docs/sdk/v0.50/learn/advanced/simulation.mdx | 2 +- docs/sdk/v0.50/learn/advanced/store.mdx | 4 +- .../sdk/v0.50/learn/advanced/transactions.mdx | 20 +++++----- docs/sdk/v0.50/learn/advanced/upgrade.mdx | 6 +-- docs/sdk/v0.50/learn/beginner/accounts.mdx | 4 +- docs/sdk/v0.50/learn/beginner/app-anatomy.mdx | 32 ++++++++-------- docs/sdk/v0.50/learn/beginner/gas-fees.mdx | 6 +-- .../v0.50/learn/beginner/query-lifecycle.mdx | 12 +++--- .../sdk/v0.50/learn/beginner/tx-lifecycle.mdx | 8 ++-- .../learn/intro/sdk-app-architecture.mdx | 2 +- .../sdk/v0.50/user/run-node/interact-node.mdx | 6 +-- docs/sdk/v0.50/user/run-node/keyring.mdx | 2 +- docs/sdk/v0.50/user/run-node/run-node.mdx | 4 +- docs/sdk/v0.50/user/run-node/txs.mdx | 2 +- .../adr-033-protobuf-inter-module-comm.mdx | 2 +- .../architecture/adr-076-tx-malleability.mdx | 6 +-- .../building-modules/beginblock-endblock.mdx | 12 +++--- .../v0.53/build/building-modules/genesis.mdx | 10 ++--- .../v0.53/build/building-modules/intro.mdx | 4 +- .../build/building-modules/invariants.mdx | 4 +- .../v0.53/build/building-modules/keeper.mdx | 12 +++--- .../building-modules/messages-and-queries.mdx | 20 +++++----- .../building-modules/module-interfaces.mdx | 4 +- .../build/building-modules/module-manager.mdx | 36 +++++++++--------- .../build/building-modules/msg-services.mdx | 10 ++--- .../v0.53/build/building-modules/preblock.mdx | 4 +- .../build/building-modules/query-services.mdx | 4 +- .../build/building-modules/simulator.mdx | 4 +- .../v0.53/build/building-modules/upgrade.mdx | 4 +- docs/sdk/v0.53/learn/advanced/baseapp.mdx | 28 +++++++------- docs/sdk/v0.53/learn/advanced/cli.mdx | 20 +++++----- docs/sdk/v0.53/learn/advanced/context.mdx | 2 +- docs/sdk/v0.53/learn/advanced/encoding.mdx | 14 +++---- docs/sdk/v0.53/learn/advanced/events.mdx | 12 +++--- docs/sdk/v0.53/learn/advanced/grpc_rest.mdx | 6 +-- docs/sdk/v0.53/learn/advanced/node.mdx | 6 +-- .../v0.53/learn/advanced/runtx_middleware.mdx | 2 +- docs/sdk/v0.53/learn/advanced/simulation.mdx | 2 +- docs/sdk/v0.53/learn/advanced/store.mdx | 8 ++-- .../sdk/v0.53/learn/advanced/transactions.mdx | 22 +++++------ docs/sdk/v0.53/learn/advanced/upgrade.mdx | 6 +-- docs/sdk/v0.53/learn/beginner/accounts.mdx | 6 +-- docs/sdk/v0.53/learn/beginner/app-anatomy.mdx | 34 ++++++++--------- docs/sdk/v0.53/learn/beginner/gas-fees.mdx | 8 ++-- .../v0.53/learn/beginner/query-lifecycle.mdx | 12 +++--- .../sdk/v0.53/learn/beginner/tx-lifecycle.mdx | 10 ++--- .../learn/intro/sdk-app-architecture.mdx | 2 +- docs/sdk/v0.53/learn/intro/sdk-design.mdx | 2 +- .../sdk/v0.53/user/run-node/interact-node.mdx | 6 +-- docs/sdk/v0.53/user/run-node/keyring.mdx | 2 +- docs/sdk/v0.53/user/run-node/run-node.mdx | 4 +- docs/sdk/v0.53/user/run-node/txs.mdx | 2 +- 117 files changed, 484 insertions(+), 484 deletions(-) diff --git a/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start.mdx b/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start.mdx index f0c021b5..c036845c 100644 --- a/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start.mdx +++ b/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start.mdx @@ -277,7 +277,7 @@ Deploy standard contracts at genesis for Create2, Multicall3, Permit2, and Safe ### Recommended Reading - + EVM execution and parameter configuration diff --git a/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/using-local-node.mdx b/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/using-local-node.mdx index a2cd70f2..b0ee7ca3 100644 --- a/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/using-local-node.mdx +++ b/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/using-local-node.mdx @@ -256,7 +256,7 @@ Deploy standard contracts at genesis for Create2, Multicall3, Permit2, and Safe ### Recommended Reading - + EVM execution and parameter configuration diff --git a/docs/ibc/next/migrations/v5-to-v6.mdx b/docs/ibc/next/migrations/v5-to-v6.mdx index cdc9a636..00fd8814 100644 --- a/docs/ibc/next/migrations/v5-to-v6.mdx +++ b/docs/ibc/next/migrations/v5-to-v6.mdx @@ -108,7 +108,7 @@ Prior to ibc-go v6 the controller submodule exposed only these two functions (to However, these functions have now been deprecated in favour of the new controller submodule `MsgServer` and will be removed in later releases. -Both APIs remain functional and maintain backwards compatibility in ibc-go v6, however consumers of these APIs are now recommended to follow the message passing paradigm outlined in Cosmos SDK [ADR 031](docs/sdk/next/documentation/legacy/adr-comprehensive#adr-031) and [ADR 033](docs/sdk/next/documentation/legacy/adr-comprehensive#adr-033). This is facilitated by the Cosmos SDK [`MsgServiceRouter`](https://github.com/cosmos/cosmos-sdk/blob/main/baseapp/msg_service_router.go#L17) and chain developers creating custom application logic can now omit the ICS27 controller submodule `Keeper` from their module and instead depend on message routing. +Both APIs remain functional and maintain backwards compatibility in ibc-go v6, however consumers of these APIs are now recommended to follow the message passing paradigm outlined in Cosmos SDK [ADR 031](https://github.com/cosmos/cosmos-sdk/tree/main/docs/architecture#adr-031) and [ADR 033](https://github.com/cosmos/cosmos-sdk/tree/main/docs/architecture#adr-033). This is facilitated by the Cosmos SDK [`MsgServiceRouter`](https://github.com/cosmos/cosmos-sdk/blob/main/baseapp/msg_service_router.go#L17) and chain developers creating custom application logic can now omit the ICS27 controller submodule `Keeper` from their module and instead depend on message routing. Depending on the use case, developers of custom authentication modules face one of three scenarios: diff --git a/docs/ibc/v10.1.x/migrations/v5-to-v6.mdx b/docs/ibc/v10.1.x/migrations/v5-to-v6.mdx index 40fd9a7c..7d930edf 100644 --- a/docs/ibc/v10.1.x/migrations/v5-to-v6.mdx +++ b/docs/ibc/v10.1.x/migrations/v5-to-v6.mdx @@ -108,7 +108,7 @@ Prior to ibc-go v6 the controller submodule exposed only these two functions (to However, these functions have now been deprecated in favour of the new controller submodule `MsgServer` and will be removed in later releases. -Both APIs remain functional and maintain backwards compatibility in ibc-go v6, however consumers of these APIs are now recommended to follow the message passing paradigm outlined in Cosmos SDK [ADR 031](docs/sdk/next/documentation/legacy/adr-comprehensive#adr-031) and [ADR 033](docs/sdk/next/documentation/legacy/adr-comprehensive#adr-033). This is facilitated by the Cosmos SDK [`MsgServiceRouter`](https://github.com/cosmos/cosmos-sdk/blob/main/baseapp/msg_service_router.go#L17) and chain developers creating custom application logic can now omit the ICS27 controller submodule `Keeper` from their module and instead depend on message routing. +Both APIs remain functional and maintain backwards compatibility in ibc-go v6, however consumers of these APIs are now recommended to follow the message passing paradigm outlined in Cosmos SDK [ADR 031](https://github.com/cosmos/cosmos-sdk/tree/main/docs/architecture#adr-031) and [ADR 033](https://github.com/cosmos/cosmos-sdk/tree/main/docs/architecture#adr-033). This is facilitated by the Cosmos SDK [`MsgServiceRouter`](https://github.com/cosmos/cosmos-sdk/blob/main/baseapp/msg_service_router.go#L17) and chain developers creating custom application logic can now omit the ICS27 controller submodule `Keeper` from their module and instead depend on message routing. Depending on the use case, developers of custom authentication modules face one of three scenarios: diff --git a/docs/ibc/v6.3.x/migrations/v5-to-v6.mdx b/docs/ibc/v6.3.x/migrations/v5-to-v6.mdx index cf96d71e..799ce5fa 100644 --- a/docs/ibc/v6.3.x/migrations/v5-to-v6.mdx +++ b/docs/ibc/v6.3.x/migrations/v5-to-v6.mdx @@ -108,7 +108,7 @@ Prior to ibc-go v6 the controller submodule exposed only these two functions (to However, these functions have now been deprecated in favour of the new controller submodule `MsgServer` and will be removed in later releases. -Both APIs remain functional and maintain backwards compatibility in ibc-go v6, however consumers of these APIs are now recommended to follow the message passing paradigm outlined in Cosmos SDK [ADR 031](docs/sdk/next/documentation/legacy/adr-comprehensive#adr-031) and [ADR 033](docs/sdk/next/documentation/legacy/adr-comprehensive#adr-033). This is facilitated by the Cosmos SDK [`MsgServiceRouter`](https://github.com/cosmos/cosmos-sdk/blob/main/baseapp/msg_service_router.go#L17) and chain developers creating custom application logic can now omit the ICS27 controller submodule `Keeper` from their module and instead depend on message routing. +Both APIs remain functional and maintain backwards compatibility in ibc-go v6, however consumers of these APIs are now recommended to follow the message passing paradigm outlined in Cosmos SDK [ADR 031](https://github.com/cosmos/cosmos-sdk/tree/main/docs/architecture#adr-031) and [ADR 033](https://github.com/cosmos/cosmos-sdk/tree/main/docs/architecture#adr-033). This is facilitated by the Cosmos SDK [`MsgServiceRouter`](https://github.com/cosmos/cosmos-sdk/blob/main/baseapp/msg_service_router.go#L17) and chain developers creating custom application logic can now omit the ICS27 controller submodule `Keeper` from their module and instead depend on message routing. Depending on the use case, developers of custom authentication modules face one of three scenarios: diff --git a/docs/ibc/v7.8.x/migrations/v5-to-v6.mdx b/docs/ibc/v7.8.x/migrations/v5-to-v6.mdx index c38c1657..bde8c339 100644 --- a/docs/ibc/v7.8.x/migrations/v5-to-v6.mdx +++ b/docs/ibc/v7.8.x/migrations/v5-to-v6.mdx @@ -108,7 +108,7 @@ Prior to ibc-go v6 the controller submodule exposed only these two functions (to However, these functions have now been deprecated in favour of the new controller submodule `MsgServer` and will be removed in later releases. -Both APIs remain functional and maintain backwards compatibility in ibc-go v6, however consumers of these APIs are now recommended to follow the message passing paradigm outlined in Cosmos SDK [ADR 031](docs/sdk/next/documentation/legacy/adr-comprehensive#adr-031) and [ADR 033](docs/sdk/next/documentation/legacy/adr-comprehensive#adr-033). This is facilitated by the Cosmos SDK [`MsgServiceRouter`](https://github.com/cosmos/cosmos-sdk/blob/main/baseapp/msg_service_router.go#L17) and chain developers creating custom application logic can now omit the ICS27 controller submodule `Keeper` from their module and instead depend on message routing. +Both APIs remain functional and maintain backwards compatibility in ibc-go v6, however consumers of these APIs are now recommended to follow the message passing paradigm outlined in Cosmos SDK [ADR 031](https://github.com/cosmos/cosmos-sdk/tree/main/docs/architecture#adr-031) and [ADR 033](https://github.com/cosmos/cosmos-sdk/tree/main/docs/architecture#adr-033). This is facilitated by the Cosmos SDK [`MsgServiceRouter`](https://github.com/cosmos/cosmos-sdk/blob/main/baseapp/msg_service_router.go#L17) and chain developers creating custom application logic can now omit the ICS27 controller submodule `Keeper` from their module and instead depend on message routing. Depending on the use case, developers of custom authentication modules face one of three scenarios: diff --git a/docs/ibc/v8.5.x/migrations/v5-to-v6.mdx b/docs/ibc/v8.5.x/migrations/v5-to-v6.mdx index 6d64fad5..8af0719d 100644 --- a/docs/ibc/v8.5.x/migrations/v5-to-v6.mdx +++ b/docs/ibc/v8.5.x/migrations/v5-to-v6.mdx @@ -108,7 +108,7 @@ Prior to ibc-go v6 the controller submodule exposed only these two functions (to However, these functions have now been deprecated in favour of the new controller submodule `MsgServer` and will be removed in later releases. -Both APIs remain functional and maintain backwards compatibility in ibc-go v6, however consumers of these APIs are now recommended to follow the message passing paradigm outlined in Cosmos SDK [ADR 031](docs/sdk/next/documentation/legacy/adr-comprehensive#adr-031) and [ADR 033](docs/sdk/next/documentation/legacy/adr-comprehensive#adr-033). This is facilitated by the Cosmos SDK [`MsgServiceRouter`](https://github.com/cosmos/cosmos-sdk/blob/main/baseapp/msg_service_router.go#L17) and chain developers creating custom application logic can now omit the ICS27 controller submodule `Keeper` from their module and instead depend on message routing. +Both APIs remain functional and maintain backwards compatibility in ibc-go v6, however consumers of these APIs are now recommended to follow the message passing paradigm outlined in Cosmos SDK [ADR 031](https://github.com/cosmos/cosmos-sdk/tree/main/docs/architecture#adr-031) and [ADR 033](https://github.com/cosmos/cosmos-sdk/tree/main/docs/architecture#adr-033). This is facilitated by the Cosmos SDK [`MsgServiceRouter`](https://github.com/cosmos/cosmos-sdk/blob/main/baseapp/msg_service_router.go#L17) and chain developers creating custom application logic can now omit the ICS27 controller submodule `Keeper` from their module and instead depend on message routing. Depending on the use case, developers of custom authentication modules face one of three scenarios: diff --git a/docs/sdk/v0.47/build/architecture/adr-033-protobuf-inter-module-comm.mdx b/docs/sdk/v0.47/build/architecture/adr-033-protobuf-inter-module-comm.mdx index c655050d..3cd52041 100644 --- a/docs/sdk/v0.47/build/architecture/adr-033-protobuf-inter-module-comm.mdx +++ b/docs/sdk/v0.47/build/architecture/adr-033-protobuf-inter-module-comm.mdx @@ -23,7 +23,7 @@ service definitions defined in [ADR 021](/docs/sdk/v0.47/build/architecture/adr- ## Context -In the current Cosmos SDK documentation on the [Object-Capability Model](/docs/sdk/v0.47//learn/advanced/ocap), it is stated that: +In the current Cosmos SDK documentation on the [Object-Capability Model](/docs/sdk/v0.47/learn/advanced/ocap), it is stated that: > We assume that a thriving ecosystem of Cosmos SDK modules that are easy to compose into a blockchain application will contain faulty or malicious modules. diff --git a/docs/sdk/v0.47/build/building-apps/app-mempool.mdx b/docs/sdk/v0.47/build/building-apps/app-mempool.mdx index e25e7242..755d2e9e 100644 --- a/docs/sdk/v0.47/build/building-apps/app-mempool.mdx +++ b/docs/sdk/v0.47/build/building-apps/app-mempool.mdx @@ -16,7 +16,7 @@ Notably it introduces the `PrepareProposal` and `ProcessProposal` steps of ABCI+ ### Pre-requisite Readings -* [BaseApp](/docs/sdk/v0.47//learn/advanced/baseapp) +* [BaseApp](/docs/sdk/v0.47/learn/advanced/baseapp) diff --git a/docs/sdk/v0.47/build/building-modules/beginblock-endblock.mdx b/docs/sdk/v0.47/build/building-modules/beginblock-endblock.mdx index 52c63434..b6b32ebd 100644 --- a/docs/sdk/v0.47/build/building-modules/beginblock-endblock.mdx +++ b/docs/sdk/v0.47/build/building-modules/beginblock-endblock.mdx @@ -4,7 +4,7 @@ title: BeginBlocker and EndBlocker **Synopsis** -`BeginBlocker` and `EndBlocker` are optional methods module developers can implement in their module. They will be triggered at the beginning and at the end of each block respectively, when the [`BeginBlock`](/docs/sdk/v0.47//learn/advanced/baseapp#beginblock) and [`EndBlock`](/docs/sdk/v0.47//learn/advanced/baseapp#endblock) ABCI messages are received from the underlying consensus engine. +`BeginBlocker` and `EndBlocker` are optional methods module developers can implement in their module. They will be triggered at the beginning and at the end of each block respectively, when the [`BeginBlock`](/docs/sdk/v0.47/learn/advanced/baseapp#beginblock) and [`EndBlock`](/docs/sdk/v0.47/learn/advanced/baseapp#endblock) ABCI messages are received from the underlying consensus engine. @@ -23,9 +23,9 @@ When needed, `BeginBlocker` and `EndBlocker` are implemented as part of the [`Be The actual implementation of `BeginBlocker` and `EndBlocker` in `abci.go` are very similar to that of a [`Msg` service](/docs/sdk/v0.47/build/building-modules/msg-services): -* They generally use the [`keeper`](/docs/sdk/v0.47/build/building-modules/keeper) and [`ctx`](/docs/sdk/v0.47//learn/advanced/context) to retrieve information about the latest state. +* They generally use the [`keeper`](/docs/sdk/v0.47/build/building-modules/keeper) and [`ctx`](/docs/sdk/v0.47/learn/advanced/context) to retrieve information about the latest state. * If needed, they use the `keeper` and `ctx` to trigger state-transitions. -* If needed, they can emit [`events`](/docs/sdk/v0.47//learn/advanced/events) via the `ctx`'s `EventManager`. +* If needed, they can emit [`events`](/docs/sdk/v0.47/learn/advanced/events) via the `ctx`'s `EventManager`. A specificity of the `EndBlocker` is that it can return validator updates to the underlying consensus engine in the form of an [`[]abci.ValidatorUpdates`](https://docs.cometbft.com/v0.37/spec/abci/abci++_methods#endblock). This is the preferred way to implement custom validator changes. diff --git a/docs/sdk/v0.47/build/building-modules/genesis.mdx b/docs/sdk/v0.47/build/building-modules/genesis.mdx index c2e68d19..efbca31b 100644 --- a/docs/sdk/v0.47/build/building-modules/genesis.mdx +++ b/docs/sdk/v0.47/build/building-modules/genesis.mdx @@ -18,7 +18,7 @@ Modules generally handle a subset of the state and, as such, they need to define ## Type Definition -The subset of the genesis state defined from a given module is generally defined in a `genesis.proto` file ([more info](/docs/sdk/v0.47//learn/advanced/encoding#gogoproto) on how to define protobuf messages). The struct defining the module's subset of the genesis state is usually called `GenesisState` and contains all the module-related values that need to be initialized during the genesis process. +The subset of the genesis state defined from a given module is generally defined in a `genesis.proto` file ([more info](/docs/sdk/v0.47/learn/advanced/encoding#gogoproto) on how to define protobuf messages). The struct defining the module's subset of the genesis state is usually called `GenesisState` and contains all the module-related values that need to be initialized during the genesis process. See an example of `GenesisState` protobuf message definition from the `auth` module: @@ -607,9 +607,9 @@ Other than the methods related directly to `GenesisState`, module developers are ### `InitGenesis` -The `InitGenesis` method is executed during [`InitChain`](/docs/sdk/v0.47//learn/advanced/baseapp#initchain) when the application is first started. Given a `GenesisState`, it initializes the subset of the state managed by the module by using the module's [`keeper`](/docs/sdk/v0.47/build/building-modules/keeper) setter function on each parameter within the `GenesisState`. +The `InitGenesis` method is executed during [`InitChain`](/docs/sdk/v0.47/learn/advanced/baseapp#initchain) when the application is first started. Given a `GenesisState`, it initializes the subset of the state managed by the module by using the module's [`keeper`](/docs/sdk/v0.47/build/building-modules/keeper) setter function on each parameter within the `GenesisState`. -The [module manager](/docs/sdk/v0.47/build/building-modules/module-manager#manager) of the application is responsible for calling the `InitGenesis` method of each of the application's modules in order. This order is set by the application developer via the manager's `SetOrderGenesisMethod`, which is called in the [application's constructor function](/docs/sdk/v0.47//learn/beginner/overview-app#constructor-function). +The [module manager](/docs/sdk/v0.47/build/building-modules/module-manager#manager) of the application is responsible for calling the `InitGenesis` method of each of the application's modules in order. This order is set by the application developer via the manager's `SetOrderGenesisMethod`, which is called in the [application's constructor function](/docs/sdk/v0.47/learn/beginner/app-anatomy#constructor-function). See an example of `InitGenesis` from the `auth` module: diff --git a/docs/sdk/v0.47/build/building-modules/intro.mdx b/docs/sdk/v0.47/build/building-modules/intro.mdx index 409dc7ed..98fc6b61 100644 --- a/docs/sdk/v0.47/build/building-modules/intro.mdx +++ b/docs/sdk/v0.47/build/building-modules/intro.mdx @@ -11,18 +11,18 @@ Modules define most of the logic of Cosmos SDK applications. Developers compose ### Pre-requisite Readings -* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.47//learn/beginner/overview-app) -* [Lifecycle of a Cosmos SDK transaction](/docs/sdk/v0.47//learn/beginner/tx-lifecycle) +* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.47/learn/beginner/app-anatomy) +* [Lifecycle of a Cosmos SDK transaction](/docs/sdk/v0.47/learn/beginner/tx-lifecycle) ## Role of Modules in a Cosmos SDK Application -The Cosmos SDK can be thought of as the Ruby-on-Rails of blockchain development. It comes with a core that provides the basic functionalities every blockchain application needs, like a [boilerplate implementation of the ABCI](/docs/sdk/v0.47//learn/advanced/baseapp) to communicate with the underlying consensus engine, a [`multistore`](/docs/sdk/v0.47//learn/advanced/store#multistore) to persist state, a [server](/docs/sdk/v0.47//learn/advanced/node) to form a full-node and [interfaces](/docs/sdk/v0.47/build/building-modules/module-interfaces) to handle queries. +The Cosmos SDK can be thought of as the Ruby-on-Rails of blockchain development. It comes with a core that provides the basic functionalities every blockchain application needs, like a [boilerplate implementation of the ABCI](/docs/sdk/v0.47/learn/advanced/baseapp) to communicate with the underlying consensus engine, a [`multistore`](/docs/sdk/v0.47/learn/advanced/store#multistore) to persist state, a [server](/docs/sdk/v0.47/learn/advanced/node) to form a full-node and [interfaces](/docs/sdk/v0.47/build/building-modules/module-interfaces) to handle queries. On top of this core, the Cosmos SDK enables developers to build modules that implement the business logic of their application. In other words, SDK modules implement the bulk of the logic of applications, while the core does the wiring and enables modules to be composed together. The end goal is to build a robust ecosystem of open-source Cosmos SDK modules, making it increasingly easier to build complex blockchain applications. -Cosmos SDK modules can be seen as little state-machines within the state-machine. They generally define a subset of the state using one or more `KVStore`s in the [main multistore](/docs/sdk/v0.47//learn/advanced/store), as well as a subset of [message types](/docs/sdk/v0.47/build/building-modules/messages-and-queries#messages). These messages are routed by one of the main components of Cosmos SDK core, [`BaseApp`](/docs/sdk/v0.47//learn/advanced/baseapp), to a module Protobuf [`Msg` service](/docs/sdk/v0.47/build/building-modules/msg-services) that defines them. +Cosmos SDK modules can be seen as little state-machines within the state-machine. They generally define a subset of the state using one or more `KVStore`s in the [main multistore](/docs/sdk/v0.47/learn/advanced/store), as well as a subset of [message types](/docs/sdk/v0.47/build/building-modules/messages-and-queries#messages). These messages are routed by one of the main components of Cosmos SDK core, [`BaseApp`](/docs/sdk/v0.47/learn/advanced/baseapp), to a module Protobuf [`Msg` service](/docs/sdk/v0.47/build/building-modules/msg-services) that defines them. ```text expandable + @@ -76,7 +76,7 @@ As a result of this architecture, building a Cosmos SDK application usually revo While there are no definitive guidelines for writing modules, here are some important design principles developers should keep in mind when building them: * **Composability**: Cosmos SDK applications are almost always composed of multiple modules. This means developers need to carefully consider the integration of their module not only with the core of the Cosmos SDK, but also with other modules. The former is achieved by following standard design patterns outlined [here](#main-components-of-cosmos-sdk-modules), while the latter is achieved by properly exposing the store(s) of the module via the [`keeper`](/docs/sdk/v0.47/build/building-modules/keeper). -* **Specialization**: A direct consequence of the **composability** feature is that modules should be **specialized**. Developers should carefully establish the scope of their module and not batch multiple functionalities into the same module. This separation of concerns enables modules to be re-used in other projects and improves the upgradability of the application. **Specialization** also plays an important role in the [object-capabilities model](/docs/sdk/v0.47//learn/advanced/ocap) of the Cosmos SDK. +* **Specialization**: A direct consequence of the **composability** feature is that modules should be **specialized**. Developers should carefully establish the scope of their module and not batch multiple functionalities into the same module. This separation of concerns enables modules to be re-used in other projects and improves the upgradability of the application. **Specialization** also plays an important role in the [object-capabilities model](/docs/sdk/v0.47/learn/advanced/ocap) of the Cosmos SDK. * **Capabilities**: Most modules need to read and/or write to the store(s) of other modules. However, in an open-source environment, it is possible for some modules to be malicious. That is why module developers need to carefully think not only about how their module interacts with other modules, but also about how to give access to the module's store(s). The Cosmos SDK takes a capabilities-oriented approach to inter-module security. This means that each store defined by a module is accessed by a `key`, which is held by the module's [`keeper`](/docs/sdk/v0.47/build/building-modules/keeper). This `keeper` defines how to access the store(s) and under what conditions. Access to the module's store(s) is done by passing a reference to the module's `keeper`. ## Main Components of Cosmos SDK Modules @@ -84,8 +84,8 @@ While there are no definitive guidelines for writing modules, here are some impo Modules are by convention defined in the `./x/` subfolder (e.g. the `bank` module will be defined in the `./x/bank` folder). They generally share the same core components: * A [`keeper`](/docs/sdk/v0.47/build/building-modules/keeper), used to access the module's store(s) and update the state. -* A [`Msg` service](/docs/sdk/v0.47/build/building-modules/messages-and-queries#messages), used to process messages when they are routed to the module by [`BaseApp`](/docs/sdk/v0.47//learn/advanced/baseapp#message-routing) and trigger state-transitions. -* A [query service](/docs/sdk/v0.47/build/building-modules/query-services), used to process user queries when they are routed to the module by [`BaseApp`](/docs/sdk/v0.47//learn/advanced/baseapp#query-routing). +* A [`Msg` service](/docs/sdk/v0.47/build/building-modules/messages-and-queries#messages), used to process messages when they are routed to the module by [`BaseApp`](/docs/sdk/v0.47/learn/advanced/baseapp#message-routing) and trigger state-transitions. +* A [query service](/docs/sdk/v0.47/build/building-modules/query-services), used to process user queries when they are routed to the module by [`BaseApp`](/docs/sdk/v0.47/learn/advanced/baseapp#query-routing). * Interfaces, for end users to query the subset of the state defined by the module and create `message`s of the custom types defined in the module. In addition to these components, modules implement the `AppModule` interface in order to be managed by the [`module manager`](/docs/sdk/v0.47/build/building-modules/module-manager). diff --git a/docs/sdk/v0.47/build/building-modules/invariants.mdx b/docs/sdk/v0.47/build/building-modules/invariants.mdx index ef593587..074c3d55 100644 --- a/docs/sdk/v0.47/build/building-modules/invariants.mdx +++ b/docs/sdk/v0.47/build/building-modules/invariants.mdx @@ -473,7 +473,7 @@ error { } ``` -The `InvariantRegistry` is therefore typically instantiated by instantiating the `keeper` of the `crisis` module in the [application's constructor function](/docs/sdk/v0.47//learn/beginner/overview-app#constructor-function). +The `InvariantRegistry` is therefore typically instantiated by instantiating the `keeper` of the `crisis` module in the [application's constructor function](/docs/sdk/v0.47/learn/beginner/app-anatomy#constructor-function). `Invariant`s can be checked manually via [`message`s](/docs/sdk/v0.47/build/building-modules/messages-and-queries), but most often they are checked automatically at the end of each block. Here is an example from the `crisis` module: diff --git a/docs/sdk/v0.47/build/building-modules/keeper.mdx b/docs/sdk/v0.47/build/building-modules/keeper.mdx index e8d0f256..543658bf 100644 --- a/docs/sdk/v0.47/build/building-modules/keeper.mdx +++ b/docs/sdk/v0.47/build/building-modules/keeper.mdx @@ -19,9 +19,9 @@ title: Keepers The Cosmos SDK is a framework that makes it easy for developers to build complex decentralized applications from scratch, mainly by composing modules together. As the ecosystem of open-source modules for the Cosmos SDK expands, it will become increasingly likely that some of these modules contain vulnerabilities, as a result of the negligence or malice of their developer. -The Cosmos SDK adopts an [object-capabilities-based approach](/docs/sdk/v0.47//learn/advanced/ocap) to help developers better protect their application from unwanted inter-module interactions, and `keeper`s are at the core of this approach. A `keeper` can be considered quite literally to be the gatekeeper of a module's store(s). Each store (typically an [`IAVL` Store](/docs/sdk/v0.47//learn/advanced/store#iavl-store)) defined within a module comes with a `storeKey`, which grants unlimited access to it. The module's `keeper` holds this `storeKey` (which should otherwise remain unexposed), and defines [methods](#implementing-methods) for reading and writing to the store(s). +The Cosmos SDK adopts an [object-capabilities-based approach](/docs/sdk/v0.47/learn/advanced/ocap) to help developers better protect their application from unwanted inter-module interactions, and `keeper`s are at the core of this approach. A `keeper` can be considered quite literally to be the gatekeeper of a module's store(s). Each store (typically an [`IAVL` Store](/docs/sdk/v0.47/learn/advanced/store#iavl-store)) defined within a module comes with a `storeKey`, which grants unlimited access to it. The module's `keeper` holds this `storeKey` (which should otherwise remain unexposed), and defines [methods](#implementing-methods) for reading and writing to the store(s). -The core idea behind the object-capabilities approach is to only reveal what is necessary to get the work done. In practice, this means that instead of handling permissions of modules through access-control lists, module `keeper`s are passed a reference to the specific instance of the other modules' `keeper`s that they need to access (this is done in the [application's constructor function](/docs/sdk/v0.47//learn/beginner/overview-app#constructor-function)). As a consequence, a module can only interact with the subset of state defined in another module via the methods exposed by the instance of the other module's `keeper`. This is a great way for developers to control the interactions that their own module can have with modules developed by external developers. +The core idea behind the object-capabilities approach is to only reveal what is necessary to get the work done. In practice, this means that instead of handling permissions of modules through access-control lists, module `keeper`s are passed a reference to the specific instance of the other modules' `keeper`s that they need to access (this is done in the [application's constructor function](/docs/sdk/v0.47/learn/beginner/app-anatomy#constructor-function)). As a consequence, a module can only interact with the subset of state defined in another module via the methods exposed by the instance of the other module's `keeper`. This is a great way for developers to control the interactions that their own module can have with modules developed by external developers. ## Type Definition @@ -212,10 +212,10 @@ return valUpdates.Updates Let us go through the different parameters: * An expected `keeper` is a `keeper` external to a module that is required by the internal `keeper` of said module. External `keeper`s are listed in the internal `keeper`'s type definition as interfaces. These interfaces are themselves defined in an `expected_keepers.go` file in the root of the module's folder. In this context, interfaces are used to reduce the number of dependencies, as well as to facilitate the maintenance of the module itself. -* `storeKey`s grant access to the store(s) of the [multistore](/docs/sdk/v0.47//learn/advanced/store) managed by the module. They should always remain unexposed to external modules. -* `cdc` is the [codec](/docs/sdk/v0.47//learn/advanced/encoding) used to marshall and unmarshall structs to/from `[]byte`. The `cdc` can be any of `codec.BinaryCodec`, `codec.JSONCodec` or `codec.Codec` based on your requirements. It can be either a proto or amino codec as long as they implement these interfaces. The authority listed is a module account or user account that has the right to change module level parameters. Previously this was handled by the param module, which has been deprecated. +* `storeKey`s grant access to the store(s) of the [multistore](/docs/sdk/v0.47/learn/advanced/store) managed by the module. They should always remain unexposed to external modules. +* `cdc` is the [codec](/docs/sdk/v0.47/learn/advanced/encoding) used to marshall and unmarshall structs to/from `[]byte`. The `cdc` can be any of `codec.BinaryCodec`, `codec.JSONCodec` or `codec.Codec` based on your requirements. It can be either a proto or amino codec as long as they implement these interfaces. The authority listed is a module account or user account that has the right to change module level parameters. Previously this was handled by the param module, which has been deprecated. -Of course, it is possible to define different types of internal `keeper`s for the same module (e.g. a read-only `keeper`). Each type of `keeper` comes with its own constructor function, which is called from the [application's constructor function](/docs/sdk/v0.47//learn/beginner/overview-app). This is where `keeper`s are instantiated, and where developers make sure to pass correct instances of modules' `keeper`s to other modules that require them. +Of course, it is possible to define different types of internal `keeper`s for the same module (e.g. a read-only `keeper`). Each type of `keeper` comes with its own constructor function, which is called from the [application's constructor function](/docs/sdk/v0.47/learn/beginner/app-anatomy). This is where `keeper`s are instantiated, and where developers make sure to pass correct instances of modules' `keeper`s to other modules that require them. ## Implementing Methods @@ -253,7 +253,7 @@ and the method will go through the following steps: For more, see an example of `keeper`'s [methods implementation from the `staking` module](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/staking/keeper/keeper.go). -The [module `KVStore`](/docs/sdk/v0.47//learn/advanced/store#kvstore-and-commitkvstore-interfaces) also provides an `Iterator()` method which returns an `Iterator` object to iterate over a domain of keys. +The [module `KVStore`](/docs/sdk/v0.47/learn/advanced/store#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: diff --git a/docs/sdk/v0.47/build/building-modules/messages-and-queries.mdx b/docs/sdk/v0.47/build/building-modules/messages-and-queries.mdx index 35bbfc38..f35f0b73 100644 --- a/docs/sdk/v0.47/build/building-modules/messages-and-queries.mdx +++ b/docs/sdk/v0.47/build/building-modules/messages-and-queries.mdx @@ -17,13 +17,13 @@ title: Messages and Queries ## Messages -`Msg`s are objects whose end-goal is to trigger state-transitions. They are wrapped in [transactions](/docs/sdk/v0.47//learn/advanced/transactions), which may contain one or more of them. +`Msg`s are objects whose end-goal is to trigger state-transitions. They are wrapped in [transactions](/docs/sdk/v0.47/learn/advanced/transactions), which may contain one or more of them. -When a transaction is relayed from the underlying consensus engine to the Cosmos SDK application, it is first decoded by [`BaseApp`](/docs/sdk/v0.47//learn/advanced/baseapp). Then, each message contained in the transaction is extracted and routed to the appropriate module via `BaseApp`'s `MsgServiceRouter` so that it can be processed by the module's [`Msg` service](/docs/sdk/v0.47/build/building-modules/msg-services). For a more detailed explanation of the lifecycle of a transaction, click [here](/docs/sdk/v0.47//learn/beginner/tx-lifecycle). +When a transaction is relayed from the underlying consensus engine to the Cosmos SDK application, it is first decoded by [`BaseApp`](/docs/sdk/v0.47/learn/advanced/baseapp). Then, each message contained in the transaction is extracted and routed to the appropriate module via `BaseApp`'s `MsgServiceRouter` so that it can be processed by the module's [`Msg` service](/docs/sdk/v0.47/build/building-modules/msg-services). For a more detailed explanation of the lifecycle of a transaction, click [here](/docs/sdk/v0.47/learn/beginner/tx-lifecycle). ### `Msg` Services -Defining Protobuf `Msg` services is the recommended way to handle messages. A Protobuf `Msg` service should be created for each module, typically in `tx.proto` (see more info about [conventions and naming](/docs/sdk/v0.47//learn/advanced/encoding#faq)). It must have an RPC service method defined for each message in the module. +Defining Protobuf `Msg` services is the recommended way to handle messages. A Protobuf `Msg` service should be created for each module, typically in `tx.proto` (see more info about [conventions and naming](/docs/sdk/v0.47/learn/advanced/encoding#faq)). It must have an RPC service method defined for each message in the module. See an example of a `Msg` service definition from `x/bank` module: @@ -880,7 +880,7 @@ return []sdk.AccAddress{ ## Queries -A `query` is a request for information made by end-users of applications through an interface and processed by a full-node. A `query` is received by a full-node through its consensus engine and relayed to the application via the ABCI. It is then routed to the appropriate module via `BaseApp`'s `QueryRouter` so that it can be processed by the module's query service (./04-query-services.md). For a deeper look at the lifecycle of a `query`, click [here](/docs/sdk/v0.47//learn/beginner/query-lifecycle). +A `query` is a request for information made by end-users of applications through an interface and processed by a full-node. A `query` is received by a full-node through its consensus engine and relayed to the application via the ABCI. It is then routed to the appropriate module via `BaseApp`'s `QueryRouter` so that it can be processed by the module's query service (./04-query-services.md). For a deeper look at the lifecycle of a `query`, click [here](/docs/sdk/v0.47/learn/beginner/query-lifecycle). ### gRPC Queries @@ -906,14 +906,14 @@ queryCategory/queryRoute/queryType/arg1/arg2/... where: -* `queryCategory` is the category of the `query`, typically `custom` for module queries. It is used to differentiate between different kinds of queries within `BaseApp`'s [`Query` method](/docs/sdk/v0.47//learn/advanced/baseapp#query). -* `queryRoute` is used by `BaseApp`'s [`queryRouter`](/docs/sdk/v0.47//learn/advanced/baseapp#grpc-query-router) to map the `query` to its module. Usually, `queryRoute` should be the name of the module. +* `queryCategory` is the category of the `query`, typically `custom` for module queries. It is used to differentiate between different kinds of queries within `BaseApp`'s [`Query` method](/docs/sdk/v0.47/learn/advanced/baseapp#query). +* `queryRoute` is used by `BaseApp`'s [`queryRouter`](/docs/sdk/v0.47/learn/advanced/baseapp#grpc-query-router) to map the `query` to its module. Usually, `queryRoute` should be the name of the module. * `queryType` is used by the module's [`querier`](/docs/sdk/v0.47/build/building-modules/query-services#query-services) to map the `query` to the appropriate `querier function` within the module. * `args` are the actual arguments needed to process the `query`. They are filled out by the end-user. Note that for bigger queries, you might prefer passing arguments in the `Data` field of the request `req` instead of the `path`. The `path` for each `query` must be defined by the module developer in the module's [command-line interface file](/docs/sdk/v0.47/build/building-modules/module-interfaces#query-commands).Overall, there are 3 mains components module developers need to implement in order to make the subset of the state defined by their module queryable: -* A [`querier`](/docs/sdk/v0.47/build/building-modules/query-services#query-services), to process the `query` once it has been [routed to the module](/docs/sdk/v0.47//learn/advanced/baseapp#grpc-query-router). +* A [`querier`](/docs/sdk/v0.47/build/building-modules/query-services#query-services), to process the `query` once it has been [routed to the module](/docs/sdk/v0.47/learn/advanced/baseapp#grpc-query-router). * [Query commands](/docs/sdk/v0.47/build/building-modules/module-interfaces#query-commands) in the module's CLI file, where the `path` for each `query` is specified. * `query` return types. Typically defined in a file `types/querier.go`, they specify the result type of each of the module's `queries`. These custom types must implement the `String()` method of [`fmt.Stringer`](https://pkg.go.dev/fmt#Stringer). diff --git a/docs/sdk/v0.47/build/building-modules/module-interfaces.mdx b/docs/sdk/v0.47/build/building-modules/module-interfaces.mdx index 16b9942f..b84cbac1 100644 --- a/docs/sdk/v0.47/build/building-modules/module-interfaces.mdx +++ b/docs/sdk/v0.47/build/building-modules/module-interfaces.mdx @@ -17,11 +17,11 @@ This document details how to build CLI and REST interfaces for a module. Example ## CLI -One of the main interfaces for an application is the [command-line interface](/docs/sdk/v0.47//learn/advanced/cli). This entrypoint adds commands from the application's modules enabling end-users to create [**messages**](/docs/sdk/v0.47/build/building-modules/messages-and-queries#messages) wrapped in transactions and [**queries**](/docs/sdk/v0.47/build/building-modules/messages-and-queries#queries). The CLI files are typically found in the module's `./client/cli` folder. +One of the main interfaces for an application is the [command-line interface](/docs/sdk/v0.47/learn/advanced/cli). This entrypoint adds commands from the application's modules enabling end-users to create [**messages**](/docs/sdk/v0.47/build/building-modules/messages-and-queries#messages) wrapped in transactions and [**queries**](/docs/sdk/v0.47/build/building-modules/messages-and-queries#queries). The CLI files are typically found in the module's `./client/cli` folder. ### Transaction Commands -In order to create messages that trigger state changes, end-users must create [transactions](/docs/sdk/v0.47//learn/advanced/transactions) that wrap and deliver the messages. A transaction command creates a transaction that includes one or more messages. +In order to create messages that trigger state changes, end-users must create [transactions](/docs/sdk/v0.47/learn/advanced/transactions) that wrap and deliver the messages. A transaction command creates a transaction that includes one or more messages. Transaction commands typically have their own `tx.go` file that lives within the module's `./client/cli` folder. The commands are specified in getter functions and the name of the function should include the name of the command. @@ -2049,7 +2049,7 @@ return BankOutputs{ ### Flags -[Flags](/docs/sdk/v0.47//learn/advanced/cli#flags) allow users to customize commands. `--fees` and `--gas-prices` are examples of flags that allow users to set the [fees](/docs/sdk/v0.47//learn/beginner/gas-fees) and gas prices for their transactions. +[Flags](/docs/sdk/v0.47/learn/advanced/cli#flags) allow users to customize commands. `--fees` and `--gas-prices` are examples of flags that allow users to set the [fees](/docs/sdk/v0.47/learn/beginner/gas-fees) and gas prices for their transactions. Flags that are specific to a module are typically created in a `flags.go` file in the module's `./client/cli` folder. When creating a flag, developers set the value type, the name of the flag, the default value, and a description about the flag. Developers also have the option to mark flags as *required* so that an error is thrown if the user does not include a value for the flag. @@ -2896,6 +2896,6 @@ Modules that want to expose REST queries should add `google.api.http` annotation // Reference: https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/auth/v1beta1/query.proto#L14-L89 ``` -gRPC gateway is started in-process along with the application and CometBFT. It can be enabled or disabled by setting gRPC Configuration `enable` in [`app.toml`](/docs/sdk/v0.47//user/run-node/interact-node#configuring-the-node-using-apptoml). +gRPC gateway is started in-process along with the application and CometBFT. It can be enabled or disabled by setting gRPC Configuration `enable` in [`app.toml`](/docs/sdk/v0.47/user/run-node/interact-node#configuring-the-node-using-apptoml). -The Cosmos SDK provides a command for generating [Swagger](https://swagger.io/) documentation (`protoc-gen-swagger`). Setting `swagger` in [`app.toml`](/docs/sdk/v0.47//user/run-node/interact-node#configuring-the-node-using-apptoml) defines if swagger documentation should be automatically registered. +The Cosmos SDK provides a command for generating [Swagger](https://swagger.io/) documentation (`protoc-gen-swagger`). Setting `swagger` in [`app.toml`](/docs/sdk/v0.47/user/run-node/interact-node#configuring-the-node-using-apptoml) defines if swagger documentation should be automatically registered. diff --git a/docs/sdk/v0.47/build/building-modules/module-manager.mdx b/docs/sdk/v0.47/build/building-modules/module-manager.mdx index fd297d65..e55a642f 100644 --- a/docs/sdk/v0.47/build/building-modules/module-manager.mdx +++ b/docs/sdk/v0.47/build/building-modules/module-manager.mdx @@ -4,7 +4,7 @@ title: Module Manager **Synopsis** -Cosmos SDK modules need to implement the [`AppModule` interfaces](#application-module-interfaces), in order to be managed by the application's [module manager](#module-manager). The module manager plays an important role in [`message` and `query` routing](/docs/sdk/v0.47//learn/advanced/baseapp#msg-service-router), and allows application developers to set the order of execution of a variety of functions like [`BeginBlocker` and `EndBlocker`](/docs/sdk/v0.47//learn/beginner/overview-app#beginblocker-and-endblocker). +Cosmos SDK modules need to implement the [`AppModule` interfaces](#application-module-interfaces), in order to be managed by the application's [module manager](#module-manager). The module manager plays an important role in [`message` and `query` routing](/docs/sdk/v0.47/learn/advanced/baseapp#msg-service-router), and allows application developers to set the order of execution of a variety of functions like [`BeginBlocker` and `EndBlocker`](/docs/sdk/v0.47/learn/beginner/app-anatomy#beginblocker-and-endblocker). @@ -38,7 +38,7 @@ The above interfaces are mostly embedding smaller interfaces (extension interfac * [`HasPrecommit`](#hasprecommit): The extension interface that contains information about the `AppModule` and `Precommit`. * [`HasPrepareCheckState`](#haspreparecheckstate): The extension interface that contains information about the `AppModule` and `PrepareCheckState`. -The `AppModuleBasic` interface exists to define independent methods of the module, i.e. those that do not depend on other modules in the application. This allows for the construction of the basic application structure early in the application definition, generally in the `init()` function of the [main application file](/docs/sdk/v0.47//learn/beginner/overview-app#core-application-file). +The `AppModuleBasic` interface exists to define independent methods of the module, i.e. those that do not depend on other modules in the application. This allows for the construction of the basic application structure early in the application definition, generally in the `init()` function of the [main application file](/docs/sdk/v0.47/learn/beginner/app-anatomy#core-application-file). The `AppModule` interface exists to define inter-dependent module methods. Many modules need to interact with other modules, typically through [`keeper`s](/docs/sdk/v0.47/build/building-modules/keeper), which means there is a need for an interface where modules list their `keeper`s and other methods that require a reference to another module's object. `AppModule` interface extension, such as `BeginBlockAppModule` and `EndBlockAppModule`, also enables the module manager to set the order of execution between module's methods like `BeginBlock` and `EndBlock`, which is important in cases where the order of execution between modules matters in the context of the application. @@ -9805,14 +9805,14 @@ return out It implements the following methods: -* `NewBasicManager(modules ...AppModuleBasic)`: Constructor function. It takes a list of the application's `AppModuleBasic` and builds a new `BasicManager`. This function is generally called in the `init()` function of [`app.go`](/docs/sdk/v0.47//learn/beginner/overview-app#core-application-file) to quickly initialize the independent elements of the application's modules (click [here](https://github.com/cosmos/gaia/blob/main/app/app.go#L59-L74) to see an example). -* `RegisterLegacyAminoCodec(cdc *codec.LegacyAmino)`: Registers the [`codec.LegacyAmino`s](/docs/sdk/v0.47//learn/advanced/encoding#amino) of each of the application's `AppModuleBasic`. This function is usually called early on in the [application's construction](/docs/sdk/v0.47//learn/beginner/overview-app#constructor). +* `NewBasicManager(modules ...AppModuleBasic)`: Constructor function. It takes a list of the application's `AppModuleBasic` and builds a new `BasicManager`. This function is generally called in the `init()` function of [`app.go`](/docs/sdk/v0.47/learn/beginner/app-anatomy#core-application-file) to quickly initialize the independent elements of the application's modules (click [here](https://github.com/cosmos/gaia/blob/main/app/app.go#L59-L74) to see an example). +* `RegisterLegacyAminoCodec(cdc *codec.LegacyAmino)`: Registers the [`codec.LegacyAmino`s](/docs/sdk/v0.47/learn/advanced/encoding#amino) of each of the application's `AppModuleBasic`. This function is usually called early on in the [application's construction](/docs/sdk/v0.47/learn/beginner/app-anatomy#constructor). * `RegisterInterfaces(registry codectypes.InterfaceRegistry)`: Registers interface types and implementations of each of the application's `AppModuleBasic`. * `DefaultGenesis(cdc codec.JSONCodec)`: Provides default genesis information for modules in the application by calling the [`DefaultGenesis(cdc codec.JSONCodec)`](/docs/sdk/v0.47/build/building-modules/genesis#defaultgenesis) function of each module. It only calls the modules that implements the `HasGenesisBasics` interfaces. * `ValidateGenesis(cdc codec.JSONCodec, txEncCfg client.TxEncodingConfig, genesis map[string]json.RawMessage)`: Validates the genesis information modules by calling the [`ValidateGenesis(codec.JSONCodec, client.TxEncodingConfig, json.RawMessage)`](/docs/sdk/v0.47/build/building-modules/genesis#validategenesis) function of modules implementing the `HasGenesisBasics` interface. * `RegisterGRPCGatewayRoutes(clientCtx client.Context, rtr *runtime.ServeMux)`: Registers gRPC routes for modules. -* `AddTxCommands(rootTxCmd *cobra.Command)`: Adds modules' transaction commands to the application's [`rootTxCommand`](/docs/sdk/v0.47//learn/advanced/cli#transaction-commands). This function is usually called function from the `main.go` function of the [application's command-line interface](/docs/sdk/v0.47//learn/advanced/cli). -* `AddQueryCommands(rootQueryCmd *cobra.Command)`: Adds modules' query commands to the application's [`rootQueryCommand`](/docs/sdk/v0.47//learn/advanced/cli#query-commands). This function is usually called function from the `main.go` function of the [application's command-line interface](/docs/sdk/v0.47//learn/advanced/cli). +* `AddTxCommands(rootTxCmd *cobra.Command)`: Adds modules' transaction commands to the application's [`rootTxCommand`](/docs/sdk/v0.47/learn/advanced/cli#transaction-commands). This function is usually called function from the `main.go` function of the [application's command-line interface](/docs/sdk/v0.47/learn/advanced/cli). +* `AddQueryCommands(rootQueryCmd *cobra.Command)`: Adds modules' query commands to the application's [`rootQueryCommand`](/docs/sdk/v0.47/learn/advanced/cli#query-commands). This function is usually called function from the `main.go` function of the [application's command-line interface](/docs/sdk/v0.47/learn/advanced/cli). ### `Manager` @@ -10623,14 +10623,14 @@ return out The module manager is used throughout the application whenever an action on a collection of modules is required. It implements the following methods: -* `NewManager(modules ...AppModule)`: Constructor function. It takes a list of the application's `AppModule`s and builds a new `Manager`. It is generally called from the application's main [constructor function](/docs/sdk/v0.47//learn/beginner/overview-app#constructor-function). -* `SetOrderInitGenesis(moduleNames ...string)`: Sets the order in which the [`InitGenesis`](/docs/sdk/v0.47/build/building-modules/genesis#initgenesis) function of each module will be called when the application is first started. This function is generally called from the application's main [constructor function](/docs/sdk/v0.47//learn/beginner/overview-app#constructor-function). +* `NewManager(modules ...AppModule)`: Constructor function. It takes a list of the application's `AppModule`s and builds a new `Manager`. It is generally called from the application's main [constructor function](/docs/sdk/v0.47/learn/beginner/app-anatomy#constructor-function). +* `SetOrderInitGenesis(moduleNames ...string)`: Sets the order in which the [`InitGenesis`](/docs/sdk/v0.47/build/building-modules/genesis#initgenesis) function of each module will be called when the application is first started. This function is generally called from the application's main [constructor function](/docs/sdk/v0.47/learn/beginner/app-anatomy#constructor-function). To initialize modules successfully, module dependencies should be considered. For example, the `genutil` module must occur after `staking` module so that the pools are properly initialized with tokens from genesis accounts, the `genutils` module must also occur after `auth` so that it can access the params from auth, IBC's `capability` module should be initialized before all other modules so that it can initialize any capabilities. -* `SetOrderExportGenesis(moduleNames ...string)`: Sets the order in which the [`ExportGenesis`](/docs/sdk/v0.47/build/building-modules/genesis#exportgenesis) function of each module will be called in case of an export. This function is generally called from the application's main [constructor function](/docs/sdk/v0.47//learn/beginner/overview-app#constructor-function). -* `SetOrderBeginBlockers(moduleNames ...string)`: Sets the order in which the `BeginBlock()` function of each module will be called at the beginning of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.47//learn/beginner/overview-app#constructor-function). -* `SetOrderEndBlockers(moduleNames ...string)`: Sets the order in which the `EndBlock()` function of each module will be called at the end of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.47//learn/beginner/overview-app#constructor-function). -* `SetOrderPrecommiters(moduleNames ...string)`: Sets the order in which the `Precommit()` function of each module will be called during commit of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.47//learn/beginner/overview-app#constructor-function). -* `SetOrderPrepareCheckStaters(moduleNames ...string)`: Sets the order in which the `PrepareCheckState()` function of each module will be called during commit of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.47//learn/beginner/overview-app#constructor-function). +* `SetOrderExportGenesis(moduleNames ...string)`: Sets the order in which the [`ExportGenesis`](/docs/sdk/v0.47/build/building-modules/genesis#exportgenesis) function of each module will be called in case of an export. This function is generally called from the application's main [constructor function](/docs/sdk/v0.47/learn/beginner/app-anatomy#constructor-function). +* `SetOrderBeginBlockers(moduleNames ...string)`: Sets the order in which the `BeginBlock()` function of each module will be called at the beginning of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.47/learn/beginner/app-anatomy#constructor-function). +* `SetOrderEndBlockers(moduleNames ...string)`: Sets the order in which the `EndBlock()` function of each module will be called at the end of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.47/learn/beginner/app-anatomy#constructor-function). +* `SetOrderPrecommiters(moduleNames ...string)`: Sets the order in which the `Precommit()` function of each module will be called during commit of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.47/learn/beginner/app-anatomy#constructor-function). +* `SetOrderPrepareCheckStaters(moduleNames ...string)`: Sets the order in which the `PrepareCheckState()` function of each module will be called during commit of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.47/learn/beginner/app-anatomy#constructor-function). * `SetOrderMigrations(moduleNames ...string)`: Sets the order of migrations to be run. If not set then migrations will be run with an order defined in `DefaultMigrationsOrder`. * `RegisterInvariants(ir sdk.InvariantRegistry)`: Registers the [invariants](/docs/sdk/v0.47/build/building-modules/invariants) of module implementing the `HasInvariants` interface. * `RegisterRoutes(router sdk.Router, queryRouter sdk.QueryRouter, legacyQuerierCdc *codec.LegacyAmino)`: Registers legacy [`Msg`](/docs/sdk/v0.47/build/building-modules/messages-and-queries#messages) and [`querier`](/docs/sdk/v0.47/build/building-modules/query-services) routes. @@ -10638,10 +10638,10 @@ The module manager is used throughout the application whenever an action on a co * `InitGenesis(ctx sdk.Context, cdc codec.JSONCodec, genesisData map[string]json.RawMessage)`: Calls the [`InitGenesis`](/docs/sdk/v0.47/build/building-modules/genesis#initgenesis) function of each module when the application is first started, in the order defined in `OrderInitGenesis`. Returns an `abci.ResponseInitChain` to the underlying consensus engine, which can contain validator updates. * `ExportGenesis(ctx sdk.Context, cdc codec.JSONCodec)`: Calls the [`ExportGenesis`](/docs/sdk/v0.47/build/building-modules/genesis#exportgenesis) function of each module, in the order defined in `OrderExportGenesis`. The export constructs a genesis file from a previously existing state, and is mainly used when a hard-fork upgrade of the chain is required. * `ExportGenesisForModules(ctx sdk.Context, cdc codec.JSONCodec, modulesToExport []string)`: Behaves the same as `ExportGenesis`, except takes a list of modules to export. -* `BeginBlock(ctx sdk.Context, req abci.RequestBeginBlock)`: At the beginning of each block, this function is called from [`BaseApp`](/docs/sdk/v0.47//learn/advanced/baseapp#beginblock) and, in turn, calls the [`BeginBlock`](/docs/sdk/v0.47/build/building-modules/beginblock-endblock) function of each modules implementing the `BeginBlockAppModule` interface, in the order defined in `OrderBeginBlockers`. It creates a child [context](/docs/sdk/v0.47//learn/advanced/context) with an event manager to aggregate [events](/docs/sdk/v0.47//learn/advanced/events) emitted from all modules. The function returns an `abci.ResponseBeginBlock` which contains the aforementioned events. -* `EndBlock(ctx sdk.Context, req abci.RequestEndBlock)`: At the end of each block, this function is called from [`BaseApp`](/docs/sdk/v0.47//learn/advanced/baseapp#endblock) and, in turn, calls the [`EndBlock`](/docs/sdk/v0.47/build/building-modules/beginblock-endblock) function of each modules implementing the `EndBlockAppModule` interface, in the order defined in `OrderEndBlockers`. It creates a child [context](/docs/sdk/v0.47//learn/advanced/context) with an event manager to aggregate [events](/docs/sdk/v0.47//learn/advanced/events) emitted from all modules. The function returns an `abci.ResponseEndBlock` which contains the aforementioned events, as well as validator set updates (if any). -* `Precommit(ctx sdk.Context)`: During [`Commit`](/docs/sdk/v0.47//learn/advanced/baseapp#commit), this function is called from `BaseApp` immediately before the [`deliverState`](/docs/sdk/v0.47//learn/advanced/baseapp#state-updates) is written to the underlying [`rootMultiStore`](/docs/sdk/v0.47//learn/advanced/store#commitkvstore) and, in turn calls the `Precommit` function of each modules implementing the `HasPrecommit` interface, in the order defined in `OrderPrecommiters`. It creates a child [context](/docs/sdk/v0.47//learn/advanced/context) where the underlying `CacheMultiStore` is that of the newly committed block's [`deliverState`](/docs/sdk/v0.47//learn/advanced/baseapp#state-updates). -* `PrepareCheckState(ctx sdk.Context)`: During [`Commit`](/docs/sdk/v0.47//learn/advanced/baseapp#commit), this function is called from `BaseApp` immediately after the [`deliverState`](/docs/sdk/v0.47//learn/advanced/baseapp#state-updates) is written to the underlying [`rootMultiStore`](/docs/sdk/v0.47//learn/advanced/store#commitmultistore) and, in turn calls the `PrepareCheckState` function of each module implementing the `HasPrepareCheckState` interface, in the order defined in `OrderPrepareCheckStaters`. It creates a child [context](/docs/sdk/v0.47//learn/advanced/context) where the underlying `CacheMultiStore` is that of the next block's [`checkState`](/docs/sdk/v0.47//learn/advanced/baseapp#state-updates). Writes to this state will be present in the [`checkState`](/docs/sdk/v0.47//learn/advanced/baseapp#state-updates) of the next block, and therefore this method can be used to prepare the `checkState` for the next block. +* `BeginBlock(ctx sdk.Context, req abci.RequestBeginBlock)`: At the beginning of each block, this function is called from [`BaseApp`](/docs/sdk/v0.47/learn/advanced/baseapp#beginblock) and, in turn, calls the [`BeginBlock`](/docs/sdk/v0.47/build/building-modules/beginblock-endblock) function of each modules implementing the `BeginBlockAppModule` interface, in the order defined in `OrderBeginBlockers`. It creates a child [context](/docs/sdk/v0.47/learn/advanced/context) with an event manager to aggregate [events](/docs/sdk/v0.47/learn/advanced/events) emitted from all modules. The function returns an `abci.ResponseBeginBlock` which contains the aforementioned events. +* `EndBlock(ctx sdk.Context, req abci.RequestEndBlock)`: At the end of each block, this function is called from [`BaseApp`](/docs/sdk/v0.47/learn/advanced/baseapp#endblock) and, in turn, calls the [`EndBlock`](/docs/sdk/v0.47/build/building-modules/beginblock-endblock) function of each modules implementing the `EndBlockAppModule` interface, in the order defined in `OrderEndBlockers`. It creates a child [context](/docs/sdk/v0.47/learn/advanced/context) with an event manager to aggregate [events](/docs/sdk/v0.47/learn/advanced/events) emitted from all modules. The function returns an `abci.ResponseEndBlock` which contains the aforementioned events, as well as validator set updates (if any). +* `Precommit(ctx sdk.Context)`: During [`Commit`](/docs/sdk/v0.47/learn/advanced/baseapp#commit), this function is called from `BaseApp` immediately before the [`deliverState`](/docs/sdk/v0.47/learn/advanced/baseapp#state-updates) is written to the underlying [`rootMultiStore`](/docs/sdk/v0.47/learn/advanced/store#commitkvstore) and, in turn calls the `Precommit` function of each modules implementing the `HasPrecommit` interface, in the order defined in `OrderPrecommiters`. It creates a child [context](/docs/sdk/v0.47/learn/advanced/context) where the underlying `CacheMultiStore` is that of the newly committed block's [`deliverState`](/docs/sdk/v0.47/learn/advanced/baseapp#state-updates). +* `PrepareCheckState(ctx sdk.Context)`: During [`Commit`](/docs/sdk/v0.47/learn/advanced/baseapp#commit), this function is called from `BaseApp` immediately after the [`deliverState`](/docs/sdk/v0.47/learn/advanced/baseapp#state-updates) is written to the underlying [`rootMultiStore`](/docs/sdk/v0.47/learn/advanced/store#commitmultistore) and, in turn calls the `PrepareCheckState` function of each module implementing the `HasPrepareCheckState` interface, in the order defined in `OrderPrepareCheckStaters`. It creates a child [context](/docs/sdk/v0.47/learn/advanced/context) where the underlying `CacheMultiStore` is that of the next block's [`checkState`](/docs/sdk/v0.47/learn/advanced/baseapp#state-updates). Writes to this state will be present in the [`checkState`](/docs/sdk/v0.47/learn/advanced/baseapp#state-updates) of the next block, and therefore this method can be used to prepare the `checkState` for the next block. Here's an example of a concrete integration within an `simapp`: diff --git a/docs/sdk/v0.47/build/building-modules/msg-services.mdx b/docs/sdk/v0.47/build/building-modules/msg-services.mdx index 11ec862c..97c9b1c7 100644 --- a/docs/sdk/v0.47/build/building-modules/msg-services.mdx +++ b/docs/sdk/v0.47/build/building-modules/msg-services.mdx @@ -4,7 +4,7 @@ title: 'Msg Services' **Synopsis** -A Protobuf `Msg` service processes [messages](/docs/sdk/v0.47/build/building-modules/messages-and-queries#messages). Protobuf `Msg` services are specific to the module in which they are defined, and only process messages defined within the said module. They are called from `BaseApp` during [`DeliverTx`](/docs/sdk/v0.47//learn/advanced/baseapp#delivertx). +A Protobuf `Msg` service processes [messages](/docs/sdk/v0.47/build/building-modules/messages-and-queries#messages). Protobuf `Msg` services are specific to the module in which they are defined, and only process messages defined within the said module. They are called from `BaseApp` during [`DeliverTx`](/docs/sdk/v0.47/learn/advanced/baseapp#delivertx). @@ -2977,7 +2977,7 @@ After the validation is successful, the `msgServer` method uses the [`keeper`](/ ### Events -Before returning, `msgServer` methods generally emit one or more [events](/docs/sdk/v0.47//learn/advanced/events) by using the `EventManager` held in the `ctx`. Use the new `EmitTypedEvent` function that uses protobuf-based event types: +Before returning, `msgServer` methods generally emit one or more [events](/docs/sdk/v0.47/learn/advanced/events) by using the `EventManager` held in the `ctx`. Use the new `EmitTypedEvent` function that uses protobuf-based event types: ```go ctx.EventManager().EmitTypedEvent( @@ -2998,7 +2998,7 @@ ctx.EventManager().EmitEvent( ) ``` -These events are relayed back to the underlying consensus engine and can be used by service providers to implement services around the application. Click [here](/docs/sdk/v0.47//learn/advanced/events) to learn more about events. +These events are relayed back to the underlying consensus engine and can be used by service providers to implement services around the application. Click [here](/docs/sdk/v0.47/learn/advanced/events) to learn more about events. 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)`: @@ -3196,7 +3196,7 @@ This diagram shows a typical structure of a Protobuf `Msg` service, and how the ## Telemetry -New [telemetry metrics](/docs/sdk/v0.47//learn/advanced/telemetry) can be created from `msgServer` methods when handling messages. +New [telemetry metrics](/docs/sdk/v0.47/learn/advanced/telemetry) can be created from `msgServer` methods when handling messages. This is an example from the `x/auth/vesting` module: diff --git a/docs/sdk/v0.47/build/building-modules/query-services.mdx b/docs/sdk/v0.47/build/building-modules/query-services.mdx index cf1efbde..80d4f9eb 100644 --- a/docs/sdk/v0.47/build/building-modules/query-services.mdx +++ b/docs/sdk/v0.47/build/building-modules/query-services.mdx @@ -4,7 +4,7 @@ title: Query Services **Synopsis** -A Protobuf Query service processes [`queries`](/docs/sdk/v0.47/build/building-modules/messages-and-queries#queries). Query services are specific to the module in which they are defined, and only process `queries` defined within said module. They are called from `BaseApp`'s [`Query` method](/docs/sdk/v0.47//learn/advanced/baseapp#query). +A Protobuf Query service processes [`queries`](/docs/sdk/v0.47/build/building-modules/messages-and-queries#queries). Query services are specific to the module in which they are defined, and only process `queries` defined within said module. They are called from `BaseApp`'s [`Query` method](/docs/sdk/v0.47/learn/advanced/baseapp#query). diff --git a/docs/sdk/v0.47/build/building-modules/simulator.mdx b/docs/sdk/v0.47/build/building-modules/simulator.mdx index 99519218..77ad90f0 100644 --- a/docs/sdk/v0.47/build/building-modules/simulator.mdx +++ b/docs/sdk/v0.47/build/building-modules/simulator.mdx @@ -6,7 +6,7 @@ title: Module Simulation ### Pre-requisite Readings -* [Cosmos Blockchain Simulator](/docs/sdk/v0.47//learn/advanced/simulation) +* [Cosmos Blockchain Simulator](/docs/sdk/v0.47/learn/advanced/simulation) ## Synopsis @@ -62,7 +62,7 @@ Operations are one of the crucial parts of the Cosmos SDK simulation. They are t (`Msg`) that are simulated with random field values. The sender of the operation is also assigned randomly. -Operations on the simulation are simulated using the full [transaction cycle](/docs/sdk/v0.47//learn/advanced/transactions) of a +Operations on the simulation are simulated using the full [transaction cycle](/docs/sdk/v0.47/learn/advanced/transactions) of a `ABCI` application that exposes the `BaseApp`. Shown below is how weights are set: diff --git a/docs/sdk/v0.47/build/building-modules/upgrade.mdx b/docs/sdk/v0.47/build/building-modules/upgrade.mdx index 319279c0..624986f3 100644 --- a/docs/sdk/v0.47/build/building-modules/upgrade.mdx +++ b/docs/sdk/v0.47/build/building-modules/upgrade.mdx @@ -4,14 +4,14 @@ title: Upgrading Modules **Synopsis** -[In-Place Store Migrations](/docs/sdk/v0.47//learn/advanced/upgrade) allow your modules to upgrade to new versions that include breaking changes. This document outlines how to build modules to take advantage of this functionality. +[In-Place Store Migrations](/docs/sdk/v0.47/learn/advanced/upgrade) allow your modules to upgrade to new versions that include breaking changes. This document outlines how to build modules to take advantage of this functionality. ### Pre-requisite Readings -* [In-Place Store Migration](/docs/sdk/v0.47//learn/advanced/upgrade) +* [In-Place Store Migration](/docs/sdk/v0.47/learn/advanced/upgrade) diff --git a/docs/sdk/v0.47/build/migrations/upgrading.mdx b/docs/sdk/v0.47/build/migrations/upgrading.mdx index 63772832..7bb98ddd 100644 --- a/docs/sdk/v0.47/build/migrations/upgrading.mdx +++ b/docs/sdk/v0.47/build/migrations/upgrading.mdx @@ -365,7 +365,7 @@ Here are the following replacements that you need to perform on your proto files Please also check that in your own app's proto files that there are no single-word names for those two proto annotations. If so, then replace them with fully-qualified names, even though those names don't actually resolve to an actual protobuf entity. -For more information, see the [encoding guide](/docs/sdk/v0.47//learn/advanced/encoding). +For more information, see the [encoding guide](/docs/sdk/v0.47/learn/advanced/encoding). ### Transactions diff --git a/docs/sdk/v0.47/learn/advanced/baseapp.mdx b/docs/sdk/v0.47/learn/advanced/baseapp.mdx index df569aa5..ab0b0d0b 100644 --- a/docs/sdk/v0.47/learn/advanced/baseapp.mdx +++ b/docs/sdk/v0.47/learn/advanced/baseapp.mdx @@ -1398,17 +1398,17 @@ When messages and queries are received by the application, they must be routed t ### `Msg` Service Router -[`sdk.Msg`s](/docs/sdk/v0.47//build/building-modules/messages-and-queries#messages) need to be routed after they are extracted from transactions, which are sent from the underlying CometBFT 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. +[`sdk.Msg`s](/docs/sdk/v0.47/build/building-modules/messages-and-queries#messages) need to be routed after they are extracted from transactions, which are sent from the underlying CometBFT 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.47.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.47.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 application's `msgServiceRouter` is initialized with all the routes using the application's [module manager](/docs/sdk/v0.47//build/building-modules/module-manager#manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.47/learn/beginner/app-anatomy#constructor-function). +The application's `msgServiceRouter` is initialized with all the routes using the application's [module manager](/docs/sdk/v0.47/build/building-modules/module-manager#manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.47/learn/beginner/app-anatomy#constructor-function). ### gRPC Query Router -Similar to `sdk.Msg`s, [`queries`](/docs/sdk/v0.47//build/building-modules/messages-and-queries#queries) need to be routed to the appropriate module's [`Query` service](/docs/sdk/v0.47//build/building-modules/query-services). To do so, `BaseApp` holds a `grpcQueryRouter`, which maps modules' fully-qualified service methods (`string`, defined in their Protobuf `Query` gRPC) to their `QueryServer` implementation. The `grpcQueryRouter` is called during the initial stages of query processing, which can be either by directly sending a gRPC query to the gRPC endpoint, or via the [`Query` ABCI message](#query) on the CometBFT RPC endpoint. +Similar to `sdk.Msg`s, [`queries`](/docs/sdk/v0.47/build/building-modules/messages-and-queries#queries) need to be routed to the appropriate module's [`Query` service](/docs/sdk/v0.47/build/building-modules/query-services). To do so, `BaseApp` holds a `grpcQueryRouter`, which maps modules' fully-qualified service methods (`string`, defined in their Protobuf `Query` gRPC) to their `QueryServer` implementation. The `grpcQueryRouter` is called during the initial stages of query processing, which can be either by directly sending a gRPC query to the gRPC endpoint, or via the [`Query` ABCI message](#query) on the CometBFT RPC endpoint. -Just like the `msgServiceRouter`, the `grpcQueryRouter` is initialized with all the query routes using the application's [module manager](/docs/sdk/v0.47//build/building-modules/module-manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.47/learn/beginner/app-anatomy#app-constructor). +Just like the `msgServiceRouter`, the `grpcQueryRouter` is initialized with all the query routes using the application's [module manager](/docs/sdk/v0.47/build/building-modules/module-manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.47/learn/beginner/app-anatomy#app-constructor). ## Main ABCI 1.0 Messages @@ -1782,7 +1782,7 @@ Before the first transaction of a given block is processed, a [volatile state](# `DeliverTx` performs the **exact same steps as `CheckTx`**, with a little caveat at step 3 and the addition of a fifth step: 1. The `AnteHandler` does **not** check that the transaction's `gas-prices` is sufficient. That is because the `min-gas-prices` value `gas-prices` is checked against is local to the node, and therefore what is enough for one full-node might not be for another. This means that the proposer can potentially include transactions for free, although they are not incentivised to do so, as they earn a bonus on the total fee of the block they propose. -2. For each `sdk.Msg` in the transaction, route to the appropriate module's Protobuf [`Msg` service](/docs/sdk/v0.47//build/building-modules/msg-services). Additional *stateful* checks are performed, and the branched multistore held in `deliverState`'s `context` is updated by the module's `keeper`. If the `Msg` service returns successfully, the branched multistore held in `context` is written to `deliverState` `CacheMultiStore`. +2. For each `sdk.Msg` in the transaction, route to the appropriate module's Protobuf [`Msg` service](/docs/sdk/v0.47/build/building-modules/msg-services). Additional *stateful* checks are performed, and the branched multistore held in `deliverState`'s `context` is updated by the module's `keeper`. If the `Msg` service returns successfully, the branched multistore held in `context` is written to `deliverState` `CacheMultiStore`. 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: @@ -3449,7 +3449,7 @@ Click [here](/docs/sdk/v0.47/learn/beginner/gas-fees#antehandler) for more on th `RunMsgs` is called from `RunTx` with `runTxModeCheck` as parameter to check the existence of a route for each message the transaction, and with `runTxModeDeliver` to actually process the `sdk.Msg`s. -First, it retrieves the `sdk.Msg`'s fully-qualified type name, by checking the `type_url` of the Protobuf `Any` representing the `sdk.Msg`. Then, using the application's [`msgServiceRouter`](#msg-service-router), it checks for the existence of `Msg` service method related to that `type_url`. At this point, if `mode == runTxModeCheck`, `RunMsgs` returns. Otherwise, if `mode == runTxModeDeliver`, the [`Msg` service](/docs/sdk/v0.47//build/building-modules/msg-services) RPC is executed, before `RunMsgs` returns. +First, it retrieves the `sdk.Msg`'s fully-qualified type name, by checking the `type_url` of the Protobuf `Any` representing the `sdk.Msg`. Then, using the application's [`msgServiceRouter`](#msg-service-router), it checks for the existence of `Msg` service method related to that `type_url`. At this point, if `mode == runTxModeCheck`, `RunMsgs` returns. Otherwise, if `mode == runTxModeDeliver`, the [`Msg` service](/docs/sdk/v0.47/build/building-modules/msg-services) RPC is executed, before `RunMsgs` returns. ### PostHandler @@ -3491,7 +3491,7 @@ The [`InitChain` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x * [`checkState` and `deliverState`](#state-updates) via `setState`. * The [block gas meter](/docs/sdk/v0.47/learn/beginner/gas-fees#block-gas-meter), with infinite gas to process genesis transactions. -Finally, the `InitChain(req abci.RequestInitChain)` method of `BaseApp` calls the [`initChainer()`](/docs/sdk/v0.47/learn/beginner/app-anatomy#initchainer) of the application in order to initialize the main state of the application from the `genesis file` and, if defined, call the [`InitGenesis`](/docs/sdk/v0.47//build/building-modules/genesis#initgenesis) function of each of the application's modules. +Finally, the `InitChain(req abci.RequestInitChain)` method of `BaseApp` calls the [`initChainer()`](/docs/sdk/v0.47/learn/beginner/app-anatomy#initchainer) of the application in order to initialize the main state of the application from the `genesis file` and, if defined, call the [`InitGenesis`](/docs/sdk/v0.47/build/building-modules/genesis#initgenesis) function of each of the application's modules. ### BeginBlock @@ -4681,13 +4681,13 @@ The [`BeginBlock` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37. * Initialize the [block gas meter](/docs/sdk/v0.47/learn/beginner/gas-fees#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()`](/docs/sdk/v0.47/learn/beginner/app-anatomy#beginblocker-and-endblock), which mainly runs the [`BeginBlocker()`](/docs/sdk/v0.47//build/building-modules/beginblock-endblock#beginblock) method of each of the application's modules. +* Run the application's [`beginBlocker()`](/docs/sdk/v0.47/learn/beginner/app-anatomy#beginblocker-and-endblock), which mainly runs the [`BeginBlocker()`](/docs/sdk/v0.47/build/building-modules/beginblock-endblock#beginblock) method of each of the application's modules. * Set the [`VoteInfos`](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_methods.md#voteinfo) of the application, i.e. the list of validators whose *precommit* for the previous block was included by the proposer of the current block. This information is carried into the [`Context`](/docs/sdk/v0.47/learn/advanced/context) so that it can be used during `DeliverTx` and `EndBlock`. ### EndBlock -The [`EndBlock` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_basic_concepts.md#method-overview) is sent from the underlying CometBFT engine after [`DeliverTx`](#delivertx) as been run for each transaction in the block. It allows developers to have logic be executed at the end of each block. In the Cosmos SDK, the bulk `EndBlock(req abci.RequestEndBlock)` method is to run the application's [`EndBlocker()`](/docs/sdk/v0.47/learn/beginner/app-anatomy#beginblocker-and-endblock), which mainly runs the [`EndBlocker()`](/docs/sdk/v0.47//build/building-modules/beginblock-endblock#beginblock) method of each of the application's modules. +The [`EndBlock` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_basic_concepts.md#method-overview) is sent from the underlying CometBFT engine after [`DeliverTx`](#delivertx) as been run for each transaction in the block. It allows developers to have logic be executed at the end of each block. In the Cosmos SDK, the bulk `EndBlock(req abci.RequestEndBlock)` method is to run the application's [`EndBlocker()`](/docs/sdk/v0.47/learn/beginner/app-anatomy#beginblocker-and-endblock), which mainly runs the [`EndBlocker()`](/docs/sdk/v0.47/build/building-modules/beginblock-endblock#beginblock) method of each of the application's modules. ### Commit @@ -4703,7 +4703,7 @@ The [`Info` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x/spec ### Query -The [`Query` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_basic_concepts.md#info-methods) is used to serve queries received from the underlying consensus engine, including queries received via RPC like CometBFT RPC. It used to be the main entrypoint to build interfaces with the application, but with the introduction of [gRPC queries](/docs/sdk/v0.47//build/building-modules/query-services) in Cosmos SDK v0.40, its usage is more limited. The application must respect a few rules when implementing the `Query` method, which are outlined [here](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_app_requirements.md#query). +The [`Query` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_basic_concepts.md#info-methods) is used to serve queries received from the underlying consensus engine, including queries received via RPC like CometBFT RPC. It used to be the main entrypoint to build interfaces with the application, but with the introduction of [gRPC queries](/docs/sdk/v0.47/build/building-modules/query-services) in Cosmos SDK v0.40, its usage is more limited. The application must respect a few rules when implementing the `Query` method, which are outlined [here](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_app_requirements.md#query). Each CometBFT `query` comes with a `path`, which is a `string` which denotes what to query. If the `path` matches a gRPC fully-qualified service method, then `BaseApp` will defer the query to the `grpcQueryRouter` and let it handle it like explained [above](#grpc-query-router). Otherwise, the `path` represents a query that is not (yet) handled by the gRPC router. `BaseApp` splits the `path` string with the `/` delimiter. By convention, the first element of the split string (`split[0]`) contains the category of `query` (`app`, `p2p`, `store` or `custom` ). The `BaseApp` implementation of the `Query(req abci.RequestQuery)` method is a simple dispatcher serving these 4 main categories of queries: diff --git a/docs/sdk/v0.47/learn/advanced/cli.mdx b/docs/sdk/v0.47/learn/advanced/cli.mdx index 341b3647..c8e01fb1 100644 --- a/docs/sdk/v0.47/learn/advanced/cli.mdx +++ b/docs/sdk/v0.47/learn/advanced/cli.mdx @@ -4,7 +4,7 @@ title: Command-Line Interface **Synopsis** -This document describes how command-line interface (CLI) works on a high-level, for an [**application**](/docs/sdk/v0.47/learn/beginner/app-anatomy). A separate document for implementing a CLI for a Cosmos SDK [**module**](/docs/sdk/v0.47//build/building-modules/intro) can be found [here](/docs/sdk/v0.47//build/building-modules/module-interfaces#cli). +This document describes how command-line interface (CLI) works on a high-level, for an [**application**](/docs/sdk/v0.47/learn/beginner/app-anatomy). A separate document for implementing a CLI for a Cosmos SDK [**module**](/docs/sdk/v0.47/build/building-modules/intro) can be found [here](/docs/sdk/v0.47/build/building-modules/module-interfaces#cli). ## Command-Line Interface @@ -23,7 +23,7 @@ The first four strings specify the command: * The root command for the entire application `simd`. * The subcommand `tx`, which contains all commands that let users create transactions. -* The subcommand `bank` to indicate which module to route the command to ([`x/bank`](/docs/sdk/v0.47//build/modules/bank/README) module in this case). +* The subcommand `bank` to indicate which module to route the command to ([`x/bank`](/docs/sdk/v0.47/build/modules/bank/README) module in this case). * The type of transaction `send`. The next two strings are arguments: the `from_address` the user wishes to send from, the `to_address` of the recipient, and the `amount` they want to send. Finally, the last few strings of the command are optional flags to indicate how much the user is willing to pay in fees (calculated using the amount of gas used to execute the transaction and the gas prices provided by the user). @@ -79,7 +79,7 @@ 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`](/docs/sdk/v0.47/learn/advanced/node). The Status of a node includes `NodeInfo`,`SyncInfo` and `ValidatorInfo`. -* **Keys** [commands](https://github.com/cosmos/cosmos-sdk/blob/v0.47.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 ` 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.47.0-rc1/client/keys/add.go). For more details about usage of `--keyring-backend` for storage of key credentials look at the [keyring docs](/docs/sdk/v0.47//user/run-node/keyring). +* **Keys** [commands](https://github.com/cosmos/cosmos-sdk/blob/v0.47.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 ` 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.47.0-rc1/client/keys/add.go). For more details about usage of `--keyring-backend` for storage of key credentials look at the [keyring docs](/docs/sdk/v0.47/user/run-node/keyring). * **Server** commands from the Cosmos SDK server package. These commands are responsible for providing the mechanisms necessary to start an ABCI CometBFT application and provides the CLI framework (based on [cobra](https://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. Learn more [here](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/server). * [**Transaction**](#transaction-commands) commands. @@ -1084,7 +1084,7 @@ The root-level `status` and `keys` subcommands are common across most applicatio ### Transaction Commands -[Transactions](/docs/sdk/v0.47/learn/advanced/transactions) are objects wrapping [`Msg`s](/docs/sdk/v0.47//build/building-modules/messages-and-queries#messages) that trigger state changes. To enable the creation of transactions using the CLI interface, a function `txCommand` is generally added to the `rootCmd`: +[Transactions](/docs/sdk/v0.47/learn/advanced/transactions) are objects wrapping [`Msg`s](/docs/sdk/v0.47/build/building-modules/messages-and-queries#messages) that trigger state changes. To enable the creation of transactions using the CLI interface, a function `txCommand` is generally added to the `rootCmd`: ```go expandable package cmd @@ -1417,9 +1417,9 @@ return simApp.ExportAppStateAndValidators(forZeroHeight, jailAllowedAddrs, modul This `txCommand` function adds all the transaction available to end-users for the application. This typically includes: -* **Sign command** from the [`auth`](/docs/sdk/v0.47//build/modules/auth/README) module that signs messages in a transaction. To enable multisig, add the `auth` module's `MultiSign` command. Since every transaction requires some sort of signature in order to be valid, the signing command is necessary for every application. +* **Sign command** from the [`auth`](/docs/sdk/v0.47/build/modules/auth/README) module that signs messages in a transaction. To enable multisig, add the `auth` module's `MultiSign` command. Since every transaction requires some sort of signature in order to be valid, the signing command is necessary for every application. * **Broadcast command** from the Cosmos SDK client tools, to broadcast transactions. -* **All [module transaction commands](/docs/sdk/v0.47//build/building-modules/module-interfaces#transaction-commands)** the application is dependent on, retrieved by using the [basic module manager's](/docs/sdk/v0.47//build/building-modules/module-manager#basic-manager) `AddTxCommands()` function. +* **All [module transaction commands](/docs/sdk/v0.47/build/building-modules/module-interfaces#transaction-commands)** the application is dependent on, retrieved by using the [basic module manager's](/docs/sdk/v0.47/build/building-modules/module-manager#basic-manager) `AddTxCommands()` function. Here is an example of a `txCommand` aggregating these subcommands from the `simapp` application: @@ -1754,7 +1754,7 @@ return simApp.ExportAppStateAndValidators(forZeroHeight, jailAllowedAddrs, modul ### Query Commands -[**Queries**](/docs/sdk/v0.47//build/building-modules/messages-and-queries#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`: +[**Queries**](/docs/sdk/v0.47/build/building-modules/messages-and-queries#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`: ```go expandable package cmd @@ -2091,7 +2091,7 @@ This `queryCommand` function adds all the queries available to end-users for the * **Account command** from the `auth` module, which displays the state (e.g. account balance) of an account given an address. * **Validator command** from the Cosmos SDK rpc client tools, which displays the validator set of a given height. * **Block command** from the Cosmos SDK RPC client tools, which displays the block data for a given height. -* **All [module query commands](/docs/sdk/v0.47//build/building-modules/module-interfaces#query-commands)** the application is dependent on, retrieved by using the [basic module manager's](/docs/sdk/v0.47//build/building-modules/module-manager#basic-manager) `AddQueryCommands()` function. +* **All [module query commands](/docs/sdk/v0.47/build/building-modules/module-interfaces#query-commands)** the application is dependent on, retrieved by using the [basic module manager's](/docs/sdk/v0.47/build/building-modules/module-manager#basic-manager) `AddQueryCommands()` function. Here is an example of a `queryCommand` aggregating subcommands from the `simapp` application: @@ -2426,11 +2426,11 @@ return simApp.ExportAppStateAndValidators(forZeroHeight, jailAllowedAddrs, modul ## Flags -Flags are used to modify commands; developers can include them in a `flags.go` file with their CLI. Users can explicitly include them in commands or pre-configure them by inside their [`app.toml`](/docs/sdk/v0.47//user/run-node/interact-node#configuring-the-node-using-apptoml). Commonly pre-configured flags include the `--node` to connect to and `--chain-id` of the blockchain the user wishes to interact with. +Flags are used to modify commands; developers can include them in a `flags.go` file with their CLI. Users can explicitly include them in commands or pre-configure them by inside their [`app.toml`](/docs/sdk/v0.47/user/run-node/interact-node#configuring-the-node-using-apptoml). Commonly pre-configured flags include the `--node` to connect to and `--chain-id` of the blockchain the user wishes to interact with. A *persistent* flag (as opposed to a *local* flag) added to a command transcends all of its children: subcommands will inherit the configured values for these flags. Additionally, all flags have default values when they are added to commands; some toggle an option off but others are empty values that the user needs to override to create valid commands. A flag can be explicitly marked as *required* so that an error is automatically thrown if the user does not provide a value, but it is also acceptable to handle unexpected missing flags differently. -Flags are added to commands directly (generally in the [module's CLI file](/docs/sdk/v0.47//build/building-modules/module-interfaces#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. +Flags are added to commands directly (generally in the [module's CLI file](/docs/sdk/v0.47/build/building-modules/module-interfaces#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. ## Environment variables diff --git a/docs/sdk/v0.47/learn/advanced/encoding.mdx b/docs/sdk/v0.47/learn/advanced/encoding.mdx index a139be30..6af0df63 100644 --- a/docs/sdk/v0.47/learn/advanced/encoding.mdx +++ b/docs/sdk/v0.47/learn/advanced/encoding.mdx @@ -259,7 +259,7 @@ return msg, nil } ``` -A standard implementation of both these objects can be found in the [`auth/tx` module](/docs/sdk/v0.47//build/modules/auth/tx): +A standard implementation of both these objects can be found in the [`auth/tx` module](/docs/sdk/v0.47/build/modules/auth/tx): ```go expandable package tx @@ -496,7 +496,7 @@ return nil, fmt.Errorf("expected %T, got %T", &wrapper{ } ``` -See [ADR-020](/docs/sdk/v0.47//build/architecture/adr-020-protobuf-transaction-encoding) for details of how a transaction is encoded. +See [ADR-020](/docs/sdk/v0.47/build/architecture/adr-020-protobuf-transaction-encoding) for details of how a transaction is encoded. ### Interface Encoding and Usage of `Any` @@ -511,7 +511,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](/docs/sdk/v0.47//build/modules/auth/vesting), 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? +In this `Profile` example, we hardcoded `account` as a `BaseAccount`. However, there are several other types of [user accounts related to vesting](/docs/sdk/v0.47/build/modules/auth/vesting), 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? ```go expandable package types @@ -989,7 +989,7 @@ error } ``` -In [ADR-019](/docs/sdk/v0.47//build/architecture/adr-019-protobuf-state-encoding), 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: +In [ADR-019](/docs/sdk/v0.47/build/architecture/adr-019-protobuf-state-encoding), 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: ```protobuf message Profile { @@ -1063,7 +1063,7 @@ return nil The `UnpackInterfaces` gets called recursively on all structs implementing this method, to allow all `Any`s to have their `GetCachedValue()` correctly populated. -For more information about interface encoding, and especially on `UnpackInterfaces` and how the `Any`'s `type_url` gets resolved using the `InterfaceRegistry`, please refer to [ADR-019](/docs/sdk/v0.47//build/architecture/adr-019-protobuf-state-encoding). +For more information about interface encoding, and especially on `UnpackInterfaces` and how the `Any`'s `type_url` gets resolved using the `InterfaceRegistry`, please refer to [ADR-019](/docs/sdk/v0.47/build/architecture/adr-019-protobuf-state-encoding). #### `Any` Encoding in the Cosmos SDK @@ -1855,14 +1855,14 @@ import ( Protobuf types can be defined to encode: * state -* [`Msg`s](/docs/sdk/v0.47//build/building-modules/messages-and-queries#messages) -* [Query services](/docs/sdk/v0.47//build/building-modules/query-services) -* [genesis](/docs/sdk/v0.47//build/building-modules/genesis) +* [`Msg`s](/docs/sdk/v0.47/build/building-modules/messages-and-queries#messages) +* [Query services](/docs/sdk/v0.47/build/building-modules/query-services) +* [genesis](/docs/sdk/v0.47/build/building-modules/genesis) #### Naming and conventions We encourage developers to follow industry guidelines: [Protocol Buffers style guide](https://developers.google.com/protocol-buffers/docs/style) -and [Buf](https://buf.build/docs/style-guide), see more details in [ADR 023](/docs/sdk/v0.47//build/architecture/adr-023-protobuf-naming) +and [Buf](https://buf.build/docs/style-guide), see more details in [ADR 023](/docs/sdk/v0.47/build/architecture/adr-023-protobuf-naming) ### How to update modules to protobuf encoding diff --git a/docs/sdk/v0.47/learn/advanced/events.mdx b/docs/sdk/v0.47/learn/advanced/events.mdx index 7529e380..7e198215 100644 --- a/docs/sdk/v0.47/learn/advanced/events.mdx +++ b/docs/sdk/v0.47/learn/advanced/events.mdx @@ -35,10 +35,10 @@ An Event contains: To parse the attribute values as strings, make sure to add `'` (single quotes) around each attribute value. -*Typed Events* are Protobuf-defined [messages](/docs/sdk/v0.47//build/architecture/adr-032-typed-events) used by the Cosmos SDK +*Typed Events* are Protobuf-defined [messages](/docs/sdk/v0.47/build/architecture/adr-032-typed-events) used by the Cosmos SDK for emitting and querying Events. They are defined in a `event.proto` file, on a **per-module basis** and are read as `proto.Message`. *Legacy Events* are defined on a **per-module basis** in the module's `/types/events.go` file. -They are triggered from the module's Protobuf [`Msg` service](/docs/sdk/v0.47//build/building-modules/msg-services) +They are triggered from the module's Protobuf [`Msg` service](/docs/sdk/v0.47/build/building-modules/msg-services) by using the [`EventManager`](#eventmanager). In addition, each module documents its events under in the `Events` sections of its specs (x/`{moduleName}`/`README.md`). @@ -57,9 +57,9 @@ The following examples show how to query Events using the Cosmos SDK. | Event | Description | | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | `tx.height=23` | Query all transactions at height 23 | -| `message.action='/cosmos.bank.v1beta1.Msg/Send'` | Query all transactions containing a x/bank `Send` [Service `Msg`](/docs/sdk/v0.47//build/building-modules/msg-services). Note the `'`s around the value. | +| `message.action='/cosmos.bank.v1beta1.Msg/Send'` | Query all transactions containing a x/bank `Send` [Service `Msg`](/docs/sdk/v0.47/build/building-modules/msg-services). Note the `'`s around the value. | | `message.module='bank'` | Query all transactions containing messages from the x/bank module. Note the `'`s around the value. | -| `create_validator.validator='cosmosval1...'` | x/staking-specific Event, see [x/staking SPEC](/docs/sdk/v0.47//build/modules/staking/README). | +| `create_validator.validator='cosmosval1...'` | x/staking-specific Event, see [x/staking SPEC](/docs/sdk/v0.47/build/modules/staking/README). | ## EventManager @@ -2163,7 +2163,7 @@ sdk.Handler { switch msg := msg.(type) { ``` -See the [`Msg` services](/docs/sdk/v0.47//build/building-modules/msg-services) concept doc for a more detailed +See the [`Msg` services](/docs/sdk/v0.47/build/building-modules/msg-services) concept doc for a more detailed view on how to typically implement Events and use the `EventManager` in modules. ## Subscribing to Events diff --git a/docs/sdk/v0.47/learn/advanced/grpc_rest.mdx b/docs/sdk/v0.47/learn/advanced/grpc_rest.mdx index 8bacff8d..4af493fd 100644 --- a/docs/sdk/v0.47/learn/advanced/grpc_rest.mdx +++ b/docs/sdk/v0.47/learn/advanced/grpc_rest.mdx @@ -23,7 +23,7 @@ The node also exposes some other endpoints, such as the CometBFT P2P endpoint, o In the Cosmos SDK, Protobuf is the main [encoding](/docs/sdk/v0.47/learn/advanced/encoding) library. This brings a wide range of Protobuf-based tools that can be plugged into the Cosmos SDK. One such tool is [gRPC](https://grpc.io), a modern open-source high performance RPC framework that has decent client support in several languages. -Each module exposes a [Protobuf `Query` service](/docs/sdk/v0.47//build/building-modules/messages-and-queries#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: +Each module exposes a [Protobuf `Query` service](/docs/sdk/v0.47/build/building-modules/messages-and-queries#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: ```go expandable package types @@ -122,7 +122,7 @@ Application ) ``` -Note: It is not possible to expose any [Protobuf `Msg` service](/docs/sdk/v0.47//build/building-modules/messages-and-queries#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](/docs/sdk/v0.47//user/run-node/txs) for more information. +Note: It is not possible to expose any [Protobuf `Msg` service](/docs/sdk/v0.47/build/building-modules/messages-and-queries#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](/docs/sdk/v0.47/user/run-node/txs) for more information. The `grpc.Server` is a concrete gRPC server, which spawns and serves all gRPC query requests and a broadcast transaction request. This server can be configured inside `~/.simapp/config/app.toml`: @@ -133,7 +133,7 @@ The `grpc.Server` is a concrete gRPC server, which spawns and serves all gRPC qu `~/.simapp` is the directory where the node's configuration and databases are stored. By default, it's set to `~/.{app_name}`. -Once the gRPC server is started, you can send requests to it using a gRPC client. Some examples are given in our [Interact with the Node](/docs/sdk/v0.47//user/run-node/interact-node#using-grpc) tutorial. +Once the gRPC server is started, you can send requests to it using a gRPC client. Some examples are given in our [Interact with the Node](/docs/sdk/v0.47/user/run-node/interact-node#using-grpc) tutorial. An overview of all available gRPC endpoints shipped with the Cosmos SDK is [Protobuf documentation](https://buf.build/cosmos/cosmos-sdk). diff --git a/docs/sdk/v0.47/learn/advanced/node.mdx b/docs/sdk/v0.47/learn/advanced/node.mdx index e6db7e41..152086a0 100644 --- a/docs/sdk/v0.47/learn/advanced/node.mdx +++ b/docs/sdk/v0.47/learn/advanced/node.mdx @@ -2868,4 +2868,4 @@ Upon starting, the node will bootstrap its RPC and P2P server and start dialing ## Other commands -To discover how to concretely run a node and interact with it, please refer to our [Running a Node, API and CLI](/docs/sdk/v0.47//user/run-node/run-node) guide. +To discover how to concretely run a node and interact with it, please refer to our [Running a Node, API and CLI](/docs/sdk/v0.47/user/run-node/run-node) guide. diff --git a/docs/sdk/v0.47/learn/advanced/runtx_middleware.mdx b/docs/sdk/v0.47/learn/advanced/runtx_middleware.mdx index 3dfeda44..c8bc463b 100644 --- a/docs/sdk/v0.47/learn/advanced/runtx_middleware.mdx +++ b/docs/sdk/v0.47/learn/advanced/runtx_middleware.mdx @@ -6,7 +6,7 @@ title: RunTx recovery middleware 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](/docs/sdk/v0.47//build/architecture/adr-022-custom-panic-handling) and the implementation in [recovery.go](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/baseapp/recovery.go). +More context can found in the corresponding [ADR-022](/docs/sdk/v0.47/build/architecture/adr-022-custom-panic-handling) and the implementation in [recovery.go](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/baseapp/recovery.go). ## Interface diff --git a/docs/sdk/v0.47/learn/advanced/simulation.mdx b/docs/sdk/v0.47/learn/advanced/simulation.mdx index f680c3e9..f5a569b8 100644 --- a/docs/sdk/v0.47/learn/advanced/simulation.mdx +++ b/docs/sdk/v0.47/learn/advanced/simulation.mdx @@ -98,5 +98,5 @@ Here are some suggestions when encountering a simulation failure: Learn how you can integrate the simulation into your Cosmos SDK-based application: * Application Simulation Manager -* [Building modules: Simulator](/docs/sdk/v0.47//build/building-modules/simulator) +* [Building modules: Simulator](/docs/sdk/v0.47/build/building-modules/simulator) * Simulator tests diff --git a/docs/sdk/v0.47/learn/advanced/transactions.mdx b/docs/sdk/v0.47/learn/advanced/transactions.mdx index d96eee39..2bcd08e7 100644 --- a/docs/sdk/v0.47/learn/advanced/transactions.mdx +++ b/docs/sdk/v0.47/learn/advanced/transactions.mdx @@ -17,7 +17,7 @@ title: Transactions ## Transactions -Transactions are comprised of metadata held in [contexts](/docs/sdk/v0.47/learn/advanced/context) and [`sdk.Msg`s](/docs/sdk/v0.47//build/building-modules/messages-and-queries) that trigger state changes within a module through the module's Protobuf [`Msg` service](/docs/sdk/v0.47//build/building-modules/msg-services). +Transactions are comprised of metadata held in [contexts](/docs/sdk/v0.47/learn/advanced/context) and [`sdk.Msg`s](/docs/sdk/v0.47/build/building-modules/messages-and-queries) that trigger state changes within a module through the module's Protobuf [`Msg` service](/docs/sdk/v0.47/build/building-modules/msg-services). When users want to interact with an application and make state changes (e.g. sending coins), they create transactions. Each of a transaction's `sdk.Msg` must be signed using the private key associated with the appropriate account(s), before the transaction is broadcasted to the network. A transaction must then be included in a block, validated, and approved by the network through the consensus process. To read more about the lifecycle of a transaction, click [here](/docs/sdk/v0.47/learn/beginner/tx-lifecycle). @@ -178,7 +178,7 @@ The most used implementation of the `Tx` interface is the Protobuf `Tx` message, // Reference: https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/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](/docs/sdk/v0.47//build/architecture/adr-027-deterministic-protobuf-serialization)): +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](/docs/sdk/v0.47/build/architecture/adr-027-deterministic-protobuf-serialization)): ```protobuf // Reference: https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L48-L65 @@ -799,12 +799,12 @@ The next paragraphs will describe each of these components, in this order. Module `sdk.Msg`s are not to be confused with [ABCI Messages](https://docs.cometbft.com/v0.37/spec/abci/) which define interactions between the CometBFT and application layers. -**Messages** (or `sdk.Msg`s) are module-specific objects that trigger state transitions within the scope of the module they belong to. Module developers define the messages for their module by adding methods to the Protobuf [`Msg` service](/docs/sdk/v0.47//build/building-modules/msg-services), and also implement the corresponding `MsgServer`. +**Messages** (or `sdk.Msg`s) are module-specific objects that trigger state transitions within the scope of the module they belong to. Module developers define the messages for their module by adding methods to the Protobuf [`Msg` service](/docs/sdk/v0.47/build/building-modules/msg-services), and also implement the corresponding `MsgServer`. -Each `sdk.Msg`s is related to exactly one Protobuf [`Msg` service](/docs/sdk/v0.47//build/building-modules/msg-services) RPC, defined inside each module's `tx.proto` file. A SDK app router automatically maps every `sdk.Msg` to a corresponding RPC. Protobuf generates a `MsgServer` interface for each module `Msg` service, and the module developer needs to implement this interface. +Each `sdk.Msg`s is related to exactly one Protobuf [`Msg` service](/docs/sdk/v0.47/build/building-modules/msg-services) RPC, defined inside each module's `tx.proto` file. A SDK app router automatically maps every `sdk.Msg` to a corresponding RPC. Protobuf generates a `MsgServer` interface for each module `Msg` service, and the module developer needs to implement this interface. This design puts more responsibility on module developers, allowing application developers to reuse common functionalities without having to implement state transition logic repetitively. -To learn more about Protobuf `Msg` services and how to implement `MsgServer`, click [here](/docs/sdk/v0.47//build/building-modules/msg-services). +To learn more about Protobuf `Msg` services and how to implement `MsgServer`, click [here](/docs/sdk/v0.47/build/building-modules/msg-services). While messages contain the information for state transition logic, a transaction's other metadata and relevant information are stored in the `TxBuilder` and `Context`. @@ -1015,7 +1015,7 @@ Once the transaction bytes are generated, there are currently three ways of broa Application developers create entry points to the application by creating a [command-line interface](/docs/sdk/v0.47/learn/advanced/cli), [gRPC and/or REST interface](/docs/sdk/v0.47/learn/advanced/grpc_rest), typically found in the application's `./cmd` folder. These interfaces allow users to interact with the application through command-line. -For the [command-line interface](/docs/sdk/v0.47//build/building-modules/module-interfaces#cli), module developers create subcommands to add as children to the application top-level transaction command `TxCmd`. CLI commands actually bundle all the steps of transaction processing into one simple command: creating messages, generating transactions and broadcasting. For concrete examples, see the [Interacting with a Node](/docs/sdk/v0.47//user/run-node/interact-node) section. An example transaction made using CLI looks like: +For the [command-line interface](/docs/sdk/v0.47/build/building-modules/module-interfaces#cli), module developers create subcommands to add as children to the application top-level transaction command `TxCmd`. CLI commands actually bundle all the steps of transaction processing into one simple command: creating messages, generating transactions and broadcasting. For concrete examples, see the [Interacting with a Node](/docs/sdk/v0.47/user/run-node/interact-node) section. An example transaction made using CLI looks like: ```bash simd tx send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000stake @@ -1023,7 +1023,7 @@ simd tx send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000stake #### gRPC -[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](/docs/sdk/v0.47//build/building-modules/query-services). However, the Cosmos SDK also exposes a few other module-agnostic gRPC services, one of them being the `Tx` service: +[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](/docs/sdk/v0.47/build/building-modules/query-services). However, the Cosmos SDK also exposes a few other module-agnostic gRPC services, one of them being the `Tx` service: ```go expandable syntax = "proto3"; @@ -1329,13 +1329,13 @@ message TxDecodeAminoResponse { 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. -Examples of broadcasting and simulating a transaction are shown [here](/docs/sdk/v0.47//user/run-node/txs#programmatically-with-go). +Examples of broadcasting and simulating a transaction are shown [here](/docs/sdk/v0.47/user/run-node/txs#programmatically-with-go). #### REST Each gRPC method has its corresponding REST endpoint, generated using [gRPC-gateway](https://github.com/grpc-ecosystem/grpc-gateway). Therefore, instead of using gRPC, you can also use HTTP to broadcast the same transaction, on the `POST /cosmos/tx/v1beta1/txs` endpoint. -An example can be seen [here](/docs/sdk/v0.47//user/run-node/txs#using-rest) +An example can be seen [here](/docs/sdk/v0.47/user/run-node/txs#using-rest) #### CometBFT RPC diff --git a/docs/sdk/v0.47/learn/advanced/upgrade.mdx b/docs/sdk/v0.47/learn/advanced/upgrade.mdx index 4102a25c..0798147f 100644 --- a/docs/sdk/v0.47/learn/advanced/upgrade.mdx +++ b/docs/sdk/v0.47/learn/advanced/upgrade.mdx @@ -15,7 +15,7 @@ The Cosmos SDK uses two methods to perform upgrades: * Exporting the entire application state to a JSON file using the `export` CLI command, making changes, and then starting a new binary with the changed JSON file as the genesis file. -* Perform upgrades in place, which significantly decrease the upgrade time for chains with a larger state. Use the [Module Upgrade Guide](/docs/sdk/v0.47//build/building-modules/upgrade) to set up your application modules to take advantage of in-place upgrades. +* Perform upgrades in place, which significantly decrease the upgrade time for chains with a larger state. Use the [Module Upgrade Guide](/docs/sdk/v0.47/build/building-modules/upgrade) to set up your application modules to take advantage of in-place upgrades. This document provides steps to use the In-Place Store Migrations upgrade method. @@ -63,7 +63,7 @@ app.UpgradeKeeper.SetUpgradeHandler("my-plan", func(ctx sdk.Context, plan upgrad }) ``` -To learn more about configuring migration scripts for your modules, see the [Module Upgrade Guide](/docs/sdk/v0.47//build/building-modules/upgrade). +To learn more about configuring migration scripts for your modules, see the [Module Upgrade Guide](/docs/sdk/v0.47/build/building-modules/upgrade). ### Order Of Migrations @@ -161,4 +161,4 @@ You can sync a full node to an existing blockchain which has been upgraded using To successfully sync, you must start with the initial binary that the blockchain started with at genesis. If all Software Upgrade Plans contain binary instruction, then you can run Cosmovisor with auto-download option to automatically handle downloading and switching to the binaries associated with each sequential upgrade. Otherwise, you need to manually provide all binaries to Cosmovisor. -To learn more about Cosmovisor, see the [Cosmovisor Quick Start](/docs/sdk/v0.47//build/tooling/cosmovisor). +To learn more about Cosmovisor, see the [Cosmovisor Quick Start](/docs/sdk/v0.47/build/tooling/cosmovisor). diff --git a/docs/sdk/v0.47/learn/beginner/accounts.mdx b/docs/sdk/v0.47/learn/beginner/accounts.mdx index bc657e20..f9205fad 100644 --- a/docs/sdk/v0.47/learn/beginner/accounts.mdx +++ b/docs/sdk/v0.47/learn/beginner/accounts.mdx @@ -17,7 +17,7 @@ This document describes the in-built account and public key system of the Cosmos ## Account Definition -In the Cosmos SDK, an *account* designates a pair of *public key* `PubKey` and *private key* `PrivKey`. The `PubKey` can be derived to generate various `Addresses`, which are used to identify users (among other parties) in the application. `Addresses` are also associated with [`message`s](/docs/sdk/v0.47//build/building-modules/messages-and-queries#messages) to identify the sender of the `message`. The `PrivKey` is used to generate [digital signatures](#keys-accounts-addresses-and-signatures) to prove that an `Address` associated with the `PrivKey` approved of a given `message`. +In the Cosmos SDK, an *account* designates a pair of *public key* `PubKey` and *private key* `PrivKey`. The `PubKey` can be derived to generate various `Addresses`, which are used to identify users (among other parties) in the application. `Addresses` are also associated with [`message`s](/docs/sdk/v0.47/build/building-modules/messages-and-queries#messages) to identify the sender of the `message`. The `PrivKey` is used to generate [digital signatures](#keys-accounts-addresses-and-signatures) to prove that an `Address` associated with the `PrivKey` approved of a given `message`. For HD key derivation the Cosmos SDK uses a standard called [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki). The BIP32 allows users to create an HD wallet (as specified in [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)) - a set of accounts derived from an initial secret seed. A seed is usually created from a 12- or 24-word mnemonic. A single seed can derive any number of `PrivKey`s using a one-way cryptographic function. Then, a `PubKey` can be derived from the `PrivKey`. Naturally, the mnemonic is the most sensitive information, as private keys can always be re-generated if the mnemonic is preserved. @@ -3121,7 +3121,7 @@ The default implementation of `Keyring` comes from the third-party [`99designs/k 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](/docs/sdk/v0.47//build/architecture/adr-020-protobuf-transaction-encoding) that the canonical `payload` to sign is the `SignDoc` struct, deterministically encoded using [ADR-027](/docs/sdk/v0.47//build/architecture/adr-027-deterministic-protobuf-serialization). Note that signature verification is not implemented in the Cosmos SDK by default, it is deferred to the [`anteHandler`](/docs/sdk/v0.47/learn/advanced/baseapp#antehandler). +* `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](/docs/sdk/v0.47/build/architecture/adr-020-protobuf-transaction-encoding) that the canonical `payload` to sign is the `SignDoc` struct, deterministically encoded using [ADR-027](/docs/sdk/v0.47/build/architecture/adr-027-deterministic-protobuf-serialization). Note that signature verification is not implemented in the Cosmos SDK by default, it is deferred to the [`anteHandler`](/docs/sdk/v0.47/learn/advanced/baseapp#antehandler). ```protobuf // Reference: https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L48-L65 diff --git a/docs/sdk/v0.47/learn/beginner/gas-fees.mdx b/docs/sdk/v0.47/learn/beginner/gas-fees.mdx index 740e10c3..feaf98d0 100644 --- a/docs/sdk/v0.47/learn/beginner/gas-fees.mdx +++ b/docs/sdk/v0.47/learn/beginner/gas-fees.mdx @@ -20,7 +20,7 @@ This document describes the default strategies to handle gas and fees within a C In the Cosmos SDK, `gas` is a special unit that is used to track the consumption of resources during execution. `gas` is typically consumed whenever read and writes are made to the store, but it can also be consumed if expensive computation needs to be done. It serves two main purposes: * Make sure blocks are not consuming too many resources and are finalized. This is implemented by default in the Cosmos SDK via the [block gas meter](#block-gas-meter). -* Prevent spam and abuse from end-user. To this end, `gas` consumed during [`message`](/docs/sdk/v0.47//build/building-modules/messages-and-queries#messages) execution is typically priced, resulting in a `fee` (`fees = gas * gas-prices`). `fees` generally have to be paid by the sender of the `message`. Note that the Cosmos SDK does not enforce `gas` pricing by default, as there may be other ways to prevent spam (e.g. bandwidth schemes). Still, most applications implement `fee` mechanisms to prevent spam by using the [`AnteHandler`](#antehandler). +* Prevent spam and abuse from end-user. To this end, `gas` consumed during [`message`](/docs/sdk/v0.47/build/building-modules/messages-and-queries#messages) execution is typically priced, resulting in a `fee` (`fees = gas * gas-prices`). `fees` generally have to be paid by the sender of the `message`. Note that the Cosmos SDK does not enforce `gas` pricing by default, as there may be other ways to prevent spam (e.g. bandwidth schemes). Still, most applications implement `fee` mechanisms to prevent spam by using the [`AnteHandler`](#antehandler). ## Gas Meter @@ -406,7 +406,7 @@ By default, the Cosmos SDK makes use of two different gas meters, the [main gas `ctx.GasMeter()` is the main gas meter of the application. The main gas meter is initialized in `BeginBlock` via `setDeliverState`, and then tracks gas consumption during execution sequences that lead to state-transitions, i.e. those originally triggered by [`BeginBlock`](/docs/sdk/v0.47/learn/advanced/baseapp#beginblock), [`DeliverTx`](/docs/sdk/v0.47/learn/advanced/baseapp#delivertx) and [`EndBlock`](/docs/sdk/v0.47/learn/advanced/baseapp#endblock). At the beginning of each `DeliverTx`, the main gas meter **must be set to 0** in the [`AnteHandler`](#antehandler), so that it can track gas consumption per-transaction. -Gas consumption can be done manually, generally by the module developer in the [`BeginBlocker`, `EndBlocker`](/docs/sdk/v0.47//build/building-modules/beginblock-endblock) or [`Msg` service](/docs/sdk/v0.47//build/building-modules/msg-services), but most of the time it is done automatically whenever there is a read or write to the store. This automatic gas consumption logic is implemented in a special store called [`GasKv`](/docs/sdk/v0.47/learn/advanced/store#gaskv-store). +Gas consumption can be done manually, generally by the module developer in the [`BeginBlocker`, `EndBlocker`](/docs/sdk/v0.47/build/building-modules/beginblock-endblock) or [`Msg` service](/docs/sdk/v0.47/build/building-modules/msg-services), but most of the time it is done automatically whenever there is a read or write to the store. This automatic gas consumption logic is implemented in a special store called [`GasKv`](/docs/sdk/v0.47/learn/advanced/store#gaskv-store). ### Block Gas Meter @@ -858,7 +858,7 @@ This enables developers to play with various types for the transaction of their // Reference: https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L13-L26 ``` -* Verify signatures for each [`message`](/docs/sdk/v0.47//build/building-modules/messages-and-queries#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`. +* Verify signatures for each [`message`](/docs/sdk/v0.47/build/building-modules/messages-and-queries#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. * Set `newCtx.GasMeter` to 0, with a limit of `GasWanted`. **This step is crucial**, as it not only makes sure the transaction cannot consume infinite gas, but also that `ctx.GasMeter` is reset in-between each `DeliverTx` (`ctx` is set to `newCtx` after `anteHandler` is run, and the `anteHandler` is run each time `DeliverTx` is called). diff --git a/docs/sdk/v0.47/learn/beginner/overview-app.mdx b/docs/sdk/v0.47/learn/beginner/overview-app.mdx index 46324b81..5680b3d1 100644 --- a/docs/sdk/v0.47/learn/beginner/overview-app.mdx +++ b/docs/sdk/v0.47/learn/beginner/overview-app.mdx @@ -51,10 +51,10 @@ The first thing defined in `app.go` is the `type` of the application. It is gene * **A reference to [`baseapp`](/docs/sdk/v0.47/learn/advanced/baseapp).** The custom application defined in `app.go` is an extension of `baseapp`. When a transaction is relayed by CometBFT to the application, `app` uses `baseapp`'s methods to route them to the appropriate module. `baseapp` implements most of the core logic for the application, including all the [ABCI methods](https://docs.cometbft.com/v0.37/spec/abci/) and the [routing logic](/docs/sdk/v0.47/learn/advanced/baseapp#routing). * **A list of store keys**. The [store](/docs/sdk/v0.47/learn/advanced/store), which contains the entire state, is implemented as a [`multistore`](/docs/sdk/v0.47/learn/advanced/store#multistore) (i.e. a store of stores) in the Cosmos SDK. Each module uses one or multiple stores in the multistore to persist their part of the state. These stores can be accessed with specific keys that are declared in the `app` type. These keys, along with the `keepers`, are at the heart of the [object-capabilities model](/docs/sdk/v0.47/learn/advanced/ocap) of the Cosmos SDK. -* **A list of module's `keeper`s.** Each module defines an abstraction called [`keeper`](/docs/sdk/v0.47//build/building-modules/keeper), which handles reads and writes for this module's store(s). The `keeper`'s methods of one module can be called from other modules (if authorized), which is why they are declared in the application's type and exported as interfaces to other modules so that the latter can only access the authorized functions. +* **A list of module's `keeper`s.** Each module defines an abstraction called [`keeper`](/docs/sdk/v0.47/build/building-modules/keeper), which handles reads and writes for this module's store(s). The `keeper`'s methods of one module can be called from other modules (if authorized), which is why they are declared in the application's type and exported as interfaces to other modules so that the latter can only access the authorized functions. * **A reference to an [`appCodec`](/docs/sdk/v0.47/learn/advanced/encoding).** The application's `appCodec` is used to serialize and deserialize data structures in order to store them, as stores can only persist `[]bytes`. The default codec is [Protocol Buffers](/docs/sdk/v0.47/learn/advanced/encoding). * **A reference to a [`legacyAmino`](/docs/sdk/v0.47/learn/advanced/encoding) codec.** Some parts of the Cosmos SDK have not been migrated to use the `appCodec` above, and are still hardcoded to use Amino. Other parts explicitly use Amino for backwards compatibility. For these reasons, the application still holds a reference to the legacy Amino codec. Please note that the Amino codec will be removed from the SDK in the upcoming releases. -* **A reference to a [module manager](/docs/sdk/v0.47//build/building-modules/module-manager#manager)** and a [basic module manager](/docs/sdk/v0.47//build/building-modules/module-manager#basicmanager). The module manager is an object that contains a list of the application's modules. It facilitates operations related to these modules, like registering their [`Msg` service](/docs/sdk/v0.47/learn/advanced/baseapp#msg-services) and [gRPC `Query` service](/docs/sdk/v0.47/learn/advanced/baseapp#grpc-query-services), or setting the order of execution between modules for various functions like [`InitChainer`](#initchainer), [`BeginBlocker` and `EndBlocker`](#beginblocker-and-endblocker). +* **A reference to a [module manager](/docs/sdk/v0.47/build/building-modules/module-manager#manager)** and a [basic module manager](/docs/sdk/v0.47/build/building-modules/module-manager#basicmanager). The module manager is an object that contains a list of the application's modules. It facilitates operations related to these modules, like registering their [`Msg` service](/docs/sdk/v0.47/learn/advanced/baseapp#msg-services) and [gRPC `Query` service](/docs/sdk/v0.47/learn/advanced/baseapp#grpc-query-services), or setting the order of execution between modules for various functions like [`InitChainer`](#initchainer), [`BeginBlocker` and `EndBlocker`](#beginblocker-and-endblocker). See an example of application type definition from `simapp`, the Cosmos SDK's own app used for demo and testing purposes: @@ -1040,12 +1040,12 @@ Application Here are the main actions performed by this function: -* Instantiate a new [`codec`](/docs/sdk/v0.47/learn/advanced/encoding) and initialize the `codec` of each of the application's modules using the [basic manager](/docs/sdk/v0.47//build/building-modules/module-manager#basicmanager). +* Instantiate a new [`codec`](/docs/sdk/v0.47/learn/advanced/encoding) and initialize the `codec` of each of the application's modules using the [basic manager](/docs/sdk/v0.47/build/building-modules/module-manager#basicmanager). * Instantiate a new application with a reference to a `baseapp` instance, a codec, and all the appropriate store keys. * Instantiate all the [`keeper`](#keeper) objects defined in the application's `type` using the `NewKeeper` function of each of the application's modules. Note that keepers must be instantiated in the correct order, as the `NewKeeper` of one module might require a reference to another module's `keeper`. -* Instantiate the application's [module manager](/docs/sdk/v0.47//build/building-modules/module-manager#manager) with the [`AppModule`](#application-module-interface) object of each of the application's modules. +* Instantiate the application's [module manager](/docs/sdk/v0.47/build/building-modules/module-manager#manager) with the [`AppModule`](#application-module-interface) object of each of the application's modules. * With the module manager, initialize the application's [`Msg` services](/docs/sdk/v0.47/learn/advanced/baseapp#msg-services), [gRPC `Query` services](/docs/sdk/v0.47/learn/advanced/baseapp#grpc-query-services), [legacy `Msg` routes](/docs/sdk/v0.47/learn/advanced/baseapp#routing), and [legacy query routes](/docs/sdk/v0.47/learn/advanced/baseapp#query-routing). When a transaction is relayed to the application by CometBFT via the ABCI, it is routed to the appropriate module's [`Msg` service](#msg-services) using the routes defined here. Likewise, when a gRPC query request is received by the application, it is routed to the appropriate module's [`gRPC query service`](#grpc-query-services) using the gRPC routes defined here. The Cosmos SDK still supports legacy `Msg`s and legacy CometBFT queries, which are routed using the legacy `Msg` routes and the legacy query routes, respectively. -* With the module manager, register the [application's modules' invariants](/docs/sdk/v0.47//build/building-modules/invariants). Invariants are variables (e.g. total supply of a token) that are evaluated at the end of each block. The process of checking invariants is done via a special module called the [`InvariantsRegistry`](/docs/sdk/v0.47//build/building-modules/invariants#invariant-registry). The value of the invariant should be equal to a predicted value defined in the module. Should the value be different than the predicted one, special logic defined in the invariant registry is triggered (usually the chain is halted). This is useful to make sure that no critical bug goes unnoticed, producing long-lasting effects that are hard to fix. +* With the module manager, register the [application's modules' invariants](/docs/sdk/v0.47/build/building-modules/invariants). Invariants are variables (e.g. total supply of a token) that are evaluated at the end of each block. The process of checking invariants is done via a special module called the [`InvariantsRegistry`](/docs/sdk/v0.47/build/building-modules/invariants#invariant-registry). The value of the invariant should be equal to a predicted value defined in the module. Should the value be different than the predicted one, special logic defined in the invariant registry is triggered (usually the chain is halted). This is useful to make sure that no critical bug goes unnoticed, producing long-lasting effects that are hard to fix. * With the module manager, set the order of execution between the `InitGenesis`, `BeginBlocker`, and `EndBlocker` functions of each of the [application's modules](#application-module-interface). Note that not all modules implement these functions. * Set the remaining application parameters: * [`InitChainer`](#initchainer): used to initialize the application when it is first started. @@ -1941,7 +1941,7 @@ return encodingConfig The `InitChainer` is a function that initializes the state of the application from a genesis file (i.e. token balances of genesis accounts). It is called when the application receives the `InitChain` message from the CometBFT engine, which happens when the node is started at `appBlockHeight == 0` (i.e. on genesis). The application must set the `InitChainer` in its [constructor](#constructor-function) via the [`SetInitChainer`](https://pkg.go.dev/github.com/cosmos/cosmos-sdk/baseapp#BaseApp.SetInitChainer) method. -In general, the `InitChainer` is mostly composed of the [`InitGenesis`](/docs/sdk/v0.47//build/building-modules/genesis#initgenesis) function of each of the application's modules. This is done by calling the `InitGenesis` function of the module manager, which in turn calls the `InitGenesis` function of each of the modules it contains. Note that the order in which the modules' `InitGenesis` functions must be called has to be set in the module manager using the [module manager's](/docs/sdk/v0.47//build/building-modules/module-manager) `SetOrderInitGenesis` method. This is done in the [application's constructor](#constructor-function), and the `SetOrderInitGenesis` has to be called before the `SetInitChainer`. +In general, the `InitChainer` is mostly composed of the [`InitGenesis`](/docs/sdk/v0.47/build/building-modules/genesis#initgenesis) function of each of the application's modules. This is done by calling the `InitGenesis` function of the module manager, which in turn calls the `InitGenesis` function of each of the modules it contains. Note that the order in which the modules' `InitGenesis` functions must be called has to be set in the module manager using the [module manager's](/docs/sdk/v0.47/build/building-modules/module-manager) `SetOrderInitGenesis` method. This is done in the [application's constructor](#constructor-function), and the `SetOrderInitGenesis` has to be called before the `SetInitChainer`. See an example of an `InitChainer` from `simapp`: @@ -2828,7 +2828,7 @@ return encodingConfig The Cosmos SDK offers developers the possibility to implement automatic execution of code as part of their application. This is implemented through two functions called `BeginBlocker` and `EndBlocker`. They are called when the application receives the `BeginBlock` and `EndBlock` messages from the CometBFT engine, which happens respectively at the beginning and at the end of each block. The application must set the `BeginBlocker` and `EndBlocker` in its [constructor](#constructor-function) via the [`SetBeginBlocker`](https://pkg.go.dev/github.com/cosmos/cosmos-sdk/baseapp#BaseApp.SetBeginBlocker) and [`SetEndBlocker`](https://pkg.go.dev/github.com/cosmos/cosmos-sdk/baseapp#BaseApp.SetEndBlocker) methods. -In general, the `BeginBlocker` and `EndBlocker` functions are mostly composed of the [`BeginBlock` and `EndBlock`](/docs/sdk/v0.47//build/building-modules/beginblock-endblock) functions of each of the application's modules. This is done by calling the `BeginBlock` and `EndBlock` functions of the module manager, which in turn calls the `BeginBlock` and `EndBlock` functions of each of the modules it contains. Note that the order in which the modules' `BeginBlock` and `EndBlock` functions must be called has to be set in the module manager using the `SetOrderBeginBlockers` and `SetOrderEndBlockers` methods, respectively. This is done via the [module manager](/docs/sdk/v0.47//build/building-modules/module-manager) in the [application's constructor](#constructor-function), and the `SetOrderBeginBlockers` and `SetOrderEndBlockers` methods have to be called before the `SetBeginBlocker` and `SetEndBlocker` functions. +In general, the `BeginBlocker` and `EndBlocker` functions are mostly composed of the [`BeginBlock` and `EndBlock`](/docs/sdk/v0.47/build/building-modules/beginblock-endblock) functions of each of the application's modules. This is done by calling the `BeginBlock` and `EndBlock` functions of the module manager, which in turn calls the `BeginBlock` and `EndBlock` functions of each of the modules it contains. Note that the order in which the modules' `BeginBlock` and `EndBlock` functions must be called has to be set in the module manager using the `SetOrderBeginBlockers` and `SetOrderEndBlockers` methods, respectively. This is done via the [module manager](/docs/sdk/v0.47/build/building-modules/module-manager) in the [application's constructor](#constructor-function), and the `SetOrderBeginBlockers` and `SetOrderEndBlockers` methods have to be called before the `SetBeginBlocker` and `SetEndBlocker` functions. As a sidenote, it is important to remember that application-specific blockchains are deterministic. Developers must be careful not to introduce non-determinism in `BeginBlocker` or `EndBlocker`, and must also be careful not to make them too computationally expensive, as [gas](/docs/sdk/v0.47/learn/beginner/gas-fees) does not constrain the cost of `BeginBlocker` and `EndBlocker` execution. @@ -3740,8 +3740,8 @@ type EncodingConfig struct { Here are descriptions of what each of the four fields means: * `InterfaceRegistry`: The `InterfaceRegistry` is used by the Protobuf codec to handle interfaces that are encoded and decoded (we also say "unpacked") using [`google.protobuf.Any`](https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/any.proto). `Any` could be thought as a struct that contains a `type_url` (name of a concrete type implementing the interface) and a `value` (its encoded bytes). `InterfaceRegistry` provides a mechanism for registering interfaces and implementations that can be safely unpacked from `Any`. Each application module implements the `RegisterInterfaces` method that can be used to register the module's own interfaces and implementations. - * You can read more about `Any` in [ADR-019](/docs/sdk/v0.47//build/architecture/adr-019-protobuf-state-encoding). - * To go more into details, the Cosmos SDK uses an implementation of the Protobuf specification called [`gogoprotobuf`](https://github.com/cosmos/gogoproto). By default, the [gogo protobuf implementation of `Any`](https://pkg.go.dev/github.com/cosmos/gogoproto/types) uses [global type registration](https://github.com/cosmos/gogoproto/blob/master/proto/properties.go#L540) to decode values packed in `Any` into concrete Go types. This introduces a vulnerability where any malicious module in the dependency tree could register a type with the global protobuf registry and cause it to be loaded and unmarshaled by a transaction that referenced it in the `type_url` field. For more information, please refer to [ADR-019](/docs/sdk/v0.47//build/architecture/adr-019-protobuf-state-encoding). + * You can read more about `Any` in [ADR-019](/docs/sdk/v0.47/build/architecture/adr-019-protobuf-state-encoding). + * To go more into details, the Cosmos SDK uses an implementation of the Protobuf specification called [`gogoprotobuf`](https://github.com/cosmos/gogoproto). By default, the [gogo protobuf implementation of `Any`](https://pkg.go.dev/github.com/cosmos/gogoproto/types) uses [global type registration](https://github.com/cosmos/gogoproto/blob/master/proto/properties.go#L540) to decode values packed in `Any` into concrete Go types. This introduces a vulnerability where any malicious module in the dependency tree could register a type with the global protobuf registry and cause it to be loaded and unmarshaled by a transaction that referenced it in the `type_url` field. For more information, please refer to [ADR-019](/docs/sdk/v0.47/build/architecture/adr-019-protobuf-state-encoding). * `Codec`: The default codec used throughout the Cosmos SDK. It is composed of a `BinaryCodec` used to encode and decode state, and a `JSONCodec` used to output data to the users (for example, in the [CLI](#cli)). By default, the SDK uses Protobuf as `Codec`. * `TxConfig`: `TxConfig` defines an interface a client can utilize to generate an application-defined concrete transaction type. Currently, the SDK handles two transaction types: `SIGN_MODE_DIRECT` (which uses Protobuf binary as over-the-wire encoding) and `SIGN_MODE_LEGACY_AMINO_JSON` (which depends on Amino). Read more about transactions [here](/docs/sdk/v0.47/learn/advanced/transactions). * `Amino`: Some legacy parts of the Cosmos SDK still use Amino for backwards-compatibility. Each module exposes a `RegisterLegacyAmino` method to register the module's specific types within Amino. This `Amino` codec should not be used by app developers anymore, and will be removed in future releases. @@ -4630,13 +4630,13 @@ return encodingConfig ## Modules -[Modules](/docs/sdk/v0.47//build/building-modules/intro) are the heart and soul of Cosmos SDK applications. They can be considered as state-machines nested within the state-machine. When a transaction is relayed from the underlying CometBFT engine via the ABCI to the application, it is routed by [`baseapp`](/docs/sdk/v0.47/learn/advanced/baseapp) to the appropriate module in order to be processed. This paradigm enables developers to easily build complex state-machines, as most of the modules they need often already exist. **For developers, most of the work involved in building a Cosmos SDK application revolves around building custom modules required by their application that do not exist yet, and integrating them with modules that do already exist into one coherent application**. In the application directory, the standard practice is to store modules in the `x/` folder (not to be confused with the Cosmos SDK's `x/` folder, which contains already-built modules). +[Modules](/docs/sdk/v0.47/build/building-modules/intro) are the heart and soul of Cosmos SDK applications. They can be considered as state-machines nested within the state-machine. When a transaction is relayed from the underlying CometBFT engine via the ABCI to the application, it is routed by [`baseapp`](/docs/sdk/v0.47/learn/advanced/baseapp) to the appropriate module in order to be processed. This paradigm enables developers to easily build complex state-machines, as most of the modules they need often already exist. **For developers, most of the work involved in building a Cosmos SDK application revolves around building custom modules required by their application that do not exist yet, and integrating them with modules that do already exist into one coherent application**. In the application directory, the standard practice is to store modules in the `x/` folder (not to be confused with the Cosmos SDK's `x/` folder, which contains already-built modules). ### Application Module Interface -Modules must implement [interfaces](/docs/sdk/v0.47//build/building-modules/module-manager#application-module-interfaces) defined in the Cosmos SDK, [`AppModuleBasic`](/docs/sdk/v0.47//build/building-modules/module-manager#appmodulebasic) and [`AppModule`](/docs/sdk/v0.47//build/building-modules/module-manager#appmodule). The former implements basic non-dependent elements of the module, such as the `codec`, while the latter handles the bulk of the module methods (including methods that require references to other modules' `keeper`s). Both the `AppModule` and `AppModuleBasic` types are, by convention, defined in a file called `module.go`. +Modules must implement [interfaces](/docs/sdk/v0.47/build/building-modules/module-manager#application-module-interfaces) defined in the Cosmos SDK, [`AppModuleBasic`](/docs/sdk/v0.47/build/building-modules/module-manager#appmodulebasic) and [`AppModule`](/docs/sdk/v0.47/build/building-modules/module-manager#appmodule). The former implements basic non-dependent elements of the module, such as the `codec`, while the latter handles the bulk of the module methods (including methods that require references to other modules' `keeper`s). Both the `AppModule` and `AppModuleBasic` types are, by convention, defined in a file called `module.go`. -`AppModule` exposes a collection of useful methods on the module that facilitates the composition of modules into a coherent application. These methods are called from the [`module manager`](/docs/sdk/v0.47//build/building-modules/module-manager#manager), which manages the application's collection of modules. +`AppModule` exposes a collection of useful methods on the module that facilitates the composition of modules into a coherent application. These methods are called from the [`module manager`](/docs/sdk/v0.47/build/building-modules/module-manager#manager), which manages the application's collection of modules. ### `Msg` Services @@ -4665,7 +4665,7 @@ Each module should also implement the `RegisterServices` method as part of the [ ### gRPC `Query` Services -gRPC `Query` services allow users to query the state using [gRPC](https://grpc.io). They are enabled by default, and can be configured under the `grpc.enable` and `grpc.address` fields inside [`app.toml`](/docs/sdk/v0.47//user/run-node/interact-node#configuring-the-node-using-apptoml). +gRPC `Query` services allow users to query the state using [gRPC](https://grpc.io). They are enabled by default, and can be configured under the `grpc.enable` and `grpc.address` fields inside [`app.toml`](/docs/sdk/v0.47/user/run-node/interact-node#configuring-the-node-using-apptoml). gRPC `Query` services are defined in the module's Protobuf definition files, specifically inside `query.proto`. The `query.proto` definition file exposes a single `Query` [Protobuf service](https://developers.google.com/protocol-buffers/docs/proto#services). Each gRPC query endpoint corresponds to a service method, starting with the `rpc` keyword, inside the `Query` service. @@ -4675,7 +4675,7 @@ Finally, each module should also implement the `RegisterServices` method as part ### Keeper -[`Keepers`](/docs/sdk/v0.47//build/building-modules/keeper) are the gatekeepers of their module's store(s). To read or write in a module's store, it is mandatory to go through one of its `keeper`'s methods. This is ensured by the [object-capabilities](/docs/sdk/v0.47/learn/advanced/ocap) model of the Cosmos SDK. Only objects that hold the key to a store can access it, and only the module's `keeper` should hold the key(s) to the module's store(s). +[`Keepers`](/docs/sdk/v0.47/build/building-modules/keeper) are the gatekeepers of their module's store(s). To read or write in a module's store, it is mandatory to go through one of its `keeper`'s methods. This is ensured by the [object-capabilities](/docs/sdk/v0.47/learn/advanced/ocap) model of the Cosmos SDK. Only objects that hold the key to a store can access it, and only the module's `keeper` should hold the key(s) to the module's store(s). `Keepers` are generally defined in a file called `keeper.go`. It contains the `keeper`'s type definition and methods. @@ -4693,7 +4693,7 @@ Each module defines command-line commands, gRPC services, and REST routes to be #### CLI -Generally, the [commands related to a module](/docs/sdk/v0.47//build/building-modules/module-interfaces#cli) are defined in a folder called `client/cli` in the module's folder. The CLI divides commands into two categories, transactions and queries, defined in `client/cli/tx.go` and `client/cli/query.go`, respectively. Both commands are built on top of the [Cobra Library](https://github.com/spf13/cobra): +Generally, the [commands related to a module](/docs/sdk/v0.47/build/building-modules/module-interfaces#cli) are defined in a folder called `client/cli` in the module's folder. The CLI divides commands into two categories, transactions and queries, defined in `client/cli/tx.go` and `client/cli/query.go`, respectively. Both commands are built on top of the [Cobra Library](https://github.com/spf13/cobra): * Transactions commands let users generate new transactions so that they can be included in a block and eventually update the state. One command should be created for each defined in the module. The command calls the constructor of the message with the parameters provided by the end-user, and wraps it into a transaction. The Cosmos SDK handles signing and the addition of other transaction metadata. * Queries let users query the subset of the state defined by the module. Query commands forward queries to the [application's query router](/docs/sdk/v0.47/learn/advanced/baseapp#query-routing), which routes them to the appropriate the `queryRoute` parameter supplied. @@ -4713,7 +4713,7 @@ Some external clients may not wish to use gRPC. In this case, the Cosmos SDK pro The REST endpoints are defined in the Protobuf files, along with the gRPC services, using Protobuf annotations. Modules that want to expose REST queries should add `google.api.http` annotations to their `rpc` methods. By default, all REST endpoints defined in the SDK have a URL starting with the `/cosmos/` prefix. -The Cosmos SDK also provides a development endpoint to generate [Swagger](https://swagger.io/) definition files for these REST endpoints. This endpoint can be enabled inside the [`app.toml`](/docs/sdk/v0.47//user/run-node/run-node#configuring-the-node-using-apptoml) config file, under the `api.swagger` key. +The Cosmos SDK also provides a development endpoint to generate [Swagger](https://swagger.io/) definition files for these REST endpoints. This endpoint can be enabled inside the [`app.toml`](/docs/sdk/v0.47/user/run-node/run-node#configuring-the-node-using-apptoml) config file, under the `api.swagger` key. ## Application Interface diff --git a/docs/sdk/v0.47/learn/beginner/query-lifecycle.mdx b/docs/sdk/v0.47/learn/beginner/query-lifecycle.mdx index e850de77..d8cb8a8e 100644 --- a/docs/sdk/v0.47/learn/beginner/query-lifecycle.mdx +++ b/docs/sdk/v0.47/learn/beginner/query-lifecycle.mdx @@ -16,9 +16,9 @@ This document describes the lifecycle of a query in a Cosmos SDK application, fr ## Query Creation -A [**query**](/docs/sdk/v0.47//build/building-modules/messages-and-queries#queries) is a request for information made by end-users of applications through an interface and processed by a full-node. Users can query information about the network, the application itself, and application state directly from the application's stores or modules. Note that queries are different from [transactions](/docs/sdk/v0.47/learn/advanced/transactions) (view the lifecycle [here](/docs/sdk/v0.47/learn/beginner/tx-lifecycle)), particularly in that they do not require consensus to be processed (as they do not trigger state-transitions); they can be fully handled by one full-node. +A [**query**](/docs/sdk/v0.47/build/building-modules/messages-and-queries#queries) is a request for information made by end-users of applications through an interface and processed by a full-node. Users can query information about the network, the application itself, and application state directly from the application's stores or modules. Note that queries are different from [transactions](/docs/sdk/v0.47/learn/advanced/transactions) (view the lifecycle [here](/docs/sdk/v0.47/learn/beginner/tx-lifecycle)), particularly in that they do not require consensus to be processed (as they do not trigger state-transitions); they can be fully handled by one full-node. -For the purpose of explaining the query lifecycle, let's say the query, `MyQuery`, is requesting a list of delegations made by a certain delegator address in the application called `simapp`. As is to be expected, the [`staking`](/docs/sdk/v0.47//build/modules/staking/README) module handles this query. But first, there are a few ways `MyQuery` can be created by users. +For the purpose of explaining the query lifecycle, let's say the query, `MyQuery`, is requesting a list of delegations made by a certain delegator address in the application called `simapp`. As is to be expected, the [`staking`](/docs/sdk/v0.47/build/modules/staking/README) module handles this query. But first, there are a few ways `MyQuery` can be created by users. ### CLI @@ -28,7 +28,7 @@ The main interface for an application is the command-line interface. Users conne simd query staking delegations ``` -This query command was defined by the [`staking`](/docs/sdk/v0.47//build/modules/staking/README) module developer and added to the list of subcommands by the application developer when creating the CLI. +This query command was defined by the [`staking`](/docs/sdk/v0.47/build/modules/staking/README) module developer and added to the list of subcommands by the application developer when creating the CLI. Note that the general format is as follows: @@ -36,7 +36,7 @@ Note that the general format is as follows: simd query [moduleName] [command] --flag ``` -To provide values such as `--node` (the full-node the CLI connects to), the user can use the [`app.toml`](/docs/sdk/v0.47//user/run-node/interact-node#configuring-the-node-using-apptoml) config file to set them or provide them as flags. +To provide values such as `--node` (the full-node the CLI connects to), the user can use the [`app.toml`](/docs/sdk/v0.47/user/run-node/interact-node#configuring-the-node-using-apptoml) config file to set them or provide them as flags. The CLI understands a specific set of commands, defined in a hierarchical structure by the application developer: from the [root command](/docs/sdk/v0.47/learn/advanced/cli#root-command) (`simd`), the type of command (`Myquery`), the module that contains the command (`staking`), and command itself (`delegations`). Thus, the CLI knows exactly which module handles this command and directly passes the call there. @@ -75,7 +75,7 @@ The preceding examples show how an external user can interact with a node by que The first thing that is created in the execution of a CLI command is a `client.Context`. A `client.Context` is an object that stores all the data needed to process a request on the user side. In particular, a `client.Context` stores the following: * **Codec**: The [encoder/decoder](/docs/sdk/v0.47/learn/advanced/encoding) used by the application, used to marshal the parameters and query before making the CometBFT RPC request and unmarshal the returned response into a JSON object. The default codec used by the CLI is Protobuf. -* **Account Decoder**: The account decoder from the [`auth`](/docs/sdk/v0.47//build/modules/auth/README) module, which translates `[]byte`s into accounts. +* **Account Decoder**: The account decoder from the [`auth`](/docs/sdk/v0.47/build/modules/auth/README) module, which translates `[]byte`s into accounts. * **RPC Client**: The CometBFT RPC Client, or node, to which requests are relayed. * **Keyring**: A [Key Manager](/docs/sdk/v0.47/learn/beginner/accounts#keyring) used to sign transactions and handle other operations with keys. * **Output Writer**: A [Writer](https://pkg.go.dev/io/#Writer) used to output the response. @@ -2457,7 +2457,7 @@ Read more about ABCI Clients and CometBFT RPC in the [CometBFT documentation](ht When a query is received by the full-node after it has been relayed from the underlying consensus engine, it is at that point being handled within an environment that understands application-specific types and has a copy of the state. [`baseapp`](/docs/sdk/v0.47/learn/advanced/baseapp) implements the ABCI [`Query()`](/docs/sdk/v0.47/learn/advanced/baseapp#query) function and handles gRPC queries. The query route is parsed, and it matches the fully-qualified service method name of an existing service method (most likely in one of the modules), then `baseapp` relays the request to the relevant module. -Since `MyQuery` has a Protobuf fully-qualified service method name from the `staking` module (recall `/cosmos.staking.v1beta1.Query/Delegations`), `baseapp` first parses the path, then uses its own internal `GRPCQueryRouter` to retrieve the corresponding gRPC handler, and routes the query to the module. The gRPC handler is responsible for recognizing this query, retrieving the appropriate values from the application's stores, and returning a response. Read more about query services [here](/docs/sdk/v0.47//build/building-modules/query-services). +Since `MyQuery` has a Protobuf fully-qualified service method name from the `staking` module (recall `/cosmos.staking.v1beta1.Query/Delegations`), `baseapp` first parses the path, then uses its own internal `GRPCQueryRouter` to retrieve the corresponding gRPC handler, and routes the query to the module. The gRPC handler is responsible for recognizing this query, retrieving the appropriate values from the application's stores, and returning a response. Read more about query services [here](/docs/sdk/v0.47/build/building-modules/query-services). Once a result is received from the querier, `baseapp` begins the process of returning a response to the user. diff --git a/docs/sdk/v0.47/learn/beginner/tx-lifecycle.mdx b/docs/sdk/v0.47/learn/beginner/tx-lifecycle.mdx index f1dd38ba..6edb6eef 100644 --- a/docs/sdk/v0.47/learn/beginner/tx-lifecycle.mdx +++ b/docs/sdk/v0.47/learn/beginner/tx-lifecycle.mdx @@ -92,7 +92,7 @@ To discard obviously invalid messages, the `BaseApp` type calls the `ValidateBas `ValidateBasic` can include only **stateless** checks (the checks that do not require access to the state). -The `ValidateBasic` method on messages has been deprecated in favor of validating messages directly in their respective [`Msg` services](/docs/sdk/v0.47//build/building-modules/msg-services#Validation). +The `ValidateBasic` method on messages has been deprecated in favor of validating messages directly in their respective [`Msg` services](/docs/sdk/v0.47/build/building-modules/msg-services#Validation). Read [RFC 001](https://docs.cosmos.network/main/rfc/rfc-001-tx-validation) for more details. @@ -103,7 +103,7 @@ Read [RFC 001](https://docs.cosmos.network/main/rfc/rfc-001-tx-validation) for m #### Guideline -`ValidateBasic` should not be used anymore. Message validation should be performed in the `Msg` service when [handling a message](/docs/sdk/v0.47//build/building-modules/msg-services#Validation) in a module Msg Server. +`ValidateBasic` should not be used anymore. Message validation should be performed in the `Msg` service when [handling a message](/docs/sdk/v0.47/build/building-modules/msg-services#Validation) in a module Msg Server. ### AnteHandler @@ -219,8 +219,8 @@ Instead of using their `checkState`, full-nodes use `deliverState`: * **`MsgServiceRouter`:** After `CheckTx` exits, `DeliverTx` continues to run [`runMsgs`](/docs/sdk/v0.47/learn/advanced/baseapp#runtx-antehandler-runmsgs-posthandler) to fully execute each `Msg` within the transaction. Since the transaction may have messages from different modules, `BaseApp` needs to know which module - to find the appropriate handler. This is achieved using `BaseApp`'s `MsgServiceRouter` so that it can be processed by the module's Protobuf [`Msg` service](/docs/sdk/v0.47//build/building-modules/msg-services). - For `LegacyMsg` routing, the `Route` function is called via the [module manager](/docs/sdk/v0.47//build/building-modules/module-manager) to retrieve the route name and find the legacy [`Handler`](/docs/sdk/v0.47//build/building-modules/msg-services#handler-type) within the module. + to find the appropriate handler. This is achieved using `BaseApp`'s `MsgServiceRouter` so that it can be processed by the module's Protobuf [`Msg` service](/docs/sdk/v0.47/build/building-modules/msg-services). + For `LegacyMsg` routing, the `Route` function is called via the [module manager](/docs/sdk/v0.47/build/building-modules/module-manager) to retrieve the route name and find the legacy [`Handler`](/docs/sdk/v0.47/build/building-modules/msg-services#handler-type) within the module. * **`Msg` service:** Protobuf `Msg` service is responsible for executing each message in the `Tx` and causes state transitions to persist in `deliverTxState`. diff --git a/docs/sdk/v0.47/learn/intro/overview.mdx b/docs/sdk/v0.47/learn/intro/overview.mdx index c83d6d9d..776bca86 100644 --- a/docs/sdk/v0.47/learn/intro/overview.mdx +++ b/docs/sdk/v0.47/learn/intro/overview.mdx @@ -4,7 +4,7 @@ title: What is the Cosmos SDK The [Cosmos SDK](https://github.com/cosmos/cosmos-sdk) is an open-source framework for building multi-asset public Proof-of-Stake (PoS) blockchains, like the Cosmos Hub, as well as permissioned Proof-of-Authority (PoA) blockchains. Blockchains built with the Cosmos SDK are generally referred to as **application-specific blockchains**. -The goal of the Cosmos SDK is to allow developers to easily create custom blockchains from scratch that can natively interoperate with other blockchains. We envision the Cosmos SDK as the npm-like framework to build secure blockchain applications on top of [CometBFT](https://github.com/cometbft/cometbft). SDK-based blockchains are built out of composable [modules](/docs/sdk/v0.47//build/building-modules/intro), most of which are open-source and readily available for any developers to use. Anyone can create a module for the Cosmos SDK, and integrating already-built modules is as simple as importing them into your blockchain application. What's more, the Cosmos SDK is a capabilities-based system that allows developers to better reason about the security of interactions between modules. For a deeper look at capabilities, jump to [Object-Capability Model](/docs/sdk/v0.47/learn/advanced/ocap). +The goal of the Cosmos SDK is to allow developers to easily create custom blockchains from scratch that can natively interoperate with other blockchains. We envision the Cosmos SDK as the npm-like framework to build secure blockchain applications on top of [CometBFT](https://github.com/cometbft/cometbft). SDK-based blockchains are built out of composable [modules](/docs/sdk/v0.47/build/building-modules/intro), most of which are open-source and readily available for any developers to use. Anyone can create a module for the Cosmos SDK, and integrating already-built modules is as simple as importing them into your blockchain application. What's more, the Cosmos SDK is a capabilities-based system that allows developers to better reason about the security of interactions between modules. For a deeper look at capabilities, jump to [Object-Capability Model](/docs/sdk/v0.47/learn/advanced/ocap). ## What are Application-Specific Blockchains diff --git a/docs/sdk/v0.47/learn/intro/sdk-app-architecture.mdx b/docs/sdk/v0.47/learn/intro/sdk-app-architecture.mdx index ece16441..8d61bf21 100644 --- a/docs/sdk/v0.47/learn/intro/sdk-app-architecture.mdx +++ b/docs/sdk/v0.47/learn/intro/sdk-app-architecture.mdx @@ -84,7 +84,7 @@ Note that **CometBFT only handles transaction bytes**. It has no knowledge of wh Here are the most important messages of the ABCI: * `CheckTx`: When a transaction is received by CometBFT, it is passed to the application to check if a few basic requirements are met. `CheckTx` is used to protect the mempool of full-nodes against spam transactions. . A special handler called the [`AnteHandler`](/docs/sdk/v0.47/learn/beginner/gas-fees#antehandler) is used to execute a series of validation steps such as checking for sufficient fees and validating the signatures. If the checks are valid, the transaction is added to the [mempool](https://docs.cometbft.com/v0.37/spec/p2p/messages/mempool) and relayed to peer nodes. Note that transactions are not processed (i.e. no modification of the state occurs) with `CheckTx` since they have not been included in a block yet. -* `DeliverTx`: When a [valid block](https://docs.cometbft.com/v0.37/spec/core/data_structures#block) is received by CometBFT, 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](/docs/sdk/v0.47//build/building-modules/msg-services) RPC for each message in the transaction. +* `DeliverTx`: When a [valid block](https://docs.cometbft.com/v0.37/spec/core/data_structures#block) is received by CometBFT, 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](/docs/sdk/v0.47/build/building-modules/msg-services) 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 [CometBFT docs](https://docs.cometbft.com/v0.37/spec/abci/). diff --git a/docs/sdk/v0.47/user/run-node/interact-node.mdx b/docs/sdk/v0.47/user/run-node/interact-node.mdx index ddf311ec..0fcc0ff8 100644 --- a/docs/sdk/v0.47/user/run-node/interact-node.mdx +++ b/docs/sdk/v0.47/user/run-node/interact-node.mdx @@ -10,7 +10,7 @@ There are multiple ways to interact with a node: using the CLI, using gRPC or us **Pre-requisite Readings** -* [gRPC, REST and CometBFT Endpoints](/docs/sdk/v0.47//learn/advanced/grpc_rest) +* [gRPC, REST and CometBFT Endpoints](/docs/sdk/v0.47/learn/advanced/grpc_rest) * [Running a Node](/docs/sdk/v0.47/user/run-node/run-node) @@ -54,7 +54,7 @@ You should see two delegations, the first one made from the `gentx`, and the sec ## Using gRPC -The Protobuf ecosystem developed tools for different use cases, including code-generation from `*.proto` files into various languages. These tools allow the building of clients easily. Often, the client connection (i.e. the transport) can be plugged and replaced very easily. Let's explore one of the most popular transport: [gRPC](/docs/sdk/v0.47//learn/advanced/grpc_rest). +The Protobuf ecosystem developed tools for different use cases, including code-generation from `*.proto` files into various languages. These tools allow the building of clients easily. Often, the client connection (i.e. the transport) can be plugged and replaced very easily. Let's explore one of the most popular transport: [gRPC](/docs/sdk/v0.47/learn/advanced/grpc_rest). Since the code generation library largely depends on your own tech stack, we will only present three alternatives: @@ -258,7 +258,7 @@ CosmJS documentation can be found at [Link](https://cosmos.github.io/cosmjs). As ## Using the REST Endpoints -As described in the [gRPC guide](/docs/sdk/v0.47//learn/advanced/grpc_rest), all gRPC services on the Cosmos SDK are made available for more convenient REST-based queries through gRPC-gateway. The format of the URL path is based on the Protobuf service method's full-qualified name, but may contain small customizations so that final URLs look more idiomatic. For example, the REST endpoint for the `cosmos.bank.v1beta1.Query/AllBalances` method is `GET /cosmos/bank/v1beta1/balances/{address}`. Request arguments are passed as query parameters. +As described in the [gRPC guide](/docs/sdk/v0.47/learn/advanced/grpc_rest), all gRPC services on the Cosmos SDK are made available for more convenient REST-based queries through gRPC-gateway. The format of the URL path is based on the Protobuf service method's full-qualified name, but may contain small customizations so that final URLs look more idiomatic. For example, the REST endpoint for the `cosmos.bank.v1beta1.Query/AllBalances` method is `GET /cosmos/bank/v1beta1/balances/{address}`. Request arguments are passed as query parameters. Note that the REST endpoints are not enabled by default. To enable them, edit the `api` section of your `~/.simapp/config/app.toml` file: diff --git a/docs/sdk/v0.47/user/run-node/keyring.mdx b/docs/sdk/v0.47/user/run-node/keyring.mdx index 49fc7bf4..f02b717b 100644 --- a/docs/sdk/v0.47/user/run-node/keyring.mdx +++ b/docs/sdk/v0.47/user/run-node/keyring.mdx @@ -4,7 +4,7 @@ title: Setting up the keyring **Synopsis** -This document describes how to configure and use the keyring and its various backends for an [**application**](/docs/sdk/v0.47//learn/beginner/overview-app). +This document describes how to configure and use the keyring and its various backends for an [**application**](/docs/sdk/v0.47/learn/beginner/app-anatomy). The keyring holds the private/public keypairs used to interact with a node. For instance, a validator key needs to be set up before running the blockchain node, so that blocks can be correctly signed. The private key can be stored in different locations, called "backends", such as a file or the operating system's own key storage. diff --git a/docs/sdk/v0.47/user/run-node/run-node.mdx b/docs/sdk/v0.47/user/run-node/run-node.mdx index 8cc36517..2ba7961f 100644 --- a/docs/sdk/v0.47/user/run-node/run-node.mdx +++ b/docs/sdk/v0.47/user/run-node/run-node.mdx @@ -10,7 +10,7 @@ Now that the application is ready and the keyring populated, it's time to see ho **Pre-requisite Readings** -* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.47//learn/beginner/overview-app) +* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.47/learn/beginner/app-anatomy) * [Setting up the keyring](/docs/sdk/v0.47/user/run-node/keyring) @@ -86,7 +86,7 @@ simd genesis add-genesis-account $MY_VALIDATOR_ADDRESS 100000000000stake Recall that `$MY_VALIDATOR_ADDRESS` is a variable that holds the address of the `my_validator` key in the [keyring](/docs/sdk/v0.47/user/run-node/keyring#adding-keys-to-the-keyring). Also note that the tokens in the Cosmos SDK have the `{amount}{denom}` format: `amount` is is a 18-digit-precision decimal number, and `denom` is the unique token identifier with its denomination key (e.g. `atom` or `uatom`). Here, we are granting `stake` tokens, as `stake` is the token identifier used for staking in [`simapp`](https://github.com/cosmos/cosmos-sdk/tree/main/simapp). For your own chain with its own staking denom, that token identifier should be used instead. -Now that your account has some tokens, you need to add a validator to your chain. Validators are special full-nodes that participate in the consensus process (implemented in the [underlying consensus engine](/docs/sdk/v0.47//learn/intro/sdk-app-architecture#cometbft)) in order to add new blocks to the chain. Any account can declare its intention to become a validator operator, but only those with sufficient delegation get to enter the active set (for example, only the top 125 validator candidates with the most delegation get to be validators in the Cosmos Hub). For this guide, you will add your local node (created via the `init` command above) as a validator of your chain. Validators can be declared before a chain is first started via a special transaction included in the genesis file called a `gentx`: +Now that your account has some tokens, you need to add a validator to your chain. Validators are special full-nodes that participate in the consensus process (implemented in the [underlying consensus engine](/docs/sdk/v0.47/learn/intro/sdk-app-architecture#cometbft)) in order to add new blocks to the chain. Any account can declare its intention to become a validator operator, but only those with sufficient delegation get to enter the active set (for example, only the top 125 validator candidates with the most delegation get to be validators in the Cosmos Hub). For this guide, you will add your local node (created via the `init` command above) as a validator of your chain. Validators can be declared before a chain is first started via a special transaction included in the genesis file called a `gentx`: ```bash # Create a gentx. diff --git a/docs/sdk/v0.47/user/run-node/txs.mdx b/docs/sdk/v0.47/user/run-node/txs.mdx index 91c1d094..1ed639c8 100644 --- a/docs/sdk/v0.47/user/run-node/txs.mdx +++ b/docs/sdk/v0.47/user/run-node/txs.mdx @@ -378,7 +378,7 @@ error { ### Broadcasting a Transaction -The preferred way to broadcast a transaction is to use gRPC, though using REST (via `gRPC-gateway`) or the CometBFT RPC is also posible. An overview of the differences between these methods is exposed [here](/docs/sdk/v0.47//learn/advanced/grpc_rest). For this tutorial, we will only describe the gRPC method. +The preferred way to broadcast a transaction is to use gRPC, though using REST (via `gRPC-gateway`) or the CometBFT RPC is also posible. An overview of the differences between these methods is exposed [here](/docs/sdk/v0.47/learn/advanced/grpc_rest). For this tutorial, we will only describe the gRPC method. ```go expandable import ( diff --git a/docs/sdk/v0.50/build/architecture/adr-033-protobuf-inter-module-comm.mdx b/docs/sdk/v0.50/build/architecture/adr-033-protobuf-inter-module-comm.mdx index 90daebd3..6e585b47 100644 --- a/docs/sdk/v0.50/build/architecture/adr-033-protobuf-inter-module-comm.mdx +++ b/docs/sdk/v0.50/build/architecture/adr-033-protobuf-inter-module-comm.mdx @@ -23,7 +23,7 @@ service definitions defined in [ADR 021](/docs/sdk/v0.50/build/architecture/adr- ## Context -In the current Cosmos SDK documentation on the [Object-Capability Model](/docs/sdk/v0.50//learn/advanced/ocap), it is stated that: +In the current Cosmos SDK documentation on the [Object-Capability Model](/docs/sdk/v0.50/learn/advanced/ocap), it is stated that: > We assume that a thriving ecosystem of Cosmos SDK modules that are easy to compose into a blockchain application will contain faulty or malicious modules. diff --git a/docs/sdk/v0.50/build/architecture/adr-076-tx-malleability.mdx b/docs/sdk/v0.50/build/architecture/adr-076-tx-malleability.mdx index 484f2f47..2dc288d0 100644 --- a/docs/sdk/v0.50/build/architecture/adr-076-tx-malleability.mdx +++ b/docs/sdk/v0.50/build/architecture/adr-076-tx-malleability.mdx @@ -90,7 +90,7 @@ representation. #### Fields not covered by Amino JSON -Another area that needs to be addressed carefully is the discrepancy between `AminoSignDoc`(see [`aminojson.proto`](/docs/sdk/v0.50//x/tx/signing/aminojson/internal/aminojsonpb/aminojson.proto)) used for `SIGN_MODE_LEGACY_AMINO_JSON` and the actual contents of `TxBody` and `AuthInfo` (see [`tx.proto`](/docs/sdk/v0.50//proto/cosmos/tx/v1beta1/tx.proto)). +Another area that needs to be addressed carefully is the discrepancy between `AminoSignDoc`(see [`aminojson.proto`](/docs/sdk/v0.50/x/tx/signing/aminojson/internal/aminojsonpb/aminojson.proto)) used for `SIGN_MODE_LEGACY_AMINO_JSON` and the actual contents of `TxBody` and `AuthInfo` (see [`tx.proto`](/docs/sdk/v0.50/proto/cosmos/tx/v1beta1/tx.proto)). If fields get added to `TxBody` or `AuthInfo`, they must either have a corresponding representing in `AminoSignDoc` or Amino JSON signatures must be rejected when those new fields are set. Making sure that this is done is a highly manual process, and developers could easily make the mistake of updating `TxBody` or `AuthInfo` without paying any attention to the implementation of `GetSignBytes` for Amino JSON. This is a critical @@ -169,5 +169,5 @@ or get rejected. * [ADR 027: Deterministic Protobuf Serialization](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-027-deterministic-protobuf-serialization.md) * [ADR 020](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-020-protobuf-transaction-encoding.md#unknown-field-filtering) -* [`aminojson.proto`](/docs/sdk/v0.50//x/tx/signing/aminojson/internal/aminojsonpb/aminojson.proto) -* [`tx.proto`](/docs/sdk/v0.50//proto/cosmos/tx/v1beta1/tx.proto) +* [`aminojson.proto`](/docs/sdk/v0.50/x/tx/signing/aminojson/internal/aminojsonpb/aminojson.proto) +* [`tx.proto`](/docs/sdk/v0.50/proto/cosmos/tx/v1beta1/tx.proto) diff --git a/docs/sdk/v0.50/build/building-apps/app-mempool.mdx b/docs/sdk/v0.50/build/building-apps/app-mempool.mdx index 16331499..e1762f11 100644 --- a/docs/sdk/v0.50/build/building-apps/app-mempool.mdx +++ b/docs/sdk/v0.50/build/building-apps/app-mempool.mdx @@ -15,7 +15,7 @@ Notably it introduces the `PrepareProposal` and `ProcessProposal` steps of ABCI+ **Pre-requisite Readings** -* [BaseApp](/docs/sdk/v0.50//learn/advanced/baseapp) +* [BaseApp](/docs/sdk/v0.50/learn/advanced/baseapp) diff --git a/docs/sdk/v0.50/build/building-modules/beginblock-endblock.mdx b/docs/sdk/v0.50/build/building-modules/beginblock-endblock.mdx index 68467769..1fbd5c30 100644 --- a/docs/sdk/v0.50/build/building-modules/beginblock-endblock.mdx +++ b/docs/sdk/v0.50/build/building-modules/beginblock-endblock.mdx @@ -5,7 +5,7 @@ title: BeginBlocker and EndBlocker **Synopsis** -`BeginBlocker` and `EndBlocker` are optional methods module developers can implement in their module. They will be triggered at the beginning and at the end of each block respectively, when the [`BeginBlock`](/docs/sdk/v0.50//learn/advanced/baseapp#beginblock) and [`EndBlock`](/docs/sdk/v0.50//learn/advanced/baseapp#endblock) ABCI messages are received from the underlying consensus engine. +`BeginBlocker` and `EndBlocker` are optional methods module developers can implement in their module. They will be triggered at the beginning and at the end of each block respectively, when the [`BeginBlock`](/docs/sdk/v0.50/learn/advanced/baseapp#beginblock) and [`EndBlock`](/docs/sdk/v0.50/learn/advanced/baseapp#endblock) ABCI messages are received from the underlying consensus engine. @@ -25,9 +25,9 @@ When needed, `BeginBlocker` and `EndBlocker` are implemented as part of the [`Ha The actual implementation of `BeginBlocker` and `EndBlocker` in `abci.go` are very similar to that of a [`Msg` service](/docs/sdk/v0.50/build/building-modules/msg-services): -* They generally use the [`keeper`](/docs/sdk/v0.50/build/building-modules/keeper) and [`ctx`](/docs/sdk/v0.50//learn/advanced/context) to retrieve information about the latest state. +* They generally use the [`keeper`](/docs/sdk/v0.50/build/building-modules/keeper) and [`ctx`](/docs/sdk/v0.50/learn/advanced/context) to retrieve information about the latest state. * If needed, they use the `keeper` and `ctx` to trigger state-transitions. -* If needed, they can emit [`events`](/docs/sdk/v0.50//learn/advanced/events) via the `ctx`'s `EventManager`. +* If needed, they can emit [`events`](/docs/sdk/v0.50/learn/advanced/events) via the `ctx`'s `EventManager`. A specific type of `EndBlocker` is available to return validator updates to the underlying consensus engine in the form of an [`[]abci.ValidatorUpdates`](https://docs.cometbft.com/v0.37/spec/abci/abci++_methods#endblock). This is the preferred way to implement custom validator changes. diff --git a/docs/sdk/v0.50/build/building-modules/genesis.mdx b/docs/sdk/v0.50/build/building-modules/genesis.mdx index 1e6457fd..9d4e43fb 100644 --- a/docs/sdk/v0.50/build/building-modules/genesis.mdx +++ b/docs/sdk/v0.50/build/building-modules/genesis.mdx @@ -18,7 +18,7 @@ Modules generally handle a subset of the state and, as such, they need to define ## Type Definition -The subset of the genesis state defined from a given module is generally defined in a `genesis.proto` file ([more info](/docs/sdk/v0.50//learn/advanced/encoding#gogoproto) on how to define protobuf messages). The struct defining the module's subset of the genesis state is usually called `GenesisState` and contains all the module-related values that need to be initialized during the genesis process. +The subset of the genesis state defined from a given module is generally defined in a `genesis.proto` file ([more info](/docs/sdk/v0.50/learn/advanced/encoding#gogoproto) on how to define protobuf messages). The struct defining the module's subset of the genesis state is usually called `GenesisState` and contains all the module-related values that need to be initialized during the genesis process. See an example of `GenesisState` protobuf message definition from the `auth` module: @@ -612,9 +612,9 @@ Other than the methods related directly to `GenesisState`, module developers are ### `InitGenesis` -The `InitGenesis` method is executed during [`InitChain`](/docs/sdk/v0.50//learn/advanced/baseapp#initchain) when the application is first started. Given a `GenesisState`, it initializes the subset of the state managed by the module by using the module's [`keeper`](/docs/sdk/v0.50/build/building-modules/keeper) setter function on each parameter within the `GenesisState`. +The `InitGenesis` method is executed during [`InitChain`](/docs/sdk/v0.50/learn/advanced/baseapp#initchain) when the application is first started. Given a `GenesisState`, it initializes the subset of the state managed by the module by using the module's [`keeper`](/docs/sdk/v0.50/build/building-modules/keeper) setter function on each parameter within the `GenesisState`. -The [module manager](/docs/sdk/v0.50/build/building-modules/module-manager) of the application is responsible for calling the `InitGenesis` method of each of the application's modules in order. This order is set by the application developer via the manager's `SetOrderGenesisMethod`, which is called in the [application's constructor function](/docs/sdk/v0.50//learn/beginner/app-anatomy#constructor-function). +The [module manager](/docs/sdk/v0.50/build/building-modules/module-manager) of the application is responsible for calling the `InitGenesis` method of each of the application's modules in order. This order is set by the application developer via the manager's `SetOrderGenesisMethod`, which is called in the [application's constructor function](/docs/sdk/v0.50/learn/beginner/app-anatomy#constructor-function). See an example of `InitGenesis` from the `auth` module: diff --git a/docs/sdk/v0.50/build/building-modules/invariants.mdx b/docs/sdk/v0.50/build/building-modules/invariants.mdx index 5db3bdf0..19808d99 100644 --- a/docs/sdk/v0.50/build/building-modules/invariants.mdx +++ b/docs/sdk/v0.50/build/building-modules/invariants.mdx @@ -497,7 +497,7 @@ error { } ``` -The `InvariantRegistry` is therefore typically instantiated by instantiating the `keeper` of the `crisis` module in the [application's constructor function](/docs/sdk/v0.50//learn/beginner/app-anatomy#constructor-function). +The `InvariantRegistry` is therefore typically instantiated by instantiating the `keeper` of the `crisis` module in the [application's constructor function](/docs/sdk/v0.50/learn/beginner/app-anatomy#constructor-function). `Invariant`s can be checked manually via [`message`s](/docs/sdk/v0.50/build/building-modules/messages-and-queries), but most often they are checked automatically at the end of each block. Here is an example from the `crisis` module: diff --git a/docs/sdk/v0.50/build/building-modules/keeper.mdx b/docs/sdk/v0.50/build/building-modules/keeper.mdx index 77cead7d..4304121f 100644 --- a/docs/sdk/v0.50/build/building-modules/keeper.mdx +++ b/docs/sdk/v0.50/build/building-modules/keeper.mdx @@ -19,9 +19,9 @@ title: Keepers The Cosmos SDK is a framework that makes it easy for developers to build complex decentralized applications from scratch, mainly by composing modules together. As the ecosystem of open-source modules for the Cosmos SDK expands, it will become increasingly likely that some of these modules contain vulnerabilities, as a result of the negligence or malice of their developer. -The Cosmos SDK adopts an [object-capabilities-based approach](/docs/sdk/v0.50//learn/advanced/ocap) to help developers better protect their application from unwanted inter-module interactions, and `keeper`s are at the core of this approach. A `keeper` can be considered quite literally to be the gatekeeper of a module's store(s). Each store (typically an [`IAVL` Store](/docs/sdk/v0.50//learn/advanced/store#iavl-store)) defined within a module comes with a `storeKey`, which grants unlimited access to it. The module's `keeper` holds this `storeKey` (which should otherwise remain unexposed), and defines [methods](#implementing-methods) for reading and writing to the store(s). +The Cosmos SDK adopts an [object-capabilities-based approach](/docs/sdk/v0.50/learn/advanced/ocap) to help developers better protect their application from unwanted inter-module interactions, and `keeper`s are at the core of this approach. A `keeper` can be considered quite literally to be the gatekeeper of a module's store(s). Each store (typically an [`IAVL` Store](/docs/sdk/v0.50/learn/advanced/store#iavl-store)) defined within a module comes with a `storeKey`, which grants unlimited access to it. The module's `keeper` holds this `storeKey` (which should otherwise remain unexposed), and defines [methods](#implementing-methods) for reading and writing to the store(s). -The core idea behind the object-capabilities approach is to only reveal what is necessary to get the work done. In practice, this means that instead of handling permissions of modules through access-control lists, module `keeper`s are passed a reference to the specific instance of the other modules' `keeper`s that they need to access (this is done in the [application's constructor function](/docs/sdk/v0.50//learn/beginner/app-anatomy#constructor-function)). As a consequence, a module can only interact with the subset of state defined in another module via the methods exposed by the instance of the other module's `keeper`. This is a great way for developers to control the interactions that their own module can have with modules developed by external developers. +The core idea behind the object-capabilities approach is to only reveal what is necessary to get the work done. In practice, this means that instead of handling permissions of modules through access-control lists, module `keeper`s are passed a reference to the specific instance of the other modules' `keeper`s that they need to access (this is done in the [application's constructor function](/docs/sdk/v0.50/learn/beginner/app-anatomy#constructor-function)). As a consequence, a module can only interact with the subset of state defined in another module via the methods exposed by the instance of the other module's `keeper`. This is a great way for developers to control the interactions that their own module can have with modules developed by external developers. ## Type Definition @@ -212,11 +212,11 @@ return valUpdates.Updates Let us go through the different parameters: * An expected `keeper` is a `keeper` external to a module that is required by the internal `keeper` of said module. External `keeper`s are listed in the internal `keeper`'s type definition as interfaces. These interfaces are themselves defined in an `expected_keepers.go` file in the root of the module's folder. In this context, interfaces are used to reduce the number of dependencies, as well as to facilitate the maintenance of the module itself. -* `storeKey`s grant access to the store(s) of the [multistore](/docs/sdk/v0.50//learn/advanced/store) managed by the module. They should always remain unexposed to external modules. -* `cdc` is the [codec](/docs/sdk/v0.50//learn/advanced/encoding) used to marshall and unmarshall structs to/from `[]byte`. The `cdc` can be any of `codec.BinaryCodec`, `codec.JSONCodec` or `codec.Codec` based on your requirements. It can be either a proto or amino codec as long as they implement these interfaces. +* `storeKey`s grant access to the store(s) of the [multistore](/docs/sdk/v0.50/learn/advanced/store) managed by the module. They should always remain unexposed to external modules. +* `cdc` is the [codec](/docs/sdk/v0.50/learn/advanced/encoding) used to marshall and unmarshall structs to/from `[]byte`. The `cdc` can be any of `codec.BinaryCodec`, `codec.JSONCodec` or `codec.Codec` based on your requirements. It can be either a proto or amino codec as long as they implement these interfaces. * The authority listed is a module account or user account that has the right to change module level parameters. Previously this was handled by the param module, which has been deprecated. -Of course, it is possible to define different types of internal `keeper`s for the same module (e.g. a read-only `keeper`). Each type of `keeper` comes with its own constructor function, which is called from the [application's constructor function](/docs/sdk/v0.50//learn/beginner/app-anatomy). This is where `keeper`s are instantiated, and where developers make sure to pass correct instances of modules' `keeper`s to other modules that require them. +Of course, it is possible to define different types of internal `keeper`s for the same module (e.g. a read-only `keeper`). Each type of `keeper` comes with its own constructor function, which is called from the [application's constructor function](/docs/sdk/v0.50/learn/beginner/app-anatomy). This is where `keeper`s are instantiated, and where developers make sure to pass correct instances of modules' `keeper`s to other modules that require them. ## Implementing Methods @@ -254,7 +254,7 @@ and the method will go through the following steps: For more, see an example of `keeper`'s [methods implementation from the `staking` module](https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/staking/keeper/keeper.go). -The [module `KVStore`](/docs/sdk/v0.50//learn/advanced/store#kvstore-and-commitkvstore-interfaces) also provides an `Iterator()` method which returns an `Iterator` object to iterate over a domain of keys. +The [module `KVStore`](/docs/sdk/v0.50/learn/advanced/store#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: diff --git a/docs/sdk/v0.50/build/building-modules/messages-and-queries.mdx b/docs/sdk/v0.50/build/building-modules/messages-and-queries.mdx index 6e735aa6..c1533884 100644 --- a/docs/sdk/v0.50/build/building-modules/messages-and-queries.mdx +++ b/docs/sdk/v0.50/build/building-modules/messages-and-queries.mdx @@ -17,13 +17,13 @@ title: Messages and Queries ## Messages -`Msg`s are objects whose end-goal is to trigger state-transitions. They are wrapped in [transactions](/docs/sdk/v0.50//learn/advanced/transactions), which may contain one or more of them. +`Msg`s are objects whose end-goal is to trigger state-transitions. They are wrapped in [transactions](/docs/sdk/v0.50/learn/advanced/transactions), which may contain one or more of them. -When a transaction is relayed from the underlying consensus engine to the Cosmos SDK application, it is first decoded by [`BaseApp`](/docs/sdk/v0.50//learn/advanced/baseapp). Then, each message contained in the transaction is extracted and routed to the appropriate module via `BaseApp`'s `MsgServiceRouter` so that it can be processed by the module's [`Msg` service](/docs/sdk/v0.50/build/building-modules/msg-services). For a more detailed explanation of the lifecycle of a transaction, click [here](/docs/sdk/v0.50//learn/beginner/tx-lifecycle). +When a transaction is relayed from the underlying consensus engine to the Cosmos SDK application, it is first decoded by [`BaseApp`](/docs/sdk/v0.50/learn/advanced/baseapp). Then, each message contained in the transaction is extracted and routed to the appropriate module via `BaseApp`'s `MsgServiceRouter` so that it can be processed by the module's [`Msg` service](/docs/sdk/v0.50/build/building-modules/msg-services). For a more detailed explanation of the lifecycle of a transaction, click [here](/docs/sdk/v0.50/learn/beginner/tx-lifecycle). ### `Msg` Services -Defining Protobuf `Msg` services is the recommended way to handle messages. A Protobuf `Msg` service should be created for each module, typically in `tx.proto` (see more info about [conventions and naming](/docs/sdk/v0.50//learn/advanced/encoding#faq)). It must have an RPC service method defined for each message in the module. +Defining Protobuf `Msg` services is the recommended way to handle messages. A Protobuf `Msg` service should be created for each module, typically in `tx.proto` (see more info about [conventions and naming](/docs/sdk/v0.50/learn/advanced/encoding#faq)). It must have an RPC service method defined for each message in the module. 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` and the RPC response `MsgResponse`. For example: @@ -256,7 +256,7 @@ In order for clients (CLI and gRPC-gateway) to have these URLs registered, the C ## Queries -A `query` is a request for information made by end-users of applications through an interface and processed by a full-node. A `query` is received by a full-node through its consensus engine and relayed to the application via the ABCI. It is then routed to the appropriate module via `BaseApp`'s `QueryRouter` so that it can be processed by the module's query service (./04-query-services.md). For a deeper look at the lifecycle of a `query`, click [here](/docs/sdk/v0.50//learn/beginner/query-lifecycle). +A `query` is a request for information made by end-users of applications through an interface and processed by a full-node. A `query` is received by a full-node through its consensus engine and relayed to the application via the ABCI. It is then routed to the appropriate module via `BaseApp`'s `QueryRouter` so that it can be processed by the module's query service (./04-query-services.md). For a deeper look at the lifecycle of a `query`, click [here](/docs/sdk/v0.50/learn/beginner/query-lifecycle). ### gRPC Queries diff --git a/docs/sdk/v0.50/build/building-modules/module-interfaces.mdx b/docs/sdk/v0.50/build/building-modules/module-interfaces.mdx index 365eef4f..a09a01ee 100644 --- a/docs/sdk/v0.50/build/building-modules/module-interfaces.mdx +++ b/docs/sdk/v0.50/build/building-modules/module-interfaces.mdx @@ -17,11 +17,11 @@ This document details how to build CLI and REST interfaces for a module. Example ## CLI -One of the main interfaces for an application is the [command-line interface](/docs/sdk/v0.50//learn/advanced/cli). This entrypoint adds commands from the application's modules enabling end-users to create [**messages**](/docs/sdk/v0.50/build/building-modules/messages-and-queries#messages) wrapped in transactions and [**queries**](/docs/sdk/v0.50/build/building-modules/messages-and-queries#messages#queries). The CLI files are typically found in the module's `./client/cli` folder. +One of the main interfaces for an application is the [command-line interface](/docs/sdk/v0.50/learn/advanced/cli). This entrypoint adds commands from the application's modules enabling end-users to create [**messages**](/docs/sdk/v0.50/build/building-modules/messages-and-queries#messages) wrapped in transactions and [**queries**](/docs/sdk/v0.50/build/building-modules/messages-and-queries#messages#queries). The CLI files are typically found in the module's `./client/cli` folder. ### Transaction Commands -In order to create messages that trigger state changes, end-users must create [transactions](/docs/sdk/v0.50//learn/advanced/transactions) that wrap and deliver the messages. A transaction command creates a transaction that includes one or more messages. +In order to create messages that trigger state changes, end-users must create [transactions](/docs/sdk/v0.50/learn/advanced/transactions) that wrap and deliver the messages. A transaction command creates a transaction that includes one or more messages. Transaction commands typically have their own `tx.go` file that lives within the module's `./client/cli` folder. The commands are specified in getter functions and the name of the function should include the name of the command. diff --git a/docs/sdk/v0.50/build/building-modules/module-manager.mdx b/docs/sdk/v0.50/build/building-modules/module-manager.mdx index 2f79134e..bd8e8a22 100644 --- a/docs/sdk/v0.50/build/building-modules/module-manager.mdx +++ b/docs/sdk/v0.50/build/building-modules/module-manager.mdx @@ -5,7 +5,7 @@ title: Module Manager **Synopsis** -Cosmos SDK modules need to implement the [`AppModule` interfaces](#application-module-interfaces), in order to be managed by the application's [module manager](#module-manager). The module manager plays an important role in [`message` and `query` routing](/docs/sdk/v0.50//learn/advanced/baseapp#routing), and allows application developers to set the order of execution of a variety of functions like [`PreBlocker`](/docs/sdk/v0.50//learn/beginner/app-anatomy#preblocker) and [`BeginBlocker` and `EndBlocker`](/docs/sdk/v0.50//learn/beginner/app-anatomy#begingblocker-and-endblocker). +Cosmos SDK modules need to implement the [`AppModule` interfaces](#application-module-interfaces), in order to be managed by the application's [module manager](#module-manager). The module manager plays an important role in [`message` and `query` routing](/docs/sdk/v0.50/learn/advanced/baseapp#routing), and allows application developers to set the order of execution of a variety of functions like [`PreBlocker`](/docs/sdk/v0.50/learn/beginner/app-anatomy#preblocker) and [`BeginBlocker` and `EndBlocker`](/docs/sdk/v0.50/learn/beginner/app-anatomy#begingblocker-and-endblocker). @@ -47,7 +47,7 @@ The above interfaces are mostly embedding smaller interfaces (extension interfac * (legacy) [`module.HasInvariants`](#hasinvariants): The extension interface for registering invariants. * (legacy) [`module.HasConsensusVersion`](#hasconsensusversion): The extension interface for declaring a module consensus version. -The `AppModuleBasic` interface exists to define independent methods of the module, i.e. those that do not depend on other modules in the application. This allows for the construction of the basic application structure early in the application definition, generally in the `init()` function of the [main application file](/docs/sdk/v0.50//learn/beginner/app-anatomy#core-application-file). +The `AppModuleBasic` interface exists to define independent methods of the module, i.e. those that do not depend on other modules in the application. This allows for the construction of the basic application structure early in the application definition, generally in the `init()` function of the [main application file](/docs/sdk/v0.50/learn/beginner/app-anatomy#core-application-file). The `AppModule` interface exists to define inter-dependent module methods. Many modules need to interact with other modules, typically through [`keeper`s](/docs/sdk/v0.50/build/building-modules/keeper), which means there is a need for an interface where modules list their `keeper`s and other methods that require a reference to another module's object. `AppModule` interface extension, such as `HasBeginBlocker` and `HasEndBlocker`, also enables the module manager to set the order of execution between module's methods like `BeginBlock` and `EndBlock`, which is important in cases where the order of execution between modules matters in the context of the application. @@ -12448,15 +12448,15 @@ return out It implements the following methods: -* `NewBasicManager(modules ...AppModuleBasic)`: Constructor function. It takes a list of the application's `AppModuleBasic` and builds a new `BasicManager`. This function is generally called in the `init()` function of [`app.go`](/docs/sdk/v0.50//learn/beginner/app-anatomy#core-application-file) to quickly initialize the independent elements of the application's modules (click [here](https://github.com/cosmos/gaia/blob/main/app/app.go#L59-L74) to see an example). +* `NewBasicManager(modules ...AppModuleBasic)`: Constructor function. It takes a list of the application's `AppModuleBasic` and builds a new `BasicManager`. This function is generally called in the `init()` function of [`app.go`](/docs/sdk/v0.50/learn/beginner/app-anatomy#core-application-file) to quickly initialize the independent elements of the application's modules (click [here](https://github.com/cosmos/gaia/blob/main/app/app.go#L59-L74) to see an example). * `NewBasicManagerFromManager(manager *Manager, customModuleBasics map[string]AppModuleBasic)`: Contructor function. It creates a new `BasicManager` from a `Manager`. The `BasicManager` will contain all `AppModuleBasic` from the `AppModule` manager using `CoreAppModuleBasicAdaptor` whenever possible. Module's `AppModuleBasic` can be overridden by passing a custom AppModuleBasic map -* `RegisterLegacyAminoCodec(cdc *codec.LegacyAmino)`: Registers the [`codec.LegacyAmino`s](/docs/sdk/v0.50//learn/advanced/encoding#amino) of each of the application's `AppModuleBasic`. This function is usually called early on in the [application's construction](/docs/sdk/v0.50//learn/beginner/app-anatomy#constructor). +* `RegisterLegacyAminoCodec(cdc *codec.LegacyAmino)`: Registers the [`codec.LegacyAmino`s](/docs/sdk/v0.50/learn/advanced/encoding#amino) of each of the application's `AppModuleBasic`. This function is usually called early on in the [application's construction](/docs/sdk/v0.50/learn/beginner/app-anatomy#constructor). * `RegisterInterfaces(registry codectypes.InterfaceRegistry)`: Registers interface types and implementations of each of the application's `AppModuleBasic`. * `DefaultGenesis(cdc codec.JSONCodec)`: Provides default genesis information for modules in the application by calling the [`DefaultGenesis(cdc codec.JSONCodec)`](/docs/sdk/v0.50/build/building-modules/genesis#defaultgenesis) function of each module. It only calls the modules that implements the `HasGenesisBasics` interfaces. * `ValidateGenesis(cdc codec.JSONCodec, txEncCfg client.TxEncodingConfig, genesis map[string]json.RawMessage)`: Validates the genesis information modules by calling the [`ValidateGenesis(codec.JSONCodec, client.TxEncodingConfig, json.RawMessage)`](/docs/sdk/v0.50/build/building-modules/genesis#validategenesis) function of modules implementing the `HasGenesisBasics` interface. * `RegisterGRPCGatewayRoutes(clientCtx client.Context, rtr *runtime.ServeMux)`: Registers gRPC routes for modules. -* `AddTxCommands(rootTxCmd *cobra.Command)`: Adds modules' transaction commands (defined as `GetTxCmd() *cobra.Command`) to the application's [`rootTxCommand`](/docs/sdk/v0.50//learn/advanced/cli#transaction-commands). This function is usually called function from the `main.go` function of the [application's command-line interface](/docs/sdk/v0.50//learn/advanced/cli). -* `AddQueryCommands(rootQueryCmd *cobra.Command)`: Adds modules' query commands (defined as `GetQueryCmd() *cobra.Command`) to the application's [`rootQueryCommand`](/docs/sdk/v0.50//learn/advanced/cli#query-commands). This function is usually called function from the `main.go` function of the [application's command-line interface](/docs/sdk/v0.50//learn/advanced/cli). +* `AddTxCommands(rootTxCmd *cobra.Command)`: Adds modules' transaction commands (defined as `GetTxCmd() *cobra.Command`) to the application's [`rootTxCommand`](/docs/sdk/v0.50/learn/advanced/cli#transaction-commands). This function is usually called function from the `main.go` function of the [application's command-line interface](/docs/sdk/v0.50/learn/advanced/cli). +* `AddQueryCommands(rootQueryCmd *cobra.Command)`: Adds modules' query commands (defined as `GetQueryCmd() *cobra.Command`) to the application's [`rootQueryCommand`](/docs/sdk/v0.50/learn/advanced/cli#query-commands). This function is usually called function from the `main.go` function of the [application's command-line interface](/docs/sdk/v0.50/learn/advanced/cli). ### `Manager` @@ -13516,26 +13516,26 @@ return out The module manager is used throughout the application whenever an action on a collection of modules is required. It implements the following methods: -* `NewManager(modules ...AppModule)`: Constructor function. It takes a list of the application's `AppModule`s and builds a new `Manager`. It is generally called from the application's main [constructor function](/docs/sdk/v0.50//learn/beginner/app-anatomy#constructor-function). -* `SetOrderInitGenesis(moduleNames ...string)`: Sets the order in which the [`InitGenesis`](/docs/sdk/v0.50/build/building-modules/genesis#initgenesis) function of each module will be called when the application is first started. This function is generally called from the application's main [constructor function](/docs/sdk/v0.50//learn/beginner/app-anatomy#constructor-function). +* `NewManager(modules ...AppModule)`: Constructor function. It takes a list of the application's `AppModule`s and builds a new `Manager`. It is generally called from the application's main [constructor function](/docs/sdk/v0.50/learn/beginner/app-anatomy#constructor-function). +* `SetOrderInitGenesis(moduleNames ...string)`: Sets the order in which the [`InitGenesis`](/docs/sdk/v0.50/build/building-modules/genesis#initgenesis) function of each module will be called when the application is first started. This function is generally called from the application's main [constructor function](/docs/sdk/v0.50/learn/beginner/app-anatomy#constructor-function). To initialize modules successfully, module dependencies should be considered. For example, the `genutil` module must occur after `staking` module so that the pools are properly initialized with tokens from genesis accounts, the `genutils` module must also occur after `auth` so that it can access the params from auth, IBC's `capability` module should be initialized before all other modules so that it can initialize any capabilities. -* `SetOrderExportGenesis(moduleNames ...string)`: Sets the order in which the [`ExportGenesis`](/docs/sdk/v0.50/build/building-modules/genesis#exportgenesis) function of each module will be called in case of an export. This function is generally called from the application's main [constructor function](/docs/sdk/v0.50//learn/beginner/app-anatomy#constructor-function). -* `SetOrderPreBlockers(moduleNames ...string)`: Sets the order in which the `PreBlock()` function of each module will be called before `BeginBlock()` of all modules. This function is generally called from the application's main [constructor function](/docs/sdk/v0.50//learn/beginner/app-anatomy#constructor-function). -* `SetOrderBeginBlockers(moduleNames ...string)`: Sets the order in which the `BeginBlock()` function of each module will be called at the beginning of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.50//learn/beginner/app-anatomy#constructor-function). -* `SetOrderEndBlockers(moduleNames ...string)`: Sets the order in which the `EndBlock()` function of each module will be called at the end of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.50//learn/beginner/app-anatomy#constructor-function). -* `SetOrderPrecommiters(moduleNames ...string)`: Sets the order in which the `Precommit()` function of each module will be called during commit of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.50//learn/beginner/app-anatomy#constructor-function). -* `SetOrderPrepareCheckStaters(moduleNames ...string)`: Sets the order in which the `PrepareCheckState()` function of each module will be called during commit of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.50//learn/beginner/app-anatomy#constructor-function). +* `SetOrderExportGenesis(moduleNames ...string)`: Sets the order in which the [`ExportGenesis`](/docs/sdk/v0.50/build/building-modules/genesis#exportgenesis) function of each module will be called in case of an export. This function is generally called from the application's main [constructor function](/docs/sdk/v0.50/learn/beginner/app-anatomy#constructor-function). +* `SetOrderPreBlockers(moduleNames ...string)`: Sets the order in which the `PreBlock()` function of each module will be called before `BeginBlock()` of all modules. This function is generally called from the application's main [constructor function](/docs/sdk/v0.50/learn/beginner/app-anatomy#constructor-function). +* `SetOrderBeginBlockers(moduleNames ...string)`: Sets the order in which the `BeginBlock()` function of each module will be called at the beginning of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.50/learn/beginner/app-anatomy#constructor-function). +* `SetOrderEndBlockers(moduleNames ...string)`: Sets the order in which the `EndBlock()` function of each module will be called at the end of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.50/learn/beginner/app-anatomy#constructor-function). +* `SetOrderPrecommiters(moduleNames ...string)`: Sets the order in which the `Precommit()` function of each module will be called during commit of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.50/learn/beginner/app-anatomy#constructor-function). +* `SetOrderPrepareCheckStaters(moduleNames ...string)`: Sets the order in which the `PrepareCheckState()` function of each module will be called during commit of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.50/learn/beginner/app-anatomy#constructor-function). * `SetOrderMigrations(moduleNames ...string)`: Sets the order of migrations to be run. If not set then migrations will be run with an order defined in `DefaultMigrationsOrder`. * `RegisterInvariants(ir sdk.InvariantRegistry)`: Registers the [invariants](/docs/sdk/v0.50/build/building-modules/invariants) of module implementing the `HasInvariants` interface. * `RegisterServices(cfg Configurator)`: Registers the services of modules implementing the `HasServices` interface. * `InitGenesis(ctx context.Context, cdc codec.JSONCodec, genesisData map[string]json.RawMessage)`: Calls the [`InitGenesis`](/docs/sdk/v0.50/build/building-modules/genesis#initgenesis) function of each module when the application is first started, in the order defined in `OrderInitGenesis`. Returns an `abci.ResponseInitChain` to the underlying consensus engine, which can contain validator updates. * `ExportGenesis(ctx context.Context, cdc codec.JSONCodec)`: Calls the [`ExportGenesis`](/docs/sdk/v0.50/build/building-modules/genesis#exportgenesis) function of each module, in the order defined in `OrderExportGenesis`. The export constructs a genesis file from a previously existing state, and is mainly used when a hard-fork upgrade of the chain is required. * `ExportGenesisForModules(ctx context.Context, cdc codec.JSONCodec, modulesToExport []string)`: Behaves the same as `ExportGenesis`, except takes a list of modules to export. -* `BeginBlock(ctx context.Context) error`: At the beginning of each block, this function is called from [`BaseApp`](/docs/sdk/v0.50//learn/advanced/baseapp#beginblock) and, in turn, calls the [`BeginBlock`](/docs/sdk/v0.50/build/building-modules/beginblock-endblock) function of each modules implementing the `appmodule.HasBeginBlocker` interface, in the order defined in `OrderBeginBlockers`. It creates a child [context](/docs/sdk/v0.50//learn/advanced/context) with an event manager to aggregate [events](/docs/sdk/v0.50//learn/advanced/events) emitted from each modules. -* `EndBlock(ctx context.Context) error`: At the end of each block, this function is called from [`BaseApp`](/docs/sdk/v0.50//learn/advanced/baseapp#endblock) and, in turn, calls the [`EndBlock`](/docs/sdk/v0.50/build/building-modules/beginblock-endblock) function of each modules implementing the `appmodule.HasEndBlocker` interface, in the order defined in `OrderEndBlockers`. It creates a child [context](/docs/sdk/v0.50//learn/advanced/context) with an event manager to aggregate [events](/docs/sdk/v0.50//learn/advanced/events) emitted from all modules. The function returns an `abci` which contains the aforementioned events, as well as validator set updates (if any). -* `EndBlock(context.Context) ([]abci.ValidatorUpdate, error)`: At the end of each block, this function is called from [`BaseApp`](/docs/sdk/v0.50//learn/advanced/baseapp#endblock) and, in turn, calls the [`EndBlock`](/docs/sdk/v0.50/build/building-modules/beginblock-endblock) function of each modules implementing the `module.HasABCIEndBlock` interface, in the order defined in `OrderEndBlockers`. It creates a child [context](/docs/sdk/v0.50//learn/advanced/context) with an event manager to aggregate [events](/docs/sdk/v0.50//learn/advanced/events) emitted from all modules. The function returns an `abci` which contains the aforementioned events, as well as validator set updates (if any). -* `Precommit(ctx context.Context)`: During [`Commit`](/docs/sdk/v0.50//learn/advanced/baseapp#commit), this function is called from `BaseApp` immediately before the [`deliverState`](/docs/sdk/v0.50//learn/advanced/baseapp#state-updates) is written to the underlying [`rootMultiStore`](/docs/sdk/v0.50//learn/advanced/store#commitmultistore) and, in turn calls the `Precommit` function of each modules implementing the `HasPrecommit` interface, in the order defined in `OrderPrecommiters`. It creates a child [context](/docs/sdk/v0.50//learn/advanced/context) where the underlying `CacheMultiStore` is that of the newly committed block's [`finalizeblockstate`](/docs/sdk/v0.50//learn/advanced/baseapp#state-updates). -* `PrepareCheckState(ctx context.Context)`: During [`Commit`](/docs/sdk/v0.50//learn/advanced/baseapp#commit), this function is called from `BaseApp` immediately after the [`deliverState`](/docs/sdk/v0.50//learn/advanced/baseapp#state-updates) is written to the underlying [`rootMultiStore`](/docs/sdk/v0.50//learn/advanced/store#commitmultistore) and, in turn calls the `PrepareCheckState` function of each module implementing the `HasPrepareCheckState` interface, in the order defined in `OrderPrepareCheckStaters`. It creates a child [context](/docs/sdk/v0.50//learn/advanced/context) where the underlying `CacheMultiStore` is that of the next block's [`checkState`](/docs/sdk/v0.50//learn/advanced/baseapp#state-updates). Writes to this state will be present in the [`checkState`](/docs/sdk/v0.50//learn/advanced/baseapp#state-updates) of the next block, and therefore this method can be used to prepare the `checkState` for the next block. +* `BeginBlock(ctx context.Context) error`: At the beginning of each block, this function is called from [`BaseApp`](/docs/sdk/v0.50/learn/advanced/baseapp#beginblock) and, in turn, calls the [`BeginBlock`](/docs/sdk/v0.50/build/building-modules/beginblock-endblock) function of each modules implementing the `appmodule.HasBeginBlocker` interface, in the order defined in `OrderBeginBlockers`. It creates a child [context](/docs/sdk/v0.50/learn/advanced/context) with an event manager to aggregate [events](/docs/sdk/v0.50/learn/advanced/events) emitted from each modules. +* `EndBlock(ctx context.Context) error`: At the end of each block, this function is called from [`BaseApp`](/docs/sdk/v0.50/learn/advanced/baseapp#endblock) and, in turn, calls the [`EndBlock`](/docs/sdk/v0.50/build/building-modules/beginblock-endblock) function of each modules implementing the `appmodule.HasEndBlocker` interface, in the order defined in `OrderEndBlockers`. It creates a child [context](/docs/sdk/v0.50/learn/advanced/context) with an event manager to aggregate [events](/docs/sdk/v0.50/learn/advanced/events) emitted from all modules. The function returns an `abci` which contains the aforementioned events, as well as validator set updates (if any). +* `EndBlock(context.Context) ([]abci.ValidatorUpdate, error)`: At the end of each block, this function is called from [`BaseApp`](/docs/sdk/v0.50/learn/advanced/baseapp#endblock) and, in turn, calls the [`EndBlock`](/docs/sdk/v0.50/build/building-modules/beginblock-endblock) function of each modules implementing the `module.HasABCIEndBlock` interface, in the order defined in `OrderEndBlockers`. It creates a child [context](/docs/sdk/v0.50/learn/advanced/context) with an event manager to aggregate [events](/docs/sdk/v0.50/learn/advanced/events) emitted from all modules. The function returns an `abci` which contains the aforementioned events, as well as validator set updates (if any). +* `Precommit(ctx context.Context)`: During [`Commit`](/docs/sdk/v0.50/learn/advanced/baseapp#commit), this function is called from `BaseApp` immediately before the [`deliverState`](/docs/sdk/v0.50/learn/advanced/baseapp#state-updates) is written to the underlying [`rootMultiStore`](/docs/sdk/v0.50/learn/advanced/store#commitmultistore) and, in turn calls the `Precommit` function of each modules implementing the `HasPrecommit` interface, in the order defined in `OrderPrecommiters`. It creates a child [context](/docs/sdk/v0.50/learn/advanced/context) where the underlying `CacheMultiStore` is that of the newly committed block's [`finalizeblockstate`](/docs/sdk/v0.50/learn/advanced/baseapp#state-updates). +* `PrepareCheckState(ctx context.Context)`: During [`Commit`](/docs/sdk/v0.50/learn/advanced/baseapp#commit), this function is called from `BaseApp` immediately after the [`deliverState`](/docs/sdk/v0.50/learn/advanced/baseapp#state-updates) is written to the underlying [`rootMultiStore`](/docs/sdk/v0.50/learn/advanced/store#commitmultistore) and, in turn calls the `PrepareCheckState` function of each module implementing the `HasPrepareCheckState` interface, in the order defined in `OrderPrepareCheckStaters`. It creates a child [context](/docs/sdk/v0.50/learn/advanced/context) where the underlying `CacheMultiStore` is that of the next block's [`checkState`](/docs/sdk/v0.50/learn/advanced/baseapp#state-updates). Writes to this state will be present in the [`checkState`](/docs/sdk/v0.50/learn/advanced/baseapp#state-updates) of the next block, and therefore this method can be used to prepare the `checkState` for the next block. Here's an example of a concrete integration within an `simapp`: diff --git a/docs/sdk/v0.50/build/building-modules/msg-services.mdx b/docs/sdk/v0.50/build/building-modules/msg-services.mdx index 936ef394..b07ae4e9 100644 --- a/docs/sdk/v0.50/build/building-modules/msg-services.mdx +++ b/docs/sdk/v0.50/build/building-modules/msg-services.mdx @@ -5,7 +5,7 @@ title: 'Msg Services' **Synopsis** -A Protobuf `Msg` service processes [messages](/docs/sdk/v0.50/build/building-modules/messages-and-queries). Protobuf `Msg` services are specific to the module in which they are defined, and only process messages defined within the said module. They are called from `BaseApp` during [`DeliverTx`](/docs/sdk/v0.50//learn/advanced/baseapp#delivertx). +A Protobuf `Msg` service processes [messages](/docs/sdk/v0.50/build/building-modules/messages-and-queries). Protobuf `Msg` services are specific to the module in which they are defined, and only process messages defined within the said module. They are called from `BaseApp` during [`DeliverTx`](/docs/sdk/v0.50/learn/advanced/baseapp#delivertx). @@ -3101,7 +3101,7 @@ After the validation is successful, the `msgServer` method uses the [`keeper`](/ ### Events -Before returning, `msgServer` methods generally emit one or more [events](/docs/sdk/v0.50//learn/advanced/events) by using the `EventManager` held in the `ctx`. Use the new `EmitTypedEvent` function that uses protobuf-based event types: +Before returning, `msgServer` methods generally emit one or more [events](/docs/sdk/v0.50/learn/advanced/events) by using the `EventManager` held in the `ctx`. Use the new `EmitTypedEvent` function that uses protobuf-based event types: ```go ctx.EventManager().EmitTypedEvent( @@ -3122,7 +3122,7 @@ ctx.EventManager().EmitEvent( ) ``` -These events are relayed back to the underlying consensus engine and can be used by service providers to implement services around the application. Click [here](/docs/sdk/v0.50//learn/advanced/events) to learn more about events. +These events are relayed back to the underlying consensus engine and can be used by service providers to implement services around the application. Click [here](/docs/sdk/v0.50/learn/advanced/events) to learn more about events. 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 context.Context, res proto.Message, err error)`: @@ -3356,7 +3356,7 @@ This diagram shows a typical structure of a Protobuf `Msg` service, and how the ## Telemetry -New [telemetry metrics](/docs/sdk/v0.50//learn/advanced/telemetry) can be created from `msgServer` methods when handling messages. +New [telemetry metrics](/docs/sdk/v0.50/learn/advanced/telemetry) can be created from `msgServer` methods when handling messages. This is an example from the `x/auth/vesting` module: diff --git a/docs/sdk/v0.50/build/building-modules/preblock.mdx b/docs/sdk/v0.50/build/building-modules/preblock.mdx index 137d8809..b5174390 100644 --- a/docs/sdk/v0.50/build/building-modules/preblock.mdx +++ b/docs/sdk/v0.50/build/building-modules/preblock.mdx @@ -4,7 +4,7 @@ title: PreBlocker **Synopsis** -`PreBlocker` is optional method module developers can implement in their module. They will be triggered before [`BeginBlock`](/docs/sdk/v0.50//learn/advanced/baseapp#beginblock). +`PreBlocker` is optional method module developers can implement in their module. They will be triggered before [`BeginBlock`](/docs/sdk/v0.50/learn/advanced/baseapp#beginblock). diff --git a/docs/sdk/v0.50/build/building-modules/query-services.mdx b/docs/sdk/v0.50/build/building-modules/query-services.mdx index 0b9248aa..d2888d68 100644 --- a/docs/sdk/v0.50/build/building-modules/query-services.mdx +++ b/docs/sdk/v0.50/build/building-modules/query-services.mdx @@ -5,7 +5,7 @@ title: Query Services **Synopsis** -A Protobuf Query service processes [`queries`](/docs/sdk/v0.50/build/building-modules/messages-and-queries#queries). Query services are specific to the module in which they are defined, and only process `queries` defined within said module. They are called from `BaseApp`'s [`Query` method](/docs/sdk/v0.50//learn/advanced/baseapp#query). +A Protobuf Query service processes [`queries`](/docs/sdk/v0.50/build/building-modules/messages-and-queries#queries). Query services are specific to the module in which they are defined, and only process `queries` defined within said module. They are called from `BaseApp`'s [`Query` method](/docs/sdk/v0.50/learn/advanced/baseapp#query). diff --git a/docs/sdk/v0.50/build/building-modules/simulator.mdx b/docs/sdk/v0.50/build/building-modules/simulator.mdx index 873d4cd2..b3381cc4 100644 --- a/docs/sdk/v0.50/build/building-modules/simulator.mdx +++ b/docs/sdk/v0.50/build/building-modules/simulator.mdx @@ -5,7 +5,7 @@ title: Module Simulation **Pre-requisite Readings** -* [Cosmos Blockchain Simulator](/docs/sdk/v0.50//learn/advanced/simulation) +* [Cosmos Blockchain Simulator](/docs/sdk/v0.50/learn/advanced/simulation) ## Synopsis @@ -60,7 +60,7 @@ Operations are one of the crucial parts of the Cosmos SDK simulation. They are t (`Msg`) that are simulated with random field values. The sender of the operation is also assigned randomly. -Operations on the simulation are simulated using the full [transaction cycle](/docs/sdk/v0.50//learn/advanced/transactions) of a +Operations on the simulation are simulated using the full [transaction cycle](/docs/sdk/v0.50/learn/advanced/transactions) of a `ABCI` application that exposes the `BaseApp`. Shown below is how weights are set: diff --git a/docs/sdk/v0.50/build/building-modules/upgrade.mdx b/docs/sdk/v0.50/build/building-modules/upgrade.mdx index 3b20228d..09f7bcbc 100644 --- a/docs/sdk/v0.50/build/building-modules/upgrade.mdx +++ b/docs/sdk/v0.50/build/building-modules/upgrade.mdx @@ -4,13 +4,13 @@ title: Upgrading Modules **Synopsis** -[In-Place Store Migrations](/docs/sdk/v0.50//learn/advanced/upgrade) allow your modules to upgrade to new versions that include breaking changes. This document outlines how to build modules to take advantage of this functionality. +[In-Place Store Migrations](/docs/sdk/v0.50/learn/advanced/upgrade) allow your modules to upgrade to new versions that include breaking changes. This document outlines how to build modules to take advantage of this functionality. **Pre-requisite Readings** -* [In-Place Store Migration](/docs/sdk/v0.50//learn/advanced/upgrade) +* [In-Place Store Migration](/docs/sdk/v0.50/learn/advanced/upgrade) diff --git a/docs/sdk/v0.50/learn/advanced/baseapp.mdx b/docs/sdk/v0.50/learn/advanced/baseapp.mdx index 912d3d7e..04cd72d3 100644 --- a/docs/sdk/v0.50/learn/advanced/baseapp.mdx +++ b/docs/sdk/v0.50/learn/advanced/baseapp.mdx @@ -1496,17 +1496,17 @@ When messages and queries are received by the application, they must be routed t ### `Msg` Service Router -[`sdk.Msg`s](/docs/sdk/v0.50//build/building-modules/messages-and-queries#messages) need to be routed after they are extracted from transactions, which are sent from the underlying CometBFT engine via the [`CheckTx`](#checktx) and [`FinalizeBlock`](#finalizeblock) 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. +[`sdk.Msg`s](/docs/sdk/v0.50/build/building-modules/messages-and-queries#messages) need to be routed after they are extracted from transactions, which are sent from the underlying CometBFT engine via the [`CheckTx`](#checktx) and [`FinalizeBlock`](#finalizeblock) 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.50.0-alpha.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.50.0-alpha.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](/docs/sdk/v0.50//build/building-modules/module-manager#manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.50/learn/beginner/app-anatomy#constructor-function). +The application's `msgServiceRouter` is initialized with all the routes using the application's [module manager](/docs/sdk/v0.50/build/building-modules/module-manager#manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.50/learn/beginner/app-anatomy#constructor-function). ### gRPC Query Router -Similar to `sdk.Msg`s, [`queries`](/docs/sdk/v0.50//build/building-modules/messages-and-queries#queries) need to be routed to the appropriate module's [`Query` service](/docs/sdk/v0.50//build/building-modules/query-services). To do so, `BaseApp` holds a `grpcQueryRouter`, which maps modules' fully-qualified service methods (`string`, defined in their Protobuf `Query` gRPC) to their `QueryServer` implementation. The `grpcQueryRouter` is called during the initial stages of query processing, which can be either by directly sending a gRPC query to the gRPC endpoint, or via the [`Query` ABCI message](#query) on the CometBFT RPC endpoint. +Similar to `sdk.Msg`s, [`queries`](/docs/sdk/v0.50/build/building-modules/messages-and-queries#queries) need to be routed to the appropriate module's [`Query` service](/docs/sdk/v0.50/build/building-modules/query-services). To do so, `BaseApp` holds a `grpcQueryRouter`, which maps modules' fully-qualified service methods (`string`, defined in their Protobuf `Query` gRPC) to their `QueryServer` implementation. The `grpcQueryRouter` is called during the initial stages of query processing, which can be either by directly sending a gRPC query to the gRPC endpoint, or via the [`Query` ABCI message](#query) on the CometBFT RPC endpoint. -Just like the `msgServiceRouter`, the `grpcQueryRouter` is initialized with all the query routes using the application's [module manager](/docs/sdk/v0.50//build/building-modules/module-manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.50/learn/beginner/app-anatomy#app-constructor). +Just like the `msgServiceRouter`, the `grpcQueryRouter` is initialized with all the query routes using the application's [module manager](/docs/sdk/v0.50/build/building-modules/module-manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.50/learn/beginner/app-anatomy#app-constructor). ## Main ABCI 2.0 Messages @@ -3335,7 +3335,7 @@ Click [here](/docs/sdk/v0.50/learn/beginner/gas-fees#antehandler) for more on th `RunMsgs` is called from `RunTx` with `runTxModeCheck` as parameter to check the existence of a route for each message the transaction, and with `execModeFinalize` to actually process the `sdk.Msg`s. -First, it retrieves the `sdk.Msg`'s fully-qualified type name, by checking the `type_url` of the Protobuf `Any` representing the `sdk.Msg`. Then, using the application's [`msgServiceRouter`](#msg-service-router), it checks for the existence of `Msg` service method related to that `type_url`. At this point, if `mode == runTxModeCheck`, `RunMsgs` returns. Otherwise, if `mode == execModeFinalize`, the [`Msg` service](/docs/sdk/v0.50//build/building-modules/msg-services) RPC is executed, before `RunMsgs` returns. +First, it retrieves the `sdk.Msg`'s fully-qualified type name, by checking the `type_url` of the Protobuf `Any` representing the `sdk.Msg`. Then, using the application's [`msgServiceRouter`](#msg-service-router), it checks for the existence of `Msg` service method related to that `type_url`. At this point, if `mode == runTxModeCheck`, `RunMsgs` returns. Otherwise, if `mode == execModeFinalize`, the [`Msg` service](/docs/sdk/v0.50/build/building-modules/msg-services) RPC is executed, before `RunMsgs` returns. ### PostHandler @@ -3378,7 +3378,7 @@ The [`InitChain` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x * [`checkState` and `finalizeBlockState`](#state-updates) via `setState`. * The [block gas meter](/docs/sdk/v0.50/learn/beginner/gas-fees#block-gas-meter), with infinite gas to process genesis transactions. -Finally, the `InitChain(req abci.RequestInitChain)` method of `BaseApp` calls the [`initChainer()`](/docs/sdk/v0.50/learn/beginner/app-anatomy#initchainer) of the application in order to initialize the main state of the application from the `genesis file` and, if defined, call the [`InitGenesis`](/docs/sdk/v0.50//build/building-modules/genesis#initgenesis) function of each of the application's modules. +Finally, the `InitChain(req abci.RequestInitChain)` method of `BaseApp` calls the [`initChainer()`](/docs/sdk/v0.50/learn/beginner/app-anatomy#initchainer) of the application in order to initialize the main state of the application from the `genesis file` and, if defined, call the [`InitGenesis`](/docs/sdk/v0.50/build/building-modules/genesis#initgenesis) function of each of the application's modules. ### FinalizeBlock @@ -4703,7 +4703,7 @@ return legacyVotes #### PreBlock -* Run the application's [`preBlocker()`](/docs/sdk/v0.50/learn/beginner/app-anatomy#preblocker), which mainly runs the [`PreBlocker()`](/docs/sdk/v0.50//build/building-modules/preblock#preblock) method of each of the modules. +* Run the application's [`preBlocker()`](/docs/sdk/v0.50/learn/beginner/app-anatomy#preblocker), which mainly runs the [`PreBlocker()`](/docs/sdk/v0.50/build/building-modules/preblock#preblock) method of each of the modules. #### BeginBlock @@ -5997,7 +5997,7 @@ return legacyVotes * Initialize the [block gas meter](/docs/sdk/v0.50/learn/beginner/gas-fees#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()`](/docs/sdk/v0.50/learn/beginner/app-anatomy#beginblocker-and-endblocker), which mainly runs the [`BeginBlocker()`](/docs/sdk/v0.50//build/building-modules/beginblock-endblock#beginblock) method of each of the modules. +* Run the application's [`beginBlocker()`](/docs/sdk/v0.50/learn/beginner/app-anatomy#beginblocker-and-endblocker), which mainly runs the [`BeginBlocker()`](/docs/sdk/v0.50/build/building-modules/beginblock-endblock#beginblock) method of each of the modules. * Set the [`VoteInfos`](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_methods.md#voteinfo) of the application, i.e. the list of validators whose *precommit* for the previous block was included by the proposer of the current block. This information is carried into the [`Context`](/docs/sdk/v0.50/learn/advanced/context) so that it can be used during transaction execution and EndBlock. @@ -7294,7 +7294,7 @@ error { Transaction execution within `FinalizeBlock` performs the **exact same steps as `CheckTx`**, with a little caveat at step 3 and the addition of a fifth step: 1. The `AnteHandler` does **not** check that the transaction's `gas-prices` is sufficient. That is because the `min-gas-prices` value `gas-prices` is checked against is local to the node, and therefore what is enough for one full-node might not be for another. This means that the proposer can potentially include transactions for free, although they are not incentivised to do so, as they earn a bonus on the total fee of the block they propose. -2. For each `sdk.Msg` in the transaction, route to the appropriate module's Protobuf [`Msg` service](/docs/sdk/v0.50//build/building-modules/msg-services). Additional *stateful* checks are performed, and the branched multistore held in `finalizeBlockState`'s `context` is updated by the module's `keeper`. If the `Msg` service returns successfully, the branched multistore held in `context` is written to `finalizeBlockState` `CacheMultiStore`. +2. For each `sdk.Msg` in the transaction, route to the appropriate module's Protobuf [`Msg` service](/docs/sdk/v0.50/build/building-modules/msg-services). Additional *stateful* checks are performed, and the branched multistore held in `finalizeBlockState`'s `context` is updated by the module's `keeper`. If the `Msg` service returns successfully, the branched multistore held in `context` is written to `finalizeBlockState` `CacheMultiStore`. 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: @@ -8971,7 +8971,7 @@ The [`Info` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x/spec ### Query -The [`Query` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_basic_concepts.md#info-methods) is used to serve queries received from the underlying consensus engine, including queries received via RPC like CometBFT RPC. It used to be the main entrypoint to build interfaces with the application, but with the introduction of [gRPC queries](/docs/sdk/v0.50//build/building-modules/query-services) in Cosmos SDK v0.40, its usage is more limited. The application must respect a few rules when implementing the `Query` method, which are outlined [here](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_app_requirements.md#query). +The [`Query` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_basic_concepts.md#info-methods) is used to serve queries received from the underlying consensus engine, including queries received via RPC like CometBFT RPC. It used to be the main entrypoint to build interfaces with the application, but with the introduction of [gRPC queries](/docs/sdk/v0.50/build/building-modules/query-services) in Cosmos SDK v0.40, its usage is more limited. The application must respect a few rules when implementing the `Query` method, which are outlined [here](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_app_requirements.md#query). Each CometBFT `query` comes with a `path`, which is a `string` which denotes what to query. If the `path` matches a gRPC fully-qualified service method, then `BaseApp` will defer the query to the `grpcQueryRouter` and let it handle it like explained [above](#grpc-query-router). Otherwise, the `path` represents a query that is not (yet) handled by the gRPC router. `BaseApp` splits the `path` string with the `/` delimiter. By convention, the first element of the split string (`split[0]`) contains the category of `query` (`app`, `p2p`, `store` or `custom` ). The `BaseApp` implementation of the `Query(req abci.RequestQuery)` method is a simple dispatcher serving these 4 main categories of queries: diff --git a/docs/sdk/v0.50/learn/advanced/cli.mdx b/docs/sdk/v0.50/learn/advanced/cli.mdx index 3d9169d1..33a2e965 100644 --- a/docs/sdk/v0.50/learn/advanced/cli.mdx +++ b/docs/sdk/v0.50/learn/advanced/cli.mdx @@ -4,7 +4,7 @@ title: Command-Line Interface **Synopsis** -This document describes how command-line interface (CLI) works on a high-level, for an [**application**](/docs/sdk/v0.50/learn/beginner/app-anatomy). A separate document for implementing a CLI for a Cosmos SDK [**module**](/docs/sdk/v0.50//build/building-modules/intro) can be found [here](/docs/sdk/v0.50//build/building-modules/module-interfaces#cli). +This document describes how command-line interface (CLI) works on a high-level, for an [**application**](/docs/sdk/v0.50/learn/beginner/app-anatomy). A separate document for implementing a CLI for a Cosmos SDK [**module**](/docs/sdk/v0.50/build/building-modules/intro) can be found [here](/docs/sdk/v0.50/build/building-modules/module-interfaces#cli). ## Command-Line Interface @@ -23,7 +23,7 @@ The first four strings specify the command: * The root command for the entire application `simd`. * The subcommand `tx`, which contains all commands that let users create transactions. -* The subcommand `bank` to indicate which module to route the command to ([`x/bank`](/docs/sdk/v0.50//build/modules/bank/README) module in this case). +* The subcommand `bank` to indicate which module to route the command to ([`x/bank`](/docs/sdk/v0.50/build/modules/bank/README) module in this case). * The type of transaction `send`. The next two strings are arguments: the `from_address` the user wishes to send from, the `to_address` of the recipient, and the `amount` they want to send. Finally, the last few strings of the command are optional flags to indicate how much the user is willing to pay in fees (calculated using the amount of gas used to execute the transaction and the gas prices provided by the user). @@ -74,7 +74,7 @@ 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`](/docs/sdk/v0.50/learn/advanced/node). The Status of a node includes `NodeInfo`,`SyncInfo` and `ValidatorInfo`. -* **Keys** [commands](https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.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 ` 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.50.0-alpha.0/client/keys/add.go). For more details about usage of `--keyring-backend` for storage of key credentials look at the [keyring docs](/docs/sdk/v0.50//user/run-node/keyring). +* **Keys** [commands](https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.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 ` 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.50.0-alpha.0/client/keys/add.go). For more details about usage of `--keyring-backend` for storage of key credentials look at the [keyring docs](/docs/sdk/v0.50/user/run-node/keyring). * **Server** commands from the Cosmos SDK server package. These commands are responsible for providing the mechanisms necessary to start an ABCI CometBFT application and provides the CLI framework (based on [cobra](https://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. Learn more [here](https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/server). * [**Transaction**](#transaction-commands) commands. @@ -1217,7 +1217,7 @@ The root-level `status` and `keys` subcommands are common across most applicatio ### Transaction Commands -[Transactions](/docs/sdk/v0.50/learn/advanced/transactions) are objects wrapping [`Msg`s](/docs/sdk/v0.50//build/building-modules/messages-and-queries#messages) that trigger state changes. To enable the creation of transactions using the CLI interface, a function `txCommand` is generally added to the `rootCmd`: +[Transactions](/docs/sdk/v0.50/learn/advanced/transactions) are objects wrapping [`Msg`s](/docs/sdk/v0.50/build/building-modules/messages-and-queries#messages) that trigger state changes. To enable the creation of transactions using the CLI interface, a function `txCommand` is generally added to the `rootCmd`: ```go expandable //go:build !app_v1 @@ -1594,9 +1594,9 @@ return simApp.ExportAppStateAndValidators(forZeroHeight, jailAllowedAddrs, modul This `txCommand` function adds all the transaction available to end-users for the application. This typically includes: -* **Sign command** from the [`auth`](/docs/sdk/v0.50//build/modules/auth/README) module that signs messages in a transaction. To enable multisig, add the `auth` module's `MultiSign` command. Since every transaction requires some sort of signature in order to be valid, the signing command is necessary for every application. +* **Sign command** from the [`auth`](/docs/sdk/v0.50/build/modules/auth/README) module that signs messages in a transaction. To enable multisig, add the `auth` module's `MultiSign` command. Since every transaction requires some sort of signature in order to be valid, the signing command is necessary for every application. * **Broadcast command** from the Cosmos SDK client tools, to broadcast transactions. -* **All [module transaction commands](/docs/sdk/v0.50//build/building-modules/module-interfaces#transaction-commands)** the application is dependent on, retrieved by using the [basic module manager's](/docs/sdk/v0.50//build/building-modules/module-manager#basic-manager) `AddTxCommands()` function, or enhanced by [AutoCLI](https://docs.cosmos.network/main/core/autocli). +* **All [module transaction commands](/docs/sdk/v0.50/build/building-modules/module-interfaces#transaction-commands)** the application is dependent on, retrieved by using the [basic module manager's](/docs/sdk/v0.50/build/building-modules/module-manager#basic-manager) `AddTxCommands()` function, or enhanced by [AutoCLI](https://docs.cosmos.network/main/core/autocli). Here is an example of a `txCommand` aggregating these subcommands from the `simapp` application: @@ -1980,7 +1980,7 @@ Read more about [AutoCLI](https://docs.cosmos.network/main/core/autocli) in its ### Query Commands -[**Queries**](/docs/sdk/v0.50//build/building-modules/messages-and-queries#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`: +[**Queries**](/docs/sdk/v0.50/build/building-modules/messages-and-queries#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`: ```go expandable //go:build !app_v1 @@ -2361,7 +2361,7 @@ This `queryCommand` function adds all the queries available to end-users for the * **Account command** from the `auth` module, which displays the state (e.g. account balance) of an account given an address. * **Validator command** from the Cosmos SDK rpc client tools, which displays the validator set of a given height. * **Block command** from the Cosmos SDK RPC client tools, which displays the block data for a given height. -* **All [module query commands](/docs/sdk/v0.50//build/building-modules/module-interfaces#query-commands)** the application is dependent on, retrieved by using the [basic module manager's](/docs/sdk/v0.50//build/building-modules/module-manager#basic-manager) `AddQueryCommands()` function, or enhanced by [AutoCLI](https://docs.cosmos.network/main/core/autocli). +* **All [module query commands](/docs/sdk/v0.50/build/building-modules/module-interfaces#query-commands)** the application is dependent on, retrieved by using the [basic module manager's](/docs/sdk/v0.50/build/building-modules/module-manager#basic-manager) `AddQueryCommands()` function, or enhanced by [AutoCLI](https://docs.cosmos.network/main/core/autocli). Here is an example of a `queryCommand` aggregating subcommands from the `simapp` application: @@ -2745,11 +2745,11 @@ Read more about [AutoCLI](https://docs.cosmos.network/main/core/autocli) in its ## Flags -Flags are used to modify commands; developers can include them in a `flags.go` file with their CLI. Users can explicitly include them in commands or pre-configure them by inside their [`app.toml`](/docs/sdk/v0.50//user/run-node/run-node#configuring-the-node-using-apptoml-and-configtoml). Commonly pre-configured flags include the `--node` to connect to and `--chain-id` of the blockchain the user wishes to interact with. +Flags are used to modify commands; developers can include them in a `flags.go` file with their CLI. Users can explicitly include them in commands or pre-configure them by inside their [`app.toml`](/docs/sdk/v0.50/user/run-node/run-node#configuring-the-node-using-apptoml-and-configtoml). Commonly pre-configured flags include the `--node` to connect to and `--chain-id` of the blockchain the user wishes to interact with. A *persistent* flag (as opposed to a *local* flag) added to a command transcends all of its children: subcommands will inherit the configured values for these flags. Additionally, all flags have default values when they are added to commands; some toggle an option off but others are empty values that the user needs to override to create valid commands. A flag can be explicitly marked as *required* so that an error is automatically thrown if the user does not provide a value, but it is also acceptable to handle unexpected missing flags differently. -Flags are added to commands directly (generally in the [module's CLI file](/docs/sdk/v0.50//build/building-modules/module-interfaces#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. +Flags are added to commands directly (generally in the [module's CLI file](/docs/sdk/v0.50/build/building-modules/module-interfaces#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. ## Environment variables diff --git a/docs/sdk/v0.50/learn/advanced/encoding.mdx b/docs/sdk/v0.50/learn/advanced/encoding.mdx index f9d91bcc..f5966e92 100644 --- a/docs/sdk/v0.50/learn/advanced/encoding.mdx +++ b/docs/sdk/v0.50/learn/advanced/encoding.mdx @@ -47,7 +47,7 @@ via Protobuf. This means that modules may use Protobuf encoding, but the types m implement `ProtoMarshaler`. If modules wish to avoid implementing this interface for their types, this is autogenerated via [buf](https://buf.build/) -If modules use [Collections](/docs/sdk/v0.50//build/packages/collections) or [ORM](/docs/sdk/v0.50//build/packages/orm), encoding and decoding are handled, marshal and unmarshal should not be handled manually unless for specific cases identified by the developer. +If modules use [Collections](/docs/sdk/v0.50/build/packages/collections) or [ORM](/docs/sdk/v0.50/build/packages/orm), encoding and decoding are handled, marshal and unmarshal should not be handled manually unless for specific cases identified by the developer. ### Gogoproto @@ -237,7 +237,7 @@ return "" } ``` -A standard implementation of both these objects can be found in the [`auth/tx` module](/docs/sdk/v0.50//build/modules/auth/tx): +A standard implementation of both these objects can be found in the [`auth/tx` module](/docs/sdk/v0.50/build/modules/auth/tx): ```go expandable package tx @@ -473,7 +473,7 @@ return nil, fmt.Errorf("expected %T, got %T", &wrapper{ } ``` -See [ADR-020](/docs/sdk/v0.50//architecture/adr-020-protobuf-transaction-encoding) for details of how a transaction is encoded. +See [ADR-020](/docs/sdk/v0.50/architecture/adr-020-protobuf-transaction-encoding) for details of how a transaction is encoded. ### Interface Encoding and Usage of `Any` @@ -488,7 +488,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](/docs/sdk/v0.50//build/modules/auth/vesting), 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? +In this `Profile` example, we hardcoded `account` as a `BaseAccount`. However, there are several other types of [user accounts related to vesting](/docs/sdk/v0.50/build/modules/auth/vesting), 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? ```go expandable package types @@ -558,7 +558,7 @@ bool } ``` -In [ADR-019](/docs/sdk/v0.50//architecture/adr-019-protobuf-state-encoding), 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: +In [ADR-019](/docs/sdk/v0.50/architecture/adr-019-protobuf-state-encoding), 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: ```protobuf message Profile { @@ -632,7 +632,7 @@ return nil The `UnpackInterfaces` gets called recursively on all structs implementing this method, to allow all `Any`s to have their `GetCachedValue()` correctly populated. -For more information about interface encoding, and especially on `UnpackInterfaces` and how the `Any`'s `type_url` gets resolved using the `InterfaceRegistry`, please refer to [ADR-019](/docs/sdk/v0.50//architecture/adr-019-protobuf-state-encoding). +For more information about interface encoding, and especially on `UnpackInterfaces` and how the `Any`'s `type_url` gets resolved using the `InterfaceRegistry`, please refer to [ADR-019](/docs/sdk/v0.50/architecture/adr-019-protobuf-state-encoding). #### `Any` Encoding in the Cosmos SDK @@ -1399,14 +1399,14 @@ import ( Protobuf types can be defined to encode: * state -* [`Msg`s](/docs/sdk/v0.50//build/building-modules/messages-and-queries#messages) -* [Query services](/docs/sdk/v0.50//build/building-modules/query-services) -* [genesis](/docs/sdk/v0.50//build/building-modules/genesis) +* [`Msg`s](/docs/sdk/v0.50/build/building-modules/messages-and-queries#messages) +* [Query services](/docs/sdk/v0.50/build/building-modules/query-services) +* [genesis](/docs/sdk/v0.50/build/building-modules/genesis) #### Naming and conventions We encourage developers to follow industry guidelines: [Protocol Buffers style guide](https://developers.google.com/protocol-buffers/docs/style) -and [Buf](https://buf.build/docs/style-guide), see more details in [ADR 023](/docs/sdk/v0.50//architecture/adr-023-protobuf-naming) +and [Buf](https://buf.build/docs/style-guide), see more details in [ADR 023](/docs/sdk/v0.50/architecture/adr-023-protobuf-naming) ### How to update modules to protobuf encoding diff --git a/docs/sdk/v0.50/learn/advanced/events.mdx b/docs/sdk/v0.50/learn/advanced/events.mdx index f7d7950d..4b4e9db6 100644 --- a/docs/sdk/v0.50/learn/advanced/events.mdx +++ b/docs/sdk/v0.50/learn/advanced/events.mdx @@ -34,10 +34,10 @@ An Event contains: To parse the attribute values as strings, make sure to add `'` (single quotes) around each attribute value. -*Typed Events* are Protobuf-defined [messages](/docs/sdk/v0.50//build/architecture/adr-032-typed-events) used by the Cosmos SDK +*Typed Events* are Protobuf-defined [messages](/docs/sdk/v0.50/build/architecture/adr-032-typed-events) used by the Cosmos SDK for emitting and querying Events. They are defined in a `event.proto` file, on a **per-module basis** and are read as `proto.Message`. *Legacy Events* are defined on a **per-module basis** in the module's `/types/events.go` file. -They are triggered from the module's Protobuf [`Msg` service](/docs/sdk/v0.50//build/building-modules/msg-services) +They are triggered from the module's Protobuf [`Msg` service](/docs/sdk/v0.50/build/building-modules/msg-services) by using the [`EventManager`](#eventmanager). In addition, each module documents its events under in the `Events` sections of its specs (x/`{moduleName}`/`README.md`). @@ -56,9 +56,9 @@ The following examples show how to query Events using the Cosmos SDK. | Event | Description | | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | `tx.height=23` | Query all transactions at height 23 | -| `message.action='/cosmos.bank.v1beta1.Msg/Send'` | Query all transactions containing a x/bank `Send` [Service `Msg`](/docs/sdk/v0.50//build/building-modules/msg-services). Note the `'`s around the value. | +| `message.action='/cosmos.bank.v1beta1.Msg/Send'` | Query all transactions containing a x/bank `Send` [Service `Msg`](/docs/sdk/v0.50/build/building-modules/msg-services). Note the `'`s around the value. | | `message.module='bank'` | Query all transactions containing messages from the x/bank module. Note the `'`s around the value. | -| `create_validator.validator='cosmosval1...'` | x/staking-specific Event, see [x/staking SPEC](/docs/sdk/v0.50//build/modules/staking/README). | +| `create_validator.validator='cosmosval1...'` | x/staking-specific Event, see [x/staking SPEC](/docs/sdk/v0.50/build/modules/staking/README). | ## EventManager @@ -2257,7 +2257,7 @@ ctx.EventManager().EmitEvent( Where the `EventManager` is accessed via the [`Context`](/docs/sdk/v0.50/learn/advanced/context). -See the [`Msg` services](/docs/sdk/v0.50//build/building-modules/msg-services) concept doc for a more detailed +See the [`Msg` services](/docs/sdk/v0.50/build/building-modules/msg-services) concept doc for a more detailed view on how to typically implement Events and use the `EventManager` in modules. ## Subscribing to Events diff --git a/docs/sdk/v0.50/learn/advanced/grpc_rest.mdx b/docs/sdk/v0.50/learn/advanced/grpc_rest.mdx index 1c5eafc9..515f0248 100644 --- a/docs/sdk/v0.50/learn/advanced/grpc_rest.mdx +++ b/docs/sdk/v0.50/learn/advanced/grpc_rest.mdx @@ -27,7 +27,7 @@ All endpoints are defaulted to localhost and must be modified to be exposed to t In the Cosmos SDK, Protobuf is the main [encoding](/docs/sdk/v0.50/learn/advanced/encoding) library. This brings a wide range of Protobuf-based tools that can be plugged into the Cosmos SDK. One such tool is [gRPC](https://grpc.io), a modern open-source high performance RPC framework that has decent client support in several languages. -Each module exposes a [Protobuf `Query` service](/docs/sdk/v0.50//build/building-modules/messages-and-queries#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: +Each module exposes a [Protobuf `Query` service](/docs/sdk/v0.50/build/building-modules/messages-and-queries#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: ```go expandable package types @@ -139,7 +139,7 @@ Application ) ``` -Note: It is not possible to expose any [Protobuf `Msg` service](/docs/sdk/v0.50//build/building-modules/messages-and-queries#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](/docs/sdk/v0.50//user/run-node/txs) for more information. +Note: It is not possible to expose any [Protobuf `Msg` service](/docs/sdk/v0.50/build/building-modules/messages-and-queries#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](/docs/sdk/v0.50/user/run-node/txs) for more information. The `grpc.Server` is a concrete gRPC server, which spawns and serves all gRPC query requests and a broadcast transaction request. This server can be configured inside `~/.simapp/config/app.toml`: @@ -150,7 +150,7 @@ The `grpc.Server` is a concrete gRPC server, which spawns and serves all gRPC qu `~/.simapp` is the directory where the node's configuration and databases are stored. By default, it's set to `~/.{app_name}`. -Once the gRPC server is started, you can send requests to it using a gRPC client. Some examples are given in our [Interact with the Node](/docs/sdk/v0.50//user/run-node/interact-node#using-grpc) tutorial. +Once the gRPC server is started, you can send requests to it using a gRPC client. Some examples are given in our [Interact with the Node](/docs/sdk/v0.50/user/run-node/interact-node#using-grpc) tutorial. An overview of all available gRPC endpoints shipped with the Cosmos SDK is [Protobuf documentation](https://buf.build/cosmos/cosmos-sdk). diff --git a/docs/sdk/v0.50/learn/advanced/node.mdx b/docs/sdk/v0.50/learn/advanced/node.mdx index 3fd202f2..532ef111 100644 --- a/docs/sdk/v0.50/learn/advanced/node.mdx +++ b/docs/sdk/v0.50/learn/advanced/node.mdx @@ -3201,4 +3201,4 @@ Upon starting, the node will bootstrap its RPC and P2P server and start dialing ## Other commands -To discover how to concretely run a node and interact with it, please refer to our [Running a Node, API and CLI](/docs/sdk/v0.50//user/run-node/run-node) guide. +To discover how to concretely run a node and interact with it, please refer to our [Running a Node, API and CLI](/docs/sdk/v0.50/user/run-node/run-node) guide. diff --git a/docs/sdk/v0.50/learn/advanced/runtx_middleware.mdx b/docs/sdk/v0.50/learn/advanced/runtx_middleware.mdx index f1ef0bc3..9aecce6f 100644 --- a/docs/sdk/v0.50/learn/advanced/runtx_middleware.mdx +++ b/docs/sdk/v0.50/learn/advanced/runtx_middleware.mdx @@ -6,7 +6,7 @@ title: RunTx recovery middleware 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](/docs/sdk/v0.50//build/architecture/adr-022-custom-panic-handling) and the implementation in [recovery.go](https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/baseapp/recovery.go). +More context can found in the corresponding [ADR-022](/docs/sdk/v0.50/build/architecture/adr-022-custom-panic-handling) and the implementation in [recovery.go](https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/baseapp/recovery.go). ## Interface diff --git a/docs/sdk/v0.50/learn/advanced/simulation.mdx b/docs/sdk/v0.50/learn/advanced/simulation.mdx index 8a28dc70..9ea5255a 100644 --- a/docs/sdk/v0.50/learn/advanced/simulation.mdx +++ b/docs/sdk/v0.50/learn/advanced/simulation.mdx @@ -98,5 +98,5 @@ Here are some suggestions when encountering a simulation failure: Learn how you can build the simulation into your Cosmos SDK-based application: * Application Simulation Manager -* [Building modules: Simulator](/docs/sdk/v0.50//build/building-modules/simulator) +* [Building modules: Simulator](/docs/sdk/v0.50/build/building-modules/simulator) * Simulator tests diff --git a/docs/sdk/v0.50/learn/advanced/store.mdx b/docs/sdk/v0.50/learn/advanced/store.mdx index 2367e049..466a0f5e 100644 --- a/docs/sdk/v0.50/learn/advanced/store.mdx +++ b/docs/sdk/v0.50/learn/advanced/store.mdx @@ -16,7 +16,7 @@ A store is a data structure that holds the state of the application. ## Introduction to Cosmos SDK Stores -The Cosmos SDK comes with a large set of stores to persist the state of applications. By default, the main store of Cosmos SDK applications is a `multistore`, i.e. a store of stores. Developers can add any number of key-value stores to the multistore, depending on their application needs. The multistore exists to support the modularity of the Cosmos SDK, as it lets each module declare and manage their own subset of the state. Key-value stores in the multistore can only be accessed with a specific capability `key`, which is typically held in the [`keeper`](/docs/sdk/v0.50//build/building-modules/keeper) of the module that declared the store. +The Cosmos SDK comes with a large set of stores to persist the state of applications. By default, the main store of Cosmos SDK applications is a `multistore`, i.e. a store of stores. Developers can add any number of key-value stores to the multistore, depending on their application needs. The multistore exists to support the modularity of the Cosmos SDK, as it lets each module declare and manage their own subset of the state. Key-value stores in the multistore can only be accessed with a specific capability `key`, which is typically held in the [`keeper`](/docs/sdk/v0.50/build/building-modules/keeper) of the module that declared the store. ```text expandable +-----------------------------------------------------+ @@ -5932,7 +5932,7 @@ return store.(types.KVStore) A `KVStore` is a simple key-value store used to store and retrieve data. A `CommitKVStore` is a `KVStore` that also implements a `Committer`. By default, stores mounted in `baseapp`'s main `CommitMultiStore` are `CommitKVStore`s. The `KVStore` interface is primarily used to restrict modules from accessing the committer. -Individual `KVStore`s are used by modules to manage a subset of the global state. `KVStores` can be accessed by objects that hold a specific key. This `key` should only be exposed to the [`keeper`](/docs/sdk/v0.50//build/building-modules/keeper) of the module that defines the store. +Individual `KVStore`s are used by modules to manage a subset of the global state. `KVStores` can be accessed by objects that hold a specific key. This `key` should only be exposed to the [`keeper`](/docs/sdk/v0.50/build/building-modules/keeper) of the module that defines the store. `CommitKVStore`s are declared by proxy of their respective `key` and mounted on the application's [multistore](#multistore) in the [main application file](/docs/sdk/v0.50/learn/beginner/app-anatomy#core-application-file). In the same file, the `key` is also passed to the module's `keeper` that is responsible for managing the store. diff --git a/docs/sdk/v0.50/learn/advanced/transactions.mdx b/docs/sdk/v0.50/learn/advanced/transactions.mdx index 8feda10f..1ee968b1 100644 --- a/docs/sdk/v0.50/learn/advanced/transactions.mdx +++ b/docs/sdk/v0.50/learn/advanced/transactions.mdx @@ -16,7 +16,7 @@ title: Transactions ## Transactions -Transactions are comprised of metadata held in [contexts](/docs/sdk/v0.50/learn/advanced/context) and [`sdk.Msg`s](/docs/sdk/v0.50//build/building-modules/messages-and-queries) that trigger state changes within a module through the module's Protobuf [`Msg` service](/docs/sdk/v0.50//build/building-modules/msg-services). +Transactions are comprised of metadata held in [contexts](/docs/sdk/v0.50/learn/advanced/context) and [`sdk.Msg`s](/docs/sdk/v0.50/build/building-modules/messages-and-queries) that trigger state changes within a module through the module's Protobuf [`Msg` service](/docs/sdk/v0.50/build/building-modules/msg-services). When users want to interact with an application and make state changes (e.g. sending coins), they create transactions. Each of a transaction's `sdk.Msg` must be signed using the private key associated with the appropriate account(s), before the transaction is broadcasted to the network. A transaction must then be included in a block, validated, and approved by the network through the consensus process. To read more about the lifecycle of a transaction, click [here](/docs/sdk/v0.50/learn/beginner/tx-lifecycle). @@ -207,7 +207,7 @@ The most used implementation of the `Tx` interface is the Protobuf `Tx` message, // Reference: https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.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](/docs/sdk/v0.50//build/architecture/adr-027-deterministic-protobuf-serialization)): +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](/docs/sdk/v0.50/build/architecture/adr-027-deterministic-protobuf-serialization)): ```protobuf // Reference: https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/proto/cosmos/tx/v1beta1/tx.proto#L48-L65 @@ -722,7 +722,7 @@ There are also *expert* screens, which will only be displayed if the user has ch Data is formatted using a set of `ValueRenderer` which the SDK provides defaults for all the known messages and value types. Chain developers can also opt to implement their own `ValueRenderer` for a type/message if they'd like to display information differently. -If you wish to learn more, please refer to [ADR-050](/docs/sdk/v0.50//build/architecture/adr-050-sign-mode-textual). +If you wish to learn more, please refer to [ADR-050](/docs/sdk/v0.50/build/architecture/adr-050-sign-mode-textual). #### Custom Sign modes @@ -744,12 +744,12 @@ The next paragraphs will describe each of these components, in this order. Module `sdk.Msg`s are not to be confused with [ABCI Messages](https://docs.cometbft.com/v0.37/spec/abci/) which define interactions between the CometBFT and application layers. -**Messages** (or `sdk.Msg`s) are module-specific objects that trigger state transitions within the scope of the module they belong to. Module developers define the messages for their module by adding methods to the Protobuf [`Msg` service](/docs/sdk/v0.50//build/building-modules/msg-services), and also implement the corresponding `MsgServer`. +**Messages** (or `sdk.Msg`s) are module-specific objects that trigger state transitions within the scope of the module they belong to. Module developers define the messages for their module by adding methods to the Protobuf [`Msg` service](/docs/sdk/v0.50/build/building-modules/msg-services), and also implement the corresponding `MsgServer`. -Each `sdk.Msg`s is related to exactly one Protobuf [`Msg` service](/docs/sdk/v0.50//build/building-modules/msg-services) RPC, defined inside each module's `tx.proto` file. A SDK app router automatically maps every `sdk.Msg` to a corresponding RPC. Protobuf generates a `MsgServer` interface for each module `Msg` service, and the module developer needs to implement this interface. +Each `sdk.Msg`s is related to exactly one Protobuf [`Msg` service](/docs/sdk/v0.50/build/building-modules/msg-services) RPC, defined inside each module's `tx.proto` file. A SDK app router automatically maps every `sdk.Msg` to a corresponding RPC. Protobuf generates a `MsgServer` interface for each module `Msg` service, and the module developer needs to implement this interface. This design puts more responsibility on module developers, allowing application developers to reuse common functionalities without having to implement state transition logic repetitively. -To learn more about Protobuf `Msg` services and how to implement `MsgServer`, click [here](/docs/sdk/v0.50//build/building-modules/msg-services). +To learn more about Protobuf `Msg` services and how to implement `MsgServer`, click [here](/docs/sdk/v0.50/build/building-modules/msg-services). While messages contain the information for state transition logic, a transaction's other metadata and relevant information are stored in the `TxBuilder` and `Context`. @@ -974,7 +974,7 @@ Once the transaction bytes are generated, there are currently three ways of broa Application developers create entry points to the application by creating a [command-line interface](/docs/sdk/v0.50/learn/advanced/cli), [gRPC and/or REST interface](/docs/sdk/v0.50/learn/advanced/grpc_rest), typically found in the application's `./cmd` folder. These interfaces allow users to interact with the application through command-line. -For the [command-line interface](/docs/sdk/v0.50//build/building-modules/module-interfaces#cli), module developers create subcommands to add as children to the application top-level transaction command `TxCmd`. CLI commands actually bundle all the steps of transaction processing into one simple command: creating messages, generating transactions and broadcasting. For concrete examples, see the [Interacting with a Node](/docs/sdk/v0.50//user/run-node/interact-node) section. An example transaction made using CLI looks like: +For the [command-line interface](/docs/sdk/v0.50/build/building-modules/module-interfaces#cli), module developers create subcommands to add as children to the application top-level transaction command `TxCmd`. CLI commands actually bundle all the steps of transaction processing into one simple command: creating messages, generating transactions and broadcasting. For concrete examples, see the [Interacting with a Node](/docs/sdk/v0.50/user/run-node/interact-node) section. An example transaction made using CLI looks like: ```bash simd tx send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000stake @@ -982,7 +982,7 @@ simd tx send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000stake #### gRPC -[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](/docs/sdk/v0.50//build/building-modules/query-services). However, the Cosmos SDK also exposes a few other module-agnostic gRPC services, one of them being the `Tx` service: +[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](/docs/sdk/v0.50/build/building-modules/query-services). However, the Cosmos SDK also exposes a few other module-agnostic gRPC services, one of them being the `Tx` service: ```go expandable syntax = "proto3"; @@ -1303,13 +1303,13 @@ message TxDecodeAminoResponse { 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. -Examples of broadcasting and simulating a transaction are shown [here](/docs/sdk/v0.50//user/run-node/txs#programmatically-with-go). +Examples of broadcasting and simulating a transaction are shown [here](/docs/sdk/v0.50/user/run-node/txs#programmatically-with-go). #### REST Each gRPC method has its corresponding REST endpoint, generated using [gRPC-gateway](https://github.com/grpc-ecosystem/grpc-gateway). Therefore, instead of using gRPC, you can also use HTTP to broadcast the same transaction, on the `POST /cosmos/tx/v1beta1/txs` endpoint. -An example can be seen [here](/docs/sdk/v0.50//user/run-node/txs#using-rest) +An example can be seen [here](/docs/sdk/v0.50/user/run-node/txs#using-rest) #### CometBFT RPC diff --git a/docs/sdk/v0.50/learn/advanced/upgrade.mdx b/docs/sdk/v0.50/learn/advanced/upgrade.mdx index 4102a25c..0798147f 100644 --- a/docs/sdk/v0.50/learn/advanced/upgrade.mdx +++ b/docs/sdk/v0.50/learn/advanced/upgrade.mdx @@ -15,7 +15,7 @@ The Cosmos SDK uses two methods to perform upgrades: * Exporting the entire application state to a JSON file using the `export` CLI command, making changes, and then starting a new binary with the changed JSON file as the genesis file. -* Perform upgrades in place, which significantly decrease the upgrade time for chains with a larger state. Use the [Module Upgrade Guide](/docs/sdk/v0.47//build/building-modules/upgrade) to set up your application modules to take advantage of in-place upgrades. +* Perform upgrades in place, which significantly decrease the upgrade time for chains with a larger state. Use the [Module Upgrade Guide](/docs/sdk/v0.47/build/building-modules/upgrade) to set up your application modules to take advantage of in-place upgrades. This document provides steps to use the In-Place Store Migrations upgrade method. @@ -63,7 +63,7 @@ app.UpgradeKeeper.SetUpgradeHandler("my-plan", func(ctx sdk.Context, plan upgrad }) ``` -To learn more about configuring migration scripts for your modules, see the [Module Upgrade Guide](/docs/sdk/v0.47//build/building-modules/upgrade). +To learn more about configuring migration scripts for your modules, see the [Module Upgrade Guide](/docs/sdk/v0.47/build/building-modules/upgrade). ### Order Of Migrations @@ -161,4 +161,4 @@ You can sync a full node to an existing blockchain which has been upgraded using To successfully sync, you must start with the initial binary that the blockchain started with at genesis. If all Software Upgrade Plans contain binary instruction, then you can run Cosmovisor with auto-download option to automatically handle downloading and switching to the binaries associated with each sequential upgrade. Otherwise, you need to manually provide all binaries to Cosmovisor. -To learn more about Cosmovisor, see the [Cosmovisor Quick Start](/docs/sdk/v0.47//build/tooling/cosmovisor). +To learn more about Cosmovisor, see the [Cosmovisor Quick Start](/docs/sdk/v0.47/build/tooling/cosmovisor). diff --git a/docs/sdk/v0.50/learn/beginner/accounts.mdx b/docs/sdk/v0.50/learn/beginner/accounts.mdx index 70a7a037..25cf1269 100644 --- a/docs/sdk/v0.50/learn/beginner/accounts.mdx +++ b/docs/sdk/v0.50/learn/beginner/accounts.mdx @@ -16,7 +16,7 @@ This document describes the in-built account and public key system of the Cosmos ## Account Definition -In the Cosmos SDK, an *account* designates a pair of *public key* `PubKey` and *private key* `PrivKey`. The `PubKey` can be derived to generate various `Addresses`, which are used to identify users (among other parties) in the application. `Addresses` are also associated with [`message`s](/docs/sdk/v0.50//build/building-modules/messages-and-queries#messages) to identify the sender of the `message`. The `PrivKey` is used to generate [digital signatures](#signatures) to prove that an `Address` associated with the `PrivKey` approved of a given `message`. +In the Cosmos SDK, an *account* designates a pair of *public key* `PubKey` and *private key* `PrivKey`. The `PubKey` can be derived to generate various `Addresses`, which are used to identify users (among other parties) in the application. `Addresses` are also associated with [`message`s](/docs/sdk/v0.50/build/building-modules/messages-and-queries#messages) to identify the sender of the `message`. The `PrivKey` is used to generate [digital signatures](#signatures) to prove that an `Address` associated with the `PrivKey` approved of a given `message`. For HD key derivation the Cosmos SDK uses a standard called [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki). The BIP32 allows users to create an HD wallet (as specified in [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)) - a set of accounts derived from an initial secret seed. A seed is usually created from a 12- or 24-word mnemonic. A single seed can derive any number of `PrivKey`s using a one-way cryptographic function. Then, a `PubKey` can be derived from the `PrivKey`. Naturally, the mnemonic is the most sensitive information, as private keys can always be re-generated if the mnemonic is preserved. @@ -3191,7 +3191,7 @@ The default implementation of `Keyring` comes from the third-party [`99designs/k 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](/docs/sdk/v0.50//build/architecture/adr-020-protobuf-transaction-encoding) that the canonical `payload` to sign is the `SignDoc` struct, deterministically encoded using [ADR-027](/docs/sdk/v0.50//build/architecture/adr-027-deterministic-protobuf-serialization). Note that signature verification is not implemented in the Cosmos SDK by default, it is deferred to the [`anteHandler`](/docs/sdk/v0.50/learn/advanced/baseapp#antehandler). +* `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](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding) that the canonical `payload` to sign is the `SignDoc` struct, deterministically encoded using [ADR-027](/docs/sdk/v0.50/build/architecture/adr-027-deterministic-protobuf-serialization). Note that signature verification is not implemented in the Cosmos SDK by default, it is deferred to the [`anteHandler`](/docs/sdk/v0.50/learn/advanced/baseapp#antehandler). ```protobuf // Reference: https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/proto/cosmos/tx/v1beta1/tx.proto#L50-L66 diff --git a/docs/sdk/v0.50/learn/beginner/app-anatomy.mdx b/docs/sdk/v0.50/learn/beginner/app-anatomy.mdx index b5b29ea1..91e5c1ce 100644 --- a/docs/sdk/v0.50/learn/beginner/app-anatomy.mdx +++ b/docs/sdk/v0.50/learn/beginner/app-anatomy.mdx @@ -51,10 +51,10 @@ The first thing defined in `app.go` is the `type` of the application. It is gene * **A reference to [`baseapp`](/docs/sdk/v0.50/learn/advanced/baseapp).** The custom application defined in `app.go` is an extension of `baseapp`. When a transaction is relayed by CometBFT to the application, `app` uses `baseapp`'s methods to route them to the appropriate module. `baseapp` implements most of the core logic for the application, including all the [ABCI methods](https://docs.cometbft.com/v0.37/spec/abci/) and the [routing logic](/docs/sdk/v0.50/learn/advanced/baseapp#routing). * **A list of store keys**. The [store](/docs/sdk/v0.50/learn/advanced/store), which contains the entire state, is implemented as a [`multistore`](/docs/sdk/v0.50/learn/advanced/store#multistore) (i.e. a store of stores) in the Cosmos SDK. Each module uses one or multiple stores in the multistore to persist their part of the state. These stores can be accessed with specific keys that are declared in the `app` type. These keys, along with the `keepers`, are at the heart of the [object-capabilities model](/docs/sdk/v0.50/learn/advanced/ocap) of the Cosmos SDK. -* **A list of module's `keeper`s.** Each module defines an abstraction called [`keeper`](/docs/sdk/v0.50//build/building-modules/keeper), which handles reads and writes for this module's store(s). The `keeper`'s methods of one module can be called from other modules (if authorized), which is why they are declared in the application's type and exported as interfaces to other modules so that the latter can only access the authorized functions. +* **A list of module's `keeper`s.** Each module defines an abstraction called [`keeper`](/docs/sdk/v0.50/build/building-modules/keeper), which handles reads and writes for this module's store(s). The `keeper`'s methods of one module can be called from other modules (if authorized), which is why they are declared in the application's type and exported as interfaces to other modules so that the latter can only access the authorized functions. * **A reference to an [`appCodec`](/docs/sdk/v0.50/learn/advanced/encoding).** The application's `appCodec` is used to serialize and deserialize data structures in order to store them, as stores can only persist `[]bytes`. The default codec is [Protocol Buffers](/docs/sdk/v0.50/learn/advanced/encoding). * **A reference to a [`legacyAmino`](/docs/sdk/v0.50/learn/advanced/encoding) codec.** Some parts of the Cosmos SDK have not been migrated to use the `appCodec` above, and are still hardcoded to use Amino. Other parts explicitly use Amino for backwards compatibility. For these reasons, the application still holds a reference to the legacy Amino codec. Please note that the Amino codec will be removed from the SDK in the upcoming releases. -* **A reference to a [module manager](/docs/sdk/v0.50//build/building-modules/module-manager#manager)** and a [basic module manager](/docs/sdk/v0.50//build/building-modules/module-manager#basicmanager). The module manager is an object that contains a list of the application's modules. It facilitates operations related to these modules, like registering their [`Msg` service](/docs/sdk/v0.50/learn/advanced/baseapp#msg-services) and [gRPC `Query` service](/docs/sdk/v0.50/learn/advanced/baseapp#grpc-query-services), or setting the order of execution between modules for various functions like [`InitChainer`](#initchainer), [`PreBlocker`](#preblocker) and [`BeginBlocker` and `EndBlocker`](#beginblocker-and-endblocker). +* **A reference to a [module manager](/docs/sdk/v0.50/build/building-modules/module-manager#manager)** and a [basic module manager](/docs/sdk/v0.50/build/building-modules/module-manager#basicmanager). The module manager is an object that contains a list of the application's modules. It facilitates operations related to these modules, like registering their [`Msg` service](/docs/sdk/v0.50/learn/advanced/baseapp#msg-services) and [gRPC `Query` service](/docs/sdk/v0.50/learn/advanced/baseapp#grpc-query-services), or setting the order of execution between modules for various functions like [`InitChainer`](#initchainer), [`PreBlocker`](#preblocker) and [`BeginBlocker` and `EndBlocker`](#beginblocker-and-endblocker). See an example of application type definition from `simapp`, the Cosmos SDK's own app used for demo and testing purposes: @@ -1102,12 +1102,12 @@ Application Here are the main actions performed by this function: -* Instantiate a new [`codec`](/docs/sdk/v0.50/learn/advanced/encoding) and initialize the `codec` of each of the application's modules using the [basic manager](/docs/sdk/v0.50//build/building-modules/module-manager#basicmanager). +* Instantiate a new [`codec`](/docs/sdk/v0.50/learn/advanced/encoding) and initialize the `codec` of each of the application's modules using the [basic manager](/docs/sdk/v0.50/build/building-modules/module-manager#basicmanager). * Instantiate a new application with a reference to a `baseapp` instance, a codec, and all the appropriate store keys. * Instantiate all the [`keeper`](#keeper) objects defined in the application's `type` using the `NewKeeper` function of each of the application's modules. Note that keepers must be instantiated in the correct order, as the `NewKeeper` of one module might require a reference to another module's `keeper`. -* Instantiate the application's [module manager](/docs/sdk/v0.50//build/building-modules/module-manager#manager) with the [`AppModule`](#application-module-interface) object of each of the application's modules. +* Instantiate the application's [module manager](/docs/sdk/v0.50/build/building-modules/module-manager#manager) with the [`AppModule`](#application-module-interface) object of each of the application's modules. * With the module manager, initialize the application's [`Msg` services](/docs/sdk/v0.50/learn/advanced/baseapp#msg-services), [gRPC `Query` services](/docs/sdk/v0.50/learn/advanced/baseapp#grpc-query-services), [legacy `Msg` routes](/docs/sdk/v0.50/learn/advanced/baseapp#routing), and [legacy query routes](/docs/sdk/v0.50/learn/advanced/baseapp#query-routing). When a transaction is relayed to the application by CometBFT via the ABCI, it is routed to the appropriate module's [`Msg` service](#msg-services) using the routes defined here. Likewise, when a gRPC query request is received by the application, it is routed to the appropriate module's [`gRPC query service`](#grpc-query-services) using the gRPC routes defined here. The Cosmos SDK still supports legacy `Msg`s and legacy CometBFT queries, which are routed using the legacy `Msg` routes and the legacy query routes, respectively. -* With the module manager, register the [application's modules' invariants](/docs/sdk/v0.50//build/building-modules/invariants). Invariants are variables (e.g. total supply of a token) that are evaluated at the end of each block. The process of checking invariants is done via a special module called the [`InvariantsRegistry`](/docs/sdk/v0.50//build/building-modules/invariants#invariant-registry). The value of the invariant should be equal to a predicted value defined in the module. Should the value be different than the predicted one, special logic defined in the invariant registry is triggered (usually the chain is halted). This is useful to make sure that no critical bug goes unnoticed, producing long-lasting effects that are hard to fix. +* With the module manager, register the [application's modules' invariants](/docs/sdk/v0.50/build/building-modules/invariants). Invariants are variables (e.g. total supply of a token) that are evaluated at the end of each block. The process of checking invariants is done via a special module called the [`InvariantsRegistry`](/docs/sdk/v0.50/build/building-modules/invariants#invariant-registry). The value of the invariant should be equal to a predicted value defined in the module. Should the value be different than the predicted one, special logic defined in the invariant registry is triggered (usually the chain is halted). This is useful to make sure that no critical bug goes unnoticed, producing long-lasting effects that are hard to fix. * With the module manager, set the order of execution between the `InitGenesis`, `PreBlocker`, `BeginBlocker`, and `EndBlocker` functions of each of the [application's modules](#application-module-interface). Note that not all modules implement these functions. * Set the remaining application parameters: * [`InitChainer`](#initchainer): used to initialize the application when it is first started. @@ -2053,7 +2053,7 @@ return paramsKeeper The `InitChainer` is a function that initializes the state of the application from a genesis file (i.e. token balances of genesis accounts). It is called when the application receives the `InitChain` message from the CometBFT engine, which happens when the node is started at `appBlockHeight == 0` (i.e. on genesis). The application must set the `InitChainer` in its [constructor](#constructor-function) via the [`SetInitChainer`](https://pkg.go.dev/github.com/cosmos/cosmos-sdk/baseapp#BaseApp.SetInitChainer) method. -In general, the `InitChainer` is mostly composed of the [`InitGenesis`](/docs/sdk/v0.50//build/building-modules/genesis#initgenesis) function of each of the application's modules. This is done by calling the `InitGenesis` function of the module manager, which in turn calls the `InitGenesis` function of each of the modules it contains. Note that the order in which the modules' `InitGenesis` functions must be called has to be set in the module manager using the [module manager's](/docs/sdk/v0.50//build/building-modules/module-manager) `SetOrderInitGenesis` method. This is done in the [application's constructor](#application-constructor), and the `SetOrderInitGenesis` has to be called before the `SetInitChainer`. +In general, the `InitChainer` is mostly composed of the [`InitGenesis`](/docs/sdk/v0.50/build/building-modules/genesis#initgenesis) function of each of the application's modules. This is done by calling the `InitGenesis` function of the module manager, which in turn calls the `InitGenesis` function of each of the modules it contains. Note that the order in which the modules' `InitGenesis` functions must be called has to be set in the module manager using the [module manager's](/docs/sdk/v0.50/build/building-modules/module-manager) `SetOrderInitGenesis` method. This is done in the [application's constructor](#application-constructor), and the `SetOrderInitGenesis` has to be called before the `SetInitChainer`. See an example of an `InitChainer` from `simapp`: @@ -3004,7 +3004,7 @@ The new ctx must be passed to all the other lifecycle methods. The Cosmos SDK offers developers the possibility to implement automatic execution of code as part of their application. This is implemented through two functions called `BeginBlocker` and `EndBlocker`. They are called when the application receives the `FinalizeBlock` messages from the CometBFT consensus engine, which happens respectively at the beginning and at the end of each block. The application must set the `BeginBlocker` and `EndBlocker` in its [constructor](#constructor-function) via the [`SetBeginBlocker`](https://pkg.go.dev/github.com/cosmos/cosmos-sdk/baseapp#BaseApp.SetBeginBlocker) and [`SetEndBlocker`](https://pkg.go.dev/github.com/cosmos/cosmos-sdk/baseapp#BaseApp.SetEndBlocker) methods. -In general, the `BeginBlocker` and `EndBlocker` functions are mostly composed of the [`BeginBlock` and `EndBlock`](/docs/sdk/v0.50//build/building-modules/beginblock-endblock) functions of each of the application's modules. This is done by calling the `BeginBlock` and `EndBlock` functions of the module manager, which in turn calls the `BeginBlock` and `EndBlock` functions of each of the modules it contains. Note that the order in which the modules' `BeginBlock` and `EndBlock` functions must be called has to be set in the module manager using the `SetOrderBeginBlockers` and `SetOrderEndBlockers` methods, respectively. This is done via the [module manager](/docs/sdk/v0.50//build/building-modules/module-manager) in the [application's constructor](#application-constructor), and the `SetOrderBeginBlockers` and `SetOrderEndBlockers` methods have to be called before the `SetBeginBlocker` and `SetEndBlocker` functions. +In general, the `BeginBlocker` and `EndBlocker` functions are mostly composed of the [`BeginBlock` and `EndBlock`](/docs/sdk/v0.50/build/building-modules/beginblock-endblock) functions of each of the application's modules. This is done by calling the `BeginBlock` and `EndBlock` functions of the module manager, which in turn calls the `BeginBlock` and `EndBlock` functions of each of the modules it contains. Note that the order in which the modules' `BeginBlock` and `EndBlock` functions must be called has to be set in the module manager using the `SetOrderBeginBlockers` and `SetOrderEndBlockers` methods, respectively. This is done via the [module manager](/docs/sdk/v0.50/build/building-modules/module-manager) in the [application's constructor](#application-constructor), and the `SetOrderBeginBlockers` and `SetOrderEndBlockers` methods have to be called before the `SetBeginBlocker` and `SetEndBlocker` functions. As a sidenote, it is important to remember that application-specific blockchains are deterministic. Developers must be careful not to introduce non-determinism in `BeginBlocker` or `EndBlocker`, and must also be careful not to make them too computationally expensive, as [gas](/docs/sdk/v0.50/learn/beginner/gas-fees) does not constrain the cost of `BeginBlocker` and `EndBlocker` execution. @@ -3965,8 +3965,8 @@ type EncodingConfig struct { Here are descriptions of what each of the four fields means: * `InterfaceRegistry`: The `InterfaceRegistry` is used by the Protobuf codec to handle interfaces that are encoded and decoded (we also say "unpacked") using [`google.protobuf.Any`](https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/any.proto). `Any` could be thought as a struct that contains a `type_url` (name of a concrete type implementing the interface) and a `value` (its encoded bytes). `InterfaceRegistry` provides a mechanism for registering interfaces and implementations that can be safely unpacked from `Any`. Each application module implements the `RegisterInterfaces` method that can be used to register the module's own interfaces and implementations. - * You can read more about `Any` in [ADR-019](/docs/sdk/v0.50//build/architecture/adr-019-protobuf-state-encoding). - * To go more into details, the Cosmos SDK uses an implementation of the Protobuf specification called [`gogoprotobuf`](https://github.com/cosmos/gogoproto). By default, the [gogo protobuf implementation of `Any`](https://pkg.go.dev/github.com/cosmos/gogoproto/types) uses [global type registration](https://github.com/cosmos/gogoproto/blob/master/proto/properties.go#L540) to decode values packed in `Any` into concrete Go types. This introduces a vulnerability where any malicious module in the dependency tree could register a type with the global protobuf registry and cause it to be loaded and unmarshaled by a transaction that referenced it in the `type_url` field. For more information, please refer to [ADR-019](/docs/sdk/v0.50//build/architecture/adr-019-protobuf-state-encoding). + * You can read more about `Any` in [ADR-019](/docs/sdk/v0.50/build/architecture/adr-019-protobuf-state-encoding). + * To go more into details, the Cosmos SDK uses an implementation of the Protobuf specification called [`gogoprotobuf`](https://github.com/cosmos/gogoproto). By default, the [gogo protobuf implementation of `Any`](https://pkg.go.dev/github.com/cosmos/gogoproto/types) uses [global type registration](https://github.com/cosmos/gogoproto/blob/master/proto/properties.go#L540) to decode values packed in `Any` into concrete Go types. This introduces a vulnerability where any malicious module in the dependency tree could register a type with the global protobuf registry and cause it to be loaded and unmarshaled by a transaction that referenced it in the `type_url` field. For more information, please refer to [ADR-019](/docs/sdk/v0.50/build/architecture/adr-019-protobuf-state-encoding). * `Codec`: The default codec used throughout the Cosmos SDK. It is composed of a `BinaryCodec` used to encode and decode state, and a `JSONCodec` used to output data to the users (for example, in the [CLI](#cli)). By default, the SDK uses Protobuf as `Codec`. * `TxConfig`: `TxConfig` defines an interface a client can utilize to generate an application-defined concrete transaction type. Currently, the SDK handles two transaction types: `SIGN_MODE_DIRECT` (which uses Protobuf binary as over-the-wire encoding) and `SIGN_MODE_LEGACY_AMINO_JSON` (which depends on Amino). Read more about transactions [here](/docs/sdk/v0.50/learn/advanced/transactions). * `Amino`: Some legacy parts of the Cosmos SDK still use Amino for backwards-compatibility. Each module exposes a `RegisterLegacyAmino` method to register the module's specific types within Amino. This `Amino` codec should not be used by app developers anymore, and will be removed in future releases. @@ -3996,13 +3996,13 @@ type EncodingConfig struct { ## Modules -[Modules](/docs/sdk/v0.50//build/building-modules/intro) are the heart and soul of Cosmos SDK applications. They can be considered as state-machines nested within the state-machine. When a transaction is relayed from the underlying CometBFT engine via the ABCI to the application, it is routed by [`baseapp`](/docs/sdk/v0.50/learn/advanced/baseapp) to the appropriate module in order to be processed. This paradigm enables developers to easily build complex state-machines, as most of the modules they need often already exist. **For developers, most of the work involved in building a Cosmos SDK application revolves around building custom modules required by their application that do not exist yet, and integrating them with modules that do already exist into one coherent application**. In the application directory, the standard practice is to store modules in the `x/` folder (not to be confused with the Cosmos SDK's `x/` folder, which contains already-built modules). +[Modules](/docs/sdk/v0.50/build/building-modules/intro) are the heart and soul of Cosmos SDK applications. They can be considered as state-machines nested within the state-machine. When a transaction is relayed from the underlying CometBFT engine via the ABCI to the application, it is routed by [`baseapp`](/docs/sdk/v0.50/learn/advanced/baseapp) to the appropriate module in order to be processed. This paradigm enables developers to easily build complex state-machines, as most of the modules they need often already exist. **For developers, most of the work involved in building a Cosmos SDK application revolves around building custom modules required by their application that do not exist yet, and integrating them with modules that do already exist into one coherent application**. In the application directory, the standard practice is to store modules in the `x/` folder (not to be confused with the Cosmos SDK's `x/` folder, which contains already-built modules). ### Application Module Interface -Modules must implement [interfaces](/docs/sdk/v0.50//build/building-modules/module-manager#application-module-interfaces) defined in the Cosmos SDK, [`AppModuleBasic`](/docs/sdk/v0.50//build/building-modules/module-manager#appmodulebasic) and [`AppModule`](/docs/sdk/v0.50//build/building-modules/module-manager#appmodule). The former implements basic non-dependent elements of the module, such as the `codec`, while the latter handles the bulk of the module methods (including methods that require references to other modules' `keeper`s). Both the `AppModule` and `AppModuleBasic` types are, by convention, defined in a file called `module.go`. +Modules must implement [interfaces](/docs/sdk/v0.50/build/building-modules/module-manager#application-module-interfaces) defined in the Cosmos SDK, [`AppModuleBasic`](/docs/sdk/v0.50/build/building-modules/module-manager#appmodulebasic) and [`AppModule`](/docs/sdk/v0.50/build/building-modules/module-manager#appmodule). The former implements basic non-dependent elements of the module, such as the `codec`, while the latter handles the bulk of the module methods (including methods that require references to other modules' `keeper`s). Both the `AppModule` and `AppModuleBasic` types are, by convention, defined in a file called `module.go`. -`AppModule` exposes a collection of useful methods on the module that facilitates the composition of modules into a coherent application. These methods are called from the [`module manager`](/docs/sdk/v0.50//build/building-modules/module-manager#manager), which manages the application's collection of modules. +`AppModule` exposes a collection of useful methods on the module that facilitates the composition of modules into a coherent application. These methods are called from the [`module manager`](/docs/sdk/v0.50/build/building-modules/module-manager#manager), which manages the application's collection of modules. ### `Msg` Services @@ -4031,7 +4031,7 @@ Each module should also implement the `RegisterServices` method as part of the [ ### gRPC `Query` Services -gRPC `Query` services allow users to query the state using [gRPC](https://grpc.io). They are enabled by default, and can be configured under the `grpc.enable` and `grpc.address` fields inside [`app.toml`](/docs/sdk/v0.50//user/run-node/run-node#configuring-the-node-using-apptoml-and-configtoml). +gRPC `Query` services allow users to query the state using [gRPC](https://grpc.io). They are enabled by default, and can be configured under the `grpc.enable` and `grpc.address` fields inside [`app.toml`](/docs/sdk/v0.50/user/run-node/run-node#configuring-the-node-using-apptoml-and-configtoml). gRPC `Query` services are defined in the module's Protobuf definition files, specifically inside `query.proto`. The `query.proto` definition file exposes a single `Query` [Protobuf service](https://developers.google.com/protocol-buffers/docs/proto#services). Each gRPC query endpoint corresponds to a service method, starting with the `rpc` keyword, inside the `Query` service. @@ -4041,7 +4041,7 @@ Finally, each module should also implement the `RegisterServices` method as part ### Keeper -[`Keepers`](/docs/sdk/v0.50//build/building-modules/keeper) are the gatekeepers of their module's store(s). To read or write in a module's store, it is mandatory to go through one of its `keeper`'s methods. This is ensured by the [object-capabilities](/docs/sdk/v0.50/learn/advanced/ocap) model of the Cosmos SDK. Only objects that hold the key to a store can access it, and only the module's `keeper` should hold the key(s) to the module's store(s). +[`Keepers`](/docs/sdk/v0.50/build/building-modules/keeper) are the gatekeepers of their module's store(s). To read or write in a module's store, it is mandatory to go through one of its `keeper`'s methods. This is ensured by the [object-capabilities](/docs/sdk/v0.50/learn/advanced/ocap) model of the Cosmos SDK. Only objects that hold the key to a store can access it, and only the module's `keeper` should hold the key(s) to the module's store(s). `Keepers` are generally defined in a file called `keeper.go`. It contains the `keeper`'s type definition and methods. @@ -4059,7 +4059,7 @@ Each module defines command-line commands, gRPC services, and REST routes to be #### CLI -Generally, the [commands related to a module](/docs/sdk/v0.50//build/building-modules/module-interfaces#cli) are defined in a folder called `client/cli` in the module's folder. The CLI divides commands into two categories, transactions and queries, defined in `client/cli/tx.go` and `client/cli/query.go`, respectively. Both commands are built on top of the [Cobra Library](https://github.com/spf13/cobra): +Generally, the [commands related to a module](/docs/sdk/v0.50/build/building-modules/module-interfaces#cli) are defined in a folder called `client/cli` in the module's folder. The CLI divides commands into two categories, transactions and queries, defined in `client/cli/tx.go` and `client/cli/query.go`, respectively. Both commands are built on top of the [Cobra Library](https://github.com/spf13/cobra): * Transactions commands let users generate new transactions so that they can be included in a block and eventually update the state. One command should be created for each [message type](#message-types) defined in the module. The command calls the constructor of the message with the parameters provided by the end-user, and wraps it into a transaction. The Cosmos SDK handles signing and the addition of other transaction metadata. * Queries let users query the subset of the state defined by the module. Query commands forward queries to the [application's query router](/docs/sdk/v0.50/learn/advanced/baseapp#query-routing), which routes them to the appropriate [querier](#querier) the `queryRoute` parameter supplied. @@ -4079,7 +4079,7 @@ Some external clients may not wish to use gRPC. In this case, the Cosmos SDK pro The REST endpoints are defined in the Protobuf files, along with the gRPC services, using Protobuf annotations. Modules that want to expose REST queries should add `google.api.http` annotations to their `rpc` methods. By default, all REST endpoints defined in the SDK have a URL starting with the `/cosmos/` prefix. -The Cosmos SDK also provides a development endpoint to generate [Swagger](https://swagger.io/) definition files for these REST endpoints. This endpoint can be enabled inside the [`app.toml`](/docs/sdk/v0.50//user/run-node/run-node#configuring-the-node-using-apptoml-and-configtoml) config file, under the `api.swagger` key. +The Cosmos SDK also provides a development endpoint to generate [Swagger](https://swagger.io/) definition files for these REST endpoints. This endpoint can be enabled inside the [`app.toml`](/docs/sdk/v0.50/user/run-node/run-node#configuring-the-node-using-apptoml-and-configtoml) config file, under the `api.swagger` key. ## Application Interface diff --git a/docs/sdk/v0.50/learn/beginner/gas-fees.mdx b/docs/sdk/v0.50/learn/beginner/gas-fees.mdx index 7932c651..6054923f 100644 --- a/docs/sdk/v0.50/learn/beginner/gas-fees.mdx +++ b/docs/sdk/v0.50/learn/beginner/gas-fees.mdx @@ -19,7 +19,7 @@ This document describes the default strategies to handle gas and fees within a C In the Cosmos SDK, `gas` is a special unit that is used to track the consumption of resources during execution. `gas` is typically consumed whenever read and writes are made to the store, but it can also be consumed if expensive computation needs to be done. It serves two main purposes: * Make sure blocks are not consuming too many resources and are finalized. This is implemented by default in the Cosmos SDK via the [block gas meter](#block-gas-meter). -* Prevent spam and abuse from end-user. To this end, `gas` consumed during [`message`](/docs/sdk/v0.50//build/building-modules/messages-and-queries#messages) execution is typically priced, resulting in a `fee` (`fees = gas * gas-prices`). `fees` generally have to be paid by the sender of the `message`. Note that the Cosmos SDK does not enforce `gas` pricing by default, as there may be other ways to prevent spam (e.g. bandwidth schemes). Still, most applications implement `fee` mechanisms to prevent spam by using the [`AnteHandler`](#antehandler). +* Prevent spam and abuse from end-user. To this end, `gas` consumed during [`message`](/docs/sdk/v0.50/build/building-modules/messages-and-queries#messages) execution is typically priced, resulting in a `fee` (`fees = gas * gas-prices`). `fees` generally have to be paid by the sender of the `message`. Note that the Cosmos SDK does not enforce `gas` pricing by default, as there may be other ways to prevent spam (e.g. bandwidth schemes). Still, most applications implement `fee` mechanisms to prevent spam by using the [`AnteHandler`](#antehandler). ## Gas Meter @@ -406,7 +406,7 @@ By default, the Cosmos SDK makes use of two different gas meters, the [main gas `ctx.GasMeter()` is the main gas meter of the application. The main gas meter is initialized in `FinalizeBlock` via `setFinalizeBlockState`, and then tracks gas consumption during execution sequences that lead to state-transitions, i.e. those originally triggered by [`FinalizeBlock`](/docs/sdk/v0.50/learn/advanced/baseapp#finalizeblock). At the beginning of each transaction execution, the main gas meter **must be set to 0** in the [`AnteHandler`](#antehandler), so that it can track gas consumption per-transaction. -Gas consumption can be done manually, generally by the module developer in the [`BeginBlocker`, `EndBlocker`](/docs/sdk/v0.50//build/building-modules/beginblock-endblock) or [`Msg` service](/docs/sdk/v0.50//build/building-modules/msg-services), but most of the time it is done automatically whenever there is a read or write to the store. This automatic gas consumption logic is implemented in a special store called [`GasKv`](/docs/sdk/v0.50/learn/advanced/store#gaskv-store). +Gas consumption can be done manually, generally by the module developer in the [`BeginBlocker`, `EndBlocker`](/docs/sdk/v0.50/build/building-modules/beginblock-endblock) or [`Msg` service](/docs/sdk/v0.50/build/building-modules/msg-services), but most of the time it is done automatically whenever there is a read or write to the store. This automatic gas consumption logic is implemented in a special store called [`GasKv`](/docs/sdk/v0.50/learn/advanced/store#gaskv-store). ### Block Gas Meter @@ -604,7 +604,7 @@ This enables developers to play with various types for the transaction of their // Reference: https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/proto/cosmos/tx/v1beta1/tx.proto#L14-L27 ``` -* Verify signatures for each [`message`](/docs/sdk/v0.50//build/building-modules/messages-and-queries#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`. +* Verify signatures for each [`message`](/docs/sdk/v0.50/build/building-modules/messages-and-queries#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. * Set `newCtx.GasMeter` to 0, with a limit of `GasWanted`. **This step is crucial**, as it not only makes sure the transaction cannot consume infinite gas, but also that `ctx.GasMeter` is reset in-between each transaction (`ctx` is set to `newCtx` after `anteHandler` is run, and the `anteHandler` is run each time a transactions executes). diff --git a/docs/sdk/v0.50/learn/beginner/query-lifecycle.mdx b/docs/sdk/v0.50/learn/beginner/query-lifecycle.mdx index eb5806e2..3d751034 100644 --- a/docs/sdk/v0.50/learn/beginner/query-lifecycle.mdx +++ b/docs/sdk/v0.50/learn/beginner/query-lifecycle.mdx @@ -15,9 +15,9 @@ This document describes the lifecycle of a query in a Cosmos SDK application, fr ## Query Creation -A [**query**](/docs/sdk/v0.50//build/building-modules/messages-and-queries#queries) is a request for information made by end-users of applications through an interface and processed by a full-node. Users can query information about the network, the application itself, and application state directly from the application's stores or modules. Note that queries are different from [transactions](/docs/sdk/v0.50/learn/advanced/transactions) (view the lifecycle [here](/docs/sdk/v0.50/learn/beginner/tx-lifecycle)), particularly in that they do not require consensus to be processed (as they do not trigger state-transitions); they can be fully handled by one full-node. +A [**query**](/docs/sdk/v0.50/build/building-modules/messages-and-queries#queries) is a request for information made by end-users of applications through an interface and processed by a full-node. Users can query information about the network, the application itself, and application state directly from the application's stores or modules. Note that queries are different from [transactions](/docs/sdk/v0.50/learn/advanced/transactions) (view the lifecycle [here](/docs/sdk/v0.50/learn/beginner/tx-lifecycle)), particularly in that they do not require consensus to be processed (as they do not trigger state-transitions); they can be fully handled by one full-node. -For the purpose of explaining the query lifecycle, let's say the query, `MyQuery`, is requesting a list of delegations made by a certain delegator address in the application called `simapp`. As is to be expected, the [`staking`](/docs/sdk/v0.50//build/modules/staking/README) module handles this query. But first, there are a few ways `MyQuery` can be created by users. +For the purpose of explaining the query lifecycle, let's say the query, `MyQuery`, is requesting a list of delegations made by a certain delegator address in the application called `simapp`. As is to be expected, the [`staking`](/docs/sdk/v0.50/build/modules/staking/README) module handles this query. But first, there are a few ways `MyQuery` can be created by users. ### CLI @@ -27,7 +27,7 @@ The main interface for an application is the command-line interface. Users conne simd query staking delegations ``` -This query command was defined by the [`staking`](/docs/sdk/v0.50//build/modules/staking/README) module developer and added to the list of subcommands by the application developer when creating the CLI. +This query command was defined by the [`staking`](/docs/sdk/v0.50/build/modules/staking/README) module developer and added to the list of subcommands by the application developer when creating the CLI. Note that the general format is as follows: @@ -35,7 +35,7 @@ Note that the general format is as follows: simd query [moduleName] [command] --flag ``` -To provide values such as `--node` (the full-node the CLI connects to), the user can use the [`app.toml`](/docs/sdk/v0.50//user/run-node/run-node#configuring-the-node-using-apptoml-and-configtoml) config file to set them or provide them as flags. +To provide values such as `--node` (the full-node the CLI connects to), the user can use the [`app.toml`](/docs/sdk/v0.50/user/run-node/run-node#configuring-the-node-using-apptoml-and-configtoml) config file to set them or provide them as flags. The CLI understands a specific set of commands, defined in a hierarchical structure by the application developer: from the [root command](/docs/sdk/v0.50/learn/advanced/cli#root-command) (`simd`), the type of command (`Myquery`), the module that contains the command (`staking`), and command itself (`delegations`). Thus, the CLI knows exactly which module handles this command and directly passes the call there. @@ -74,7 +74,7 @@ The preceding examples show how an external user can interact with a node by que The first thing that is created in the execution of a CLI command is a `client.Context`. A `client.Context` is an object that stores all the data needed to process a request on the user side. In particular, a `client.Context` stores the following: * **Codec**: The [encoder/decoder](/docs/sdk/v0.50/learn/advanced/encoding) used by the application, used to marshal the parameters and query before making the CometBFT RPC request and unmarshal the returned response into a JSON object. The default codec used by the CLI is Protobuf. -* **Account Decoder**: The account decoder from the [`auth`](/docs/sdk/v0.50//build/modules/auth/README) module, which translates `[]byte`s into accounts. +* **Account Decoder**: The account decoder from the [`auth`](/docs/sdk/v0.50/build/modules/auth/README) module, which translates `[]byte`s into accounts. * **RPC Client**: The CometBFT RPC Client, or node, to which requests are relayed. * **Keyring**: A \[Key Manager]../beginner/03-accounts.md#keyring) used to sign transactions and handle other operations with keys. * **Output Writer**: A [Writer](https://pkg.go.dev/io/#Writer) used to output the response. @@ -2455,7 +2455,7 @@ Read more about ABCI Clients and CometBFT RPC in the [CometBFT documentation](ht When a query is received by the full-node after it has been relayed from the underlying consensus engine, it is at that point being handled within an environment that understands application-specific types and has a copy of the state. [`baseapp`](/docs/sdk/v0.50/learn/advanced/baseapp) implements the ABCI [`Query()`](/docs/sdk/v0.50/learn/advanced/baseapp#query) function and handles gRPC queries. The query route is parsed, and it matches the fully-qualified service method name of an existing service method (most likely in one of the modules), then `baseapp` relays the request to the relevant module. -Since `MyQuery` has a Protobuf fully-qualified service method name from the `staking` module (recall `/cosmos.staking.v1beta1.Query/Delegations`), `baseapp` first parses the path, then uses its own internal `GRPCQueryRouter` to retrieve the corresponding gRPC handler, and routes the query to the module. The gRPC handler is responsible for recognizing this query, retrieving the appropriate values from the application's stores, and returning a response. Read more about query services [here](/docs/sdk/v0.50//build/building-modules/query-services). +Since `MyQuery` has a Protobuf fully-qualified service method name from the `staking` module (recall `/cosmos.staking.v1beta1.Query/Delegations`), `baseapp` first parses the path, then uses its own internal `GRPCQueryRouter` to retrieve the corresponding gRPC handler, and routes the query to the module. The gRPC handler is responsible for recognizing this query, retrieving the appropriate values from the application's stores, and returning a response. Read more about query services [here](/docs/sdk/v0.50/build/building-modules/query-services). Once a result is received from the querier, `baseapp` begins the process of returning a response to the user. diff --git a/docs/sdk/v0.50/learn/beginner/tx-lifecycle.mdx b/docs/sdk/v0.50/learn/beginner/tx-lifecycle.mdx index b0032d75..4f07c1fd 100644 --- a/docs/sdk/v0.50/learn/beginner/tx-lifecycle.mdx +++ b/docs/sdk/v0.50/learn/beginner/tx-lifecycle.mdx @@ -91,7 +91,7 @@ To discard obviously invalid messages, the `BaseApp` type calls the `ValidateBas `ValidateBasic` can include only **stateless** checks (the checks that do not require access to the state). -The `ValidateBasic` method on messages has been deprecated in favor of validating messages directly in their respective [`Msg` services](/docs/sdk/v0.50//build/building-modules/msg-services#Validation). +The `ValidateBasic` method on messages has been deprecated in favor of validating messages directly in their respective [`Msg` services](/docs/sdk/v0.50/build/building-modules/msg-services#Validation). Read [RFC 001](https://docs.cosmos.network/main/rfc/rfc-001-tx-validation) for more details. @@ -102,7 +102,7 @@ Read [RFC 001](https://docs.cosmos.network/main/rfc/rfc-001-tx-validation) for m #### Guideline -`ValidateBasic` should not be used anymore. Message validation should be performed in the `Msg` service when [handling a message](/docs/sdk/v0.50//build/building-modules/msg-services#Validation) in a module Msg Server. +`ValidateBasic` should not be used anymore. Message validation should be performed in the `Msg` service when [handling a message](/docs/sdk/v0.50/build/building-modules/msg-services#Validation) in a module Msg Server. ### AnteHandler @@ -225,8 +225,8 @@ Instead of using their `checkState`, full-nodes use `finalizeblock`: * **`MsgServiceRouter`:** After `CheckTx` exits, `FinalizeBlock` continues to run [`runMsgs`](/docs/sdk/v0.50/learn/advanced/baseapp#runtx-antehandler-runmsgs-posthandler) to fully execute each `Msg` within the transaction. Since the transaction may have messages from different modules, `BaseApp` needs to know which module - to find the appropriate handler. This is achieved using `BaseApp`'s `MsgServiceRouter` so that it can be processed by the module's Protobuf [`Msg` service](/docs/sdk/v0.50//build/building-modules/msg-services). - For `LegacyMsg` routing, the `Route` function is called via the [module manager](/docs/sdk/v0.50//build/building-modules/module-manager) to retrieve the route name and find the legacy [`Handler`](/docs/sdk/v0.50//build/building-modules/msg-services#handler-type) within the module. + to find the appropriate handler. This is achieved using `BaseApp`'s `MsgServiceRouter` so that it can be processed by the module's Protobuf [`Msg` service](/docs/sdk/v0.50/build/building-modules/msg-services). + For `LegacyMsg` routing, the `Route` function is called via the [module manager](/docs/sdk/v0.50/build/building-modules/module-manager) to retrieve the route name and find the legacy [`Handler`](/docs/sdk/v0.50/build/building-modules/msg-services#handler-type) within the module. * **`Msg` service:** Protobuf `Msg` service is responsible for executing each message in the `Tx` and causes state transitions to persist in `finalizeBlockState`. diff --git a/docs/sdk/v0.50/learn/intro/sdk-app-architecture.mdx b/docs/sdk/v0.50/learn/intro/sdk-app-architecture.mdx index 7c063b60..93bc8612 100644 --- a/docs/sdk/v0.50/learn/intro/sdk-app-architecture.mdx +++ b/docs/sdk/v0.50/learn/intro/sdk-app-architecture.mdx @@ -84,7 +84,7 @@ Note that **CometBFT only handles transaction bytes**. It has no knowledge of wh Here are the most important messages of the ABCI: * `CheckTx`: When a transaction is received by CometBFT, it is passed to the application to check if a few basic requirements are met. `CheckTx` is used to protect the mempool of full-nodes against spam transactions. . A special handler called the [`AnteHandler`](/docs/sdk/v0.50/learn/beginner/gas-fees#antehandler) is used to execute a series of validation steps such as checking for sufficient fees and validating the signatures. If the checks are valid, the transaction is added to the [mempool](https://docs.cometbft.com/v0.37/spec/p2p/messages/mempool) and relayed to peer nodes. Note that transactions are not processed (i.e. no modification of the state occurs) with `CheckTx` since they have not been included in a block yet. -* `DeliverTx`: When a [valid block](https://docs.cometbft.com/v0.37/spec/core/data_structures#block) is received by CometBFT, 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](/docs/sdk/v0.50//build/building-modules/msg-services) RPC for each message in the transaction. +* `DeliverTx`: When a [valid block](https://docs.cometbft.com/v0.37/spec/core/data_structures#block) is received by CometBFT, 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](/docs/sdk/v0.50/build/building-modules/msg-services) 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 [CometBFT docs](https://docs.cometbft.com/v0.37/spec/abci/). diff --git a/docs/sdk/v0.50/user/run-node/interact-node.mdx b/docs/sdk/v0.50/user/run-node/interact-node.mdx index f82dd6d3..41aa1656 100644 --- a/docs/sdk/v0.50/user/run-node/interact-node.mdx +++ b/docs/sdk/v0.50/user/run-node/interact-node.mdx @@ -10,7 +10,7 @@ There are multiple ways to interact with a node: using the CLI, using gRPC or us **Pre-requisite Readings** -* [gRPC, REST and CometBFT Endpoints](/docs/sdk/v0.50//learn/advanced/grpc_rest) +* [gRPC, REST and CometBFT Endpoints](/docs/sdk/v0.50/learn/advanced/grpc_rest) * [Running a Node](/docs/sdk/v0.50/user/run-node/run-node) @@ -54,7 +54,7 @@ You should see two delegations, the first one made from the `gentx`, and the sec ## Using gRPC -The Protobuf ecosystem developed tools for different use cases, including code-generation from `*.proto` files into various languages. These tools allow the building of clients easily. Often, the client connection (i.e. the transport) can be plugged and replaced very easily. Let's explore one of the most popular transport: [gRPC](/docs/sdk/v0.50//learn/advanced/grpc_rest). +The Protobuf ecosystem developed tools for different use cases, including code-generation from `*.proto` files into various languages. These tools allow the building of clients easily. Often, the client connection (i.e. the transport) can be plugged and replaced very easily. Let's explore one of the most popular transport: [gRPC](/docs/sdk/v0.50/learn/advanced/grpc_rest). Since the code generation library largely depends on your own tech stack, we will only present three alternatives: @@ -258,7 +258,7 @@ CosmJS documentation can be found at [Link](https://cosmos.github.io/cosmjs). As ## Using the REST Endpoints -As described in the [gRPC guide](/docs/sdk/v0.50//learn/advanced/grpc_rest), all gRPC services on the Cosmos SDK are made available for more convenient REST-based queries through gRPC-gateway. The format of the URL path is based on the Protobuf service method's full-qualified name, but may contain small customizations so that final URLs look more idiomatic. For example, the REST endpoint for the `cosmos.bank.v1beta1.Query/AllBalances` method is `GET /cosmos/bank/v1beta1/balances/{address}`. Request arguments are passed as query parameters. +As described in the [gRPC guide](/docs/sdk/v0.50/learn/advanced/grpc_rest), all gRPC services on the Cosmos SDK are made available for more convenient REST-based queries through gRPC-gateway. The format of the URL path is based on the Protobuf service method's full-qualified name, but may contain small customizations so that final URLs look more idiomatic. For example, the REST endpoint for the `cosmos.bank.v1beta1.Query/AllBalances` method is `GET /cosmos/bank/v1beta1/balances/{address}`. Request arguments are passed as query parameters. Note that the REST endpoints are not enabled by default. To enable them, edit the `api` section of your `~/.simapp/config/app.toml` file: diff --git a/docs/sdk/v0.50/user/run-node/keyring.mdx b/docs/sdk/v0.50/user/run-node/keyring.mdx index 741de58e..5c0579c2 100644 --- a/docs/sdk/v0.50/user/run-node/keyring.mdx +++ b/docs/sdk/v0.50/user/run-node/keyring.mdx @@ -4,7 +4,7 @@ title: Setting up the keyring **Synopsis** -This document describes how to configure and use the keyring and its various backends for an [**application**](/docs/sdk/v0.50//learn/beginner/app-anatomy). +This document describes how to configure and use the keyring and its various backends for an [**application**](/docs/sdk/v0.50/learn/beginner/app-anatomy). The keyring holds the private/public keypairs used to interact with a node. For instance, a validator key needs to be set up before running the blockchain node, so that blocks can be correctly signed. The private key can be stored in different locations, called "backends", such as a file or the operating system's own key storage. diff --git a/docs/sdk/v0.50/user/run-node/run-node.mdx b/docs/sdk/v0.50/user/run-node/run-node.mdx index e6be0439..c84570ad 100644 --- a/docs/sdk/v0.50/user/run-node/run-node.mdx +++ b/docs/sdk/v0.50/user/run-node/run-node.mdx @@ -10,7 +10,7 @@ Now that the application is ready and the keyring populated, it's time to see ho **Pre-requisite Readings** -* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.50//learn/beginner/app-anatomy) +* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.50/learn/beginner/app-anatomy) * [Setting up the keyring](/docs/sdk/v0.50/user/run-node/keyring) @@ -86,7 +86,7 @@ simd genesis add-genesis-account $MY_VALIDATOR_ADDRESS 100000000000stake Recall that `$MY_VALIDATOR_ADDRESS` is a variable that holds the address of the `my_validator` key in the [keyring](/docs/sdk/v0.50/user/run-node/keyring#adding-keys-to-the-keyring). Also note that the tokens in the Cosmos SDK have the `{amount}{denom}` format: `amount` is an 18-digit-precision decimal number, and `denom` is the unique token identifier with its denomination key (e.g. `atom` or `uatom`). Here, we are granting `stake` tokens, as `stake` is the token identifier used for staking in [`simapp`](https://github.com/cosmos/cosmos-sdk/tree/main/simapp). For your own chain with its own staking denom, that token identifier should be used instead. -Now that your account has some tokens, you need to add a validator to your chain. Validators are special full-nodes that participate in the consensus process (implemented in the [underlying consensus engine](/docs/sdk/v0.50//learn/intro/sdk-app-architecture#cometbft)) in order to add new blocks to the chain. Any account can declare its intention to become a validator operator, but only those with sufficient delegation get to enter the active set (for example, only the top 125 validator candidates with the most delegation get to be validators in the Cosmos Hub). For this guide, you will add your local node (created via the `init` command above) as a validator of your chain. Validators can be declared before a chain is first started via a special transaction included in the genesis file called a `gentx`: +Now that your account has some tokens, you need to add a validator to your chain. Validators are special full-nodes that participate in the consensus process (implemented in the [underlying consensus engine](/docs/sdk/v0.50/learn/intro/sdk-app-architecture#cometbft)) in order to add new blocks to the chain. Any account can declare its intention to become a validator operator, but only those with sufficient delegation get to enter the active set (for example, only the top 125 validator candidates with the most delegation get to be validators in the Cosmos Hub). For this guide, you will add your local node (created via the `init` command above) as a validator of your chain. Validators can be declared before a chain is first started via a special transaction included in the genesis file called a `gentx`: ```bash # Create a gentx. diff --git a/docs/sdk/v0.50/user/run-node/txs.mdx b/docs/sdk/v0.50/user/run-node/txs.mdx index 2514c84e..1330ad27 100644 --- a/docs/sdk/v0.50/user/run-node/txs.mdx +++ b/docs/sdk/v0.50/user/run-node/txs.mdx @@ -378,7 +378,7 @@ error { ### Broadcasting a Transaction -The preferred way to broadcast a transaction is to use gRPC, though using REST (via `gRPC-gateway`) or the CometBFT RPC is also posible. An overview of the differences between these methods is exposed [here](/docs/sdk/v0.50//learn/advanced/grpc_rest). For this tutorial, we will only describe the gRPC method. +The preferred way to broadcast a transaction is to use gRPC, though using REST (via `gRPC-gateway`) or the CometBFT RPC is also posible. An overview of the differences between these methods is exposed [here](/docs/sdk/v0.50/learn/advanced/grpc_rest). For this tutorial, we will only describe the gRPC method. ```go expandable import ( diff --git a/docs/sdk/v0.53/build/architecture/adr-033-protobuf-inter-module-comm.mdx b/docs/sdk/v0.53/build/architecture/adr-033-protobuf-inter-module-comm.mdx index 90daebd3..6e585b47 100644 --- a/docs/sdk/v0.53/build/architecture/adr-033-protobuf-inter-module-comm.mdx +++ b/docs/sdk/v0.53/build/architecture/adr-033-protobuf-inter-module-comm.mdx @@ -23,7 +23,7 @@ service definitions defined in [ADR 021](/docs/sdk/v0.50/build/architecture/adr- ## Context -In the current Cosmos SDK documentation on the [Object-Capability Model](/docs/sdk/v0.50//learn/advanced/ocap), it is stated that: +In the current Cosmos SDK documentation on the [Object-Capability Model](/docs/sdk/v0.50/learn/advanced/ocap), it is stated that: > We assume that a thriving ecosystem of Cosmos SDK modules that are easy to compose into a blockchain application will contain faulty or malicious modules. diff --git a/docs/sdk/v0.53/build/architecture/adr-076-tx-malleability.mdx b/docs/sdk/v0.53/build/architecture/adr-076-tx-malleability.mdx index 484f2f47..2dc288d0 100644 --- a/docs/sdk/v0.53/build/architecture/adr-076-tx-malleability.mdx +++ b/docs/sdk/v0.53/build/architecture/adr-076-tx-malleability.mdx @@ -90,7 +90,7 @@ representation. #### Fields not covered by Amino JSON -Another area that needs to be addressed carefully is the discrepancy between `AminoSignDoc`(see [`aminojson.proto`](/docs/sdk/v0.50//x/tx/signing/aminojson/internal/aminojsonpb/aminojson.proto)) used for `SIGN_MODE_LEGACY_AMINO_JSON` and the actual contents of `TxBody` and `AuthInfo` (see [`tx.proto`](/docs/sdk/v0.50//proto/cosmos/tx/v1beta1/tx.proto)). +Another area that needs to be addressed carefully is the discrepancy between `AminoSignDoc`(see [`aminojson.proto`](/docs/sdk/v0.50/x/tx/signing/aminojson/internal/aminojsonpb/aminojson.proto)) used for `SIGN_MODE_LEGACY_AMINO_JSON` and the actual contents of `TxBody` and `AuthInfo` (see [`tx.proto`](/docs/sdk/v0.50/proto/cosmos/tx/v1beta1/tx.proto)). If fields get added to `TxBody` or `AuthInfo`, they must either have a corresponding representing in `AminoSignDoc` or Amino JSON signatures must be rejected when those new fields are set. Making sure that this is done is a highly manual process, and developers could easily make the mistake of updating `TxBody` or `AuthInfo` without paying any attention to the implementation of `GetSignBytes` for Amino JSON. This is a critical @@ -169,5 +169,5 @@ or get rejected. * [ADR 027: Deterministic Protobuf Serialization](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-027-deterministic-protobuf-serialization.md) * [ADR 020](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-020-protobuf-transaction-encoding.md#unknown-field-filtering) -* [`aminojson.proto`](/docs/sdk/v0.50//x/tx/signing/aminojson/internal/aminojsonpb/aminojson.proto) -* [`tx.proto`](/docs/sdk/v0.50//proto/cosmos/tx/v1beta1/tx.proto) +* [`aminojson.proto`](/docs/sdk/v0.50/x/tx/signing/aminojson/internal/aminojsonpb/aminojson.proto) +* [`tx.proto`](/docs/sdk/v0.50/proto/cosmos/tx/v1beta1/tx.proto) diff --git a/docs/sdk/v0.53/build/building-modules/beginblock-endblock.mdx b/docs/sdk/v0.53/build/building-modules/beginblock-endblock.mdx index 72bedf43..8198e6ab 100644 --- a/docs/sdk/v0.53/build/building-modules/beginblock-endblock.mdx +++ b/docs/sdk/v0.53/build/building-modules/beginblock-endblock.mdx @@ -5,13 +5,13 @@ title: BeginBlocker and EndBlocker **Synopsis** -`BeginBlocker` and `EndBlocker` are optional methods module developers can implement in their module. They will be triggered at the beginning and at the end of each block respectively, when the [`BeginBlock`](/docs/sdk/v0.53//learn/advanced/baseapp#beginblock) and [`EndBlock`](/docs/sdk/v0.53//learn/advanced/baseapp#endblock) ABCI messages are received from the underlying consensus engine. +`BeginBlocker` and `EndBlocker` are optional methods module developers can implement in their module. They will be triggered at the beginning and at the end of each block respectively, when the [`BeginBlock`](/docs/sdk/v0.53/learn/advanced/baseapp#beginblock) and [`EndBlock`](/docs/sdk/v0.53/learn/advanced/baseapp#endblock) ABCI messages are received from the underlying consensus engine. **Pre-requisite Readings** -* [Module Manager](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) +* [Module Manager](/docs/sdk/v0.53/build/building-modules/module-manager) @@ -21,17 +21,17 @@ title: BeginBlocker and EndBlocker In 0.47.0, Prepare and Process Proposal were added that allow app developers to do arbitrary work at those phases, but they do not influence the work that will be done in BeginBlock. If an application required `BeginBlock` to execute prior to any sort of work is done then this is not possible today (0.50.0). -When needed, `BeginBlocker` and `EndBlocker` are implemented as part of the [`HasBeginBlocker`, `HasABCIEndBlocker` and `EndBlocker` interfaces](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#appmodule). This means either can be left-out if not required. The `BeginBlock` and `EndBlock` methods of the interface implemented in `module.go` generally defer to `BeginBlocker` and `EndBlocker` methods respectively, which are usually implemented in `abci.go`. +When needed, `BeginBlocker` and `EndBlocker` are implemented as part of the [`HasBeginBlocker`, `HasABCIEndBlocker` and `EndBlocker` interfaces](/docs/sdk/v0.53/build/building-modules/module-manager#appmodule). This means either can be left-out if not required. The `BeginBlock` and `EndBlock` methods of the interface implemented in `module.go` generally defer to `BeginBlocker` and `EndBlocker` methods respectively, which are usually implemented in `abci.go`. The actual implementation of `BeginBlocker` and `EndBlocker` in `abci.go` are very similar to that of a [`Msg` service](/docs/sdk/v0.53/build/building-modules/msg-services): -* They generally use the [`keeper`](/docs/sdk/v0.53/build/building-modules/keeper) and [`ctx`](/docs/sdk/v0.53//learn/advanced/context) to retrieve information about the latest state. +* They generally use the [`keeper`](/docs/sdk/v0.53/build/building-modules/keeper) and [`ctx`](/docs/sdk/v0.53/learn/advanced/context) to retrieve information about the latest state. * If needed, they use the `keeper` and `ctx` to trigger state-transitions. -* If needed, they can emit [`events`](/docs/sdk/v0.53//learn/advanced/events) via the `ctx`'s `EventManager`. +* If needed, they can emit [`events`](/docs/sdk/v0.53/learn/advanced/events) via the `ctx`'s `EventManager`. A specific type of `EndBlocker` is available to return validator updates to the underlying consensus engine in the form of an [`[]abci.ValidatorUpdates`](https://docs.cometbft.com/v0.37/spec/abci/abci++_methods#endblock). This is the preferred way to implement custom validator changes. -It is possible for developers to define the order of execution between the `BeginBlocker`/`EndBlocker` functions of each of their application's modules via the module's manager `SetOrderBeginBlocker`/`SetOrderEndBlocker` methods. For more on the module manager, click [here](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager). +It is possible for developers to define the order of execution between the `BeginBlocker`/`EndBlocker` functions of each of their application's modules via the module's manager `SetOrderBeginBlocker`/`SetOrderEndBlocker` methods. For more on the module manager, click [here](/docs/sdk/v0.53/build/building-modules/module-manager). See an example implementation of `BeginBlocker` from the `distribution` module: diff --git a/docs/sdk/v0.53/build/building-modules/genesis.mdx b/docs/sdk/v0.53/build/building-modules/genesis.mdx index b674751b..746764bc 100644 --- a/docs/sdk/v0.53/build/building-modules/genesis.mdx +++ b/docs/sdk/v0.53/build/building-modules/genesis.mdx @@ -11,14 +11,14 @@ Modules generally handle a subset of the state and, as such, they need to define **Pre-requisite Readings** -* [Module Manager](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) +* [Module Manager](/docs/sdk/v0.53/build/building-modules/module-manager) * [Keepers](/docs/sdk/v0.53/build/building-modules/keeper) ## Type Definition -The subset of the genesis state defined from a given module is generally defined in a `genesis.proto` file ([more info](/docs/sdk/v0.53//learn/advanced/encoding#gogoproto) on how to define protobuf messages). The struct defining the module's subset of the genesis state is usually called `GenesisState` and contains all the module-related values that need to be initialized during the genesis process. +The subset of the genesis state defined from a given module is generally defined in a `genesis.proto` file ([more info](/docs/sdk/v0.53/learn/advanced/encoding#gogoproto) on how to define protobuf messages). The struct defining the module's subset of the genesis state is usually called `GenesisState` and contains all the module-related values that need to be initialized during the genesis process. See an example of `GenesisState` protobuf message definition from the `auth` module: @@ -608,13 +608,13 @@ return accounts, nil ## Other Genesis Methods -Other than the methods related directly to `GenesisState`, module developers are expected to implement two other methods as part of the [`AppModuleGenesis` interface](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#appmodulegenesis) (only if the module needs to initialize a subset of state in genesis). These methods are [`InitGenesis`](#initgenesis) and [`ExportGenesis`](#exportgenesis). +Other than the methods related directly to `GenesisState`, module developers are expected to implement two other methods as part of the [`AppModuleGenesis` interface](/docs/sdk/v0.53/build/building-modules/module-manager#appmodulegenesis) (only if the module needs to initialize a subset of state in genesis). These methods are [`InitGenesis`](#initgenesis) and [`ExportGenesis`](#exportgenesis). ### `InitGenesis` -The `InitGenesis` method is executed during [`InitChain`](/docs/sdk/v0.53//learn/advanced/baseapp#initchain) when the application is first started. Given a `GenesisState`, it initializes the subset of the state managed by the module by using the module's [`keeper`](/docs/sdk/v0.53/build/building-modules/keeper) setter function on each parameter within the `GenesisState`. +The `InitGenesis` method is executed during [`InitChain`](/docs/sdk/v0.53/learn/advanced/baseapp#initchain) when the application is first started. Given a `GenesisState`, it initializes the subset of the state managed by the module by using the module's [`keeper`](/docs/sdk/v0.53/build/building-modules/keeper) setter function on each parameter within the `GenesisState`. -The [module manager](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) of the application is responsible for calling the `InitGenesis` method of each of the application's modules in order. This order is set by the application developer via the manager's `SetOrderGenesisMethod`, which is called in the [application's constructor function](/docs/sdk/v0.53//learn/beginner/app-anatomy#constructor-function). +The [module manager](/docs/sdk/v0.53/build/building-modules/module-manager) of the application is responsible for calling the `InitGenesis` method of each of the application's modules in order. This order is set by the application developer via the manager's `SetOrderGenesisMethod`, which is called in the [application's constructor function](/docs/sdk/v0.53/learn/beginner/app-anatomy#constructor-function). See an example of `InitGenesis` from the `auth` module: diff --git a/docs/sdk/v0.53/build/building-modules/intro.mdx b/docs/sdk/v0.53/build/building-modules/intro.mdx index 7b9165d7..7e478c8d 100644 --- a/docs/sdk/v0.53/build/building-modules/intro.mdx +++ b/docs/sdk/v0.53/build/building-modules/intro.mdx @@ -10,7 +10,7 @@ Modules define most of the logic of Cosmos SDK applications. Developers compose **Pre-requisite Readings** -* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.53/learn/beginner/app-anatomyy) +* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.53/learn/beginner/app-anatomy) * [Lifecycle of a Cosmos SDK transaction](/docs/sdk/v0.53/learn/beginner/tx-lifecycle) @@ -299,6 +299,6 @@ Modules are by convention defined in the `./x/` subfolder (e.g. the `bank` modul * A [query service](/docs/sdk/v0.53/build/building-modules/query-services), used to process user queries when they are routed to the module by [`BaseApp`](/docs/sdk/v0.53/learn/advanced/baseapp#query-routing). * Interfaces, for end users to query the subset of the state defined by the module and create `message`s of the custom types defined in the module. -In addition to these components, modules implement the `AppModule` interface in order to be managed by the [`module manager`](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager). +In addition to these components, modules implement the `AppModule` interface in order to be managed by the [`module manager`](/docs/sdk/v0.53/build/building-modules/module-manager). Please refer to the [structure document](/docs/sdk/v0.53/build/building-modules/structure) to learn about the recommended structure of a module's directory. diff --git a/docs/sdk/v0.53/build/building-modules/invariants.mdx b/docs/sdk/v0.53/build/building-modules/invariants.mdx index 08cca567..437061cd 100644 --- a/docs/sdk/v0.53/build/building-modules/invariants.mdx +++ b/docs/sdk/v0.53/build/building-modules/invariants.mdx @@ -82,7 +82,7 @@ return DepositsInvariant(k)(ctx) } ``` -Finally, module developers need to implement the `RegisterInvariants` method as part of the [`AppModule` interface](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#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): +Finally, module developers need to implement the `RegisterInvariants` method as part of the [`AppModule` interface](/docs/sdk/v0.53/build/building-modules/module-manager#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): ```go expandable package keeper @@ -497,7 +497,7 @@ error { } ``` -The `InvariantRegistry` is therefore typically instantiated by instantiating the `keeper` of the `crisis` module in the [application's constructor function](/docs/sdk/v0.53//learn/beginner/app-anatomy#constructor-function). +The `InvariantRegistry` is therefore typically instantiated by instantiating the `keeper` of the `crisis` module in the [application's constructor function](/docs/sdk/v0.53/learn/beginner/app-anatomy#constructor-function). `Invariant`s can be checked manually via [`message`s](/docs/sdk/v0.53/build/building-modules/messages-and-queries), but most often they are checked automatically at the end of each block. Here is an example from the `crisis` module: diff --git a/docs/sdk/v0.53/build/building-modules/keeper.mdx b/docs/sdk/v0.53/build/building-modules/keeper.mdx index b1f8a22a..6853ed31 100644 --- a/docs/sdk/v0.53/build/building-modules/keeper.mdx +++ b/docs/sdk/v0.53/build/building-modules/keeper.mdx @@ -19,9 +19,9 @@ title: Keepers The Cosmos SDK is a framework that makes it easy for developers to build complex decentralized applications from scratch, mainly by composing modules together. As the ecosystem of open-source modules for the Cosmos SDK expands, it will become increasingly likely that some of these modules contain vulnerabilities, as a result of the negligence or malice of their developer. -The Cosmos SDK adopts an [object-capabilities-based approach](/docs/sdk/v0.53//learn/advanced/ocap) to help developers better protect their application from unwanted inter-module interactions, and `keeper`s are at the core of this approach. A `keeper` can be considered quite literally to be the gatekeeper of a module's store(s). Each store (typically an [`IAVL` Store](/docs/sdk/v0.53//learn/advanced/store#iavl-store)) defined within a module comes with a `storeKey`, which grants unlimited access to it. The module's `keeper` holds this `storeKey` (which should otherwise remain unexposed), and defines [methods](#implementing-methods) for reading and writing to the store(s). +The Cosmos SDK adopts an [object-capabilities-based approach](/docs/sdk/v0.53/learn/advanced/ocap) to help developers better protect their application from unwanted inter-module interactions, and `keeper`s are at the core of this approach. A `keeper` can be considered quite literally to be the gatekeeper of a module's store(s). Each store (typically an [`IAVL` Store](/docs/sdk/v0.53/learn/advanced/store#iavl-store)) defined within a module comes with a `storeKey`, which grants unlimited access to it. The module's `keeper` holds this `storeKey` (which should otherwise remain unexposed), and defines [methods](#implementing-methods) for reading and writing to the store(s). -The core idea behind the object-capabilities approach is to only reveal what is necessary to get the work done. In practice, this means that instead of handling permissions of modules through access-control lists, module `keeper`s are passed a reference to the specific instance of the other modules' `keeper`s that they need to access (this is done in the [application's constructor function](/docs/sdk/v0.53//learn/beginner/app-anatomy#constructor-function)). As a consequence, a module can only interact with the subset of state defined in another module via the methods exposed by the instance of the other module's `keeper`. This is a great way for developers to control the interactions that their own module can have with modules developed by external developers. +The core idea behind the object-capabilities approach is to only reveal what is necessary to get the work done. In practice, this means that instead of handling permissions of modules through access-control lists, module `keeper`s are passed a reference to the specific instance of the other modules' `keeper`s that they need to access (this is done in the [application's constructor function](/docs/sdk/v0.53/learn/beginner/app-anatomy#constructor-function)). As a consequence, a module can only interact with the subset of state defined in another module via the methods exposed by the instance of the other module's `keeper`. This is a great way for developers to control the interactions that their own module can have with modules developed by external developers. ## Type Definition @@ -212,11 +212,11 @@ return valUpdates.Updates Let us go through the different parameters: * An expected `keeper` is a `keeper` external to a module that is required by the internal `keeper` of said module. External `keeper`s are listed in the internal `keeper`'s type definition as interfaces. These interfaces are themselves defined in an `expected_keepers.go` file in the root of the module's folder. In this context, interfaces are used to reduce the number of dependencies, as well as to facilitate the maintenance of the module itself. -* `storeKey`s grant access to the store(s) of the [multistore](/docs/sdk/v0.53//learn/advanced/store) managed by the module. They should always remain unexposed to external modules. -* `cdc` is the [codec](/docs/sdk/v0.53//learn/advanced/encoding) used to marshall and unmarshall structs to/from `[]byte`. The `cdc` can be any of `codec.BinaryCodec`, `codec.JSONCodec` or `codec.Codec` based on your requirements. It can be either a proto or amino codec as long as they implement these interfaces. +* `storeKey`s grant access to the store(s) of the [multistore](/docs/sdk/v0.53/learn/advanced/store) managed by the module. They should always remain unexposed to external modules. +* `cdc` is the [codec](/docs/sdk/v0.53/learn/advanced/encoding) used to marshall and unmarshall structs to/from `[]byte`. The `cdc` can be any of `codec.BinaryCodec`, `codec.JSONCodec` or `codec.Codec` based on your requirements. It can be either a proto or amino codec as long as they implement these interfaces. * The authority listed is a module account or user account that has the right to change module level parameters. Previously this was handled by the param module, which has been deprecated. -Of course, it is possible to define different types of internal `keeper`s for the same module (e.g. a read-only `keeper`). Each type of `keeper` comes with its own constructor function, which is called from the [application's constructor function](/docs/sdk/v0.53//learn/beginner/app-anatomy). This is where `keeper`s are instantiated, and where developers make sure to pass correct instances of modules' `keeper`s to other modules that require them. +Of course, it is possible to define different types of internal `keeper`s for the same module (e.g. a read-only `keeper`). Each type of `keeper` comes with its own constructor function, which is called from the [application's constructor function](/docs/sdk/v0.53/learn/beginner/app-anatomy). This is where `keeper`s are instantiated, and where developers make sure to pass correct instances of modules' `keeper`s to other modules that require them. ## Implementing Methods @@ -254,7 +254,7 @@ and the method will go through the following steps: For more, see an example of `keeper`'s [methods implementation from the `staking` module](https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/staking/keeper/keeper.go). -The [module `KVStore`](/docs/sdk/v0.53//learn/advanced/store#kvstore-and-commitkvstore-interfaces) also provides an `Iterator()` method which returns an `Iterator` object to iterate over a domain of keys. +The [module `KVStore`](/docs/sdk/v0.53/learn/advanced/store#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: diff --git a/docs/sdk/v0.53/build/building-modules/messages-and-queries.mdx b/docs/sdk/v0.53/build/building-modules/messages-and-queries.mdx index a43a93c2..367dad4d 100644 --- a/docs/sdk/v0.53/build/building-modules/messages-and-queries.mdx +++ b/docs/sdk/v0.53/build/building-modules/messages-and-queries.mdx @@ -17,13 +17,13 @@ title: Messages and Queries ## Messages -`Msg`s are objects whose end-goal is to trigger state-transitions. They are wrapped in [transactions](/docs/sdk/v0.53//learn/advanced/transactions), which may contain one or more of them. +`Msg`s are objects whose end-goal is to trigger state-transitions. They are wrapped in [transactions](/docs/sdk/v0.53/learn/advanced/transactions), which may contain one or more of them. -When a transaction is relayed from the underlying consensus engine to the Cosmos SDK application, it is first decoded by [`BaseApp`](/docs/sdk/v0.53//learn/advanced/baseapp). Then, each message contained in the transaction is extracted and routed to the appropriate module via `BaseApp`'s `MsgServiceRouter` so that it can be processed by the module's [`Msg` service](/docs/sdk/v0.53/build/building-modules/msg-services). For a more detailed explanation of the lifecycle of a transaction, click [here](/docs/sdk/v0.53//learn/beginner/tx-lifecycle). +When a transaction is relayed from the underlying consensus engine to the Cosmos SDK application, it is first decoded by [`BaseApp`](/docs/sdk/v0.53/learn/advanced/baseapp). Then, each message contained in the transaction is extracted and routed to the appropriate module via `BaseApp`'s `MsgServiceRouter` so that it can be processed by the module's [`Msg` service](/docs/sdk/v0.53/build/building-modules/msg-services). For a more detailed explanation of the lifecycle of a transaction, click [here](/docs/sdk/v0.53/learn/beginner/tx-lifecycle). ### `Msg` Services -Defining Protobuf `Msg` services is the recommended way to handle messages. A Protobuf `Msg` service should be created for each module, typically in `tx.proto` (see more info about [conventions and naming](/docs/sdk/v0.53//learn/advanced/encoding#faq)). It must have an RPC service method defined for each message in the module. +Defining Protobuf `Msg` services is the recommended way to handle messages. A Protobuf `Msg` service should be created for each module, typically in `tx.proto` (see more info about [conventions and naming](/docs/sdk/v0.53/learn/advanced/encoding#faq)). It must have an RPC service method defined for each message in the module. 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` and the RPC response `MsgResponse`. For example: @@ -240,13 +240,13 @@ The Cosmos SDK uses Protobuf definitions to generate client and server code: * `MsgServer` interface defines the server API for the `Msg` service and its implementation is described as part of the [`Msg` services](/docs/sdk/v0.53/build/building-modules/msg-services) documentation. * Structures are generated for all RPC request and response types. -A `RegisterMsgServer` method is also generated and should be used to register the module's `MsgServer` implementation in `RegisterServices` method from the [`AppModule` interface](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#appmodule). +A `RegisterMsgServer` method is also generated and should be used to register the module's `MsgServer` implementation in `RegisterServices` method from the [`AppModule` interface](/docs/sdk/v0.53/build/building-modules/module-manager#appmodule). -In order for clients (CLI and grpc-gateway) to have these URLs registered, the Cosmos SDK provides the function `RegisterMsgServiceDesc(registry codectypes.InterfaceRegistry, sd *grpc.ServiceDesc)` that should be called inside module's [`RegisterInterfaces`](docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#appmodulebasic) method, using the proto-generated `&_Msg_serviceDesc` as `*grpc.ServiceDesc` argument. +In order for clients (CLI and grpc-gateway) to have these URLs registered, the Cosmos SDK provides the function `RegisterMsgServiceDesc(registry codectypes.InterfaceRegistry, sd *grpc.ServiceDesc)` that should be called inside module's [`RegisterInterfaces`](/docs/sdk/v0.53/build/building-modules/module-manager#appmodulebasic) method, using the proto-generated `&_Msg_serviceDesc` as `*grpc.ServiceDesc` argument. ## Queries -A `query` is a request for information made by end-users of applications through an interface and processed by a full-node. A `query` is received by a full-node through its consensus engine and relayed to the application via the ABCI. It is then routed to the appropriate module via `BaseApp`'s `QueryRouter` so that it can be processed by the module's query service (./04-query-services.md). For a deeper look at the lifecycle of a `query`, click [here](/docs/sdk/v0.53//learn/beginner/query-lifecycle). +A `query` is a request for information made by end-users of applications through an interface and processed by a full-node. A `query` is received by a full-node through its consensus engine and relayed to the application via the ABCI. It is then routed to the appropriate module via `BaseApp`'s `QueryRouter` so that it can be processed by the module's query service (./04-query-services.md). For a deeper look at the lifecycle of a `query`, click [here](/docs/sdk/v0.53/learn/beginner/query-lifecycle). ### gRPC Queries @@ -260,7 +260,7 @@ Here's an example of such a `Query` service definition: As `proto.Message`s, generated `Response` types implement by default `String()` method of [`fmt.Stringer`](https://pkg.go.dev/fmt#Stringer). -A `RegisterQueryServer` method is also generated and should be used to register the module's query server in the `RegisterServices` method from the [`AppModule` interface](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#appmodule). +A `RegisterQueryServer` method is also generated and should be used to register the module's query server in the `RegisterServices` method from the [`AppModule` interface](/docs/sdk/v0.53/build/building-modules/module-manager#appmodule). ### Legacy Queries @@ -272,14 +272,14 @@ queryCategory/queryRoute/queryType/arg1/arg2/... where: -* `queryCategory` is the category of the `query`, typically `custom` for module queries. It is used to differentiate between different kinds of queries within `BaseApp`'s [`Query` method](/docs/sdk/v0.53//learn/advanced/baseapp#query). -* `queryRoute` is used by `BaseApp`'s [`queryRouter`](/docs/sdk/v0.53//learn/advanced/baseapp#query-routing) to map the `query` to its module. Usually, `queryRoute` should be the name of the module. +* `queryCategory` is the category of the `query`, typically `custom` for module queries. It is used to differentiate between different kinds of queries within `BaseApp`'s [`Query` method](/docs/sdk/v0.53/learn/advanced/baseapp#query). +* `queryRoute` is used by `BaseApp`'s [`queryRouter`](/docs/sdk/v0.53/learn/advanced/baseapp#query-routing) to map the `query` to its module. Usually, `queryRoute` should be the name of the module. * `queryType` is used by the module's [`querier`](/docs/sdk/v0.53/build/building-modules/query-services#legacy-queriers) to map the `query` to the appropriate `querier function` within the module. * `args` are the actual arguments needed to process the `query`. They are filled out by the end-user. Note that for bigger queries, you might prefer passing arguments in the `Data` field of the request `req` instead of the `path`. The `path` for each `query` must be defined by the module developer in the module's [command-line interface file](/docs/sdk/v0.53/build/building-modules/module-interfaces#query-commands).Overall, there are 3 mains components module developers need to implement in order to make the subset of the state defined by their module queryable: -* A [`querier`](/docs/sdk/v0.53/build/building-modules/query-services#legacy-queriers), to process the `query` once it has been [routed to the module](/docs/sdk/v0.53//learn/advanced/baseapp#query-routing). +* A [`querier`](/docs/sdk/v0.53/build/building-modules/query-services#legacy-queriers), to process the `query` once it has been [routed to the module](/docs/sdk/v0.53/learn/advanced/baseapp#query-routing). * [Query commands](/docs/sdk/v0.53/build/building-modules/module-interfaces#query-commands) in the module's CLI file, where the `path` for each `query` is specified. * `query` return types. Typically defined in a file `types/querier.go`, they specify the result type of each of the module's `queries`. These custom types must implement the `String()` method of [`fmt.Stringer`](https://pkg.go.dev/fmt#Stringer). diff --git a/docs/sdk/v0.53/build/building-modules/module-interfaces.mdx b/docs/sdk/v0.53/build/building-modules/module-interfaces.mdx index 08695b9a..2f06cedd 100644 --- a/docs/sdk/v0.53/build/building-modules/module-interfaces.mdx +++ b/docs/sdk/v0.53/build/building-modules/module-interfaces.mdx @@ -17,11 +17,11 @@ This document details how to build CLI and REST interfaces for a module. Example ## CLI -One of the main interfaces for an application is the [command-line interface](/docs/sdk/v0.53//learn/advanced/cli). This entrypoint adds commands from the application's modules enabling end-users to create [**messages**](/docs/sdk/v0.53/build/building-modules/messages-and-queries#messages) wrapped in transactions and [**queries**](/docs/sdk/v0.53/build/building-modules/messages-and-queries#queries). The CLI files are typically found in the module's `./client/cli` folder. +One of the main interfaces for an application is the [command-line interface](/docs/sdk/v0.53/learn/advanced/cli). This entrypoint adds commands from the application's modules enabling end-users to create [**messages**](/docs/sdk/v0.53/build/building-modules/messages-and-queries#messages) wrapped in transactions and [**queries**](/docs/sdk/v0.53/build/building-modules/messages-and-queries#queries). The CLI files are typically found in the module's `./client/cli` folder. ### Transaction Commands -In order to create messages that trigger state changes, end-users must create [transactions](/docs/sdk/v0.53//learn/advanced/transactions) that wrap and deliver the messages. A transaction command creates a transaction that includes one or more messages. +In order to create messages that trigger state changes, end-users must create [transactions](/docs/sdk/v0.53/learn/advanced/transactions) that wrap and deliver the messages. A transaction command creates a transaction that includes one or more messages. Transaction commands typically have their own `tx.go` file that lives within the module's `./client/cli` folder. The commands are specified in getter functions and the name of the function should include the name of the command. diff --git a/docs/sdk/v0.53/build/building-modules/module-manager.mdx b/docs/sdk/v0.53/build/building-modules/module-manager.mdx index b02097dc..2dc2399e 100644 --- a/docs/sdk/v0.53/build/building-modules/module-manager.mdx +++ b/docs/sdk/v0.53/build/building-modules/module-manager.mdx @@ -5,7 +5,7 @@ title: Module Manager **Synopsis** -Cosmos SDK modules need to implement the [`AppModule` interfaces](#application-module-interfaces), in order to be managed by the application's [module manager](#docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager). The module manager plays an important role in [`message` and `query` routing](/docs/sdk/v0.53/learn/advanced/baseapp#routing), and allows application developers to set the order of execution of a variety of functions like [`PreBlocker`](/docs/sdk/v0.53/learn/beginner/app-anatomyy#preblocker) and [`BeginBlocker` and `EndBlocker`](/docs/sdk/v0.53/learn/beginner/app-anatomyy#begingblocker-and-endblocker). +Cosmos SDK modules need to implement the [`AppModule` interfaces](#application-module-interfaces), in order to be managed by the application's [module manager](#docs/sdk/v0.53/build/building-modules/module-manager). The module manager plays an important role in [`message` and `query` routing](/docs/sdk/v0.53/learn/advanced/baseapp#routing), and allows application developers to set the order of execution of a variety of functions like [`PreBlocker`](/docs/sdk/v0.53/learn/beginner/app-anatomy#preblocker) and [`BeginBlocker` and `EndBlocker`](/docs/sdk/v0.53/learn/beginner/app-anatomy#beginblocker-and-endblocker). @@ -47,7 +47,7 @@ The above interfaces are mostly embedding smaller interfaces (extension interfac * (legacy) [`module.HasInvariants`](#hasinvariants): The extension interface for registering invariants. * (legacy) [`module.HasConsensusVersion`](#hasconsensusversion): The extension interface for declaring a module consensus version. -The `AppModuleBasic` interface exists to define independent methods of the module, i.e. those that do not depend on other modules in the application. This allows for the construction of the basic application structure early in the application definition, generally in the `init()` function of the [main application file](/docs/sdk/v0.53/learn/beginner/app-anatomyy#core-application-file). +The `AppModuleBasic` interface exists to define independent methods of the module, i.e. those that do not depend on other modules in the application. This allows for the construction of the basic application structure early in the application definition, generally in the `init()` function of the [main application file](/docs/sdk/v0.53/learn/beginner/app-anatomy#core-application-file). The `AppModule` interface exists to define inter-dependent module methods. Many modules need to interact with other modules, typically through [`keeper`s](/docs/sdk/v0.53/build/building-modules/keeper), which means there is a need for an interface where modules list their `keeper`s and other methods that require a reference to another module's object. `AppModule` interface extension, such as `HasBeginBlocker` and `HasEndBlocker`, also enables the module manager to set the order of execution between module's methods like `BeginBlock` and `EndBlock`, which is important in cases where the order of execution between modules matters in the context of the application. @@ -13274,15 +13274,15 @@ return out It implements the following methods: -* `NewBasicManager(modules ...AppModuleBasic)`: Constructor function. It takes a list of the application's `AppModuleBasic` and builds a new `BasicManager`. This function is generally called in the `init()` function of [`app.go`](/docs/sdk/v0.53/learn/beginner/app-anatomyy#core-application-file) to quickly initialize the independent elements of the application's modules (click [here](https://github.com/cosmos/gaia/blob/main/app/app.go#L59-L74) to see an example). +* `NewBasicManager(modules ...AppModuleBasic)`: Constructor function. It takes a list of the application's `AppModuleBasic` and builds a new `BasicManager`. This function is generally called in the `init()` function of [`app.go`](/docs/sdk/v0.53/learn/beginner/app-anatomy#core-application-file) to quickly initialize the independent elements of the application's modules (click [here](https://github.com/cosmos/gaia/blob/main/app/app.go#L59-L74) to see an example). * `NewBasicManagerFromManager(manager *Manager, customModuleBasics map[string]AppModuleBasic)`: Contructor function. It creates a new `BasicManager` from a `Manager`. The `BasicManager` will contain all `AppModuleBasic` from the `AppModule` manager using `CoreAppModuleBasicAdaptor` whenever possible. Module's `AppModuleBasic` can be overridden by passing a custom AppModuleBasic map -* `RegisterLegacyAminoCodec(cdc *codec.LegacyAmino)`: Registers the [`codec.LegacyAmino`s](/docs/sdk/v0.53/learn/advanced/encoding#amino) of each of the application's `AppModuleBasic`. This function is usually called early on in the [application's construction](/docs/sdk/v0.53/learn/beginner/app-anatomyy#constructor). +* `RegisterLegacyAminoCodec(cdc *codec.LegacyAmino)`: Registers the [`codec.LegacyAmino`s](/docs/sdk/v0.53/learn/advanced/encoding#amino) of each of the application's `AppModuleBasic`. This function is usually called early on in the [application's construction](/docs/sdk/v0.53/learn/beginner/app-anatomy#constructor). * `RegisterInterfaces(registry codectypes.InterfaceRegistry)`: Registers interface types and implementations of each of the application's `AppModuleBasic`. * `DefaultGenesis(cdc codec.JSONCodec)`: Provides default genesis information for modules in the application by calling the [`DefaultGenesis(cdc codec.JSONCodec)`](/docs/sdk/v0.53/build/building-modules/genesis#defaultgenesis) function of each module. It only calls the modules that implements the `HasGenesisBasics` interfaces. * `ValidateGenesis(cdc codec.JSONCodec, txEncCfg client.TxEncodingConfig, genesis map[string]json.RawMessage)`: Validates the genesis information modules by calling the [`ValidateGenesis(codec.JSONCodec, client.TxEncodingConfig, json.RawMessage)`](/docs/sdk/v0.53/build/building-modules/genesis#validategenesis) function of modules implementing the `HasGenesisBasics` interface. * `RegisterGRPCGatewayRoutes(clientCtx client.Context, rtr *runtime.ServeMux)`: Registers gRPC routes for modules. * `AddTxCommands(rootTxCmd *cobra.Command)`: Adds modules' transaction commands (defined as `GetTxCmd() *cobra.Command`) to the application's [`rootTxCommand`](/docs/sdk/v0.53/learn/advanced/cli#transaction-commands). This function is usually called function from the `main.go` function of the [application's command-line interface](/docs/sdk/v0.53/learn/advanced/cli). -* `AddQueryCommands(rootQueryCmd *cobra.Command)`: Adds modules' query commands (defined as `GetQueryCmd() *cobra.Command`) to the application's [`rootQueryCommand`](/docs/sdk/v0.53//learn/advanced/cli#query-commands). This function is usually called function from the `main.go` function of the [application's command-line interface](/docs/sdk/v0.53//learn/advanced/cli). +* `AddQueryCommands(rootQueryCmd *cobra.Command)`: Adds modules' query commands (defined as `GetQueryCmd() *cobra.Command`) to the application's [`rootQueryCommand`](/docs/sdk/v0.53/learn/advanced/cli#query-commands). This function is usually called function from the `main.go` function of the [application's command-line interface](/docs/sdk/v0.53/learn/advanced/cli). ### `Manager` @@ -14422,26 +14422,26 @@ return out The module manager is used throughout the application whenever an action on a collection of modules is required. It implements the following methods: -* `NewManager(modules ...AppModule)`: Constructor function. It takes a list of the application's `AppModule`s and builds a new `Manager`. It is generally called from the application's main [constructor function](/docs/sdk/v0.53//learn/beginner/app-anatomy#constructor-function). -* `SetOrderInitGenesis(moduleNames ...string)`: Sets the order in which the [`InitGenesis`](/docs/sdk/v0.53/build/building-modules/genesis#initgenesis) function of each module will be called when the application is first started. This function is generally called from the application's main [constructor function](/docs/sdk/v0.53//learn/beginner/app-anatomy#constructor-function). +* `NewManager(modules ...AppModule)`: Constructor function. It takes a list of the application's `AppModule`s and builds a new `Manager`. It is generally called from the application's main [constructor function](/docs/sdk/v0.53/learn/beginner/app-anatomy#constructor-function). +* `SetOrderInitGenesis(moduleNames ...string)`: Sets the order in which the [`InitGenesis`](/docs/sdk/v0.53/build/building-modules/genesis#initgenesis) function of each module will be called when the application is first started. This function is generally called from the application's main [constructor function](/docs/sdk/v0.53/learn/beginner/app-anatomy#constructor-function). To initialize modules successfully, module dependencies should be considered. For example, the `genutil` module must occur after `staking` module so that the pools are properly initialized with tokens from genesis accounts, the `genutils` module must also occur after `auth` so that it can access the params from auth, IBC's `capability` module should be initialized before all other modules so that it can initialize any capabilities. -* `SetOrderExportGenesis(moduleNames ...string)`: Sets the order in which the [`ExportGenesis`](/docs/sdk/v0.53/build/building-modules/genesis#exportgenesis) function of each module will be called in case of an export. This function is generally called from the application's main [constructor function](/docs/sdk/v0.53//learn/beginner/app-anatomy#constructor-function). -* `SetOrderPreBlockers(moduleNames ...string)`: Sets the order in which the `PreBlock()` function of each module will be called before `BeginBlock()` of all modules. This function is generally called from the application's main [constructor function](/docs/sdk/v0.53//learn/beginner/app-anatomy#constructor-function). -* `SetOrderBeginBlockers(moduleNames ...string)`: Sets the order in which the `BeginBlock()` function of each module will be called at the beginning of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.53//learn/beginner/app-anatomy#constructor-function). -* `SetOrderEndBlockers(moduleNames ...string)`: Sets the order in which the `EndBlock()` function of each module will be called at the end of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.53//learn/beginner/app-anatomy#constructor-function). -* `SetOrderPrecommiters(moduleNames ...string)`: Sets the order in which the `Precommit()` function of each module will be called during commit of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.53//learn/beginner/app-anatomy#constructor-function). -* `SetOrderPrepareCheckStaters(moduleNames ...string)`: Sets the order in which the `PrepareCheckState()` function of each module will be called during commit of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.53//learn/beginner/app-anatomy#constructor-function). +* `SetOrderExportGenesis(moduleNames ...string)`: Sets the order in which the [`ExportGenesis`](/docs/sdk/v0.53/build/building-modules/genesis#exportgenesis) function of each module will be called in case of an export. This function is generally called from the application's main [constructor function](/docs/sdk/v0.53/learn/beginner/app-anatomy#constructor-function). +* `SetOrderPreBlockers(moduleNames ...string)`: Sets the order in which the `PreBlock()` function of each module will be called before `BeginBlock()` of all modules. This function is generally called from the application's main [constructor function](/docs/sdk/v0.53/learn/beginner/app-anatomy#constructor-function). +* `SetOrderBeginBlockers(moduleNames ...string)`: Sets the order in which the `BeginBlock()` function of each module will be called at the beginning of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.53/learn/beginner/app-anatomy#constructor-function). +* `SetOrderEndBlockers(moduleNames ...string)`: Sets the order in which the `EndBlock()` function of each module will be called at the end of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.53/learn/beginner/app-anatomy#constructor-function). +* `SetOrderPrecommiters(moduleNames ...string)`: Sets the order in which the `Precommit()` function of each module will be called during commit of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.53/learn/beginner/app-anatomy#constructor-function). +* `SetOrderPrepareCheckStaters(moduleNames ...string)`: Sets the order in which the `PrepareCheckState()` function of each module will be called during commit of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.53/learn/beginner/app-anatomy#constructor-function). * `SetOrderMigrations(moduleNames ...string)`: Sets the order of migrations to be run. If not set then migrations will be run with an order defined in `DefaultMigrationsOrder`. * `RegisterInvariants(ir sdk.InvariantRegistry)`: Registers the [invariants](/docs/sdk/v0.53/build/building-modules/invariants) of module implementing the `HasInvariants` interface. * `RegisterServices(cfg Configurator)`: Registers the services of modules implementing the `HasServices` interface. * `InitGenesis(ctx context.Context, cdc codec.JSONCodec, genesisData map[string]json.RawMessage)`: Calls the [`InitGenesis`](/docs/sdk/v0.53/build/building-modules/genesis#initgenesis) function of each module when the application is first started, in the order defined in `OrderInitGenesis`. Returns an `abci.ResponseInitChain` to the underlying consensus engine, which can contain validator updates. * `ExportGenesis(ctx context.Context, cdc codec.JSONCodec)`: Calls the [`ExportGenesis`](/docs/sdk/v0.53/build/building-modules/genesis#exportgenesis) function of each module, in the order defined in `OrderExportGenesis`. The export constructs a genesis file from a previously existing state, and is mainly used when a hard-fork upgrade of the chain is required. * `ExportGenesisForModules(ctx context.Context, cdc codec.JSONCodec, modulesToExport []string)`: Behaves the same as `ExportGenesis`, except takes a list of modules to export. -* `BeginBlock(ctx context.Context) error`: At the beginning of each block, this function is called from [`BaseApp`](/docs/sdk/v0.53//learn/advanced/baseapp#beginblock) and, in turn, calls the [`BeginBlock`](/docs/sdk/v0.53/build/building-modules/beginblock-endblock) function of each modules implementing the `appmodule.HasBeginBlocker` interface, in the order defined in `OrderBeginBlockers`. It creates a child [context](/docs/sdk/v0.53//learn/advanced/context) with an event manager to aggregate [events](/docs/sdk/v0.53//learn/advanced/events) emitted from each modules. -* `EndBlock(ctx context.Context) error`: At the end of each block, this function is called from [`BaseApp`](/docs/sdk/v0.53//learn/advanced/baseapp#endblock) and, in turn, calls the [`EndBlock`](/docs/sdk/v0.53/build/building-modules/beginblock-endblock) function of each modules implementing the `appmodule.HasEndBlocker` interface, in the order defined in `OrderEndBlockers`. It creates a child [context](/docs/sdk/v0.53//learn/advanced/context) with an event manager to aggregate [events](/docs/sdk/v0.53//learn/advanced/events) emitted from all modules. The function returns an `abci` which contains the aforementioned events, as well as validator set updates (if any). -* `EndBlock(context.Context) ([]abci.ValidatorUpdate, error)`: At the end of each block, this function is called from [`BaseApp`](/docs/sdk/v0.53//learn/advanced/baseapp#endblock) and, in turn, calls the [`EndBlock`](/docs/sdk/v0.53/build/building-modules/beginblock-endblock) function of each modules implementing the `module.HasABCIEndBlock` interface, in the order defined in `OrderEndBlockers`. It creates a child [context](/docs/sdk/v0.53//learn/advanced/context) with an event manager to aggregate [events](/docs/sdk/v0.53//learn/advanced/events) emitted from all modules. The function returns an `abci` which contains the aforementioned events, as well as validator set updates (if any). -* `Precommit(ctx context.Context)`: During [`Commit`](/docs/sdk/v0.53//learn/advanced/baseapp#commit), this function is called from `BaseApp` immediately before the [`deliverState`](/docs/sdk/v0.53//learn/advanced/baseapp#state-updates) is written to the underlying [`rootMultiStore`](/docs/sdk/v0.53//learn/advanced/store#commitmultistore) and, in turn calls the `Precommit` function of each modules implementing the `HasPrecommit` interface, in the order defined in `OrderPrecommiters`. It creates a child [context](/docs/sdk/v0.53//learn/advanced/context) where the underlying `CacheMultiStore` is that of the newly committed block's [`finalizeblockstate`](/docs/sdk/v0.53//learn/advanced/baseapp#state-updates). -* `PrepareCheckState(ctx context.Context)`: During [`Commit`](/docs/sdk/v0.53//learn/advanced/baseapp#commit), this function is called from `BaseApp` immediately after the [`deliverState`](/docs/sdk/v0.53//learn/advanced/baseapp#state-updates) is written to the underlying [`rootMultiStore`](/docs/sdk/v0.53//learn/advanced/store#commitmultistore) and, in turn calls the `PrepareCheckState` function of each module implementing the `HasPrepareCheckState` interface, in the order defined in `OrderPrepareCheckStaters`. It creates a child [context](/docs/sdk/v0.53//learn/advanced/context) where the underlying `CacheMultiStore` is that of the next block's [`checkState`](/docs/sdk/v0.53//learn/advanced/baseapp#state-updates). Writes to this state will be present in the [`checkState`](/docs/sdk/v0.53//learn/advanced/baseapp#state-updates) of the next block, and therefore this method can be used to prepare the `checkState` for the next block. +* `BeginBlock(ctx context.Context) error`: At the beginning of each block, this function is called from [`BaseApp`](/docs/sdk/v0.53/learn/advanced/baseapp#beginblock) and, in turn, calls the [`BeginBlock`](/docs/sdk/v0.53/build/building-modules/beginblock-endblock) function of each modules implementing the `appmodule.HasBeginBlocker` interface, in the order defined in `OrderBeginBlockers`. It creates a child [context](/docs/sdk/v0.53/learn/advanced/context) with an event manager to aggregate [events](/docs/sdk/v0.53/learn/advanced/events) emitted from each modules. +* `EndBlock(ctx context.Context) error`: At the end of each block, this function is called from [`BaseApp`](/docs/sdk/v0.53/learn/advanced/baseapp#endblock) and, in turn, calls the [`EndBlock`](/docs/sdk/v0.53/build/building-modules/beginblock-endblock) function of each modules implementing the `appmodule.HasEndBlocker` interface, in the order defined in `OrderEndBlockers`. It creates a child [context](/docs/sdk/v0.53/learn/advanced/context) with an event manager to aggregate [events](/docs/sdk/v0.53/learn/advanced/events) emitted from all modules. The function returns an `abci` which contains the aforementioned events, as well as validator set updates (if any). +* `EndBlock(context.Context) ([]abci.ValidatorUpdate, error)`: At the end of each block, this function is called from [`BaseApp`](/docs/sdk/v0.53/learn/advanced/baseapp#endblock) and, in turn, calls the [`EndBlock`](/docs/sdk/v0.53/build/building-modules/beginblock-endblock) function of each modules implementing the `module.HasABCIEndBlock` interface, in the order defined in `OrderEndBlockers`. It creates a child [context](/docs/sdk/v0.53/learn/advanced/context) with an event manager to aggregate [events](/docs/sdk/v0.53/learn/advanced/events) emitted from all modules. The function returns an `abci` which contains the aforementioned events, as well as validator set updates (if any). +* `Precommit(ctx context.Context)`: During [`Commit`](/docs/sdk/v0.53/learn/advanced/baseapp#commit), this function is called from `BaseApp` immediately before the [`deliverState`](/docs/sdk/v0.53/learn/advanced/baseapp#state-updates) is written to the underlying [`rootMultiStore`](/docs/sdk/v0.53/learn/advanced/store#commitmultistore) and, in turn calls the `Precommit` function of each modules implementing the `HasPrecommit` interface, in the order defined in `OrderPrecommiters`. It creates a child [context](/docs/sdk/v0.53/learn/advanced/context) where the underlying `CacheMultiStore` is that of the newly committed block's [`finalizeblockstate`](/docs/sdk/v0.53/learn/advanced/baseapp#state-updates). +* `PrepareCheckState(ctx context.Context)`: During [`Commit`](/docs/sdk/v0.53/learn/advanced/baseapp#commit), this function is called from `BaseApp` immediately after the [`deliverState`](/docs/sdk/v0.53/learn/advanced/baseapp#state-updates) is written to the underlying [`rootMultiStore`](/docs/sdk/v0.53/learn/advanced/store#commitmultistore) and, in turn calls the `PrepareCheckState` function of each module implementing the `HasPrepareCheckState` interface, in the order defined in `OrderPrepareCheckStaters`. It creates a child [context](/docs/sdk/v0.53/learn/advanced/context) where the underlying `CacheMultiStore` is that of the next block's [`checkState`](/docs/sdk/v0.53/learn/advanced/baseapp#state-updates). Writes to this state will be present in the [`checkState`](/docs/sdk/v0.53/learn/advanced/baseapp#state-updates) of the next block, and therefore this method can be used to prepare the `checkState` for the next block. Here's an example of a concrete integration within an `simapp`: diff --git a/docs/sdk/v0.53/build/building-modules/msg-services.mdx b/docs/sdk/v0.53/build/building-modules/msg-services.mdx index 7104bd08..fed6b13f 100644 --- a/docs/sdk/v0.53/build/building-modules/msg-services.mdx +++ b/docs/sdk/v0.53/build/building-modules/msg-services.mdx @@ -5,13 +5,13 @@ title: 'Msg Services' **Synopsis** -A Protobuf `Msg` service processes [messages](/docs/sdk/v0.53/build/building-modules/messages-and-queries). Protobuf `Msg` services are specific to the module in which they are defined, and only process messages defined within the said module. They are called from `BaseApp` during [`DeliverTx`](/docs/sdk/v0.50//learn/advanced/baseapp#delivertx). +A Protobuf `Msg` service processes [messages](/docs/sdk/v0.53/build/building-modules/messages-and-queries). Protobuf `Msg` services are specific to the module in which they are defined, and only process messages defined within the said module. They are called from `BaseApp` during [`DeliverTx`](/docs/sdk/v0.50/learn/advanced/baseapp#delivertx). **Pre-requisite Readings** -* [Module Manager](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) +* [Module Manager](/docs/sdk/v0.53/build/building-modules/module-manager) * [Messages and Queries](/docs/sdk/v0.53/build/building-modules/messages-and-queries) @@ -3101,7 +3101,7 @@ After the validation is successful, the `msgServer` method uses the [`keeper`](/ ### Events -Before returning, `msgServer` methods generally emit one or more [events](/docs/sdk/v0.50//learn/advanced/events) by using the `EventManager` held in the `ctx`. Use the new `EmitTypedEvent` function that uses protobuf-based event types: +Before returning, `msgServer` methods generally emit one or more [events](/docs/sdk/v0.50/learn/advanced/events) by using the `EventManager` held in the `ctx`. Use the new `EmitTypedEvent` function that uses protobuf-based event types: ```go ctx.EventManager().EmitTypedEvent( @@ -3122,7 +3122,7 @@ ctx.EventManager().EmitEvent( ) ``` -These events are relayed back to the underlying consensus engine and can be used by service providers to implement services around the application. Click [here](/docs/sdk/v0.50//learn/advanced/events) to learn more about events. +These events are relayed back to the underlying consensus engine and can be used by service providers to implement services around the application. Click [here](/docs/sdk/v0.50/learn/advanced/events) to learn more about events. 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 context.Context, res proto.Message, err error)`: @@ -3356,7 +3356,7 @@ This diagram shows a typical structure of a Protobuf `Msg` service, and how the ## Telemetry -New [telemetry metrics](/docs/sdk/v0.50//learn/advanced/telemetry) can be created from `msgServer` methods when handling messages. +New [telemetry metrics](/docs/sdk/v0.50/learn/advanced/telemetry) can be created from `msgServer` methods when handling messages. This is an example from the `x/auth/vesting` module: diff --git a/docs/sdk/v0.53/build/building-modules/preblock.mdx b/docs/sdk/v0.53/build/building-modules/preblock.mdx index 459166ee..4ab7164b 100644 --- a/docs/sdk/v0.53/build/building-modules/preblock.mdx +++ b/docs/sdk/v0.53/build/building-modules/preblock.mdx @@ -4,13 +4,13 @@ title: PreBlocker **Synopsis** -`PreBlocker` is optional method module developers can implement in their module. They will be triggered before [`BeginBlock`](/docs/sdk/v0.53//learn/advanced/baseapp#beginblock). +`PreBlocker` is optional method module developers can implement in their module. They will be triggered before [`BeginBlock`](/docs/sdk/v0.53/learn/advanced/baseapp#beginblock). **Pre-requisite Readings** -* [Module Manager](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) +* [Module Manager](/docs/sdk/v0.53/build/building-modules/module-manager) diff --git a/docs/sdk/v0.53/build/building-modules/query-services.mdx b/docs/sdk/v0.53/build/building-modules/query-services.mdx index 37d223c8..18002818 100644 --- a/docs/sdk/v0.53/build/building-modules/query-services.mdx +++ b/docs/sdk/v0.53/build/building-modules/query-services.mdx @@ -5,13 +5,13 @@ title: Query Services **Synopsis** -A Protobuf Query service processes [`queries`](/docs/sdk/v0.53/build/building-modules/messages-and-queries). Query services are specific to the module in which they are defined, and only process `queries` defined within said module. They are called from `BaseApp`'s [`Query` method](/docs/sdk/v0.53//learn/advanced/baseapp#query). +A Protobuf Query service processes [`queries`](/docs/sdk/v0.53/build/building-modules/messages-and-queries). Query services are specific to the module in which they are defined, and only process `queries` defined within said module. They are called from `BaseApp`'s [`Query` method](/docs/sdk/v0.53/learn/advanced/baseapp#query). **Pre-requisite Readings** -* [Module Manager](/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) +* [Module Manager](/docs/sdk/v0.53/build/building-modules/module-manager) * [Messages and Queries](/docs/sdk/v0.53/build/building-modules/messages-and-queries) diff --git a/docs/sdk/v0.53/build/building-modules/simulator.mdx b/docs/sdk/v0.53/build/building-modules/simulator.mdx index c96d7c8b..8c0fb82b 100644 --- a/docs/sdk/v0.53/build/building-modules/simulator.mdx +++ b/docs/sdk/v0.53/build/building-modules/simulator.mdx @@ -5,7 +5,7 @@ title: Module Simulation **Pre-requisite Readings** -* [Cosmos Blockchain Simulator](/docs/sdk/v0.53//learn/advanced/simulation) +* [Cosmos Blockchain Simulator](/docs/sdk/v0.53/learn/advanced/simulation) @@ -1334,7 +1334,7 @@ Operations are one of the crucial parts of the Cosmos SDK simulation. They are t (`Msg`) that are simulated with random field values. The sender of the operation is also assigned randomly. -Operations on the simulation are simulated using the full [transaction cycle](/docs/sdk/v0.53//learn/advanced/transactions) of a +Operations on the simulation are simulated using the full [transaction cycle](/docs/sdk/v0.53/learn/advanced/transactions) of a `ABCI` application that exposes the `BaseApp`. ### Using Simsx diff --git a/docs/sdk/v0.53/build/building-modules/upgrade.mdx b/docs/sdk/v0.53/build/building-modules/upgrade.mdx index 934e1a13..3583bd37 100644 --- a/docs/sdk/v0.53/build/building-modules/upgrade.mdx +++ b/docs/sdk/v0.53/build/building-modules/upgrade.mdx @@ -4,13 +4,13 @@ title: Upgrading Modules **Synopsis** -[In-Place Store Migrations](/docs/sdk/v0.53//learn/advanced/upgrade) allow your modules to upgrade to new versions that include breaking changes. This document outlines how to build modules to take advantage of this functionality. +[In-Place Store Migrations](/docs/sdk/v0.53/learn/advanced/upgrade) allow your modules to upgrade to new versions that include breaking changes. This document outlines how to build modules to take advantage of this functionality. **Pre-requisite Readings** -* [In-Place Store Migration](/docs/sdk/v0.53//learn/advanced/upgrade) +* [In-Place Store Migration](/docs/sdk/v0.53/learn/advanced/upgrade) diff --git a/docs/sdk/v0.53/learn/advanced/baseapp.mdx b/docs/sdk/v0.53/learn/advanced/baseapp.mdx index fc63ba12..497e514f 100644 --- a/docs/sdk/v0.53/learn/advanced/baseapp.mdx +++ b/docs/sdk/v0.53/learn/advanced/baseapp.mdx @@ -10,7 +10,7 @@ This document describes `BaseApp`, the abstraction that implements the core func **Pre-requisite Readings** -* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.53/learn/beginner/app-anatomyy) +* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.53/learn/beginner/app-anatomy) * [Lifecycle of a Cosmos SDK transaction](/docs/sdk/v0.53/learn/beginner/tx-lifecycle) @@ -1523,7 +1523,7 @@ First, the important parameters that are initialized during the bootstrapping of * [`AnteHandler`](#antehandler): This handler is used to handle signature verification, fee payment, and other pre-message execution checks when a transaction is received. It's executed during [`CheckTx/RecheckTx`](#checktx) and [`FinalizeBlock`](#finalizeblock). -* [`InitChainer`](/docs/sdk/v0.53/learn/beginner/app-anatomyy#initchainer), [`PreBlocker`](/docs/sdk/v0.53/learn/beginner/app-anatomyy#preblocker), [`BeginBlocker` and `EndBlocker`](/docs/sdk/v0.53/learn/beginner/app-anatomyy#beginblocker-and-endblocker): These are +* [`InitChainer`](/docs/sdk/v0.53/learn/beginner/app-anatomy#initchainer), [`PreBlocker`](/docs/sdk/v0.53/learn/beginner/app-anatomy#preblocker), [`BeginBlocker` and `EndBlocker`](/docs/sdk/v0.53/learn/beginner/app-anatomy#beginblocker-and-endblocker): These are the functions executed when the application receives the `InitChain` and `FinalizeBlock` ABCI messages from the underlying CometBFT engine. @@ -1549,7 +1549,7 @@ Finally, a few more important parameters: `minGasPrices` (e.g. if `minGasPrices == 1uatom,1photon`, the `gas-price` of the transaction must be greater than `1uatom` OR `1photon`). * `appVersion`: Version of the application. It is set in the - [application's constructor function](/docs/sdk/v0.53/learn/beginner/app-anatomyy#constructor-function). + [application's constructor function](/docs/sdk/v0.53/learn/beginner/app-anatomy#constructor-function). ## Constructor @@ -1661,17 +1661,17 @@ When messages and queries are received by the application, they must be routed t ### `Msg` Service Router -[`sdk.Msg`s](/docs/sdk/v0.53//build/building-modules/messages-and-queries#messages) need to be routed after they are extracted from transactions, which are sent from the underlying CometBFT engine via the [`CheckTx`](#checktx) and [`FinalizeBlock`](#finalizeblock) 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. +[`sdk.Msg`s](/docs/sdk/v0.53/build/building-modules/messages-and-queries#messages) need to be routed after they are extracted from transactions, which are sent from the underlying CometBFT engine via the [`CheckTx`](#checktx) and [`FinalizeBlock`](#finalizeblock) 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.53.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.53.0/baseapp/msg_service_router.go#L35-L36). 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](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.53/learn/beginner/app-anatomyy#constructor-function). +The application's `msgServiceRouter` is initialized with all the routes using the application's [module manager](/docs/sdk/v0.53/build/building-modules/module-manager#manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.53/learn/beginner/app-anatomy#constructor-function). ### gRPC Query Router -Similar to `sdk.Msg`s, [`queries`](/docs/sdk/v0.53//build/building-modules/messages-and-queries#queries) need to be routed to the appropriate module's [`Query` service](/docs/sdk/v0.53//build/building-modules/query-services). To do so, `BaseApp` holds a `grpcQueryRouter`, which maps modules' fully-qualified service methods (`string`, defined in their Protobuf `Query` gRPC) to their `QueryServer` implementation. The `grpcQueryRouter` is called during the initial stages of query processing, which can be either by directly sending a gRPC query to the gRPC endpoint, or via the [`Query` ABCI message](#query) on the CometBFT RPC endpoint. +Similar to `sdk.Msg`s, [`queries`](/docs/sdk/v0.53/build/building-modules/messages-and-queries#queries) need to be routed to the appropriate module's [`Query` service](/docs/sdk/v0.53/build/building-modules/query-services). To do so, `BaseApp` holds a `grpcQueryRouter`, which maps modules' fully-qualified service methods (`string`, defined in their Protobuf `Query` gRPC) to their `QueryServer` implementation. The `grpcQueryRouter` is called during the initial stages of query processing, which can be either by directly sending a gRPC query to the gRPC endpoint, or via the [`Query` ABCI message](#query) on the CometBFT RPC endpoint. -Just like the `msgServiceRouter`, the `grpcQueryRouter` is initialized with all the query routes using the application's [module manager](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.53/learn/beginner/app-anatomyy#app-constructor). +Just like the `msgServiceRouter`, the `grpcQueryRouter` is initialized with all the query routes using the application's [module manager](/docs/sdk/v0.53/build/building-modules/module-manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.53/learn/beginner/app-anatomy#app-constructor). ## Main ABCI 2.0 Messages @@ -3665,7 +3665,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](/docs/sdk/v0.53/learn/beginner/app-anatomyy#application-constructor). The most widely used `anteHandler` is the [`auth` module](https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/x/auth/ante/ante.go). +`BaseApp` holds an `anteHandler` as parameter that is initialized in the [application's constructor](/docs/sdk/v0.53/learn/beginner/app-anatomy#application-constructor). The most widely used `anteHandler` is the [`auth` module](https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/x/auth/ante/ante.go). Click [here](/docs/sdk/v0.53/learn/beginner/gas-fees#antehandler) for more on the `anteHandler`. @@ -3673,7 +3673,7 @@ Click [here](/docs/sdk/v0.53/learn/beginner/gas-fees#antehandler) for more on th `RunMsgs` is called from `RunTx` with `runTxModeCheck` as parameter to check the existence of a route for each message the transaction, and with `execModeFinalize` to actually process the `sdk.Msg`s. -First, it retrieves the `sdk.Msg`'s fully-qualified type name, by checking the `type_url` of the Protobuf `Any` representing the `sdk.Msg`. Then, using the application's [`msgServiceRouter`](#msg-service-router), it checks for the existence of `Msg` service method related to that `type_url`. At this point, if `mode == runTxModeCheck`, `RunMsgs` returns. Otherwise, if `mode == execModeFinalize`, the [`Msg` service](/docs/sdk/v0.53//build/building-modules/msg-services) RPC is executed, before `RunMsgs` returns. +First, it retrieves the `sdk.Msg`'s fully-qualified type name, by checking the `type_url` of the Protobuf `Any` representing the `sdk.Msg`. Then, using the application's [`msgServiceRouter`](#msg-service-router), it checks for the existence of `Msg` service method related to that `type_url`. At this point, if `mode == runTxModeCheck`, `RunMsgs` returns. Otherwise, if `mode == execModeFinalize`, the [`Msg` service](/docs/sdk/v0.53/build/building-modules/msg-services) RPC is executed, before `RunMsgs` returns. ### PostHandler @@ -3716,7 +3716,7 @@ The [`InitChain` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x * [`checkState` and `finalizeBlockState`](#state-updates) via `setState`. * The [block gas meter](/docs/sdk/v0.53/learn/beginner/gas-fees#block-gas-meter), with infinite gas to process genesis transactions. -Finally, the `InitChain(req abci.RequestInitChain)` method of `BaseApp` calls the [`initChainer()`](/docs/sdk/v0.53/learn/beginner/app-anatomyy#initchainer) of the application in order to initialize the main state of the application from the `genesis file` and, if defined, call the [`InitGenesis`](/docs/sdk/v0.53//build/building-modules/genesis#initgenesis) function of each of the application's modules. +Finally, the `InitChain(req abci.RequestInitChain)` method of `BaseApp` calls the [`initChainer()`](/docs/sdk/v0.53/learn/beginner/app-anatomy#initchainer) of the application in order to initialize the main state of the application from the `genesis file` and, if defined, call the [`InitGenesis`](/docs/sdk/v0.53/build/building-modules/genesis#initgenesis) function of each of the application's modules. ### FinalizeBlock @@ -5279,7 +5279,7 @@ return legacyVotes #### PreBlock -* Run the application's [`preBlocker()`](/docs/sdk/v0.53/learn/beginner/app-anatomyy#preblocker), which mainly runs the [`PreBlocker()`](/docs/sdk/v0.53//build/building-modules/preblock#preblock) method of each of the modules. +* Run the application's [`preBlocker()`](/docs/sdk/v0.53/learn/beginner/app-anatomy#preblocker), which mainly runs the [`PreBlocker()`](/docs/sdk/v0.53/build/building-modules/preblock#preblock) method of each of the modules. #### BeginBlock @@ -6738,7 +6738,7 @@ return legacyVotes * Initialize the [block gas meter](/docs/sdk/v0.53/learn/beginner/gas-fees#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()`](/docs/sdk/v0.53/learn/beginner/app-anatomyy#beginblocker-and-endblocker), which mainly runs the [`BeginBlocker()`](/docs/sdk/v0.53//build/building-modules/beginblock-endblock#beginblock) method of each of the modules. +* Run the application's [`beginBlocker()`](/docs/sdk/v0.53/learn/beginner/app-anatomy#beginblocker-and-endblocker), which mainly runs the [`BeginBlocker()`](/docs/sdk/v0.53/build/building-modules/beginblock-endblock#beginblock) method of each of the modules. * Set the [`VoteInfos`](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_methods.md#voteinfo) of the application, i.e. the list of validators whose *precommit* for the previous block was included by the proposer of the current block. This information is carried into the [`Context`](/docs/sdk/v0.53/learn/advanced/context) so that it can be used during transaction execution and EndBlock. @@ -8200,7 +8200,7 @@ GetBaseApp() *BaseApp { Transaction execution within `FinalizeBlock` performs the **exact same steps as `CheckTx`**, with a little caveat at step 3 and the addition of a fifth step: 1. The `AnteHandler` does **not** check that the transaction's `gas-prices` is sufficient. That is because the `min-gas-prices` value `gas-prices` is checked against is local to the node, and therefore what is enough for one full-node might not be for another. This means that the proposer can potentially include transactions for free, although they are not incentivised to do so, as they earn a bonus on the total fee of the block they propose. -2. For each `sdk.Msg` in the transaction, route to the appropriate module's Protobuf [`Msg` service](/docs/sdk/v0.53//build/building-modules/msg-services). Additional *stateful* checks are performed, and the branched multistore held in `finalizeBlockState`'s `context` is updated by the module's `keeper`. If the `Msg` service returns successfully, the branched multistore held in `context` is written to `finalizeBlockState` `CacheMultiStore`. +2. For each `sdk.Msg` in the transaction, route to the appropriate module's Protobuf [`Msg` service](/docs/sdk/v0.53/build/building-modules/msg-services). Additional *stateful* checks are performed, and the branched multistore held in `finalizeBlockState`'s `context` is updated by the module's `keeper`. If the `Msg` service returns successfully, the branched multistore held in `context` is written to `finalizeBlockState` `CacheMultiStore`. 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: @@ -10042,7 +10042,7 @@ The [`Info` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x/spec ### Query -The [`Query` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_basic_concepts.md#info-methods) is used to serve queries received from the underlying consensus engine, including queries received via RPC like CometBFT RPC. It used to be the main entrypoint to build interfaces with the application, but with the introduction of [gRPC queries](/docs/sdk/v0.53//build/building-modules/query-services) in Cosmos SDK v0.40, its usage is more limited. The application must respect a few rules when implementing the `Query` method, which are outlined [here](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_app_requirements.md#query). +The [`Query` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_basic_concepts.md#info-methods) is used to serve queries received from the underlying consensus engine, including queries received via RPC like CometBFT RPC. It used to be the main entrypoint to build interfaces with the application, but with the introduction of [gRPC queries](/docs/sdk/v0.53/build/building-modules/query-services) in Cosmos SDK v0.40, its usage is more limited. The application must respect a few rules when implementing the `Query` method, which are outlined [here](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_app_requirements.md#query). Each CometBFT `query` comes with a `path`, which is a `string` which denotes what to query. If the `path` matches a gRPC fully-qualified service method, then `BaseApp` will defer the query to the `grpcQueryRouter` and let it handle it like explained [above](#grpc-query-router). Otherwise, the `path` represents a query that is not (yet) handled by the gRPC router. `BaseApp` splits the `path` string with the `/` delimiter. By convention, the first element of the split string (`split[0]`) contains the category of `query` (`app`, `p2p`, `store` or `custom` ). The `BaseApp` implementation of the `Query(req abci.RequestQuery)` method is a simple dispatcher serving these 4 main categories of queries: diff --git a/docs/sdk/v0.53/learn/advanced/cli.mdx b/docs/sdk/v0.53/learn/advanced/cli.mdx index e35e83c6..082e7526 100644 --- a/docs/sdk/v0.53/learn/advanced/cli.mdx +++ b/docs/sdk/v0.53/learn/advanced/cli.mdx @@ -4,7 +4,7 @@ title: Command-Line Interface **Synopsis** -This document describes how command-line interface (CLI) works on a high-level, for an [**application**](/docs/sdk/v0.53/learn/beginner/app-anatomyy). A separate document for implementing a CLI for a Cosmos SDK [**module**](/docs/sdk/v0.53//build/building-modules/intro) can be found [here](/docs/sdk/v0.53//build/building-modules/module-interfaces#cli). +This document describes how command-line interface (CLI) works on a high-level, for an [**application**](/docs/sdk/v0.53/learn/beginner/app-anatomy). A separate document for implementing a CLI for a Cosmos SDK [**module**](/docs/sdk/v0.53/build/building-modules/intro) can be found [here](/docs/sdk/v0.53/build/building-modules/module-interfaces#cli). ## Command-Line Interface @@ -23,7 +23,7 @@ The first four strings specify the command: * The root command for the entire application `simd`. * The subcommand `tx`, which contains all commands that let users create transactions. -* The subcommand `bank` to indicate which module to route the command to ([`x/bank`](/docs/sdk/v0.53//build/modules/bank/README) module in this case). +* The subcommand `bank` to indicate which module to route the command to ([`x/bank`](/docs/sdk/v0.53/build/modules/bank/README) module in this case). * The type of transaction `send`. The next two strings are arguments: the `from_address` the user wishes to send from, the `to_address` of the recipient, and the `amount` they want to send. Finally, the last few strings of the command are optional flags to indicate how much the user is willing to pay in fees (calculated using the amount of gas used to execute the transaction and the gas prices provided by the user). @@ -77,7 +77,7 @@ 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`](/docs/sdk/v0.53/node). The Status of a node includes `NodeInfo`,`SyncInfo` and `ValidatorInfo`. -* **Keys** [commands](https://github.com/cosmos/cosmos-sdk/blob/v0.53.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 ` 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.53.0/client/keys/add.go). For more details about usage of `--keyring-backend` for storage of key credentials look at the [keyring docs](/docs/sdk/v0.53//user/run-node/keyring). +* **Keys** [commands](https://github.com/cosmos/cosmos-sdk/blob/v0.53.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 ` 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.53.0/client/keys/add.go). For more details about usage of `--keyring-backend` for storage of key credentials look at the [keyring docs](/docs/sdk/v0.53/user/run-node/keyring). * **Server** commands from the Cosmos SDK server package. These commands are responsible for providing the mechanisms necessary to start an ABCI CometBFT application and provides the CLI framework (based on [cobra](https://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. Learn more [here](https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/server). * [**Transaction**](#transaction-commands) commands. @@ -113,7 +113,7 @@ The root-level `status` and `keys` subcommands are common across most applicatio ### Transaction Commands -[Transactions](/docs/sdk/v0.53/learn/advanced/transactions) are objects wrapping [`Msg`s](/docs/sdk/v0.53//build/building-modules/messages-and-queries#messages) that trigger state changes. To enable the creation of transactions using the CLI interface, a function `txCommand` is generally added to the `rootCmd`: +[Transactions](/docs/sdk/v0.53/learn/advanced/transactions) are objects wrapping [`Msg`s](/docs/sdk/v0.53/build/building-modules/messages-and-queries#messages) that trigger state changes. To enable the creation of transactions using the CLI interface, a function `txCommand` is generally added to the `rootCmd`: ```go // Reference: https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/simapp/simd/cmd/root_v2.go#L222-L229 @@ -121,9 +121,9 @@ The root-level `status` and `keys` subcommands are common across most applicatio This `txCommand` function adds all the transaction available to end-users for the application. This typically includes: -* **Sign command** from the [`auth`](/docs/sdk/v0.53//build/modules/auth/README) module that signs messages in a transaction. To enable multisig, add the `auth` module's `MultiSign` command. Since every transaction requires some sort of signature in order to be valid, the signing command is necessary for every application. +* **Sign command** from the [`auth`](/docs/sdk/v0.53/build/modules/auth/README) module that signs messages in a transaction. To enable multisig, add the `auth` module's `MultiSign` command. Since every transaction requires some sort of signature in order to be valid, the signing command is necessary for every application. * **Broadcast command** from the Cosmos SDK client tools, to broadcast transactions. -* **All [module transaction commands](/docs/sdk/v0.53//build/building-modules/module-interfaces#transaction-commands)** the application is dependent on, retrieved by using the [basic module manager's](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#basic-manager) `AddTxCommands()` function, or enhanced by [AutoCLI](https://docs.cosmos.network/main/core/autocli). +* **All [module transaction commands](/docs/sdk/v0.53/build/building-modules/module-interfaces#transaction-commands)** the application is dependent on, retrieved by using the [basic module manager's](/docs/sdk/v0.53/build/building-modules/module-manager#basic-manager) `AddTxCommands()` function, or enhanced by [AutoCLI](https://docs.cosmos.network/main/core/autocli). Here is an example of a `txCommand` aggregating these subcommands from the `simapp` application: @@ -138,7 +138,7 @@ Read more about [AutoCLI](https://docs.cosmos.network/main/core/autocli) in its ### Query Commands -[**Queries**](/docs/sdk/v0.53//build/building-modules/messages-and-queries#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`: +[**Queries**](/docs/sdk/v0.53/build/building-modules/messages-and-queries#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`: ```go // Reference: https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/simapp/simd/cmd/root_v2.go#L222-L229 @@ -150,7 +150,7 @@ This `queryCommand` function adds all the queries available to end-users for the * **Account command** from the `auth` module, which displays the state (e.g. account balance) of an account given an address. * **Validator command** from the Cosmos SDK rpc client tools, which displays the validator set of a given height. * **Block command** from the Cosmos SDK RPC client tools, which displays the block data for a given height. -* **All [module query commands](/docs/sdk/v0.53//build/building-modules/module-interfaces#query-commands)** the application is dependent on, retrieved by using the [basic module manager's](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#basic-manager) `AddQueryCommands()` function, or enhanced by [AutoCLI](https://docs.cosmos.network/main/core/autocli). +* **All [module query commands](/docs/sdk/v0.53/build/building-modules/module-interfaces#query-commands)** the application is dependent on, retrieved by using the [basic module manager's](/docs/sdk/v0.53/build/building-modules/module-manager#basic-manager) `AddQueryCommands()` function, or enhanced by [AutoCLI](https://docs.cosmos.network/main/core/autocli). Here is an example of a `queryCommand` aggregating subcommands from the `simapp` application: @@ -165,11 +165,11 @@ Read more about [AutoCLI](https://docs.cosmos.network/main/core/autocli) in its ## Flags -Flags are used to modify commands; developers can include them in a `flags.go` file with their CLI. Users can explicitly include them in commands or pre-configure them by inside their [`app.toml`](/docs/sdk/v0.53//user/run-node/run-node#configuring-the-node-using-apptoml-and-configtoml). Commonly pre-configured flags include the `--node` to connect to and `--chain-id` of the blockchain the user wishes to interact with. +Flags are used to modify commands; developers can include them in a `flags.go` file with their CLI. Users can explicitly include them in commands or pre-configure them by inside their [`app.toml`](/docs/sdk/v0.53/user/run-node/run-node#configuring-the-node-using-apptoml-and-configtoml). Commonly pre-configured flags include the `--node` to connect to and `--chain-id` of the blockchain the user wishes to interact with. A *persistent* flag (as opposed to a *local* flag) added to a command transcends all of its children: subcommands will inherit the configured values for these flags. Additionally, all flags have default values when they are added to commands; some toggle an option off but others are empty values that the user needs to override to create valid commands. A flag can be explicitly marked as *required* so that an error is automatically thrown if the user does not provide a value, but it is also acceptable to handle unexpected missing flags differently. -Flags are added to commands directly (generally in the [module's CLI file](/docs/sdk/v0.53//build/building-modules/module-interfaces#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. +Flags are added to commands directly (generally in the [module's CLI file](/docs/sdk/v0.53/build/building-modules/module-interfaces#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. ## Environment variables diff --git a/docs/sdk/v0.53/learn/advanced/context.mdx b/docs/sdk/v0.53/learn/advanced/context.mdx index b52c902a..2b27ba73 100644 --- a/docs/sdk/v0.53/learn/advanced/context.mdx +++ b/docs/sdk/v0.53/learn/advanced/context.mdx @@ -10,7 +10,7 @@ The `context` is a data structure intended to be passed from function to functio **Pre-requisite Readings** -* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.53/learn/beginner/app-anatomyy) +* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.53/learn/beginner/app-anatomy) * [Lifecycle of a Transaction](/docs/sdk/v0.53/learn/beginner/tx-lifecycle) diff --git a/docs/sdk/v0.53/learn/advanced/encoding.mdx b/docs/sdk/v0.53/learn/advanced/encoding.mdx index 8f7813b5..f8511d0e 100644 --- a/docs/sdk/v0.53/learn/advanced/encoding.mdx +++ b/docs/sdk/v0.53/learn/advanced/encoding.mdx @@ -10,7 +10,7 @@ While encoding in the Cosmos SDK used to be mainly handled by `go-amino` codec, **Pre-requisite Readings** -* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.53/learn/beginner/app-anatomyy) +* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.53/learn/beginner/app-anatomy) @@ -47,7 +47,7 @@ via Protobuf. This means that modules may use Protobuf encoding, but the types m implement `ProtoMarshaler`. If modules wish to avoid implementing this interface for their types, this is autogenerated via [buf](https://buf.build/) -If modules use [Collections](/docs/sdk/v0.53//build/packages/collections), encoding and decoding are handled, marshal and unmarshal should not be handled manually unless for specific cases identified by the developer. +If modules use [Collections](/docs/sdk/v0.53/build/packages/collections), encoding and decoding are handled, marshal and unmarshal should not be handled manually unless for specific cases identified by the developer. ### Gogoproto @@ -249,7 +249,7 @@ return "" } ``` -A standard implementation of both these objects can be found in the [`auth/tx` module](/docs/sdk/v0.53//build/modules/auth/tx): +A standard implementation of both these objects can be found in the [`auth/tx` module](/docs/sdk/v0.53/build/modules/auth/tx): ```go expandable package tx @@ -500,7 +500,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](/docs/sdk/v0.53//build/modules/auth/vesting), 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? +In this `Profile` example, we hardcoded `account` as a `BaseAccount`. However, there are several other types of [user accounts related to vesting](/docs/sdk/v0.53/build/modules/auth/vesting), 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? ```go expandable package types @@ -1417,9 +1417,9 @@ import ( Protobuf types can be defined to encode: * state -* [`Msg`s](/docs/sdk/v0.53//build/building-modules/messages-and-queries#messages) -* [Query services](/docs/sdk/v0.53//build/building-modules/query-services) -* [genesis](/docs/sdk/v0.53//build/building-modules/genesis) +* [`Msg`s](/docs/sdk/v0.53/build/building-modules/messages-and-queries#messages) +* [Query services](/docs/sdk/v0.53/build/building-modules/query-services) +* [genesis](/docs/sdk/v0.53/build/building-modules/genesis) #### Naming and conventions diff --git a/docs/sdk/v0.53/learn/advanced/events.mdx b/docs/sdk/v0.53/learn/advanced/events.mdx index 7508d3c2..9bb5ed0b 100644 --- a/docs/sdk/v0.53/learn/advanced/events.mdx +++ b/docs/sdk/v0.53/learn/advanced/events.mdx @@ -10,7 +10,7 @@ title: Events **Pre-requisite Readings** -* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.53/learn/beginner/app-anatomyy) +* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.53/learn/beginner/app-anatomy) * [CometBFT Documentation on Events](https://docs.cometbft.com/v0.37/spec/abci/abci++_basic_concepts#events) @@ -34,10 +34,10 @@ An Event contains: To parse the attribute values as strings, make sure to add `'` (single quotes) around each attribute value. -*Typed Events* are Protobuf-defined [messages](/docs/sdk/v0.53//build/architecture/adr-032-typed-events) used by the Cosmos SDK +*Typed Events* are Protobuf-defined [messages](/docs/sdk/v0.53/build/architecture/adr-032-typed-events) used by the Cosmos SDK for emitting and querying Events. They are defined in a `event.proto` file, on a **per-module basis** and are read as `proto.Message`. *Legacy Events* are defined on a **per-module basis** in the module's `/types/events.go` file. -They are triggered from the module's Protobuf [`Msg` service](/docs/sdk/v0.53//build/building-modules/msg-services) +They are triggered from the module's Protobuf [`Msg` service](/docs/sdk/v0.53/build/building-modules/msg-services) by using the [`EventManager`](#eventmanager). In addition, each module documents its events under in the `Events` sections of its specs (x/`{moduleName}`/`README.md`). @@ -56,9 +56,9 @@ The following examples show how to query Events using the Cosmos SDK. | Event | Description | | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | `tx.height=23` | Query all transactions at height 23 | -| `message.action='/cosmos.bank.v1beta1.Msg/Send'` | Query all transactions containing a x/bank `Send` [Service `Msg`](/docs/sdk/v0.53//build/building-modules/msg-services). Note the `'`s around the value. | +| `message.action='/cosmos.bank.v1beta1.Msg/Send'` | Query all transactions containing a x/bank `Send` [Service `Msg`](/docs/sdk/v0.53/build/building-modules/msg-services). Note the `'`s around the value. | | `message.module='bank'` | Query all transactions containing messages from the x/bank module. Note the `'`s around the value. | -| `create_validator.validator='cosmosval1...'` | x/staking-specific Event, see [x/staking SPEC](/docs/sdk/v0.53//build/modules/staking/README). | +| `create_validator.validator='cosmosval1...'` | x/staking-specific Event, see [x/staking SPEC](/docs/sdk/v0.53/build/modules/staking/README). | ## EventManager @@ -2275,7 +2275,7 @@ ctx.EventManager().EmitEvent( Where the `EventManager` is accessed via the [`Context`](/docs/sdk/v0.53/learn/advanced/context). -See the [`Msg` services](/docs/sdk/v0.53//build/building-modules/msg-services) concept doc for a more detailed +See the [`Msg` services](/docs/sdk/v0.53/build/building-modules/msg-services) concept doc for a more detailed view on how to typically implement Events and use the `EventManager` in modules. ## Subscribing to Events diff --git a/docs/sdk/v0.53/learn/advanced/grpc_rest.mdx b/docs/sdk/v0.53/learn/advanced/grpc_rest.mdx index e1cd0b8b..c85692f9 100644 --- a/docs/sdk/v0.53/learn/advanced/grpc_rest.mdx +++ b/docs/sdk/v0.53/learn/advanced/grpc_rest.mdx @@ -27,7 +27,7 @@ All endpoints are defaulted to localhost and must be modified to be exposed to t In the Cosmos SDK, Protobuf is the main [encoding](/docs/sdk/v0.53/learn/advanced/encoding) library. This brings a wide range of Protobuf-based tools that can be plugged into the Cosmos SDK. One such tool is [gRPC](https://grpc.io), a modern open-source high performance RPC framework that has decent client support in several languages. -Each module exposes a [Protobuf `Query` service](/docs/sdk/v0.53//build/building-modules/messages-and-queries#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: +Each module exposes a [Protobuf `Query` service](/docs/sdk/v0.53/build/building-modules/messages-and-queries#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: ```go expandable package types @@ -140,7 +140,7 @@ Application ) ``` -Note: It is not possible to expose any [Protobuf `Msg` service](/docs/sdk/v0.53//build/building-modules/messages-and-queries#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](/docs/sdk/v0.53//user/run-node/txs) for more information. +Note: It is not possible to expose any [Protobuf `Msg` service](/docs/sdk/v0.53/build/building-modules/messages-and-queries#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](/docs/sdk/v0.53/user/run-node/txs) for more information. The `grpc.Server` is a concrete gRPC server, which spawns and serves all gRPC query requests and a broadcast transaction request. This server can be configured inside `~/.simapp/config/app.toml`: @@ -151,7 +151,7 @@ The `grpc.Server` is a concrete gRPC server, which spawns and serves all gRPC qu `~/.simapp` is the directory where the node's configuration and databases are stored. By default, it's set to `~/.{app_name}`. -Once the gRPC server is started, you can send requests to it using a gRPC client. Some examples are given in our [Interact with the Node](/docs/sdk/v0.53//user/run-node/interact-node#using-grpc) tutorial. +Once the gRPC server is started, you can send requests to it using a gRPC client. Some examples are given in our [Interact with the Node](/docs/sdk/v0.53/user/run-node/interact-node#using-grpc) tutorial. An overview of all available gRPC endpoints shipped with the Cosmos SDK is [Protobuf documentation](https://buf.build/cosmos/cosmos-sdk). diff --git a/docs/sdk/v0.53/learn/advanced/node.mdx b/docs/sdk/v0.53/learn/advanced/node.mdx index 65a3f060..404817e4 100644 --- a/docs/sdk/v0.53/learn/advanced/node.mdx +++ b/docs/sdk/v0.53/learn/advanced/node.mdx @@ -10,7 +10,7 @@ The main endpoint of a Cosmos SDK application is the daemon client, otherwise kn **Pre-requisite Readings** -* [Anatomy of an SDK application](/docs/sdk/v0.53/learn/beginner/app-anatomyy) +* [Anatomy of an SDK application](/docs/sdk/v0.53/learn/beginner/app-anatomy) @@ -1876,7 +1876,7 @@ Application ) ``` -In practice, the [constructor of the application](/docs/sdk/v0.53/learn/beginner/app-anatomyy#constructor-function) is passed as the `appCreator`. +In practice, the [constructor of the application](/docs/sdk/v0.53/learn/beginner/app-anatomy#constructor-function) is passed as the `appCreator`. ```go // Reference: https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/simapp/simd/cmd/root_v2.go#L294-L308 @@ -4190,4 +4190,4 @@ Upon starting, the node will bootstrap its RPC and P2P server and start dialing ## Other commands -To discover how to concretely run a node and interact with it, please refer to our [Running a Node, API and CLI](/docs/sdk/v0.53//user/run-node/run-node) guide. +To discover how to concretely run a node and interact with it, please refer to our [Running a Node, API and CLI](/docs/sdk/v0.53/user/run-node/run-node) guide. diff --git a/docs/sdk/v0.53/learn/advanced/runtx_middleware.mdx b/docs/sdk/v0.53/learn/advanced/runtx_middleware.mdx index a54fee18..be804c55 100644 --- a/docs/sdk/v0.53/learn/advanced/runtx_middleware.mdx +++ b/docs/sdk/v0.53/learn/advanced/runtx_middleware.mdx @@ -6,7 +6,7 @@ title: RunTx recovery middleware 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](/docs/sdk/v0.53//build/architecture/adr-022-custom-panic-handling) and the implementation in [recovery.go](https://github.com/cosmos/cosmos-sdk/blob/v0.53.0-rc.2/baseapp/recovery.go). +More context can found in the corresponding [ADR-022](/docs/sdk/v0.53/build/architecture/adr-022-custom-panic-handling) and the implementation in [recovery.go](https://github.com/cosmos/cosmos-sdk/blob/v0.53.0-rc.2/baseapp/recovery.go). ## Interface diff --git a/docs/sdk/v0.53/learn/advanced/simulation.mdx b/docs/sdk/v0.53/learn/advanced/simulation.mdx index 194f35f2..0e11ec05 100644 --- a/docs/sdk/v0.53/learn/advanced/simulation.mdx +++ b/docs/sdk/v0.53/learn/advanced/simulation.mdx @@ -91,5 +91,5 @@ Here are some suggestions when encountering a simulation failure: Learn how you can build the simulation into your Cosmos SDK-based application: * Application Simulation Manager -* [Building modules: Simulator](/docs/sdk/v0.53//build/building-modules/simulator) +* [Building modules: Simulator](/docs/sdk/v0.53/build/building-modules/simulator) * Simulator tests diff --git a/docs/sdk/v0.53/learn/advanced/store.mdx b/docs/sdk/v0.53/learn/advanced/store.mdx index ff88fe7b..3383c831 100644 --- a/docs/sdk/v0.53/learn/advanced/store.mdx +++ b/docs/sdk/v0.53/learn/advanced/store.mdx @@ -10,13 +10,13 @@ A store is a data structure that holds the state of the application. **Pre-requisite Readings** -* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.53/learn/beginner/app-anatomyy) +* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.53/learn/beginner/app-anatomy) ## Introduction to Cosmos SDK Stores -The Cosmos SDK comes with a large set of stores to persist the state of applications. By default, the main store of Cosmos SDK applications is a `multistore`, i.e. a store of stores. Developers can add any number of key-value stores to the multistore, depending on their application needs. The multistore exists to support the modularity of the Cosmos SDK, as it lets each module declare and manage their own subset of the state. Key-value stores in the multistore can only be accessed with a specific capability `key`, which is typically held in the [`keeper`](/docs/sdk/v0.53//build/building-modules/keeper) of the module that declared the store. +The Cosmos SDK comes with a large set of stores to persist the state of applications. By default, the main store of Cosmos SDK applications is a `multistore`, i.e. a store of stores. Developers can add any number of key-value stores to the multistore, depending on their application needs. The multistore exists to support the modularity of the Cosmos SDK, as it lets each module declare and manage their own subset of the state. Key-value stores in the multistore can only be accessed with a specific capability `key`, which is typically held in the [`keeper`](/docs/sdk/v0.53/build/building-modules/keeper) of the module that declared the store. ```text expandable +-----------------------------------------------------+ @@ -5929,9 +5929,9 @@ return store.(types.KVStore) A `KVStore` is a simple key-value store used to store and retrieve data. A `CommitKVStore` is a `KVStore` that also implements a `Committer`. By default, stores mounted in `baseapp`'s main `CommitMultiStore` are `CommitKVStore`s. The `KVStore` interface is primarily used to restrict modules from accessing the committer. -Individual `KVStore`s are used by modules to manage a subset of the global state. `KVStores` can be accessed by objects that hold a specific key. This `key` should only be exposed to the [`keeper`](/docs/sdk/v0.53//build/building-modules/keeper) of the module that defines the store. +Individual `KVStore`s are used by modules to manage a subset of the global state. `KVStores` can be accessed by objects that hold a specific key. This `key` should only be exposed to the [`keeper`](/docs/sdk/v0.53/build/building-modules/keeper) of the module that defines the store. -`CommitKVStore`s are declared by proxy of their respective `key` and mounted on the application's [multistore](#multistore) in the [main application file](/docs/sdk/v0.53/learn/beginner/app-anatomyy#core-application-file). In the same file, the `key` is also passed to the module's `keeper` that is responsible for managing the store. +`CommitKVStore`s are declared by proxy of their respective `key` and mounted on the application's [multistore](#multistore) in the [main application file](/docs/sdk/v0.53/learn/beginner/app-anatomy#core-application-file). In the same file, the `key` is also passed to the module's `keeper` that is responsible for managing the store. ```go expandable package types diff --git a/docs/sdk/v0.53/learn/advanced/transactions.mdx b/docs/sdk/v0.53/learn/advanced/transactions.mdx index cb7cc941..2f689c30 100644 --- a/docs/sdk/v0.53/learn/advanced/transactions.mdx +++ b/docs/sdk/v0.53/learn/advanced/transactions.mdx @@ -10,13 +10,13 @@ title: Transactions **Pre-requisite Readings** -* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.53/learn/beginner/app-anatomyy) +* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.53/learn/beginner/app-anatomy) ## Transactions -Transactions are comprised of metadata held in [contexts](/docs/sdk/v0.53/learn/advanced/context) and [`sdk.Msg`s](/docs/sdk/v0.53//build/building-modules/messages-and-queries) that trigger state changes within a module through the module's Protobuf [`Msg` service](/docs/sdk/v0.53//build/building-modules/msg-services). +Transactions are comprised of metadata held in [contexts](/docs/sdk/v0.53/learn/advanced/context) and [`sdk.Msg`s](/docs/sdk/v0.53/build/building-modules/messages-and-queries) that trigger state changes within a module through the module's Protobuf [`Msg` service](/docs/sdk/v0.53/build/building-modules/msg-services). When users want to interact with an application and make state changes (e.g. sending coins), they create transactions. Each of a transaction's `sdk.Msg` must be signed using the private key associated with the appropriate account(s), before the transaction is broadcasted to the network. A transaction must then be included in a block, validated, and approved by the network through the consensus process. To read more about the lifecycle of a transaction, click [here](/docs/sdk/v0.53/learn/beginner/tx-lifecycle). @@ -216,7 +216,7 @@ The most used implementation of the `Tx` interface is the Protobuf `Tx` message, // Reference: https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/proto/cosmos/tx/v1beta1/tx.proto#L15-L28 ``` -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](/docs/sdk/v0.53//build/architecture/adr-027-deterministic-protobuf-serialization)): +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](/docs/sdk/v0.53/build/architecture/adr-027-deterministic-protobuf-serialization)): ```protobuf // Reference: https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/proto/cosmos/tx/v1beta1/tx.proto#L50-L67 @@ -722,7 +722,7 @@ There are also *expert* screens, which will only be displayed if the user has ch Data is formatted using a set of `ValueRenderer` which the SDK provides defaults for all the known messages and value types. Chain developers can also opt to implement their own `ValueRenderer` for a type/message if they'd like to display information differently. -If you wish to learn more, please refer to [ADR-050](/docs/sdk/v0.53//build/architecture/adr-050-sign-mode-textual). +If you wish to learn more, please refer to [ADR-050](/docs/sdk/v0.53/build/architecture/adr-050-sign-mode-textual). #### Custom Sign modes @@ -744,12 +744,12 @@ The next paragraphs will describe each of these components, in this order. Module `sdk.Msg`s are not to be confused with [ABCI Messages](https://docs.cometbft.com/v0.37/spec/abci/) which define interactions between the CometBFT and application layers. -**Messages** (or `sdk.Msg`s) are module-specific objects that trigger state transitions within the scope of the module they belong to. Module developers define the messages for their module by adding methods to the Protobuf [`Msg` service](/docs/sdk/v0.53//build/building-modules/msg-services), and also implement the corresponding `MsgServer`. +**Messages** (or `sdk.Msg`s) are module-specific objects that trigger state transitions within the scope of the module they belong to. Module developers define the messages for their module by adding methods to the Protobuf [`Msg` service](/docs/sdk/v0.53/build/building-modules/msg-services), and also implement the corresponding `MsgServer`. -Each `sdk.Msg`s is related to exactly one Protobuf [`Msg` service](/docs/sdk/v0.53//build/building-modules/msg-services) RPC, defined inside each module's `tx.proto` file. A SDK app router automatically maps every `sdk.Msg` to a corresponding RPC. Protobuf generates a `MsgServer` interface for each module `Msg` service, and the module developer needs to implement this interface. +Each `sdk.Msg`s is related to exactly one Protobuf [`Msg` service](/docs/sdk/v0.53/build/building-modules/msg-services) RPC, defined inside each module's `tx.proto` file. A SDK app router automatically maps every `sdk.Msg` to a corresponding RPC. Protobuf generates a `MsgServer` interface for each module `Msg` service, and the module developer needs to implement this interface. This design puts more responsibility on module developers, allowing application developers to reuse common functionalities without having to implement state transition logic repetitively. -To learn more about Protobuf `Msg` services and how to implement `MsgServer`, click [here](/docs/sdk/v0.53//build/building-modules/msg-services). +To learn more about Protobuf `Msg` services and how to implement `MsgServer`, click [here](/docs/sdk/v0.53/build/building-modules/msg-services). While messages contain the information for state transition logic, a transaction's other metadata and relevant information are stored in the `TxBuilder` and `Context`. @@ -986,7 +986,7 @@ Once the transaction bytes are generated, there are currently three ways of broa Application developers create entry points to the application by creating a [command-line interface](/docs/sdk/v0.53/cli), [gRPC and/or REST interface](/docs/sdk/v0.53/grpc_rest), typically found in the application's `./cmd` folder. These interfaces allow users to interact with the application through command-line. -For the [command-line interface](/docs/sdk/v0.53//build/building-modules/module-interfaces#cli), module developers create subcommands to add as children to the application top-level transaction command `TxCmd`. CLI commands actually bundle all the steps of transaction processing into one simple command: creating messages, generating transactions and broadcasting. For concrete examples, see the [Interacting with a Node](/docs/sdk/v0.53//user/run-node/interact-node) section. An example transaction made using CLI looks like: +For the [command-line interface](/docs/sdk/v0.53/build/building-modules/module-interfaces#cli), module developers create subcommands to add as children to the application top-level transaction command `TxCmd`. CLI commands actually bundle all the steps of transaction processing into one simple command: creating messages, generating transactions and broadcasting. For concrete examples, see the [Interacting with a Node](/docs/sdk/v0.53/user/run-node/interact-node) section. An example transaction made using CLI looks like: ```bash simd tx send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000stake @@ -994,7 +994,7 @@ simd tx send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000stake #### gRPC -[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](/docs/sdk/v0.53//build/building-modules/query-services). However, the Cosmos SDK also exposes a few other module-agnostic gRPC services, one of them being the `Tx` service: +[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](/docs/sdk/v0.53/build/building-modules/query-services). However, the Cosmos SDK also exposes a few other module-agnostic gRPC services, one of them being the `Tx` service: ```go expandable syntax = "proto3"; @@ -1297,13 +1297,13 @@ message TxDecodeAminoResponse { 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. -Examples of broadcasting and simulating a transaction are shown [here](/docs/sdk/v0.53//user/run-node/txs#programmatically-with-go). +Examples of broadcasting and simulating a transaction are shown [here](/docs/sdk/v0.53/user/run-node/txs#programmatically-with-go). #### REST Each gRPC method has its corresponding REST endpoint, generated using [gRPC-gateway](https://github.com/grpc-ecosystem/grpc-gateway). Therefore, instead of using gRPC, you can also use HTTP to broadcast the same transaction, on the `POST /cosmos/tx/v1beta1/txs` endpoint. -An example can be seen [here](/docs/sdk/v0.53//user/run-node/txs#using-rest) +An example can be seen [here](/docs/sdk/v0.53/user/run-node/txs#using-rest) #### CometBFT RPC diff --git a/docs/sdk/v0.53/learn/advanced/upgrade.mdx b/docs/sdk/v0.53/learn/advanced/upgrade.mdx index 4102a25c..0798147f 100644 --- a/docs/sdk/v0.53/learn/advanced/upgrade.mdx +++ b/docs/sdk/v0.53/learn/advanced/upgrade.mdx @@ -15,7 +15,7 @@ The Cosmos SDK uses two methods to perform upgrades: * Exporting the entire application state to a JSON file using the `export` CLI command, making changes, and then starting a new binary with the changed JSON file as the genesis file. -* Perform upgrades in place, which significantly decrease the upgrade time for chains with a larger state. Use the [Module Upgrade Guide](/docs/sdk/v0.47//build/building-modules/upgrade) to set up your application modules to take advantage of in-place upgrades. +* Perform upgrades in place, which significantly decrease the upgrade time for chains with a larger state. Use the [Module Upgrade Guide](/docs/sdk/v0.47/build/building-modules/upgrade) to set up your application modules to take advantage of in-place upgrades. This document provides steps to use the In-Place Store Migrations upgrade method. @@ -63,7 +63,7 @@ app.UpgradeKeeper.SetUpgradeHandler("my-plan", func(ctx sdk.Context, plan upgrad }) ``` -To learn more about configuring migration scripts for your modules, see the [Module Upgrade Guide](/docs/sdk/v0.47//build/building-modules/upgrade). +To learn more about configuring migration scripts for your modules, see the [Module Upgrade Guide](/docs/sdk/v0.47/build/building-modules/upgrade). ### Order Of Migrations @@ -161,4 +161,4 @@ You can sync a full node to an existing blockchain which has been upgraded using To successfully sync, you must start with the initial binary that the blockchain started with at genesis. If all Software Upgrade Plans contain binary instruction, then you can run Cosmovisor with auto-download option to automatically handle downloading and switching to the binaries associated with each sequential upgrade. Otherwise, you need to manually provide all binaries to Cosmovisor. -To learn more about Cosmovisor, see the [Cosmovisor Quick Start](/docs/sdk/v0.47//build/tooling/cosmovisor). +To learn more about Cosmovisor, see the [Cosmovisor Quick Start](/docs/sdk/v0.47/build/tooling/cosmovisor). diff --git a/docs/sdk/v0.53/learn/beginner/accounts.mdx b/docs/sdk/v0.53/learn/beginner/accounts.mdx index da241e5e..39f188a3 100644 --- a/docs/sdk/v0.53/learn/beginner/accounts.mdx +++ b/docs/sdk/v0.53/learn/beginner/accounts.mdx @@ -10,13 +10,13 @@ This document describes the in-built account and public key system of the Cosmos **Pre-requisite Readings** -* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.53/learn/beginner/app-anatomyy) +* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.53/learn/beginner/app-anatomy) ## Account Definition -In the Cosmos SDK, an *account* designates a pair of *public key* `PubKey` and *private key* `PrivKey`. The `PubKey` can be derived to generate various `Addresses`, which are used to identify users (among other parties) in the application. `Addresses` are also associated with [`message`s](/docs/sdk/v0.53//build/building-modules/messages-and-queries#messages) to identify the sender of the `message`. The `PrivKey` is used to generate [digital signatures](#signatures) to prove that an `Address` associated with the `PrivKey` approved of a given `message`. +In the Cosmos SDK, an *account* designates a pair of *public key* `PubKey` and *private key* `PrivKey`. The `PubKey` can be derived to generate various `Addresses`, which are used to identify users (among other parties) in the application. `Addresses` are also associated with [`message`s](/docs/sdk/v0.53/build/building-modules/messages-and-queries#messages) to identify the sender of the `message`. The `PrivKey` is used to generate [digital signatures](#signatures) to prove that an `Address` associated with the `PrivKey` approved of a given `message`. For HD key derivation the Cosmos SDK uses a standard called [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki). The BIP32 allows users to create an HD wallet (as specified in [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)) - a set of accounts derived from an initial secret seed. A seed is usually created from a 12- or 24-word mnemonic. A single seed can derive any number of `PrivKey`s using a one-way cryptographic function. Then, a `PubKey` can be derived from the `PrivKey`. Naturally, the mnemonic is the most sensitive information, as private keys can always be re-generated if the mnemonic is preserved. @@ -3258,7 +3258,7 @@ The default implementation of `Keyring` comes from the third-party [`99designs/k 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](/docs/sdk/v0.53//build/architecture/adr-020-protobuf-transaction-encoding) that the canonical `payload` to sign is the `SignDoc` struct, deterministically encoded using [ADR-027](/docs/sdk/v0.53//build/architecture/adr-027-deterministic-protobuf-serialization). Note that signature verification is not implemented in the Cosmos SDK by default, it is deferred to the [`anteHandler`](/docs/sdk/v0.53/advanced/baseapp#antehandler). +* `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](/docs/sdk/v0.53/build/architecture/adr-020-protobuf-transaction-encoding) that the canonical `payload` to sign is the `SignDoc` struct, deterministically encoded using [ADR-027](/docs/sdk/v0.53/build/architecture/adr-027-deterministic-protobuf-serialization). Note that signature verification is not implemented in the Cosmos SDK by default, it is deferred to the [`anteHandler`](/docs/sdk/v0.53/learn/advanced/baseapp#antehandler). ```protobuf // Reference: https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/proto/cosmos/tx/v1beta1/tx.proto#L50-L67 diff --git a/docs/sdk/v0.53/learn/beginner/app-anatomy.mdx b/docs/sdk/v0.53/learn/beginner/app-anatomy.mdx index 9aeaebaa..693132a0 100644 --- a/docs/sdk/v0.53/learn/beginner/app-anatomy.mdx +++ b/docs/sdk/v0.53/learn/beginner/app-anatomy.mdx @@ -49,10 +49,10 @@ In general, the core of the state-machine is defined in a file called `app.go`. The first thing defined in `app.go` is the `type` of the application. It is generally comprised of the following parts: -* **Embeding [runtime.App](/docs/sdk/v0.53//build/building-apps/runtime)** The runtime package manages the application's core components and modules through dependency injection. It provides declarative configuration for module management, state storage, and ABCI handling. +* **Embeding [runtime.App](/docs/sdk/v0.53/build/building-apps/runtime)** The runtime package manages the application's core components and modules through dependency injection. It provides declarative configuration for module management, state storage, and ABCI handling. * `Runtime` wraps `BaseApp`, meaning when a transaction is relayed by CometBFT to the application, `app` uses `runtime`'s methods to route them to the appropriate module. `BaseApp` implements all the [ABCI methods](https://docs.cometbft.com/v0.38/spec/abci/) and the [routing logic](/docs/sdk/v0.53/learn/advanced/baseapp#service-routers). - * It automatically configures the **[module manager](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#manager)** based on the app wiring configuration. The module manager facilitates operations related to these modules, like registering their [`Msg` service](/docs/sdk/v0.53//build/building-modules/msg-services) and [gRPC `Query` service](#grpc-query-services), or setting the order of execution between modules for various functions like [`InitChainer`](#initchainer), [`PreBlocker`](#preblocker) and [`BeginBlocker` and `EndBlocker`](#beginblocker-and-endblocker). -* [**An App Wiring configuration file**](/docs/sdk/v0.53//build/building-apps/runtime) The app wiring configuration file contains the list of application's modules that `runtime` must instantiate. The instantiation of the modules are done using `depinject`. It also contains the order in which all module's `InitGenesis` and `Pre/Begin/EndBlocker` methods should be executed. + * It automatically configures the **[module manager](/docs/sdk/v0.53/build/building-modules/module-manager#manager)** based on the app wiring configuration. The module manager facilitates operations related to these modules, like registering their [`Msg` service](/docs/sdk/v0.53/build/building-modules/msg-services) and [gRPC `Query` service](#grpc-query-services), or setting the order of execution between modules for various functions like [`InitChainer`](#initchainer), [`PreBlocker`](#preblocker) and [`BeginBlocker` and `EndBlocker`](#beginblocker-and-endblocker). +* [**An App Wiring configuration file**](/docs/sdk/v0.53/build/building-apps/runtime) The app wiring configuration file contains the list of application's modules that `runtime` must instantiate. The instantiation of the modules are done using `depinject`. It also contains the order in which all module's `InitGenesis` and `Pre/Begin/EndBlocker` methods should be executed. * **A reference to an [`appCodec`](/docs/sdk/v0.53/learn/advanced/encoding).** The application's `appCodec` is used to serialize and deserialize data structures in order to store them, as stores can only persist `[]bytes`. The default codec is [Protocol Buffers](/docs/sdk/v0.53/learn/advanced/encoding). * **A reference to a [`legacyAmino`](/docs/sdk/v0.53/learn/advanced/encoding) codec.** Some parts of the Cosmos SDK have not been migrated to use the `appCodec` above, and are still hardcoded to use Amino. Other parts explicitly use Amino for backwards compatibility. For these reasons, the application still holds a reference to the legacy Amino codec. Please note that the Amino codec will be removed from the SDK in the upcoming releases. @@ -619,12 +619,12 @@ Application Here are the main actions performed by this function: -* Instantiate a new [`codec`](/docs/sdk/v0.53/learn/advanced/encoding) and initialize the `codec` of each of the application's modules using the [basic manager](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#basicmanager). +* Instantiate a new [`codec`](/docs/sdk/v0.53/learn/advanced/encoding) and initialize the `codec` of each of the application's modules using the [basic manager](/docs/sdk/v0.53/build/building-modules/module-manager#basicmanager). * Instantiate a new application with a reference to a `baseapp` instance, a codec, and all the appropriate store keys. * Instantiate all the [`keeper`](#keeper) objects defined in the application's `type` using the `NewKeeper` function of each of the application's modules. Note that keepers must be instantiated in the correct order, as the `NewKeeper` of one module might require a reference to another module's `keeper`. -* Instantiate the application's [module manager](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#manager) with the [`AppModule`](#application-module-interface) object of each of the application's modules. +* Instantiate the application's [module manager](/docs/sdk/v0.53/build/building-modules/module-manager#manager) with the [`AppModule`](#application-module-interface) object of each of the application's modules. * With the module manager, initialize the application's [`Msg` services](/docs/sdk/v0.53/learn/advanced/baseapp#msg-services), [gRPC `Query` services](/docs/sdk/v0.53/learn/advanced/baseapp#grpc-query-services), [legacy `Msg` routes](/docs/sdk/v0.53/learn/advanced/baseapp#routing), and [legacy query routes](/docs/sdk/v0.53/learn/advanced/baseapp#query-routing). When a transaction is relayed to the application by CometBFT via the ABCI, it is routed to the appropriate module's [`Msg` service](#msg-services) using the routes defined here. Likewise, when a gRPC query request is received by the application, it is routed to the appropriate module's [`gRPC query service`](#grpc-query-services) using the gRPC routes defined here. The Cosmos SDK still supports legacy `Msg`s and legacy CometBFT queries, which are routed using the legacy `Msg` routes and the legacy query routes, respectively. -* With the module manager, register the [application's modules' invariants](/docs/sdk/v0.53//build/building-modules/invariants). Invariants are variables (e.g. total supply of a token) that are evaluated at the end of each block. The process of checking invariants is done via a special module called the [`InvariantsRegistry`](/docs/sdk/v0.53//build/building-modules/invariants#invariant-registry). The value of the invariant should be equal to a predicted value defined in the module. Should the value be different than the predicted one, special logic defined in the invariant registry is triggered (usually the chain is halted). This is useful to make sure that no critical bug goes unnoticed, producing long-lasting effects that are hard to fix. +* With the module manager, register the [application's modules' invariants](/docs/sdk/v0.53/build/building-modules/invariants). Invariants are variables (e.g. total supply of a token) that are evaluated at the end of each block. The process of checking invariants is done via a special module called the [`InvariantsRegistry`](/docs/sdk/v0.53/build/building-modules/invariants#invariant-registry). The value of the invariant should be equal to a predicted value defined in the module. Should the value be different than the predicted one, special logic defined in the invariant registry is triggered (usually the chain is halted). This is useful to make sure that no critical bug goes unnoticed, producing long-lasting effects that are hard to fix. * With the module manager, set the order of execution between the `InitGenesis`, `PreBlocker`, `BeginBlocker`, and `EndBlocker` functions of each of the [application's modules](#application-module-interface). Note that not all modules implement these functions. * Set the remaining application parameters: * [`InitChainer`](#initchainer): used to initialize the application when it is first started. @@ -1655,7 +1655,7 @@ return modAccAddrs The `InitChainer` is a function that initializes the state of the application from a genesis file (i.e. token balances of genesis accounts). It is called when the application receives the `InitChain` message from the CometBFT engine, which happens when the node is started at `appBlockHeight == 0` (i.e. on genesis). The application must set the `InitChainer` in its [constructor](#constructor-function) via the [`SetInitChainer`](https://pkg.go.dev/github.com/cosmos/cosmos-sdk/baseapp#BaseApp.SetInitChainer) method. -In general, the `InitChainer` is mostly composed of the [`InitGenesis`](/docs/sdk/v0.53//build/building-modules/genesis#initgenesis) function of each of the application's modules. This is done by calling the `InitGenesis` function of the module manager, which in turn calls the `InitGenesis` function of each of the modules it contains. Note that the order in which the modules' `InitGenesis` functions must be called has to be set in the module manager using the [module manager's](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) `SetOrderInitGenesis` method. This is done in the [application's constructor](#application-constructor), and the `SetOrderInitGenesis` has to be called before the `SetInitChainer`. +In general, the `InitChainer` is mostly composed of the [`InitGenesis`](/docs/sdk/v0.53/build/building-modules/genesis#initgenesis) function of each of the application's modules. This is done by calling the `InitGenesis` function of the module manager, which in turn calls the `InitGenesis` function of each of the modules it contains. Note that the order in which the modules' `InitGenesis` functions must be called has to be set in the module manager using the [module manager's](/docs/sdk/v0.53/build/building-modules/module-manager) `SetOrderInitGenesis` method. This is done in the [application's constructor](#application-constructor), and the `SetOrderInitGenesis` has to be called before the `SetInitChainer`. See an example of an `InitChainer` from `simapp`: @@ -2691,7 +2691,7 @@ The new ctx must be passed to all the other lifecycle methods. The Cosmos SDK offers developers the possibility to implement automatic execution of code as part of their application. This is implemented through two functions called `BeginBlocker` and `EndBlocker`. They are called when the application receives the `FinalizeBlock` messages from the CometBFT consensus engine, which happens respectively at the beginning and at the end of each block. The application must set the `BeginBlocker` and `EndBlocker` in its [constructor](#constructor-function) via the [`SetBeginBlocker`](https://pkg.go.dev/github.com/cosmos/cosmos-sdk/baseapp#BaseApp.SetBeginBlocker) and [`SetEndBlocker`](https://pkg.go.dev/github.com/cosmos/cosmos-sdk/baseapp#BaseApp.SetEndBlocker) methods. -In general, the `BeginBlocker` and `EndBlocker` functions are mostly composed of the [`BeginBlock` and `EndBlock`](/docs/sdk/v0.53//build/building-modules/beginblock-endblock) functions of each of the application's modules. This is done by calling the `BeginBlock` and `EndBlock` functions of the module manager, which in turn calls the `BeginBlock` and `EndBlock` functions of each of the modules it contains. Note that the order in which the modules' `BeginBlock` and `EndBlock` functions must be called has to be set in the module manager using the `SetOrderBeginBlockers` and `SetOrderEndBlockers` methods, respectively. This is done via the [module manager](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) in the [application's constructor](#application-constructor), and the `SetOrderBeginBlockers` and `SetOrderEndBlockers` methods have to be called before the `SetBeginBlocker` and `SetEndBlocker` functions. +In general, the `BeginBlocker` and `EndBlocker` functions are mostly composed of the [`BeginBlock` and `EndBlock`](/docs/sdk/v0.53/build/building-modules/beginblock-endblock) functions of each of the application's modules. This is done by calling the `BeginBlock` and `EndBlock` functions of the module manager, which in turn calls the `BeginBlock` and `EndBlock` functions of each of the modules it contains. Note that the order in which the modules' `BeginBlock` and `EndBlock` functions must be called has to be set in the module manager using the `SetOrderBeginBlockers` and `SetOrderEndBlockers` methods, respectively. This is done via the [module manager](/docs/sdk/v0.53/build/building-modules/module-manager) in the [application's constructor](#application-constructor), and the `SetOrderBeginBlockers` and `SetOrderEndBlockers` methods have to be called before the `SetBeginBlocker` and `SetEndBlocker` functions. As a sidenote, it is important to remember that application-specific blockchains are deterministic. Developers must be careful not to introduce non-determinism in `BeginBlocker` or `EndBlocker`, and must also be careful not to make them too computationally expensive, as [gas](/docs/sdk/v0.53/gas-fees) does not constrain the cost of `BeginBlocker` and `EndBlocker` execution. @@ -3737,8 +3737,8 @@ type EncodingConfig struct { Here are descriptions of what each of the four fields means: * `InterfaceRegistry`: The `InterfaceRegistry` is used by the Protobuf codec to handle interfaces that are encoded and decoded (we also say "unpacked") using [`google.protobuf.Any`](https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/any.proto). `Any` could be thought as a struct that contains a `type_url` (name of a concrete type implementing the interface) and a `value` (its encoded bytes). `InterfaceRegistry` provides a mechanism for registering interfaces and implementations that can be safely unpacked from `Any`. Each application module implements the `RegisterInterfaces` method that can be used to register the module's own interfaces and implementations. - * You can read more about `Any` in [ADR-019](/docs/sdk/v0.53//build/architecture/adr-019-protobuf-state-encoding). - * To go more into details, the Cosmos SDK uses an implementation of the Protobuf specification called [`gogoprotobuf`](https://github.com/cosmos/gogoproto). By default, the [gogo protobuf implementation of `Any`](https://pkg.go.dev/github.com/cosmos/gogoproto/types) uses [global type registration](https://github.com/cosmos/gogoproto/blob/master/proto/properties.go#L540) to decode values packed in `Any` into concrete Go types. This introduces a vulnerability where any malicious module in the dependency tree could register a type with the global protobuf registry and cause it to be loaded and unmarshaled by a transaction that referenced it in the `type_url` field. For more information, please refer to [ADR-019](/docs/sdk/v0.53//build/architecture/adr-019-protobuf-state-encoding). + * You can read more about `Any` in [ADR-019](/docs/sdk/v0.53/build/architecture/adr-019-protobuf-state-encoding). + * To go more into details, the Cosmos SDK uses an implementation of the Protobuf specification called [`gogoprotobuf`](https://github.com/cosmos/gogoproto). By default, the [gogo protobuf implementation of `Any`](https://pkg.go.dev/github.com/cosmos/gogoproto/types) uses [global type registration](https://github.com/cosmos/gogoproto/blob/master/proto/properties.go#L540) to decode values packed in `Any` into concrete Go types. This introduces a vulnerability where any malicious module in the dependency tree could register a type with the global protobuf registry and cause it to be loaded and unmarshaled by a transaction that referenced it in the `type_url` field. For more information, please refer to [ADR-019](/docs/sdk/v0.53/build/architecture/adr-019-protobuf-state-encoding). * `Codec`: The default codec used throughout the Cosmos SDK. It is composed of a `BinaryCodec` used to encode and decode state, and a `JSONCodec` used to output data to the users (for example, in the [CLI](#cli)). By default, the SDK uses Protobuf as `Codec`. * `TxConfig`: `TxConfig` defines an interface a client can utilize to generate an application-defined concrete transaction type. Currently, the SDK handles two transaction types: `SIGN_MODE_DIRECT` (which uses Protobuf binary as over-the-wire encoding) and `SIGN_MODE_LEGACY_AMINO_JSON` (which depends on Amino). Read more about transactions [here](/docs/sdk/v0.53/learn/advanced/transactions). * `Amino`: Some legacy parts of the Cosmos SDK still use Amino for backwards-compatibility. Each module exposes a `RegisterLegacyAmino` method to register the module's specific types within Amino. This `Amino` codec should not be used by app developers anymore, and will be removed in future releases. @@ -3768,13 +3768,13 @@ type EncodingConfig struct { ## Modules -[Modules](/docs/sdk/v0.53//build/building-modules/intro) are the heart and soul of Cosmos SDK applications. They can be considered as state-machines nested within the state-machine. When a transaction is relayed from the underlying CometBFT engine via the ABCI to the application, it is routed by [`baseapp`](/docs/sdk/v0.53/learn/advanced/baseapp) to the appropriate module in order to be processed. This paradigm enables developers to easily build complex state-machines, as most of the modules they need often already exist. **For developers, most of the work involved in building a Cosmos SDK application revolves around building custom modules required by their application that do not exist yet, and integrating them with modules that do already exist into one coherent application**. In the application directory, the standard practice is to store modules in the `x/` folder (not to be confused with the Cosmos SDK's `x/` folder, which contains already-built modules). +[Modules](/docs/sdk/v0.53/build/building-modules/intro) are the heart and soul of Cosmos SDK applications. They can be considered as state-machines nested within the state-machine. When a transaction is relayed from the underlying CometBFT engine via the ABCI to the application, it is routed by [`baseapp`](/docs/sdk/v0.53/learn/advanced/baseapp) to the appropriate module in order to be processed. This paradigm enables developers to easily build complex state-machines, as most of the modules they need often already exist. **For developers, most of the work involved in building a Cosmos SDK application revolves around building custom modules required by their application that do not exist yet, and integrating them with modules that do already exist into one coherent application**. In the application directory, the standard practice is to store modules in the `x/` folder (not to be confused with the Cosmos SDK's `x/` folder, which contains already-built modules). ### Application Module Interface -Modules must implement [interfaces](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#application-module-interfaces) defined in the Cosmos SDK, [`AppModuleBasic`](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#appmodulebasic) and [`AppModule`](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#appmodule). The former implements basic non-dependent elements of the module, such as the `codec`, while the latter handles the bulk of the module methods (including methods that require references to other modules' `keeper`s). Both the `AppModule` and `AppModuleBasic` types are, by convention, defined in a file called `module.go`. +Modules must implement [interfaces](/docs/sdk/v0.53/build/building-modules/module-manager#application-module-interfaces) defined in the Cosmos SDK, [`AppModuleBasic`](/docs/sdk/v0.53/build/building-modules/module-manager#appmodulebasic) and [`AppModule`](/docs/sdk/v0.53/build/building-modules/module-manager#appmodule). The former implements basic non-dependent elements of the module, such as the `codec`, while the latter handles the bulk of the module methods (including methods that require references to other modules' `keeper`s). Both the `AppModule` and `AppModuleBasic` types are, by convention, defined in a file called `module.go`. -`AppModule` exposes a collection of useful methods on the module that facilitates the composition of modules into a coherent application. These methods are called from the [`module manager`](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager#manager), which manages the application's collection of modules. +`AppModule` exposes a collection of useful methods on the module that facilitates the composition of modules into a coherent application. These methods are called from the [`module manager`](/docs/sdk/v0.53/build/building-modules/module-manager#manager), which manages the application's collection of modules. ### `Msg` Services @@ -3803,7 +3803,7 @@ Each module should also implement the `RegisterServices` method as part of the [ ### gRPC `Query` Services -gRPC `Query` services allow users to query the state using [gRPC](https://grpc.io). They are enabled by default, and can be configured under the `grpc.enable` and `grpc.address` fields inside [`app.toml`](/docs/sdk/v0.53//user/run-node/run-node#configuring-the-node-using-apptoml-and-configtoml). +gRPC `Query` services allow users to query the state using [gRPC](https://grpc.io). They are enabled by default, and can be configured under the `grpc.enable` and `grpc.address` fields inside [`app.toml`](/docs/sdk/v0.53/user/run-node/run-node#configuring-the-node-using-apptoml-and-configtoml). gRPC `Query` services are defined in the module's Protobuf definition files, specifically inside `query.proto`. The `query.proto` definition file exposes a single `Query` [Protobuf service](https://developers.google.com/protocol-buffers/docs/proto#services). Each gRPC query endpoint corresponds to a service method, starting with the `rpc` keyword, inside the `Query` service. @@ -3813,7 +3813,7 @@ Finally, each module should also implement the `RegisterServices` method as part ### Keeper -[`Keepers`](/docs/sdk/v0.53//build/building-modules/keeper) are the gatekeepers of their module's store(s). To read or write in a module's store, it is mandatory to go through one of its `keeper`'s methods. This is ensured by the [object-capabilities](/docs/sdk/v0.53/learn/advanced/ocap) model of the Cosmos SDK. Only objects that hold the key to a store can access it, and only the module's `keeper` should hold the key(s) to the module's store(s). +[`Keepers`](/docs/sdk/v0.53/build/building-modules/keeper) are the gatekeepers of their module's store(s). To read or write in a module's store, it is mandatory to go through one of its `keeper`'s methods. This is ensured by the [object-capabilities](/docs/sdk/v0.53/learn/advanced/ocap) model of the Cosmos SDK. Only objects that hold the key to a store can access it, and only the module's `keeper` should hold the key(s) to the module's store(s). `Keepers` are generally defined in a file called `keeper.go`. It contains the `keeper`'s type definition and methods. @@ -3831,7 +3831,7 @@ Each module defines command-line commands, gRPC services, and REST routes to be #### CLI -Generally, the [commands related to a module](/docs/sdk/v0.53//build/building-modules/module-interfaces#cli) are defined in a folder called `client/cli` in the module's folder. The CLI divides commands into two categories, transactions and queries, defined in `client/cli/tx.go` and `client/cli/query.go`, respectively. Both commands are built on top of the [Cobra Library](https://github.com/spf13/cobra): +Generally, the [commands related to a module](/docs/sdk/v0.53/build/building-modules/module-interfaces#cli) are defined in a folder called `client/cli` in the module's folder. The CLI divides commands into two categories, transactions and queries, defined in `client/cli/tx.go` and `client/cli/query.go`, respectively. Both commands are built on top of the [Cobra Library](https://github.com/spf13/cobra): * Transactions commands let users generate new transactions so that they can be included in a block and eventually update the state. One command should be created for each [message type](#message-types) defined in the module. The command calls the constructor of the message with the parameters provided by the end-user, and wraps it into a transaction. The Cosmos SDK handles signing and the addition of other transaction metadata. * Queries let users query the subset of the state defined by the module. Query commands forward queries to the [application's query router](/docs/sdk/v0.53/learn/advanced/baseapp#query-routing), which routes them to the appropriate [querier](#querier) the `queryRoute` parameter supplied. @@ -3851,7 +3851,7 @@ Some external clients may not wish to use gRPC. In this case, the Cosmos SDK pro The REST endpoints are defined in the Protobuf files, along with the gRPC services, using Protobuf annotations. Modules that want to expose REST queries should add `google.api.http` annotations to their `rpc` methods. By default, all REST endpoints defined in the SDK have a URL starting with the `/cosmos/` prefix. -The Cosmos SDK also provides a development endpoint to generate [Swagger](https://swagger.io/) definition files for these REST endpoints. This endpoint can be enabled inside the [`app.toml`](/docs/sdk/v0.53//user/run-node/run-node#configuring-the-node-using-apptoml-and-configtoml) config file, under the `api.swagger` key. +The Cosmos SDK also provides a development endpoint to generate [Swagger](https://swagger.io/) definition files for these REST endpoints. This endpoint can be enabled inside the [`app.toml`](/docs/sdk/v0.53/user/run-node/run-node#configuring-the-node-using-apptoml-and-configtoml) config file, under the `api.swagger` key. ## Application Interface diff --git a/docs/sdk/v0.53/learn/beginner/gas-fees.mdx b/docs/sdk/v0.53/learn/beginner/gas-fees.mdx index 7eba44e9..6c57c391 100644 --- a/docs/sdk/v0.53/learn/beginner/gas-fees.mdx +++ b/docs/sdk/v0.53/learn/beginner/gas-fees.mdx @@ -10,7 +10,7 @@ This document describes the default strategies to handle gas and fees within a C **Pre-requisite Readings** -* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.53/learn/beginner/app-anatomyy) +* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.53/learn/beginner/app-anatomy) @@ -19,7 +19,7 @@ This document describes the default strategies to handle gas and fees within a C In the Cosmos SDK, `gas` is a special unit that is used to track the consumption of resources during execution. `gas` is typically consumed whenever read and writes are made to the store, but it can also be consumed if expensive computation needs to be done. It serves two main purposes: * Make sure blocks are not consuming too many resources and are finalized. This is implemented by default in the Cosmos SDK via the [block gas meter](#block-gas-meter). -* Prevent spam and abuse from end-user. To this end, `gas` consumed during [`message`](/docs/sdk/v0.53//build/building-modules/messages-and-queries#messages) execution is typically priced, resulting in a `fee` (`fees = gas * gas-prices`). `fees` generally have to be paid by the sender of the `message`. Note that the Cosmos SDK does not enforce `gas` pricing by default, as there may be other ways to prevent spam (e.g. bandwidth schemes). Still, most applications implement `fee` mechanisms to prevent spam by using the [`AnteHandler`](#antehandler). +* Prevent spam and abuse from end-user. To this end, `gas` consumed during [`message`](/docs/sdk/v0.53/build/building-modules/messages-and-queries#messages) execution is typically priced, resulting in a `fee` (`fees = gas * gas-prices`). `fees` generally have to be paid by the sender of the `message`. Note that the Cosmos SDK does not enforce `gas` pricing by default, as there may be other ways to prevent spam (e.g. bandwidth schemes). Still, most applications implement `fee` mechanisms to prevent spam by using the [`AnteHandler`](#antehandler). ## Gas Meter @@ -406,7 +406,7 @@ By default, the Cosmos SDK makes use of two different gas meters, the [main gas `ctx.GasMeter()` is the main gas meter of the application. The main gas meter is initialized in `FinalizeBlock` via `setFinalizeBlockState`, and then tracks gas consumption during execution sequences that lead to state-transitions, i.e. those originally triggered by [`FinalizeBlock`](/docs/sdk/v0.53/learn/advanced/baseapp#finalizeblock). At the beginning of each transaction execution, the main gas meter **must be set to 0** in the [`AnteHandler`](#antehandler), so that it can track gas consumption per-transaction. -Gas consumption can be done manually, generally by the module developer in the [`BeginBlocker`, `EndBlocker`](/docs/sdk/v0.53//build/building-modules/beginblock-endblock) or [`Msg` service](/docs/sdk/v0.53//build/building-modules/msg-services), but most of the time it is done automatically whenever there is a read or write to the store. This automatic gas consumption logic is implemented in a special store called [`GasKv`](/docs/sdk/v0.53/learn/advanced/store#gaskv-store). +Gas consumption can be done manually, generally by the module developer in the [`BeginBlocker`, `EndBlocker`](/docs/sdk/v0.53/build/building-modules/beginblock-endblock) or [`Msg` service](/docs/sdk/v0.53/build/building-modules/msg-services), but most of the time it is done automatically whenever there is a read or write to the store. This automatic gas consumption logic is implemented in a special store called [`GasKv`](/docs/sdk/v0.53/learn/advanced/store#gaskv-store). ### Block Gas Meter @@ -616,7 +616,7 @@ This enables developers to play with various types for the transaction of their // Reference: https://github.com/cosmos/cosmos-sdk/blob/v0.53.0-rc.2/proto/cosmos/tx/v1beta1/tx.proto#L15-L28 ``` -* Verify signatures for each [`message`](/docs/sdk/v0.53//build/building-modules/messages-and-queries#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`. +* Verify signatures for each [`message`](/docs/sdk/v0.53/build/building-modules/messages-and-queries#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. * Set `newCtx.GasMeter` to 0, with a limit of `GasWanted`. **This step is crucial**, as it not only makes sure the transaction cannot consume infinite gas, but also that `ctx.GasMeter` is reset in-between each transaction (`ctx` is set to `newCtx` after `anteHandler` is run, and the `anteHandler` is run each time a transactions executes). diff --git a/docs/sdk/v0.53/learn/beginner/query-lifecycle.mdx b/docs/sdk/v0.53/learn/beginner/query-lifecycle.mdx index da3cd88c..85403e60 100644 --- a/docs/sdk/v0.53/learn/beginner/query-lifecycle.mdx +++ b/docs/sdk/v0.53/learn/beginner/query-lifecycle.mdx @@ -15,9 +15,9 @@ This document describes the lifecycle of a query in a Cosmos SDK application, fr ## Query Creation -A [**query**](/docs/sdk/v0.53//build/building-modules/messages-and-queries#queries) is a request for information made by end-users of applications through an interface and processed by a full-node. Users can query information about the network, the application itself, and application state directly from the application's stores or modules. Note that queries are different from [transactions](/docs/sdk/v0.53/learn/advanced/transactions) (view the lifecycle [here](/docs/sdk/v0.53/tx-lifecycle)), particularly in that they do not require consensus to be processed (as they do not trigger state-transitions); they can be fully handled by one full-node. +A [**query**](/docs/sdk/v0.53/build/building-modules/messages-and-queries#queries) is a request for information made by end-users of applications through an interface and processed by a full-node. Users can query information about the network, the application itself, and application state directly from the application's stores or modules. Note that queries are different from [transactions](/docs/sdk/v0.53/learn/advanced/transactions) (view the lifecycle [here](/docs/sdk/v0.53/tx-lifecycle)), particularly in that they do not require consensus to be processed (as they do not trigger state-transitions); they can be fully handled by one full-node. -For the purpose of explaining the query lifecycle, let's say the query, `MyQuery`, is requesting a list of delegations made by a certain delegator address in the application called `simapp`. As is to be expected, the [`staking`](/docs/sdk/v0.53//build/modules/staking/README) module handles this query. But first, there are a few ways `MyQuery` can be created by users. +For the purpose of explaining the query lifecycle, let's say the query, `MyQuery`, is requesting a list of delegations made by a certain delegator address in the application called `simapp`. As is to be expected, the [`staking`](/docs/sdk/v0.53/build/modules/staking/README) module handles this query. But first, there are a few ways `MyQuery` can be created by users. ### CLI @@ -27,7 +27,7 @@ The main interface for an application is the command-line interface. Users conne simd query staking delegations ``` -This query command was defined by the [`staking`](/docs/sdk/v0.53//build/modules/staking/README) module developer and added to the list of subcommands by the application developer when creating the CLI. +This query command was defined by the [`staking`](/docs/sdk/v0.53/build/modules/staking/README) module developer and added to the list of subcommands by the application developer when creating the CLI. Note that the general format is as follows: @@ -35,7 +35,7 @@ Note that the general format is as follows: simd query [moduleName] [command] --flag ``` -To provide values such as `--node` (the full-node the CLI connects to), the user can use the [`app.toml`](/docs/sdk/v0.53//user/run-node/run-node#configuring-the-node-using-apptoml-and-configtoml) config file to set them or provide them as flags. +To provide values such as `--node` (the full-node the CLI connects to), the user can use the [`app.toml`](/docs/sdk/v0.53/user/run-node/run-node#configuring-the-node-using-apptoml-and-configtoml) config file to set them or provide them as flags. The CLI understands a specific set of commands, defined in a hierarchical structure by the application developer: from the [root command](/docs/sdk/v0.53/learn/advanced/cli#root-command) (`simd`), the type of command (`Myquery`), the module that contains the command (`staking`), and command itself (`delegations`). Thus, the CLI knows exactly which module handles this command and directly passes the call there. @@ -74,7 +74,7 @@ The preceding examples show how an external user can interact with a node by que The first thing that is created in the execution of a CLI command is a `client.Context`. A `client.Context` is an object that stores all the data needed to process a request on the user side. In particular, a `client.Context` stores the following: * **Codec**: The [encoder/decoder](/docs/sdk/v0.53/learn/advanced/encoding) used by the application, used to marshal the parameters and query before making the CometBFT RPC request and unmarshal the returned response into a JSON object. The default codec used by the CLI is Protobuf. -* **Account Decoder**: The account decoder from the [`auth`](/docs/sdk/v0.53//build/modules/auth/README) module, which translates `[]byte`s into accounts. +* **Account Decoder**: The account decoder from the [`auth`](/docs/sdk/v0.53/build/modules/auth/README) module, which translates `[]byte`s into accounts. * **RPC Client**: The CometBFT RPC Client, or node, to which requests are relayed. * **Keyring**: A \[Key Manager]../beginner/03-accounts.md#keyring) used to sign transactions and handle other operations with keys. * **Output Writer**: A [Writer](https://pkg.go.dev/io/#Writer) used to output the response. @@ -955,7 +955,7 @@ Read more about ABCI Clients and CometBFT RPC in the [CometBFT documentation](ht When a query is received by the full-node after it has been relayed from the underlying consensus engine, it is at that point being handled within an environment that understands application-specific types and has a copy of the state. [`baseapp`](/docs/sdk/v0.53/learn/advanced/baseapp) implements the ABCI [`Query()`](/docs/sdk/v0.53/learn/advanced/baseapp#query) function and handles gRPC queries. The query route is parsed, and it matches the fully-qualified service method name of an existing service method (most likely in one of the modules), then `baseapp` relays the request to the relevant module. -Since `MyQuery` has a Protobuf fully-qualified service method name from the `staking` module (recall `/cosmos.staking.v1beta1.Query/Delegations`), `baseapp` first parses the path, then uses its own internal `GRPCQueryRouter` to retrieve the corresponding gRPC handler, and routes the query to the module. The gRPC handler is responsible for recognizing this query, retrieving the appropriate values from the application's stores, and returning a response. Read more about query services [here](/docs/sdk/v0.53//build/building-modules/query-services). +Since `MyQuery` has a Protobuf fully-qualified service method name from the `staking` module (recall `/cosmos.staking.v1beta1.Query/Delegations`), `baseapp` first parses the path, then uses its own internal `GRPCQueryRouter` to retrieve the corresponding gRPC handler, and routes the query to the module. The gRPC handler is responsible for recognizing this query, retrieving the appropriate values from the application's stores, and returning a response. Read more about query services [here](/docs/sdk/v0.53/build/building-modules/query-services). Once a result is received from the querier, `baseapp` begins the process of returning a response to the user. diff --git a/docs/sdk/v0.53/learn/beginner/tx-lifecycle.mdx b/docs/sdk/v0.53/learn/beginner/tx-lifecycle.mdx index af761985..a1d7e15c 100644 --- a/docs/sdk/v0.53/learn/beginner/tx-lifecycle.mdx +++ b/docs/sdk/v0.53/learn/beginner/tx-lifecycle.mdx @@ -10,7 +10,7 @@ This document describes the lifecycle of a transaction from creation to committe **Pre-requisite Readings** -* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.53/learn/beginner/app-anatomyy) +* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.53/learn/beginner/app-anatomy) ## Creation @@ -107,7 +107,7 @@ To discard obviously invalid messages, the `BaseApp` type calls the `ValidateBas `ValidateBasic` can include only **stateless** checks (the checks that do not require access to the state). -The `ValidateBasic` method on messages has been deprecated in favor of validating messages directly in their respective [`Msg` services](/docs/sdk/v0.53//build/building-modules/msg-services#Validation). +The `ValidateBasic` method on messages has been deprecated in favor of validating messages directly in their respective [`Msg` services](/docs/sdk/v0.53/build/building-modules/msg-services#Validation). Read [RFC 001](https://docs.cosmos.network/main/rfc/rfc-001-tx-validation) for more details. @@ -118,7 +118,7 @@ Read [RFC 001](https://docs.cosmos.network/main/rfc/rfc-001-tx-validation) for m #### Guideline -`ValidateBasic` should not be used anymore. Message validation should be performed in the `Msg` service when [handling a message](/docs/sdk/v0.53//build/building-modules/msg-services#Validation) in a module Msg Server. +`ValidateBasic` should not be used anymore. Message validation should be performed in the `Msg` service when [handling a message](/docs/sdk/v0.53/build/building-modules/msg-services#Validation) in a module Msg Server. ### AnteHandler @@ -241,8 +241,8 @@ Instead of using their `checkState`, full-nodes use `finalizeblock`: * **`MsgServiceRouter`:** After `CheckTx` exits, `FinalizeBlock` continues to run [`runMsgs`](/docs/sdk/v0.53/learn/advanced/baseapp#runtx-antehandler-runmsgs-posthandler) to fully execute each `Msg` within the transaction. Since the transaction may have messages from different modules, `BaseApp` needs to know which module - to find the appropriate handler. This is achieved using `BaseApp`'s `MsgServiceRouter` so that it can be processed by the module's Protobuf [`Msg` service](/docs/sdk/v0.53//build/building-modules/msg-services). - For `LegacyMsg` routing, the `Route` function is called via the [module manager](/docs/sdk/v0.53//build/building-modules/docs/sdk/v0.53/build/building-modules/module-manager) to retrieve the route name and find the legacy [`Handler`](/docs/sdk/v0.53//build/building-modules/msg-services#handler-type) within the module. + to find the appropriate handler. This is achieved using `BaseApp`'s `MsgServiceRouter` so that it can be processed by the module's Protobuf [`Msg` service](/docs/sdk/v0.53/build/building-modules/msg-services). + For `LegacyMsg` routing, the `Route` function is called via the [module manager](/docs/sdk/v0.53/build/building-modules/module-manager) to retrieve the route name and find the legacy [`Handler`](/docs/sdk/v0.53/build/building-modules/msg-services#handler-type) within the module. * **`Msg` service:** Protobuf `Msg` service is responsible for executing each message in the `Tx` and causes state transitions to persist in `finalizeBlockState`. diff --git a/docs/sdk/v0.53/learn/intro/sdk-app-architecture.mdx b/docs/sdk/v0.53/learn/intro/sdk-app-architecture.mdx index 2b7018c6..4920a126 100644 --- a/docs/sdk/v0.53/learn/intro/sdk-app-architecture.mdx +++ b/docs/sdk/v0.53/learn/intro/sdk-app-architecture.mdx @@ -84,7 +84,7 @@ Note that **CometBFT only handles transaction bytes**. It has no knowledge of wh Here are the most important messages of the ABCI: * `CheckTx`: When a transaction is received by CometBFT, it is passed to the application to check if a few basic requirements are met. `CheckTx` is used to protect the mempool of full-nodes against spam transactions. . A special handler called the [`AnteHandler`](/docs/sdk/v0.53/learn/beginner/gas-fees#antehandler) is used to execute a series of validation steps such as checking for sufficient fees and validating the signatures. If the checks are valid, the transaction is added to the [mempool](https://docs.cometbft.com/v0.37/spec/p2p/legacy-docs/messages/mempool) and relayed to peer nodes. Note that transactions are not processed (i.e. no modification of the state occurs) with `CheckTx` since they have not been included in a block yet. -* `DeliverTx`: When a [valid block](https://docs.cometbft.com/v0.37/spec/core/data_structures#block) is received by CometBFT, 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](/docs/sdk/v0.53//build/building-modules/msg-services) RPC for each message in the transaction. +* `DeliverTx`: When a [valid block](https://docs.cometbft.com/v0.37/spec/core/data_structures#block) is received by CometBFT, 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](/docs/sdk/v0.53/build/building-modules/msg-services) 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 [CometBFT docs](https://docs.cometbft.com/v0.37/spec/abci/). diff --git a/docs/sdk/v0.53/learn/intro/sdk-design.mdx b/docs/sdk/v0.53/learn/intro/sdk-design.mdx index f29daf50..7fb01124 100644 --- a/docs/sdk/v0.53/learn/intro/sdk-design.mdx +++ b/docs/sdk/v0.53/learn/intro/sdk-design.mdx @@ -13,7 +13,7 @@ Here is a simplified view of how transactions are handled by an application buil ## `baseapp` -`baseapp` is the boilerplate implementation of a Cosmos SDK application. It comes with an implementation of the ABCI to handle the connection with the underlying consensus engine. Typically, a Cosmos SDK application extends `baseapp` by embedding it in [`app.go`](/docs/sdk/v0.53/learn/beginner/app-anatomyy#core-application-file). +`baseapp` is the boilerplate implementation of a Cosmos SDK application. It comes with an implementation of the ABCI to handle the connection with the underlying consensus engine. Typically, a Cosmos SDK application extends `baseapp` by embedding it in [`app.go`](/docs/sdk/v0.53/learn/beginner/app-anatomy#core-application-file). Here is an example of this from `simapp`, the Cosmos SDK demonstration app: diff --git a/docs/sdk/v0.53/user/run-node/interact-node.mdx b/docs/sdk/v0.53/user/run-node/interact-node.mdx index c6cdc8d6..020a5d4a 100644 --- a/docs/sdk/v0.53/user/run-node/interact-node.mdx +++ b/docs/sdk/v0.53/user/run-node/interact-node.mdx @@ -10,7 +10,7 @@ There are multiple ways to interact with a node: using the CLI, using gRPC or us **Pre-requisite Readings** -* [gRPC, REST and CometBFT Endpoints](/docs/sdk/v0.53//learn/advanced/grpc_rest) +* [gRPC, REST and CometBFT Endpoints](/docs/sdk/v0.53/learn/advanced/grpc_rest) * [Running a Node](/docs/sdk/v0.53/user/run-node/run-node) @@ -54,7 +54,7 @@ You should see two delegations, the first one made from the `gentx`, and the sec ## Using gRPC -The Protobuf ecosystem developed tools for different use cases, including code-generation from `*.proto` files into various languages. These tools allow the building of clients easily. Often, the client connection (i.e. the transport) can be plugged and replaced very easily. Let's explore one of the most popular transport: [gRPC](/docs/sdk/v0.53//learn/advanced/grpc_rest). +The Protobuf ecosystem developed tools for different use cases, including code-generation from `*.proto` files into various languages. These tools allow the building of clients easily. Often, the client connection (i.e. the transport) can be plugged and replaced very easily. Let's explore one of the most popular transport: [gRPC](/docs/sdk/v0.53/learn/advanced/grpc_rest). Since the code generation library largely depends on your own tech stack, we will only present three alternatives: @@ -258,7 +258,7 @@ CosmJS documentation can be found at [Link](https://cosmos.github.io/cosmjs). As ## Using the REST Endpoints -As described in the [gRPC guide](/docs/sdk/v0.53//learn/advanced/grpc_rest), all gRPC services on the Cosmos SDK are made available for more convenient REST-based queries through gRPC-gateway. The format of the URL path is based on the Protobuf service method's full-qualified name, but may contain small customizations so that final URLs look more idiomatic. For example, the REST endpoint for the `cosmos.bank.v1beta1.Query/AllBalances` method is `GET /cosmos/bank/v1beta1/balances/{address}`. Request arguments are passed as query parameters. +As described in the [gRPC guide](/docs/sdk/v0.53/learn/advanced/grpc_rest), all gRPC services on the Cosmos SDK are made available for more convenient REST-based queries through gRPC-gateway. The format of the URL path is based on the Protobuf service method's full-qualified name, but may contain small customizations so that final URLs look more idiomatic. For example, the REST endpoint for the `cosmos.bank.v1beta1.Query/AllBalances` method is `GET /cosmos/bank/v1beta1/balances/{address}`. Request arguments are passed as query parameters. Note that the REST endpoints are not enabled by default. To enable them, edit the `api` section of your `~/.simapp/config/app.toml` file: diff --git a/docs/sdk/v0.53/user/run-node/keyring.mdx b/docs/sdk/v0.53/user/run-node/keyring.mdx index b9a04d5d..6e824e5c 100644 --- a/docs/sdk/v0.53/user/run-node/keyring.mdx +++ b/docs/sdk/v0.53/user/run-node/keyring.mdx @@ -4,7 +4,7 @@ title: Setting up the keyring **Synopsis** -This document describes how to configure and use the keyring and its various backends for an [**application**](/docs/sdk/v0.53//learn/beginner/app-anatomy). +This document describes how to configure and use the keyring and its various backends for an [**application**](/docs/sdk/v0.53/learn/beginner/app-anatomy). The keyring holds the private/public key pairs used to interact with a node. For instance, a validator key needs to be set up before running the blockchain node, so that blocks can be correctly signed. The private key can be stored in different locations, called "backends," such as a file or the operating system's own key storage. diff --git a/docs/sdk/v0.53/user/run-node/run-node.mdx b/docs/sdk/v0.53/user/run-node/run-node.mdx index dcfd3b01..27ae6bc6 100644 --- a/docs/sdk/v0.53/user/run-node/run-node.mdx +++ b/docs/sdk/v0.53/user/run-node/run-node.mdx @@ -10,7 +10,7 @@ Now that the application is ready and the keyring populated, it's time to see ho **Pre-requisite Readings** -* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.53//learn/beginner/app-anatomy) +* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.53/learn/beginner/app-anatomy) * [Setting up the keyring](/docs/sdk/v0.53/user/run-node/keyring) @@ -86,7 +86,7 @@ simd genesis add-genesis-account $MY_VALIDATOR_ADDRESS 100000000000stake Recall that `$MY_VALIDATOR_ADDRESS` is a variable that holds the address of the `my_validator` key in the [keyring](/docs/sdk/v0.53/user/run-node/keyring#adding-keys-to-the-keyring). Also note that the tokens in the Cosmos SDK have the `{amount}{denom}` format: `amount` is an 18-digit-precision decimal number, and `denom` is the unique token identifier with its denomination key (e.g. `atom` or `uatom`). Here, we are granting `stake` tokens, as `stake` is the token identifier used for staking in [`simapp`](https://github.com/cosmos/cosmos-sdk/tree/main/simapp). For your own chain with its own staking denom, that token identifier should be used instead. -Now that your account has some tokens, you need to add a validator to your chain. Validators are special full-nodes that participate in the consensus process (implemented in the [underlying consensus engine](/docs/sdk/v0.53//learn/intro/sdk-app-architecture#cometbft)) in order to add new blocks to the chain. Any account can declare its intention to become a validator operator, but only those with sufficient delegation get to enter the active set (for example, only the top 125 validator candidates with the most delegation get to be validators in the Cosmos Hub). For this guide, you will add your local node (created via the `init` command above) as a validator of your chain. Validators can be declared before a chain is first started via a special transaction included in the genesis file called a `gentx`: +Now that your account has some tokens, you need to add a validator to your chain. Validators are special full-nodes that participate in the consensus process (implemented in the [underlying consensus engine](/docs/sdk/v0.53/learn/intro/sdk-app-architecture#cometbft)) in order to add new blocks to the chain. Any account can declare its intention to become a validator operator, but only those with sufficient delegation get to enter the active set (for example, only the top 125 validator candidates with the most delegation get to be validators in the Cosmos Hub). For this guide, you will add your local node (created via the `init` command above) as a validator of your chain. Validators can be declared before a chain is first started via a special transaction included in the genesis file called a `gentx`: ```bash # Create a gentx. diff --git a/docs/sdk/v0.53/user/run-node/txs.mdx b/docs/sdk/v0.53/user/run-node/txs.mdx index 96385e7f..79a60c71 100644 --- a/docs/sdk/v0.53/user/run-node/txs.mdx +++ b/docs/sdk/v0.53/user/run-node/txs.mdx @@ -432,7 +432,7 @@ error { ### Broadcasting a Transaction -The preferred way to broadcast a transaction is to use gRPC, though using REST (via `gRPC-gateway`) or the CometBFT RPC is also possible. An overview of the differences between these methods is exposed [here](/docs/sdk/v0.53//learn/advanced/grpc_rest). For this tutorial, we will only describe the gRPC method. +The preferred way to broadcast a transaction is to use gRPC, though using REST (via `gRPC-gateway`) or the CometBFT RPC is also possible. An overview of the differences between these methods is exposed [here](/docs/sdk/v0.53/learn/advanced/grpc_rest). For this tutorial, we will only describe the gRPC method. ```go expandable import ( From 877e554078762438494e3f556518cd39837d19f7 Mon Sep 17 00:00:00 2001 From: Cordt Date: Fri, 24 Oct 2025 08:35:09 -0600 Subject: [PATCH 07/10] last bit of url fixes --- docs/evm/next/documentation/concepts/accounts.mdx | 2 +- .../architecture/adr-054-semver-compatible-modules.mdx | 2 +- docs/sdk/v0.47/learn/advanced/cli.mdx | 2 +- docs/sdk/v0.47/learn/beginner/query-lifecycle.mdx | 2 +- docs/sdk/v0.47/user/run-node/run-production.mdx | 2 +- .../architecture/adr-054-semver-compatible-modules.mdx | 2 +- .../v0.50/build/architecture/adr-063-core-module-api.mdx | 4 ++-- .../v0.50/build/architecture/adr-076-tx-malleability.mdx | 6 +++--- docs/sdk/v0.50/build/packages.mdx | 2 +- docs/sdk/v0.50/learn/advanced/cli.mdx | 2 +- docs/sdk/v0.50/learn/beginner/query-lifecycle.mdx | 2 +- docs/sdk/v0.50/user/run-node/run-production.mdx | 2 +- .../architecture/adr-054-semver-compatible-modules.mdx | 2 +- .../v0.53/build/architecture/adr-063-core-module-api.mdx | 4 ++-- .../v0.53/build/architecture/adr-076-tx-malleability.mdx | 6 +++--- docs/sdk/v0.53/build/migrations/intro.mdx | 2 +- docs/sdk/v0.53/build/modules/auth/auth.mdx | 2 +- docs/sdk/v0.53/learn/advanced/cli.mdx | 2 +- docs/sdk/v0.53/learn/beginner/query-lifecycle.mdx | 2 +- .../tutorials/vote-extensions/oracle/getting-started.mdx | 2 +- 20 files changed, 26 insertions(+), 26 deletions(-) diff --git a/docs/evm/next/documentation/concepts/accounts.mdx b/docs/evm/next/documentation/concepts/accounts.mdx index 5418a000..61385a15 100644 --- a/docs/evm/next/documentation/concepts/accounts.mdx +++ b/docs/evm/next/documentation/concepts/accounts.mdx @@ -62,7 +62,7 @@ type EthAccountI interface { **EIP-7702 Support**: Cosmos EVM supports [EIP-7702 code delegation](/docs/evm/next/documentation/evm-compatibility/eip-7702), allowing EOAs to temporarily delegate code execution to smart contracts through the `SetCodeHash` functionality. -For more information on Ethereum accounts head over to the [x/vm module](/docs/evm/next/documentation/cosmos-sdk/modules/vm). +For more information on Ethereum accounts head over to the [x/vm module](/docs/evm/next/documentation/protocol/modules/vm). ### Addresses and Public Keys diff --git a/docs/sdk/v0.47/build/architecture/adr-054-semver-compatible-modules.mdx b/docs/sdk/v0.47/build/architecture/adr-054-semver-compatible-modules.mdx index 2e4f221a..221ed71d 100644 --- a/docs/sdk/v0.47/build/architecture/adr-054-semver-compatible-modules.mdx +++ b/docs/sdk/v0.47/build/architecture/adr-054-semver-compatible-modules.mdx @@ -476,7 +476,7 @@ languages, possibly executed within a WASM VM. ### Minor API Revisions To declare minor API revisions of proto files, we propose the following guidelines (which were already documented -in [cosmos.app.v1alpha module options](/https://github.com/cosmos/cosmos-sdk/blob/v0.47/proto/cosmos/app/v1alpha1/module.proto)): +in [cosmos.app.v1alpha module options](https://github.com/cosmos/cosmos-sdk/blob/v0.47/proto/cosmos/app/v1alpha1/module.proto)): * proto packages which are revised from their initial version (considered revision `0`) should include a `package` * comment in some .proto file containing the test `Revision N` at the start of a comment line where `N` is the current diff --git a/docs/sdk/v0.47/learn/advanced/cli.mdx b/docs/sdk/v0.47/learn/advanced/cli.mdx index c8e01fb1..c2a6a7f1 100644 --- a/docs/sdk/v0.47/learn/advanced/cli.mdx +++ b/docs/sdk/v0.47/learn/advanced/cli.mdx @@ -1417,7 +1417,7 @@ return simApp.ExportAppStateAndValidators(forZeroHeight, jailAllowedAddrs, modul This `txCommand` function adds all the transaction available to end-users for the application. This typically includes: -* **Sign command** from the [`auth`](/docs/sdk/v0.47/build/modules/auth/README) module that signs messages in a transaction. To enable multisig, add the `auth` module's `MultiSign` command. Since every transaction requires some sort of signature in order to be valid, the signing command is necessary for every application. +* **Sign command** from the [`auth`](/docs/sdk/v0.47/build/modules/auth/auth) module that signs messages in a transaction. To enable multisig, add the `auth` module's `MultiSign` command. Since every transaction requires some sort of signature in order to be valid, the signing command is necessary for every application. * **Broadcast command** from the Cosmos SDK client tools, to broadcast transactions. * **All [module transaction commands](/docs/sdk/v0.47/build/building-modules/module-interfaces#transaction-commands)** the application is dependent on, retrieved by using the [basic module manager's](/docs/sdk/v0.47/build/building-modules/module-manager#basic-manager) `AddTxCommands()` function. diff --git a/docs/sdk/v0.47/learn/beginner/query-lifecycle.mdx b/docs/sdk/v0.47/learn/beginner/query-lifecycle.mdx index d8cb8a8e..d937cdf7 100644 --- a/docs/sdk/v0.47/learn/beginner/query-lifecycle.mdx +++ b/docs/sdk/v0.47/learn/beginner/query-lifecycle.mdx @@ -75,7 +75,7 @@ The preceding examples show how an external user can interact with a node by que The first thing that is created in the execution of a CLI command is a `client.Context`. A `client.Context` is an object that stores all the data needed to process a request on the user side. In particular, a `client.Context` stores the following: * **Codec**: The [encoder/decoder](/docs/sdk/v0.47/learn/advanced/encoding) used by the application, used to marshal the parameters and query before making the CometBFT RPC request and unmarshal the returned response into a JSON object. The default codec used by the CLI is Protobuf. -* **Account Decoder**: The account decoder from the [`auth`](/docs/sdk/v0.47/build/modules/auth/README) module, which translates `[]byte`s into accounts. +* **Account Decoder**: The account decoder from the [`auth`](/docs/sdk/v0.47/build/modules/auth/auth) module, which translates `[]byte`s into accounts. * **RPC Client**: The CometBFT RPC Client, or node, to which requests are relayed. * **Keyring**: A [Key Manager](/docs/sdk/v0.47/learn/beginner/accounts#keyring) used to sign transactions and handle other operations with keys. * **Output Writer**: A [Writer](https://pkg.go.dev/io/#Writer) used to output the response. diff --git a/docs/sdk/v0.47/user/run-node/run-production.mdx b/docs/sdk/v0.47/user/run-node/run-production.mdx index 674eb690..812dab1d 100644 --- a/docs/sdk/v0.47/user/run-node/run-production.mdx +++ b/docs/sdk/v0.47/user/run-node/run-production.mdx @@ -47,7 +47,7 @@ In the past, validators [have had issues](https://github.com/cosmos/cosmos-sdk/i ### Firewall -Nodes should not have all ports open to the public, this is a simple way to get DDOS'd. Secondly it is recommended by [CometBFT](/https://github.com/cometbft/cometbft) to never expose ports that are not required to operate a node. +Nodes should not have all ports open to the public, this is a simple way to get DDOS'd. Secondly it is recommended by [CometBFT](https://github.com/cometbft/cometbft) to never expose ports that are not required to operate a node. When setting up a firewall there are a few ports that can be open when operating a Cosmos SDK node. There is the CometBFT json-RPC, prometheus, p2p, remote signer and Cosmos SDK GRPC and REST. If the node is being operated as a node that does not offer endpoints to be used for submission or querying then a max of three endpoints are needed. diff --git a/docs/sdk/v0.50/build/architecture/adr-054-semver-compatible-modules.mdx b/docs/sdk/v0.50/build/architecture/adr-054-semver-compatible-modules.mdx index c998f963..20c72fdb 100644 --- a/docs/sdk/v0.50/build/architecture/adr-054-semver-compatible-modules.mdx +++ b/docs/sdk/v0.50/build/architecture/adr-054-semver-compatible-modules.mdx @@ -476,7 +476,7 @@ languages, possibly executed within a WASM VM. ### Minor API Revisions To declare minor API revisions of proto files, we propose the following guidelines (which were already documented -in [cosmos.app.v1alpha module options](/https://github.com/cosmos/cosmos-sdk/blob/v0.50/proto/cosmos/app/v1alpha1/module.proto)): +in [cosmos.app.v1alpha module options](https://github.com/cosmos/cosmos-sdk/blob/v0.50/proto/cosmos/app/v1alpha1/module.proto)): * proto packages which are revised from their initial version (considered revision `0`) should include a `package` * comment in some .proto file containing the test `Revision N` at the start of a comment line where `N` is the current diff --git a/docs/sdk/v0.50/build/architecture/adr-063-core-module-api.mdx b/docs/sdk/v0.50/build/architecture/adr-063-core-module-api.mdx index 9cb14b2a..ad0743ee 100644 --- a/docs/sdk/v0.50/build/architecture/adr-063-core-module-api.mdx +++ b/docs/sdk/v0.50/build/architecture/adr-063-core-module-api.mdx @@ -423,7 +423,7 @@ Additional `AppModule` extension interfaces either inside or outside of core wil these concerns. In the case of gogo proto and amino interfaces, the registration of these generally should happen as early -as possible during initialization and in [ADR 057: App Wiring](/docs/sdk/v0.50/build/architecture/adr-057-app-wiring-1), protobuf type registration\ +as possible during initialization and in [ADR 057: App Wiring](/docs/sdk/v0.50/build/architecture/adr-057-app-wiring), protobuf type registration\ happens before dependency injection (although this could alternatively be done dedicated DI providers). gRPC gateway registration should probably be handled by the runtime module, but the core API shouldn't depend on gRPC @@ -609,7 +609,7 @@ as by providing service implementations by wrapping `sdk.Context`. ## References * [ADR 033: Protobuf-based Inter-Module Communication](/docs/sdk/v0.50/build/architecture/adr-033-protobuf-inter-module-comm) -* [ADR 057: App Wiring](/docs/sdk/v0.50/build/architecture/adr-057-app-wiring-1) +* [ADR 057: App Wiring](/docs/sdk/v0.50/build/architecture/adr-057-app-wiring) * [ADR 055: ORM](/docs/sdk/v0.50/build/architecture/adr-055-orm) * [ADR 028: Public Key Addresses](/docs/sdk/v0.50/build/architecture/adr-028-public-key-addresses) * [Keeping Your Modules Compatible](https://go.dev/blog/module-compatibility) diff --git a/docs/sdk/v0.50/build/architecture/adr-076-tx-malleability.mdx b/docs/sdk/v0.50/build/architecture/adr-076-tx-malleability.mdx index 2dc288d0..02ab032a 100644 --- a/docs/sdk/v0.50/build/architecture/adr-076-tx-malleability.mdx +++ b/docs/sdk/v0.50/build/architecture/adr-076-tx-malleability.mdx @@ -90,7 +90,7 @@ representation. #### Fields not covered by Amino JSON -Another area that needs to be addressed carefully is the discrepancy between `AminoSignDoc`(see [`aminojson.proto`](/docs/sdk/v0.50/x/tx/signing/aminojson/internal/aminojsonpb/aminojson.proto)) used for `SIGN_MODE_LEGACY_AMINO_JSON` and the actual contents of `TxBody` and `AuthInfo` (see [`tx.proto`](/docs/sdk/v0.50/proto/cosmos/tx/v1beta1/tx.proto)). +Another area that needs to be addressed carefully is the discrepancy between `AminoSignDoc`(see [`aminojson.proto`](https://github.com/cosmos/cosmos-sdk/blob/v0.50/x/tx/signing/aminojson/internal/aminojsonpb/aminojson.proto)) used for `SIGN_MODE_LEGACY_AMINO_JSON` and the actual contents of `TxBody` and `AuthInfo` (see [`tx.proto`](https://github.com/cosmos/cosmos-sdk/blob/v0.50/proto/cosmos/tx/v1beta1/tx.proto)). If fields get added to `TxBody` or `AuthInfo`, they must either have a corresponding representing in `AminoSignDoc` or Amino JSON signatures must be rejected when those new fields are set. Making sure that this is done is a highly manual process, and developers could easily make the mistake of updating `TxBody` or `AuthInfo` without paying any attention to the implementation of `GetSignBytes` for Amino JSON. This is a critical @@ -169,5 +169,5 @@ or get rejected. * [ADR 027: Deterministic Protobuf Serialization](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-027-deterministic-protobuf-serialization.md) * [ADR 020](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-020-protobuf-transaction-encoding.md#unknown-field-filtering) -* [`aminojson.proto`](/docs/sdk/v0.50/x/tx/signing/aminojson/internal/aminojsonpb/aminojson.proto) -* [`tx.proto`](/docs/sdk/v0.50/proto/cosmos/tx/v1beta1/tx.proto) +* [`aminojson.proto`](https://github.com/cosmos/cosmos-sdk/blob/v0.50/x/tx/signing/aminojson/internal/aminojsonpb/aminojson.proto) +* [`tx.proto`](https://github.com/cosmos/cosmos-sdk/blob/v0.50/proto/cosmos/tx/v1beta1/tx.proto) diff --git a/docs/sdk/v0.50/build/packages.mdx b/docs/sdk/v0.50/build/packages.mdx index 6c8142b4..327ee1a6 100644 --- a/docs/sdk/v0.50/build/packages.mdx +++ b/docs/sdk/v0.50/build/packages.mdx @@ -18,7 +18,7 @@ The Cosmos SDK is a collection of Go modules. This section provides documentatio ## State Management[​](#state-management "Direct link to State Management") * [Collections](/docs/sdk/v0.50/build/packages/collections) - State management library -* [ORM](/docs/sdk/v0.50/build/03-orm.md) - State management library +* [ORM](docs/sdk/v0.50/build/packages/README#orm) - State management library ## Automation[​](#automation "Direct link to Automation") diff --git a/docs/sdk/v0.50/learn/advanced/cli.mdx b/docs/sdk/v0.50/learn/advanced/cli.mdx index 33a2e965..511b9f4e 100644 --- a/docs/sdk/v0.50/learn/advanced/cli.mdx +++ b/docs/sdk/v0.50/learn/advanced/cli.mdx @@ -1594,7 +1594,7 @@ return simApp.ExportAppStateAndValidators(forZeroHeight, jailAllowedAddrs, modul This `txCommand` function adds all the transaction available to end-users for the application. This typically includes: -* **Sign command** from the [`auth`](/docs/sdk/v0.50/build/modules/auth/README) module that signs messages in a transaction. To enable multisig, add the `auth` module's `MultiSign` command. Since every transaction requires some sort of signature in order to be valid, the signing command is necessary for every application. +* **Sign command** from the [`auth`](/docs/sdk/v0.50/build/modules/auth/auth) module that signs messages in a transaction. To enable multisig, add the `auth` module's `MultiSign` command. Since every transaction requires some sort of signature in order to be valid, the signing command is necessary for every application. * **Broadcast command** from the Cosmos SDK client tools, to broadcast transactions. * **All [module transaction commands](/docs/sdk/v0.50/build/building-modules/module-interfaces#transaction-commands)** the application is dependent on, retrieved by using the [basic module manager's](/docs/sdk/v0.50/build/building-modules/module-manager#basic-manager) `AddTxCommands()` function, or enhanced by [AutoCLI](https://docs.cosmos.network/main/core/autocli). diff --git a/docs/sdk/v0.50/learn/beginner/query-lifecycle.mdx b/docs/sdk/v0.50/learn/beginner/query-lifecycle.mdx index 3d751034..f5980e25 100644 --- a/docs/sdk/v0.50/learn/beginner/query-lifecycle.mdx +++ b/docs/sdk/v0.50/learn/beginner/query-lifecycle.mdx @@ -74,7 +74,7 @@ The preceding examples show how an external user can interact with a node by que The first thing that is created in the execution of a CLI command is a `client.Context`. A `client.Context` is an object that stores all the data needed to process a request on the user side. In particular, a `client.Context` stores the following: * **Codec**: The [encoder/decoder](/docs/sdk/v0.50/learn/advanced/encoding) used by the application, used to marshal the parameters and query before making the CometBFT RPC request and unmarshal the returned response into a JSON object. The default codec used by the CLI is Protobuf. -* **Account Decoder**: The account decoder from the [`auth`](/docs/sdk/v0.50/build/modules/auth/README) module, which translates `[]byte`s into accounts. +* **Account Decoder**: The account decoder from the [`auth`](/docs/sdk/v0.50/build/modules/auth/auth) module, which translates `[]byte`s into accounts. * **RPC Client**: The CometBFT RPC Client, or node, to which requests are relayed. * **Keyring**: A \[Key Manager]../beginner/03-accounts.md#keyring) used to sign transactions and handle other operations with keys. * **Output Writer**: A [Writer](https://pkg.go.dev/io/#Writer) used to output the response. diff --git a/docs/sdk/v0.50/user/run-node/run-production.mdx b/docs/sdk/v0.50/user/run-node/run-production.mdx index 227d2275..02e66b69 100644 --- a/docs/sdk/v0.50/user/run-node/run-production.mdx +++ b/docs/sdk/v0.50/user/run-node/run-production.mdx @@ -47,7 +47,7 @@ In the past, validators [have had issues](https://github.com/cosmos/cosmos-sdk/i ### Firewall -Nodes should not have all ports open to the public, this is a simple way to get DDOS'd. Secondly it is recommended by [CometBFT](/https://github.com/cometbft/cometbft) to never expose ports that are not required to operate a node. +Nodes should not have all ports open to the public, this is a simple way to get DDOS'd. Secondly it is recommended by [CometBFT](https://github.com/cometbft/cometbft) to never expose ports that are not required to operate a node. When setting up a firewall there are a few ports that can be open when operating a Cosmos SDK node. There is the CometBFT json-RPC, prometheus, p2p, remote signer and Cosmos SDK GRPC and REST. If the node is being operated as a node that does not offer endpoints to be used for submission or querying then a max of three endpoints are needed. diff --git a/docs/sdk/v0.53/build/architecture/adr-054-semver-compatible-modules.mdx b/docs/sdk/v0.53/build/architecture/adr-054-semver-compatible-modules.mdx index c998f963..20c72fdb 100644 --- a/docs/sdk/v0.53/build/architecture/adr-054-semver-compatible-modules.mdx +++ b/docs/sdk/v0.53/build/architecture/adr-054-semver-compatible-modules.mdx @@ -476,7 +476,7 @@ languages, possibly executed within a WASM VM. ### Minor API Revisions To declare minor API revisions of proto files, we propose the following guidelines (which were already documented -in [cosmos.app.v1alpha module options](/https://github.com/cosmos/cosmos-sdk/blob/v0.50/proto/cosmos/app/v1alpha1/module.proto)): +in [cosmos.app.v1alpha module options](https://github.com/cosmos/cosmos-sdk/blob/v0.50/proto/cosmos/app/v1alpha1/module.proto)): * proto packages which are revised from their initial version (considered revision `0`) should include a `package` * comment in some .proto file containing the test `Revision N` at the start of a comment line where `N` is the current diff --git a/docs/sdk/v0.53/build/architecture/adr-063-core-module-api.mdx b/docs/sdk/v0.53/build/architecture/adr-063-core-module-api.mdx index 9b042485..60cb29fd 100644 --- a/docs/sdk/v0.53/build/architecture/adr-063-core-module-api.mdx +++ b/docs/sdk/v0.53/build/architecture/adr-063-core-module-api.mdx @@ -423,7 +423,7 @@ Additional `AppModule` extension interfaces either inside or outside of core wil these concerns. In the case of gogo proto and amino interfaces, the registration of these generally should happen as early -as possible during initialization and in [ADR 057: App Wiring](/docs/sdk/v0.53/build/architecture/adr-057-app-wiring-1), protobuf type registration\ +as possible during initialization and in [ADR 057: App Wiring](/docs/sdk/v0.53/build/architecture/adr-057-app-wiring), protobuf type registration\ happens before dependency injection (although this could alternatively be done dedicated DI providers). gRPC gateway registration should probably be handled by the runtime module, but the core API shouldn't depend on gRPC @@ -609,7 +609,7 @@ as by providing service implementations by wrapping `sdk.Context`. ## References * [ADR 033: Protobuf-based Inter-Module Communication](/docs/sdk/v0.53/build/architecture/adr-033-protobuf-inter-module-comm) -* [ADR 057: App Wiring](/docs/sdk/v0.53/build/architecture/adr-057-app-wiring-1) +* [ADR 057: App Wiring](/docs/sdk/v0.53/build/architecture/adr-057-app-wiring) * [ADR 055: ORM](/docs/sdk/v0.53/build/architecture/adr-055-orm) * [ADR 028: Public Key Addresses](/docs/sdk/v0.53/build/architecture/adr-028-public-key-addresses) * [Keeping Your Modules Compatible](https://go.dev/blog/module-compatibility) diff --git a/docs/sdk/v0.53/build/architecture/adr-076-tx-malleability.mdx b/docs/sdk/v0.53/build/architecture/adr-076-tx-malleability.mdx index 2dc288d0..02ab032a 100644 --- a/docs/sdk/v0.53/build/architecture/adr-076-tx-malleability.mdx +++ b/docs/sdk/v0.53/build/architecture/adr-076-tx-malleability.mdx @@ -90,7 +90,7 @@ representation. #### Fields not covered by Amino JSON -Another area that needs to be addressed carefully is the discrepancy between `AminoSignDoc`(see [`aminojson.proto`](/docs/sdk/v0.50/x/tx/signing/aminojson/internal/aminojsonpb/aminojson.proto)) used for `SIGN_MODE_LEGACY_AMINO_JSON` and the actual contents of `TxBody` and `AuthInfo` (see [`tx.proto`](/docs/sdk/v0.50/proto/cosmos/tx/v1beta1/tx.proto)). +Another area that needs to be addressed carefully is the discrepancy between `AminoSignDoc`(see [`aminojson.proto`](https://github.com/cosmos/cosmos-sdk/blob/v0.50/x/tx/signing/aminojson/internal/aminojsonpb/aminojson.proto)) used for `SIGN_MODE_LEGACY_AMINO_JSON` and the actual contents of `TxBody` and `AuthInfo` (see [`tx.proto`](https://github.com/cosmos/cosmos-sdk/blob/v0.50/proto/cosmos/tx/v1beta1/tx.proto)). If fields get added to `TxBody` or `AuthInfo`, they must either have a corresponding representing in `AminoSignDoc` or Amino JSON signatures must be rejected when those new fields are set. Making sure that this is done is a highly manual process, and developers could easily make the mistake of updating `TxBody` or `AuthInfo` without paying any attention to the implementation of `GetSignBytes` for Amino JSON. This is a critical @@ -169,5 +169,5 @@ or get rejected. * [ADR 027: Deterministic Protobuf Serialization](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-027-deterministic-protobuf-serialization.md) * [ADR 020](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-020-protobuf-transaction-encoding.md#unknown-field-filtering) -* [`aminojson.proto`](/docs/sdk/v0.50/x/tx/signing/aminojson/internal/aminojsonpb/aminojson.proto) -* [`tx.proto`](/docs/sdk/v0.50/proto/cosmos/tx/v1beta1/tx.proto) +* [`aminojson.proto`](https://github.com/cosmos/cosmos-sdk/blob/v0.50/x/tx/signing/aminojson/internal/aminojsonpb/aminojson.proto) +* [`tx.proto`](https://github.com/cosmos/cosmos-sdk/blob/v0.50/proto/cosmos/tx/v1beta1/tx.proto) diff --git a/docs/sdk/v0.53/build/migrations/intro.mdx b/docs/sdk/v0.53/build/migrations/intro.mdx index 501af8cd..842f15df 100644 --- a/docs/sdk/v0.53/build/migrations/intro.mdx +++ b/docs/sdk/v0.53/build/migrations/intro.mdx @@ -10,4 +10,4 @@ Additionally, the SDK includes in-place migrations for its core modules. These i Migration from a version older than the last two major releases is not supported. -When migrating from a previous version, refer to the [`UPGRADING.md`](/docs/sdk/v0.53/build/migrations/upgrading) and the `CHANGELOG.md` of the version you are migrating to. +When migrating from a previous version, refer to the [`UPGRADING.md`](docs/sdk/v0.53/build/migrations/upgrading) and the `CHANGELOG.md` of the version you are migrating to. diff --git a/docs/sdk/v0.53/build/modules/auth/auth.mdx b/docs/sdk/v0.53/build/modules/auth/auth.mdx index 3bfa3225..70742acf 100644 --- a/docs/sdk/v0.53/build/modules/auth/auth.mdx +++ b/docs/sdk/v0.53/build/modules/auth/auth.mdx @@ -31,7 +31,7 @@ This module is used in the Cosmos Hub. ## Concepts -**Note:** The auth module is different from the [authz module](/docs/sdk/v0.50/modules/authz/). +**Note:** The auth module is different from the [authz module](/docs/sdk/v0.53/build/modules/authz/README). The differences are: diff --git a/docs/sdk/v0.53/learn/advanced/cli.mdx b/docs/sdk/v0.53/learn/advanced/cli.mdx index 082e7526..70dd42c3 100644 --- a/docs/sdk/v0.53/learn/advanced/cli.mdx +++ b/docs/sdk/v0.53/learn/advanced/cli.mdx @@ -121,7 +121,7 @@ The root-level `status` and `keys` subcommands are common across most applicatio This `txCommand` function adds all the transaction available to end-users for the application. This typically includes: -* **Sign command** from the [`auth`](/docs/sdk/v0.53/build/modules/auth/README) module that signs messages in a transaction. To enable multisig, add the `auth` module's `MultiSign` command. Since every transaction requires some sort of signature in order to be valid, the signing command is necessary for every application. +* **Sign command** from the [`auth`](/docs/sdk/v0.53/build/modules/auth/auth) module that signs messages in a transaction. To enable multisig, add the `auth` module's `MultiSign` command. Since every transaction requires some sort of signature in order to be valid, the signing command is necessary for every application. * **Broadcast command** from the Cosmos SDK client tools, to broadcast transactions. * **All [module transaction commands](/docs/sdk/v0.53/build/building-modules/module-interfaces#transaction-commands)** the application is dependent on, retrieved by using the [basic module manager's](/docs/sdk/v0.53/build/building-modules/module-manager#basic-manager) `AddTxCommands()` function, or enhanced by [AutoCLI](https://docs.cosmos.network/main/core/autocli). diff --git a/docs/sdk/v0.53/learn/beginner/query-lifecycle.mdx b/docs/sdk/v0.53/learn/beginner/query-lifecycle.mdx index 85403e60..2f1424a4 100644 --- a/docs/sdk/v0.53/learn/beginner/query-lifecycle.mdx +++ b/docs/sdk/v0.53/learn/beginner/query-lifecycle.mdx @@ -74,7 +74,7 @@ The preceding examples show how an external user can interact with a node by que The first thing that is created in the execution of a CLI command is a `client.Context`. A `client.Context` is an object that stores all the data needed to process a request on the user side. In particular, a `client.Context` stores the following: * **Codec**: The [encoder/decoder](/docs/sdk/v0.53/learn/advanced/encoding) used by the application, used to marshal the parameters and query before making the CometBFT RPC request and unmarshal the returned response into a JSON object. The default codec used by the CLI is Protobuf. -* **Account Decoder**: The account decoder from the [`auth`](/docs/sdk/v0.53/build/modules/auth/README) module, which translates `[]byte`s into accounts. +* **Account Decoder**: The account decoder from the [`auth`](/docs/sdk/v0.53/build/modules/auth/auth) module, which translates `[]byte`s into accounts. * **RPC Client**: The CometBFT RPC Client, or node, to which requests are relayed. * **Keyring**: A \[Key Manager]../beginner/03-accounts.md#keyring) used to sign transactions and handle other operations with keys. * **Output Writer**: A [Writer](https://pkg.go.dev/io/#Writer) used to output the response. diff --git a/docs/sdk/v0.53/tutorials/vote-extensions/oracle/getting-started.mdx b/docs/sdk/v0.53/tutorials/vote-extensions/oracle/getting-started.mdx index 0e949287..c446af4c 100644 --- a/docs/sdk/v0.53/tutorials/vote-extensions/oracle/getting-started.mdx +++ b/docs/sdk/v0.53/tutorials/vote-extensions/oracle/getting-started.mdx @@ -15,7 +15,7 @@ Before you start with this tutorial, make sure you have: * A working chain project. This tutorial won't cover the steps of creating a new chain/module. * Familiarity with the Cosmos SDK. If you're not, we suggest you start with [Cosmos SDK Tutorials](https://tutorials.cosmos.network), as ABCI++ is considered an advanced topic. -* Read and understood [What is an Oracle?](what-is-an-oracle). This provides necessary background information for understanding the Oracle module. +* Read and understood [What is an Oracle?](#what-is-an-oracle). This provides necessary background information for understanding the Oracle module. * Basic understanding of Go programming language. ## What are Vote extensions? From e02f45a81097aabda2b0f0edb74b130c7c8b6658 Mon Sep 17 00:00:00 2001 From: Cordt Date: Fri, 24 Oct 2025 08:46:53 -0600 Subject: [PATCH 08/10] almost done with links --- .../getting-started/build-a-chain/quick-start.mdx | 2 +- .../getting-started/build-a-chain/using-local-node.mdx | 2 +- docs/sdk/next/changelog/release-notes.mdx | 2 +- docs/sdk/v0.50/learn/advanced/encoding.mdx | 8 ++++---- docs/sdk/v0.53/build/migrations/intro.mdx | 2 +- docs/sdk/v0.53/learn/advanced/cli.mdx | 4 ++-- docs/sdk/v0.53/learn/advanced/context.mdx | 6 +++--- docs/sdk/v0.53/learn/advanced/events.mdx | 8 ++++---- docs/sdk/v0.53/learn/advanced/node.mdx | 2 +- docs/sdk/v0.53/learn/advanced/store.mdx | 2 +- docs/sdk/v0.53/learn/advanced/transactions.mdx | 2 +- docs/sdk/v0.53/learn/beginner/app-anatomy.mdx | 6 +++--- docs/sdk/v0.53/learn/beginner/query-lifecycle.mdx | 4 ++-- docs/sdk/v0.53/learn/beginner/tx-lifecycle.mdx | 8 ++++---- 14 files changed, 29 insertions(+), 29 deletions(-) diff --git a/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start.mdx b/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start.mdx index c036845c..a093a098 100644 --- a/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start.mdx +++ b/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start.mdx @@ -277,7 +277,7 @@ Deploy standard contracts at genesis for Create2, Multicall3, Permit2, and Safe ### Recommended Reading - + EVM execution and parameter configuration diff --git a/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/using-local-node.mdx b/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/using-local-node.mdx index b0ee7ca3..7dd65a63 100644 --- a/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/using-local-node.mdx +++ b/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/using-local-node.mdx @@ -256,7 +256,7 @@ Deploy standard contracts at genesis for Create2, Multicall3, Permit2, and Safe ### Recommended Reading - + EVM execution and parameter configuration diff --git a/docs/sdk/next/changelog/release-notes.mdx b/docs/sdk/next/changelog/release-notes.mdx index 410f23d8..5d8588d7 100644 --- a/docs/sdk/next/changelog/release-notes.mdx +++ b/docs/sdk/next/changelog/release-notes.mdx @@ -325,7 +325,7 @@ mode: "wide" - (core) [#14860](https://github.com/cosmos/cosmos-sdk/pull/14860) Add `Precommit` and `PrepareCheckState` AppModule callbacks. - (x/gov) [#14720](https://github.com/cosmos/cosmos-sdk/pull/14720) Upstream expedited proposals from Osmosis. - (cli) [#14659](https://github.com/cosmos/cosmos-sdk/pull/14659) Added ability to query blocks by events with queries directly passed to Tendermint, which will allow for full query operator support, e.g. `>`. -- (x/auth) [#14650](https://github.com/cosmos/cosmos-sdk/pull/14650) Add Textual SignModeHandler. Enable `SIGN_MODE_TEXTUAL` by following the [UPGRADING.md](./UPGRADING.md) instructions. +- (x/auth) [#14650](https://github.com/cosmos/cosmos-sdk/pull/14650) Add Textual SignModeHandler. Enable `SIGN_MODE_TEXTUAL` by following the [UPGRADING.md](https://github.com/cosmos/cosmos-sdk/blob/main/UPGRADING.md) instructions. - (x/crisis) [#14588](https://github.com/cosmos/cosmos-sdk/pull/14588) Use CacheContext() in AssertInvariants(). - (mempool) [#14484](https://github.com/cosmos/cosmos-sdk/pull/14484) Add priority nonce mempool option for transaction replacement. - (query) [#14468](https://github.com/cosmos/cosmos-sdk/pull/14468) Implement pagination for collections. diff --git a/docs/sdk/v0.50/learn/advanced/encoding.mdx b/docs/sdk/v0.50/learn/advanced/encoding.mdx index f5966e92..08fad7a9 100644 --- a/docs/sdk/v0.50/learn/advanced/encoding.mdx +++ b/docs/sdk/v0.50/learn/advanced/encoding.mdx @@ -473,7 +473,7 @@ return nil, fmt.Errorf("expected %T, got %T", &wrapper{ } ``` -See [ADR-020](/docs/sdk/v0.50/architecture/adr-020-protobuf-transaction-encoding) for details of how a transaction is encoded. +See [ADR-020](/docs/sdk/v0.50/build/architecture/adr-020-protobuf-transaction-encoding) for details of how a transaction is encoded. ### Interface Encoding and Usage of `Any` @@ -558,7 +558,7 @@ bool } ``` -In [ADR-019](/docs/sdk/v0.50/architecture/adr-019-protobuf-state-encoding), 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: +In [ADR-019](/docs/sdk/v0.50/build/architecture/adr-019-protobuf-state-encoding), 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: ```protobuf message Profile { @@ -632,7 +632,7 @@ return nil The `UnpackInterfaces` gets called recursively on all structs implementing this method, to allow all `Any`s to have their `GetCachedValue()` correctly populated. -For more information about interface encoding, and especially on `UnpackInterfaces` and how the `Any`'s `type_url` gets resolved using the `InterfaceRegistry`, please refer to [ADR-019](/docs/sdk/v0.50/architecture/adr-019-protobuf-state-encoding). +For more information about interface encoding, and especially on `UnpackInterfaces` and how the `Any`'s `type_url` gets resolved using the `InterfaceRegistry`, please refer to [ADR-019](/docs/sdk/v0.50/build/architecture/adr-019-protobuf-state-encoding). #### `Any` Encoding in the Cosmos SDK @@ -1406,7 +1406,7 @@ Protobuf types can be defined to encode: #### Naming and conventions We encourage developers to follow industry guidelines: [Protocol Buffers style guide](https://developers.google.com/protocol-buffers/docs/style) -and [Buf](https://buf.build/docs/style-guide), see more details in [ADR 023](/docs/sdk/v0.50/architecture/adr-023-protobuf-naming) +and [Buf](https://buf.build/docs/style-guide), see more details in [ADR 023](/docs/sdk/v0.50/build/architecture/adr-023-protobuf-naming) ### How to update modules to protobuf encoding diff --git a/docs/sdk/v0.53/build/migrations/intro.mdx b/docs/sdk/v0.53/build/migrations/intro.mdx index 842f15df..501af8cd 100644 --- a/docs/sdk/v0.53/build/migrations/intro.mdx +++ b/docs/sdk/v0.53/build/migrations/intro.mdx @@ -10,4 +10,4 @@ Additionally, the SDK includes in-place migrations for its core modules. These i Migration from a version older than the last two major releases is not supported. -When migrating from a previous version, refer to the [`UPGRADING.md`](docs/sdk/v0.53/build/migrations/upgrading) and the `CHANGELOG.md` of the version you are migrating to. +When migrating from a previous version, refer to the [`UPGRADING.md`](/docs/sdk/v0.53/build/migrations/upgrading) and the `CHANGELOG.md` of the version you are migrating to. diff --git a/docs/sdk/v0.53/learn/advanced/cli.mdx b/docs/sdk/v0.53/learn/advanced/cli.mdx index 70dd42c3..36ec0b4e 100644 --- a/docs/sdk/v0.53/learn/advanced/cli.mdx +++ b/docs/sdk/v0.53/learn/advanced/cli.mdx @@ -28,7 +28,7 @@ The first four strings specify the command: The next two strings are arguments: the `from_address` the user wishes to send from, the `to_address` of the recipient, and the `amount` they want to send. Finally, the last few strings of the command are optional flags to indicate how much the user is willing to pay in fees (calculated using the amount of gas used to execute the transaction and the gas prices provided by the user). -The CLI interacts with a [node](/docs/sdk/v0.53/node) to handle this command. The interface itself is defined in a `main.go` file. +The CLI interacts with a [node](/docs/sdk/v0.53/learn/advanced/node) to handle this command. The interface itself is defined in a `main.go` file. ### Building the CLI @@ -76,7 +76,7 @@ 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`](/docs/sdk/v0.53/node). The Status of a node includes `NodeInfo`,`SyncInfo` and `ValidatorInfo`. +* **Status** command from the Cosmos SDK rpc client tools, which prints information about the status of the connected [`Node`](/docs/sdk/v0.53/learn/advanced/node). The Status of a node includes `NodeInfo`,`SyncInfo` and `ValidatorInfo`. * **Keys** [commands](https://github.com/cosmos/cosmos-sdk/blob/v0.53.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 ` 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.53.0/client/keys/add.go). For more details about usage of `--keyring-backend` for storage of key credentials look at the [keyring docs](/docs/sdk/v0.53/user/run-node/keyring). * **Server** commands from the Cosmos SDK server package. These commands are responsible for providing the mechanisms necessary to start an ABCI CometBFT application and provides the CLI framework (based on [cobra](https://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. Learn more [here](https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/server). diff --git a/docs/sdk/v0.53/learn/advanced/context.mdx b/docs/sdk/v0.53/learn/advanced/context.mdx index 2b27ba73..eba04422 100644 --- a/docs/sdk/v0.53/learn/advanced/context.mdx +++ b/docs/sdk/v0.53/learn/advanced/context.mdx @@ -795,7 +795,7 @@ goes wrong. The pattern of usage for a Context is as follows: needs to be done - the branch `ctx` is simply discarded. If successful, the changes made to the `CacheMultiStore` can be committed to the original `ctx.ms` via `Write()`. -For example, here is a snippet from the [`runTx`](/docs/sdk/v0.53/baseapp#runtx-antehandler-runmsgs-posthandler) function in [`baseapp`](/docs/sdk/v0.53/baseapp): +For example, here is a snippet from the [`runTx`](/docs/sdk/v0.53/learn/advanced/baseapp#runtx-antehandler-runmsgs-posthandler) function in [`baseapp`](/docs/sdk/v0.53/learn/advanced/baseapp): ```go runMsgCtx, msCache := app.cacheTxContext(ctx, txBytes) @@ -816,7 +816,7 @@ Here is the process: 1. Prior to calling `runMsgs` on the message(s) in the transaction, it uses `app.cacheTxContext()` to branch and cache the context and multistore. 2. `runMsgCtx` - the context with branched store, is used in `runMsgs` to return a result. -3. If the process is running in [`checkTxMode`](/docs/sdk/v0.53/baseapp#checktx), there is no need to write the +3. If the process is running in [`checkTxMode`](/docs/sdk/v0.53/learn/advanced/baseapp#checktx), there is no need to write the changes - the result is returned immediately. -4. If the process is running in [`deliverTxMode`](/docs/sdk/v0.53/baseapp#delivertx) and the result indicates +4. If the process is running in [`deliverTxMode`](/docs/sdk/v0.53/learn/advanced/baseapp#delivertx) and the result indicates a successful run over all the messages, the branched multistore is written back to the original. diff --git a/docs/sdk/v0.53/learn/advanced/events.mdx b/docs/sdk/v0.53/learn/advanced/events.mdx index 9bb5ed0b..a7e1f56e 100644 --- a/docs/sdk/v0.53/learn/advanced/events.mdx +++ b/docs/sdk/v0.53/learn/advanced/events.mdx @@ -44,10 +44,10 @@ In addition, each module documents its events under in the `Events` sections of Lastly, Events are returned to the underlying consensus engine in the response of the following ABCI messages: -* [`BeginBlock`](/docs/sdk/v0.53/baseapp#beginblock) -* [`EndBlock`](/docs/sdk/v0.53/baseapp#endblock) -* [`CheckTx`](/docs/sdk/v0.53/baseapp#checktx) -* [`Transaction Execution`](/docs/sdk/v0.53/baseapp#transactionexecution) +* [`BeginBlock`](/docs/sdk/v0.53/learn/advanced/baseapp#beginblock) +* [`EndBlock`](/docs/sdk/v0.53/learn/advanced/baseapp#endblock) +* [`CheckTx`](/docs/sdk/v0.53/learn/advanced/baseapp#checktx) +* [`Transaction Execution`](/docs/sdk/v0.53/learn/advanced/baseapp#transactionexecution) ### Examples diff --git a/docs/sdk/v0.53/learn/advanced/node.mdx b/docs/sdk/v0.53/learn/advanced/node.mdx index 404817e4..3056820f 100644 --- a/docs/sdk/v0.53/learn/advanced/node.mdx +++ b/docs/sdk/v0.53/learn/advanced/node.mdx @@ -3033,7 +3033,7 @@ return pflag.NormalizedName(name) } ``` -The CometBFT node can be created with `app` because the latter satisfies the [`abci.Application` interface](https://github.com/cometbft/cometbft/blob/v0.37.0/abci/types/application.go#L9-L35) (given that `app` extends [`baseapp`](/docs/sdk/v0.53/baseapp)). As part of the `node.New` method, CometBFT makes sure that the height of the application (i.e. number of blocks since genesis) is equal to the height of the CometBFT 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 CometBFT node. Finally, if the height of the application is `0`, the CometBFT node will call [`InitChain`](/docs/sdk/v0.53/baseapp#initchain) on the application to initialize the state from the genesis file. +The CometBFT node can be created with `app` because the latter satisfies the [`abci.Application` interface](https://github.com/cometbft/cometbft/blob/v0.37.0/abci/types/application.go#L9-L35) (given that `app` extends [`baseapp`](/docs/sdk/v0.53/learn/advanced/baseapp)). As part of the `node.New` method, CometBFT makes sure that the height of the application (i.e. number of blocks since genesis) is equal to the height of the CometBFT 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 CometBFT node. Finally, if the height of the application is `0`, the CometBFT node will call [`InitChain`](/docs/sdk/v0.53/learn/advanced/baseapp#initchain) on the application to initialize the state from the genesis file. Once the CometBFT node is instantiated and in sync with the application, the node can be started: diff --git a/docs/sdk/v0.53/learn/advanced/store.mdx b/docs/sdk/v0.53/learn/advanced/store.mdx index 3383c831..15838325 100644 --- a/docs/sdk/v0.53/learn/advanced/store.mdx +++ b/docs/sdk/v0.53/learn/advanced/store.mdx @@ -5684,7 +5684,7 @@ err = batch.Set([]byte(latestVersionKey), bz) } ``` -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`](/docs/sdk/v0.53/baseapp). +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`](/docs/sdk/v0.53/learn/advanced/baseapp). ### CacheMultiStore diff --git a/docs/sdk/v0.53/learn/advanced/transactions.mdx b/docs/sdk/v0.53/learn/advanced/transactions.mdx index 2f689c30..1591b7ae 100644 --- a/docs/sdk/v0.53/learn/advanced/transactions.mdx +++ b/docs/sdk/v0.53/learn/advanced/transactions.mdx @@ -984,7 +984,7 @@ Once the transaction bytes are generated, there are currently three ways of broa #### CLI -Application developers create entry points to the application by creating a [command-line interface](/docs/sdk/v0.53/cli), [gRPC and/or REST interface](/docs/sdk/v0.53/grpc_rest), typically found in the application's `./cmd` folder. These interfaces allow users to interact with the application through command-line. +Application developers create entry points to the application by creating a [command-line interface](/docs/sdk/v0.53/learn/advanced/cli), [gRPC and/or REST interface](/docs/sdk/v0.53/learn/advanced/grpc_rest), typically found in the application's `./cmd` folder. These interfaces allow users to interact with the application through command-line. For the [command-line interface](/docs/sdk/v0.53/build/building-modules/module-interfaces#cli), module developers create subcommands to add as children to the application top-level transaction command `TxCmd`. CLI commands actually bundle all the steps of transaction processing into one simple command: creating messages, generating transactions and broadcasting. For concrete examples, see the [Interacting with a Node](/docs/sdk/v0.53/user/run-node/interact-node) section. An example transaction made using CLI looks like: diff --git a/docs/sdk/v0.53/learn/beginner/app-anatomy.mdx b/docs/sdk/v0.53/learn/beginner/app-anatomy.mdx index 693132a0..4f1b0c4b 100644 --- a/docs/sdk/v0.53/learn/beginner/app-anatomy.mdx +++ b/docs/sdk/v0.53/learn/beginner/app-anatomy.mdx @@ -2693,7 +2693,7 @@ The Cosmos SDK offers developers the possibility to implement automatic executio In general, the `BeginBlocker` and `EndBlocker` functions are mostly composed of the [`BeginBlock` and `EndBlock`](/docs/sdk/v0.53/build/building-modules/beginblock-endblock) functions of each of the application's modules. This is done by calling the `BeginBlock` and `EndBlock` functions of the module manager, which in turn calls the `BeginBlock` and `EndBlock` functions of each of the modules it contains. Note that the order in which the modules' `BeginBlock` and `EndBlock` functions must be called has to be set in the module manager using the `SetOrderBeginBlockers` and `SetOrderEndBlockers` methods, respectively. This is done via the [module manager](/docs/sdk/v0.53/build/building-modules/module-manager) in the [application's constructor](#application-constructor), and the `SetOrderBeginBlockers` and `SetOrderEndBlockers` methods have to be called before the `SetBeginBlocker` and `SetEndBlocker` functions. -As a sidenote, it is important to remember that application-specific blockchains are deterministic. Developers must be careful not to introduce non-determinism in `BeginBlocker` or `EndBlocker`, and must also be careful not to make them too computationally expensive, as [gas](/docs/sdk/v0.53/gas-fees) does not constrain the cost of `BeginBlocker` and `EndBlocker` execution. +As a sidenote, it is important to remember that application-specific blockchains are deterministic. Developers must be careful not to introduce non-determinism in `BeginBlocker` or `EndBlocker`, and must also be careful not to make them too computationally expensive, as [gas](/docs/sdk/v0.53/learn/beginner/gas-fees) does not constrain the cost of `BeginBlocker` and `EndBlocker` execution. See an example of `BeginBlocker` and `EndBlocker` functions from `simapp` @@ -3785,11 +3785,11 @@ Note that `sdk.Msg`s are bundled in [transactions](/docs/sdk/v0.53/learn/advance When a valid block of transactions is received by the full-node, CometBFT relays each one to the application via [`DeliverTx`](https://docs.cometbft.com/v0.37/spec/abci/abci++_app_requirements#specifics-of-responsedelivertx). Then, the application handles the transaction: 1. Upon receiving the transaction, the application first unmarshalls it from `[]byte`. -2. Then, it verifies a few things about the transaction like [fee payment and signatures](/docs/sdk/v0.53/gas-fees#antehandler) before extracting the `Msg`(s) contained in the transaction. +2. Then, it verifies a few things about the transaction like [fee payment and signatures](/docs/sdk/v0.53/learn/beginner/gas-fees#antehandler) before extracting the `Msg`(s) contained in the transaction. 3. `sdk.Msg`s are encoded using Protobuf [`Any`s](#register-codec). By analyzing each `Any`'s `type_url`, baseapp's `msgServiceRouter` routes the `sdk.Msg` to the corresponding module's `Msg` service. 4. If the message is successfully processed, the state is updated. -For more details, see [transaction lifecycle](/docs/sdk/v0.53/tx-lifecycle). +For more details, see [transaction lifecycle](/docs/sdk/v0.53/learn/beginner/tx-lifecycle). 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: diff --git a/docs/sdk/v0.53/learn/beginner/query-lifecycle.mdx b/docs/sdk/v0.53/learn/beginner/query-lifecycle.mdx index 2f1424a4..ee48faa8 100644 --- a/docs/sdk/v0.53/learn/beginner/query-lifecycle.mdx +++ b/docs/sdk/v0.53/learn/beginner/query-lifecycle.mdx @@ -15,7 +15,7 @@ This document describes the lifecycle of a query in a Cosmos SDK application, fr ## Query Creation -A [**query**](/docs/sdk/v0.53/build/building-modules/messages-and-queries#queries) is a request for information made by end-users of applications through an interface and processed by a full-node. Users can query information about the network, the application itself, and application state directly from the application's stores or modules. Note that queries are different from [transactions](/docs/sdk/v0.53/learn/advanced/transactions) (view the lifecycle [here](/docs/sdk/v0.53/tx-lifecycle)), particularly in that they do not require consensus to be processed (as they do not trigger state-transitions); they can be fully handled by one full-node. +A [**query**](/docs/sdk/v0.53/build/building-modules/messages-and-queries#queries) is a request for information made by end-users of applications through an interface and processed by a full-node. Users can query information about the network, the application itself, and application state directly from the application's stores or modules. Note that queries are different from [transactions](/docs/sdk/v0.53/learn/advanced/transactions) (view the lifecycle [here](/docs/sdk/v0.53/learn/beginner/tx-lifecycle)), particularly in that they do not require consensus to be processed (as they do not trigger state-transitions); they can be fully handled by one full-node. For the purpose of explaining the query lifecycle, let's say the query, `MyQuery`, is requesting a list of delegations made by a certain delegator address in the application called `simapp`. As is to be expected, the [`staking`](/docs/sdk/v0.53/build/modules/staking/README) module handles this query. But first, there are a few ways `MyQuery` can be created by users. @@ -713,7 +713,7 @@ At this point in the lifecycle, the user has created a CLI command with all of t #### Encoding -In our case (querying an address's delegations), `MyQuery` contains an [address](/docs/sdk/v0.53/accounts#addresses) `delegatorAddress` as its only argument. However, the request can only contain `[]byte`s, as it is ultimately relayed to a consensus engine (e.g. CometBFT) of a full-node that has no inherent knowledge of the application types. Thus, the `codec` of `client.Context` is used to marshal the address. +In our case (querying an address's delegations), `MyQuery` contains an [address](/docs/sdk/v0.53/learn/beginner/accounts#addresses) `delegatorAddress` as its only argument. However, the request can only contain `[]byte`s, as it is ultimately relayed to a consensus engine (e.g. CometBFT) of a full-node that has no inherent knowledge of the application types. Thus, the `codec` of `client.Context` is used to marshal the address. Here is what the code looks like for the CLI command: diff --git a/docs/sdk/v0.53/learn/beginner/tx-lifecycle.mdx b/docs/sdk/v0.53/learn/beginner/tx-lifecycle.mdx index a1d7e15c..b5c2bcff 100644 --- a/docs/sdk/v0.53/learn/beginner/tx-lifecycle.mdx +++ b/docs/sdk/v0.53/learn/beginner/tx-lifecycle.mdx @@ -25,13 +25,13 @@ One of the main application interfaces is the command-line interface. The transa This command automatically **creates** the transaction, **signs** it using the account's private key, and **broadcasts** it to the specified peer node. -There are several required and optional flags for transaction creation. The `--from` flag specifies which [account](/docs/sdk/v0.53/accounts) the transaction is originating from. For example, if the transaction is sending coins, the funds are drawn from the specified `from` address. +There are several required and optional flags for transaction creation. The `--from` flag specifies which [account](/docs/sdk/v0.53/learn/beginner/accounts) the transaction is originating from. For example, if the transaction is sending coins, the funds are drawn from the specified `from` address. #### Gas and Fees -Additionally, there are several [flags](/docs/sdk/v0.53/learn/advanced/cli) users can use to indicate how much they are willing to pay in [fees](/docs/sdk/v0.53/gas-fees): +Additionally, there are several [flags](/docs/sdk/v0.53/learn/advanced/cli) users can use to indicate how much they are willing to pay in [fees](/docs/sdk/v0.53/learn/beginner/gas-fees): -* `--gas` refers to how much [gas](/docs/sdk/v0.53/gas-fees), which represents computational resources, `Tx` consumes. Gas is dependent on the transaction and is not precisely calculated until execution, but can be estimated by providing `auto` as the value for `--gas`. +* `--gas` refers to how much [gas](/docs/sdk/v0.53/learn/beginner/gas-fees), which represents computational resources, `Tx` consumes. Gas is dependent on the transaction and is not precisely calculated until execution, but can be estimated by providing `auto` as the value for `--gas`. * `--gas-adjustment` (optional) can be used to scale `gas` up in order to avoid underestimating. For example, users can specify their gas adjustment as 1.5 to use 1.5 times the estimated gas. * `--gas-prices` specifies how much the user is willing to pay per unit of gas, which can be one or multiple denominations of tokens. For example, `--gas-prices=0.025uatom, 0.025upho` means the user is willing to pay 0.025uatom AND 0.025upho per unit of gas. * `--fees` specifies how much in fees the user is willing to pay in total. @@ -230,7 +230,7 @@ to during consensus. Under the hood, transaction execution is almost identical t Instead of using their `checkState`, full-nodes use `finalizeblock`: * **Decoding:** Since `FinalizeBlock` is an ABCI call, `Tx` is received in the encoded `[]byte` form. - Nodes first unmarshal the transaction, using the [`TxConfig`](/docs/sdk/v0.53/app-anatomy#register-codec) defined in the app, then call `runTx` in `execModeFinalize`, which is very similar to `CheckTx` but also executes and writes state changes. + Nodes first unmarshal the transaction, using the [`TxConfig`](/docs/sdk/v0.53/learn/beginner/app-anatomy#register-codec) defined in the app, then call `runTx` in `execModeFinalize`, which is very similar to `CheckTx` but also executes and writes state changes. * **Checks and `AnteHandler`:** Full-nodes call `validateBasicMsgs` and `AnteHandler` again. This second check happens because they may not have seen the same transactions during the addition to Mempool stage From 4edd674c842ca80dc088552c55e939117d80dadd Mon Sep 17 00:00:00 2001 From: Cordt Date: Fri, 24 Oct 2025 08:51:02 -0600 Subject: [PATCH 09/10] final batch of links --- .../next/documentation/concepts/accounts.mdx | 2 +- .../build-a-chain/quick-start.mdx | 2 +- .../build-a-chain/using-local-node.mdx | 2 +- .../v0.47/build/building-modules/genesis.mdx | 2 +- .../v0.47/build/building-modules/intro.mdx | 2 +- .../build/building-modules/invariants.mdx | 2 +- .../v0.47/build/building-modules/keeper.mdx | 4 ++-- .../build/building-modules/module-manager.mdx | 22 +++++++++---------- docs/sdk/v0.47/learn.mdx | 2 +- docs/sdk/v0.47/learn/advanced/baseapp.mdx | 20 ++++++++--------- docs/sdk/v0.47/learn/advanced/cli.mdx | 2 +- docs/sdk/v0.47/learn/advanced/context.mdx | 2 +- docs/sdk/v0.47/learn/advanced/encoding.mdx | 2 +- docs/sdk/v0.47/learn/advanced/events.mdx | 2 +- docs/sdk/v0.47/learn/advanced/node.mdx | 4 ++-- docs/sdk/v0.47/learn/advanced/store.mdx | 2 +- .../sdk/v0.47/learn/advanced/transactions.mdx | 2 +- docs/sdk/v0.47/learn/beginner/accounts.mdx | 2 +- docs/sdk/v0.47/learn/beginner/gas-fees.mdx | 2 +- .../sdk/v0.47/learn/beginner/tx-lifecycle.mdx | 8 +++---- docs/sdk/v0.47/learn/intro/sdk-design.mdx | 2 +- docs/sdk/v0.47/user/run-node/keyring.mdx | 2 +- docs/sdk/v0.47/user/run-node/run-node.mdx | 2 +- docs/sdk/v0.50/learn/advanced/encoding.mdx | 2 +- docs/sdk/v0.53/build/migrations/intro.mdx | 2 +- 25 files changed, 49 insertions(+), 49 deletions(-) diff --git a/docs/evm/next/documentation/concepts/accounts.mdx b/docs/evm/next/documentation/concepts/accounts.mdx index 61385a15..bca54b14 100644 --- a/docs/evm/next/documentation/concepts/accounts.mdx +++ b/docs/evm/next/documentation/concepts/accounts.mdx @@ -62,7 +62,7 @@ type EthAccountI interface { **EIP-7702 Support**: Cosmos EVM supports [EIP-7702 code delegation](/docs/evm/next/documentation/evm-compatibility/eip-7702), allowing EOAs to temporarily delegate code execution to smart contracts through the `SetCodeHash` functionality. -For more information on Ethereum accounts head over to the [x/vm module](/docs/evm/next/documentation/protocol/modules/vm). +For more information on Ethereum accounts head over to the [x/vm module](/docs/evm/v0.5.0/documentation/cosmos-sdk/modules/vm). ### Addresses and Public Keys diff --git a/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start.mdx b/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start.mdx index a093a098..d2a730f1 100644 --- a/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start.mdx +++ b/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/quick-start.mdx @@ -277,7 +277,7 @@ Deploy standard contracts at genesis for Create2, Multicall3, Permit2, and Safe ### Recommended Reading - + EVM execution and parameter configuration diff --git a/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/using-local-node.mdx b/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/using-local-node.mdx index 7dd65a63..e0b037db 100644 --- a/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/using-local-node.mdx +++ b/docs/evm/v0.5.0/documentation/getting-started/build-a-chain/using-local-node.mdx @@ -256,7 +256,7 @@ Deploy standard contracts at genesis for Create2, Multicall3, Permit2, and Safe ### Recommended Reading - + EVM execution and parameter configuration diff --git a/docs/sdk/v0.47/build/building-modules/genesis.mdx b/docs/sdk/v0.47/build/building-modules/genesis.mdx index efbca31b..29495d5e 100644 --- a/docs/sdk/v0.47/build/building-modules/genesis.mdx +++ b/docs/sdk/v0.47/build/building-modules/genesis.mdx @@ -609,7 +609,7 @@ Other than the methods related directly to `GenesisState`, module developers are The `InitGenesis` method is executed during [`InitChain`](/docs/sdk/v0.47/learn/advanced/baseapp#initchain) when the application is first started. Given a `GenesisState`, it initializes the subset of the state managed by the module by using the module's [`keeper`](/docs/sdk/v0.47/build/building-modules/keeper) setter function on each parameter within the `GenesisState`. -The [module manager](/docs/sdk/v0.47/build/building-modules/module-manager#manager) of the application is responsible for calling the `InitGenesis` method of each of the application's modules in order. This order is set by the application developer via the manager's `SetOrderGenesisMethod`, which is called in the [application's constructor function](/docs/sdk/v0.47/learn/beginner/app-anatomy#constructor-function). +The [module manager](/docs/sdk/v0.47/build/building-modules/module-manager#manager) of the application is responsible for calling the `InitGenesis` method of each of the application's modules in order. This order is set by the application developer via the manager's `SetOrderGenesisMethod`, which is called in the [application's constructor function](/docs/sdk/v0.47/learn/beginner/overview-app#constructor-function). See an example of `InitGenesis` from the `auth` module: diff --git a/docs/sdk/v0.47/build/building-modules/intro.mdx b/docs/sdk/v0.47/build/building-modules/intro.mdx index 98fc6b61..fbba170f 100644 --- a/docs/sdk/v0.47/build/building-modules/intro.mdx +++ b/docs/sdk/v0.47/build/building-modules/intro.mdx @@ -11,7 +11,7 @@ Modules define most of the logic of Cosmos SDK applications. Developers compose ### Pre-requisite Readings -* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.47/learn/beginner/app-anatomy) +* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.47/learn/beginner/overview-app) * [Lifecycle of a Cosmos SDK transaction](/docs/sdk/v0.47/learn/beginner/tx-lifecycle) diff --git a/docs/sdk/v0.47/build/building-modules/invariants.mdx b/docs/sdk/v0.47/build/building-modules/invariants.mdx index 074c3d55..d619190d 100644 --- a/docs/sdk/v0.47/build/building-modules/invariants.mdx +++ b/docs/sdk/v0.47/build/building-modules/invariants.mdx @@ -473,7 +473,7 @@ error { } ``` -The `InvariantRegistry` is therefore typically instantiated by instantiating the `keeper` of the `crisis` module in the [application's constructor function](/docs/sdk/v0.47/learn/beginner/app-anatomy#constructor-function). +The `InvariantRegistry` is therefore typically instantiated by instantiating the `keeper` of the `crisis` module in the [application's constructor function](/docs/sdk/v0.47/learn/beginner/overview-app#constructor-function). `Invariant`s can be checked manually via [`message`s](/docs/sdk/v0.47/build/building-modules/messages-and-queries), but most often they are checked automatically at the end of each block. Here is an example from the `crisis` module: diff --git a/docs/sdk/v0.47/build/building-modules/keeper.mdx b/docs/sdk/v0.47/build/building-modules/keeper.mdx index 543658bf..3a9e62f7 100644 --- a/docs/sdk/v0.47/build/building-modules/keeper.mdx +++ b/docs/sdk/v0.47/build/building-modules/keeper.mdx @@ -21,7 +21,7 @@ The Cosmos SDK is a framework that makes it easy for developers to build complex The Cosmos SDK adopts an [object-capabilities-based approach](/docs/sdk/v0.47/learn/advanced/ocap) to help developers better protect their application from unwanted inter-module interactions, and `keeper`s are at the core of this approach. A `keeper` can be considered quite literally to be the gatekeeper of a module's store(s). Each store (typically an [`IAVL` Store](/docs/sdk/v0.47/learn/advanced/store#iavl-store)) defined within a module comes with a `storeKey`, which grants unlimited access to it. The module's `keeper` holds this `storeKey` (which should otherwise remain unexposed), and defines [methods](#implementing-methods) for reading and writing to the store(s). -The core idea behind the object-capabilities approach is to only reveal what is necessary to get the work done. In practice, this means that instead of handling permissions of modules through access-control lists, module `keeper`s are passed a reference to the specific instance of the other modules' `keeper`s that they need to access (this is done in the [application's constructor function](/docs/sdk/v0.47/learn/beginner/app-anatomy#constructor-function)). As a consequence, a module can only interact with the subset of state defined in another module via the methods exposed by the instance of the other module's `keeper`. This is a great way for developers to control the interactions that their own module can have with modules developed by external developers. +The core idea behind the object-capabilities approach is to only reveal what is necessary to get the work done. In practice, this means that instead of handling permissions of modules through access-control lists, module `keeper`s are passed a reference to the specific instance of the other modules' `keeper`s that they need to access (this is done in the [application's constructor function](/docs/sdk/v0.47/learn/beginner/overview-app#constructor-function)). As a consequence, a module can only interact with the subset of state defined in another module via the methods exposed by the instance of the other module's `keeper`. This is a great way for developers to control the interactions that their own module can have with modules developed by external developers. ## Type Definition @@ -215,7 +215,7 @@ Let us go through the different parameters: * `storeKey`s grant access to the store(s) of the [multistore](/docs/sdk/v0.47/learn/advanced/store) managed by the module. They should always remain unexposed to external modules. * `cdc` is the [codec](/docs/sdk/v0.47/learn/advanced/encoding) used to marshall and unmarshall structs to/from `[]byte`. The `cdc` can be any of `codec.BinaryCodec`, `codec.JSONCodec` or `codec.Codec` based on your requirements. It can be either a proto or amino codec as long as they implement these interfaces. The authority listed is a module account or user account that has the right to change module level parameters. Previously this was handled by the param module, which has been deprecated. -Of course, it is possible to define different types of internal `keeper`s for the same module (e.g. a read-only `keeper`). Each type of `keeper` comes with its own constructor function, which is called from the [application's constructor function](/docs/sdk/v0.47/learn/beginner/app-anatomy). This is where `keeper`s are instantiated, and where developers make sure to pass correct instances of modules' `keeper`s to other modules that require them. +Of course, it is possible to define different types of internal `keeper`s for the same module (e.g. a read-only `keeper`). Each type of `keeper` comes with its own constructor function, which is called from the [application's constructor function](/docs/sdk/v0.47/learn/beginner/overview-app). This is where `keeper`s are instantiated, and where developers make sure to pass correct instances of modules' `keeper`s to other modules that require them. ## Implementing Methods diff --git a/docs/sdk/v0.47/build/building-modules/module-manager.mdx b/docs/sdk/v0.47/build/building-modules/module-manager.mdx index e55a642f..e969246d 100644 --- a/docs/sdk/v0.47/build/building-modules/module-manager.mdx +++ b/docs/sdk/v0.47/build/building-modules/module-manager.mdx @@ -4,7 +4,7 @@ title: Module Manager **Synopsis** -Cosmos SDK modules need to implement the [`AppModule` interfaces](#application-module-interfaces), in order to be managed by the application's [module manager](#module-manager). The module manager plays an important role in [`message` and `query` routing](/docs/sdk/v0.47/learn/advanced/baseapp#msg-service-router), and allows application developers to set the order of execution of a variety of functions like [`BeginBlocker` and `EndBlocker`](/docs/sdk/v0.47/learn/beginner/app-anatomy#beginblocker-and-endblocker). +Cosmos SDK modules need to implement the [`AppModule` interfaces](#application-module-interfaces), in order to be managed by the application's [module manager](#module-manager). The module manager plays an important role in [`message` and `query` routing](/docs/sdk/v0.47/learn/advanced/baseapp#msg-service-router), and allows application developers to set the order of execution of a variety of functions like [`BeginBlocker` and `EndBlocker`](/docs/sdk/v0.47/learn/beginner/overview-app#beginblocker-and-endblocker). @@ -38,7 +38,7 @@ The above interfaces are mostly embedding smaller interfaces (extension interfac * [`HasPrecommit`](#hasprecommit): The extension interface that contains information about the `AppModule` and `Precommit`. * [`HasPrepareCheckState`](#haspreparecheckstate): The extension interface that contains information about the `AppModule` and `PrepareCheckState`. -The `AppModuleBasic` interface exists to define independent methods of the module, i.e. those that do not depend on other modules in the application. This allows for the construction of the basic application structure early in the application definition, generally in the `init()` function of the [main application file](/docs/sdk/v0.47/learn/beginner/app-anatomy#core-application-file). +The `AppModuleBasic` interface exists to define independent methods of the module, i.e. those that do not depend on other modules in the application. This allows for the construction of the basic application structure early in the application definition, generally in the `init()` function of the [main application file](/docs/sdk/v0.47/learn/beginner/overview-app#core-application-file). The `AppModule` interface exists to define inter-dependent module methods. Many modules need to interact with other modules, typically through [`keeper`s](/docs/sdk/v0.47/build/building-modules/keeper), which means there is a need for an interface where modules list their `keeper`s and other methods that require a reference to another module's object. `AppModule` interface extension, such as `BeginBlockAppModule` and `EndBlockAppModule`, also enables the module manager to set the order of execution between module's methods like `BeginBlock` and `EndBlock`, which is important in cases where the order of execution between modules matters in the context of the application. @@ -9805,8 +9805,8 @@ return out It implements the following methods: -* `NewBasicManager(modules ...AppModuleBasic)`: Constructor function. It takes a list of the application's `AppModuleBasic` and builds a new `BasicManager`. This function is generally called in the `init()` function of [`app.go`](/docs/sdk/v0.47/learn/beginner/app-anatomy#core-application-file) to quickly initialize the independent elements of the application's modules (click [here](https://github.com/cosmos/gaia/blob/main/app/app.go#L59-L74) to see an example). -* `RegisterLegacyAminoCodec(cdc *codec.LegacyAmino)`: Registers the [`codec.LegacyAmino`s](/docs/sdk/v0.47/learn/advanced/encoding#amino) of each of the application's `AppModuleBasic`. This function is usually called early on in the [application's construction](/docs/sdk/v0.47/learn/beginner/app-anatomy#constructor). +* `NewBasicManager(modules ...AppModuleBasic)`: Constructor function. It takes a list of the application's `AppModuleBasic` and builds a new `BasicManager`. This function is generally called in the `init()` function of [`app.go`](/docs/sdk/v0.47/learn/beginner/overview-app#core-application-file) to quickly initialize the independent elements of the application's modules (click [here](https://github.com/cosmos/gaia/blob/main/app/app.go#L59-L74) to see an example). +* `RegisterLegacyAminoCodec(cdc *codec.LegacyAmino)`: Registers the [`codec.LegacyAmino`s](/docs/sdk/v0.47/learn/advanced/encoding#amino) of each of the application's `AppModuleBasic`. This function is usually called early on in the [application's construction](/docs/sdk/v0.47/learn/beginner/overview-app#constructor). * `RegisterInterfaces(registry codectypes.InterfaceRegistry)`: Registers interface types and implementations of each of the application's `AppModuleBasic`. * `DefaultGenesis(cdc codec.JSONCodec)`: Provides default genesis information for modules in the application by calling the [`DefaultGenesis(cdc codec.JSONCodec)`](/docs/sdk/v0.47/build/building-modules/genesis#defaultgenesis) function of each module. It only calls the modules that implements the `HasGenesisBasics` interfaces. * `ValidateGenesis(cdc codec.JSONCodec, txEncCfg client.TxEncodingConfig, genesis map[string]json.RawMessage)`: Validates the genesis information modules by calling the [`ValidateGenesis(codec.JSONCodec, client.TxEncodingConfig, json.RawMessage)`](/docs/sdk/v0.47/build/building-modules/genesis#validategenesis) function of modules implementing the `HasGenesisBasics` interface. @@ -10623,14 +10623,14 @@ return out The module manager is used throughout the application whenever an action on a collection of modules is required. It implements the following methods: -* `NewManager(modules ...AppModule)`: Constructor function. It takes a list of the application's `AppModule`s and builds a new `Manager`. It is generally called from the application's main [constructor function](/docs/sdk/v0.47/learn/beginner/app-anatomy#constructor-function). -* `SetOrderInitGenesis(moduleNames ...string)`: Sets the order in which the [`InitGenesis`](/docs/sdk/v0.47/build/building-modules/genesis#initgenesis) function of each module will be called when the application is first started. This function is generally called from the application's main [constructor function](/docs/sdk/v0.47/learn/beginner/app-anatomy#constructor-function). +* `NewManager(modules ...AppModule)`: Constructor function. It takes a list of the application's `AppModule`s and builds a new `Manager`. It is generally called from the application's main [constructor function](/docs/sdk/v0.47/learn/beginner/overview-app#constructor-function). +* `SetOrderInitGenesis(moduleNames ...string)`: Sets the order in which the [`InitGenesis`](/docs/sdk/v0.47/build/building-modules/genesis#initgenesis) function of each module will be called when the application is first started. This function is generally called from the application's main [constructor function](/docs/sdk/v0.47/learn/beginner/overview-app#constructor-function). To initialize modules successfully, module dependencies should be considered. For example, the `genutil` module must occur after `staking` module so that the pools are properly initialized with tokens from genesis accounts, the `genutils` module must also occur after `auth` so that it can access the params from auth, IBC's `capability` module should be initialized before all other modules so that it can initialize any capabilities. -* `SetOrderExportGenesis(moduleNames ...string)`: Sets the order in which the [`ExportGenesis`](/docs/sdk/v0.47/build/building-modules/genesis#exportgenesis) function of each module will be called in case of an export. This function is generally called from the application's main [constructor function](/docs/sdk/v0.47/learn/beginner/app-anatomy#constructor-function). -* `SetOrderBeginBlockers(moduleNames ...string)`: Sets the order in which the `BeginBlock()` function of each module will be called at the beginning of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.47/learn/beginner/app-anatomy#constructor-function). -* `SetOrderEndBlockers(moduleNames ...string)`: Sets the order in which the `EndBlock()` function of each module will be called at the end of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.47/learn/beginner/app-anatomy#constructor-function). -* `SetOrderPrecommiters(moduleNames ...string)`: Sets the order in which the `Precommit()` function of each module will be called during commit of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.47/learn/beginner/app-anatomy#constructor-function). -* `SetOrderPrepareCheckStaters(moduleNames ...string)`: Sets the order in which the `PrepareCheckState()` function of each module will be called during commit of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.47/learn/beginner/app-anatomy#constructor-function). +* `SetOrderExportGenesis(moduleNames ...string)`: Sets the order in which the [`ExportGenesis`](/docs/sdk/v0.47/build/building-modules/genesis#exportgenesis) function of each module will be called in case of an export. This function is generally called from the application's main [constructor function](/docs/sdk/v0.47/learn/beginner/overview-app#constructor-function). +* `SetOrderBeginBlockers(moduleNames ...string)`: Sets the order in which the `BeginBlock()` function of each module will be called at the beginning of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.47/learn/beginner/overview-app#constructor-function). +* `SetOrderEndBlockers(moduleNames ...string)`: Sets the order in which the `EndBlock()` function of each module will be called at the end of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.47/learn/beginner/overview-app#constructor-function). +* `SetOrderPrecommiters(moduleNames ...string)`: Sets the order in which the `Precommit()` function of each module will be called during commit of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.47/learn/beginner/overview-app#constructor-function). +* `SetOrderPrepareCheckStaters(moduleNames ...string)`: Sets the order in which the `PrepareCheckState()` function of each module will be called during commit of each block. This function is generally called from the application's main [constructor function](/docs/sdk/v0.47/learn/beginner/overview-app#constructor-function). * `SetOrderMigrations(moduleNames ...string)`: Sets the order of migrations to be run. If not set then migrations will be run with an order defined in `DefaultMigrationsOrder`. * `RegisterInvariants(ir sdk.InvariantRegistry)`: Registers the [invariants](/docs/sdk/v0.47/build/building-modules/invariants) of module implementing the `HasInvariants` interface. * `RegisterRoutes(router sdk.Router, queryRouter sdk.QueryRouter, legacyQuerierCdc *codec.LegacyAmino)`: Registers legacy [`Msg`](/docs/sdk/v0.47/build/building-modules/messages-and-queries#messages) and [`querier`](/docs/sdk/v0.47/build/building-modules/query-services) routes. diff --git a/docs/sdk/v0.47/learn.mdx b/docs/sdk/v0.47/learn.mdx index e3fdf76c..96d055bf 100644 --- a/docs/sdk/v0.47/learn.mdx +++ b/docs/sdk/v0.47/learn.mdx @@ -4,5 +4,5 @@ description: "Version: v0.47" --- * [Introduction](/docs/sdk/v0.47/learn/intro/overview) - Dive into the fundamentals of Cosmos SDK with an insightful introduction, laying the groundwork for understanding blockchain development. In this section we provide a High-Level Overview of the SDK, then dive deeper into Core concepts such as Application-Specific Blockchains, Blockchain Architecture, and finally we begin to explore what are the main components of the SDK. -* [Beginner](/docs/sdk/v0.47/learn/beginner/app-anatomy) - Start your journey with beginner-friendly resources in the Cosmos SDK's "Learn" section, providing a gentle entry point for newcomers to blockchain development. Here we focus on a little more detail, covering the Anatomy of a Cosmos SDK Application, Transaction Lifecycles, Accounts and lastly, Gas and Fees. +* [Beginner](/docs/sdk/v0.47/learn/beginner/overview-app) - Start your journey with beginner-friendly resources in the Cosmos SDK's "Learn" section, providing a gentle entry point for newcomers to blockchain development. Here we focus on a little more detail, covering the Anatomy of a Cosmos SDK Application, Transaction Lifecycles, Accounts and lastly, Gas and Fees. * [Advanced](/docs/sdk/v0.47/learn/advanced/baseapp) - Level up your Cosmos SDK expertise with advanced topics, tailored for experienced developers diving into intricate blockchain application development. We cover the Cosmos SDK on a lower level as we dive into the core of the SDK with BaseApp, Transactions, Context, Node Client (Daemon), Store, Encoding, gRPC, REST, and CometBFT Endpoints, CLI, Events, Telementry, Object-Capability Model, RunTx recovery middleware, Cosmos Blockchain Simulator, Protobuf Documentation, In-Place Store Migrations, Configuration and AutoCLI. diff --git a/docs/sdk/v0.47/learn/advanced/baseapp.mdx b/docs/sdk/v0.47/learn/advanced/baseapp.mdx index ab0b0d0b..994e23ec 100644 --- a/docs/sdk/v0.47/learn/advanced/baseapp.mdx +++ b/docs/sdk/v0.47/learn/advanced/baseapp.mdx @@ -11,7 +11,7 @@ This document describes `BaseApp`, the abstraction that implements the core func ### Pre-requisite Readings -* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.47/learn/beginner/app-anatomy) +* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.47/learn/beginner/overview-app) * [Lifecycle of a Cosmos SDK transaction](/docs/sdk/v0.47/learn/beginner/tx-lifecycle) @@ -1253,8 +1253,8 @@ First, the important parameters that are initialized during the bootstrapping of * [`AnteHandler`](#antehandler): This handler is used to handle signature verification, fee payment, and other pre-message execution checks when a transaction is received. It's executed during [`CheckTx/RecheckTx`](#checktx) and [`DeliverTx`](#delivertx). -* [`InitChainer`](/docs/sdk/v0.47/learn/beginner/app-anatomy#initchainer), - [`BeginBlocker` and `EndBlocker`](/docs/sdk/v0.47/learn/beginner/app-anatomy#beginblocker-and-endblocker): These are +* [`InitChainer`](/docs/sdk/v0.47/learn/beginner/overview-app#initchainer), + [`BeginBlocker` and `EndBlocker`](/docs/sdk/v0.47/learn/beginner/overview-app#beginblocker-and-endblocker): These are the functions executed when the application receives the `InitChain`, `BeginBlock` and `EndBlock` ABCI messages from the underlying CometBFT engine. @@ -1280,7 +1280,7 @@ Finally, a few more important parameters: `minGasPrices` (e.g. if `minGasPrices == 1uatom,1photon`, the `gas-price` of the transaction must be greater than `1uatom` OR `1photon`). * `appVersion`: Version of the application. It is set in the - [application's constructor function](/docs/sdk/v0.47/learn/beginner/app-anatomy#constructor-function). + [application's constructor function](/docs/sdk/v0.47/learn/beginner/overview-app#constructor-function). ## Constructor @@ -1402,13 +1402,13 @@ When messages and queries are received by the application, they must be routed t The [default `msgServiceRouter` included in `BaseApp`](https://github.com/cosmos/cosmos-sdk/blob/v0.47.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.47.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 application's `msgServiceRouter` is initialized with all the routes using the application's [module manager](/docs/sdk/v0.47/build/building-modules/module-manager#manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.47/learn/beginner/app-anatomy#constructor-function). +The application's `msgServiceRouter` is initialized with all the routes using the application's [module manager](/docs/sdk/v0.47/build/building-modules/module-manager#manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.47/learn/beginner/overview-app#constructor-function). ### gRPC Query Router Similar to `sdk.Msg`s, [`queries`](/docs/sdk/v0.47/build/building-modules/messages-and-queries#queries) need to be routed to the appropriate module's [`Query` service](/docs/sdk/v0.47/build/building-modules/query-services). To do so, `BaseApp` holds a `grpcQueryRouter`, which maps modules' fully-qualified service methods (`string`, defined in their Protobuf `Query` gRPC) to their `QueryServer` implementation. The `grpcQueryRouter` is called during the initial stages of query processing, which can be either by directly sending a gRPC query to the gRPC endpoint, or via the [`Query` ABCI message](#query) on the CometBFT RPC endpoint. -Just like the `msgServiceRouter`, the `grpcQueryRouter` is initialized with all the query routes using the application's [module manager](/docs/sdk/v0.47/build/building-modules/module-manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.47/learn/beginner/app-anatomy#app-constructor). +Just like the `msgServiceRouter`, the `grpcQueryRouter` is initialized with all the query routes using the application's [module manager](/docs/sdk/v0.47/build/building-modules/module-manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](/docs/sdk/v0.47/learn/beginner/overview-app#app-constructor). ## Main ABCI 1.0 Messages @@ -3441,7 +3441,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](/docs/sdk/v0.47/learn/beginner/app-anatomy#application-constructor). The most widely used `anteHandler` is the [`auth` module](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/ante/ante.go). +`BaseApp` holds an `anteHandler` as parameter that is initialized in the [application's constructor](/docs/sdk/v0.47/learn/beginner/overview-app#application-constructor). The most widely used `anteHandler` is the [`auth` module](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/ante/ante.go). Click [here](/docs/sdk/v0.47/learn/beginner/gas-fees#antehandler) for more on the `anteHandler`. @@ -3491,7 +3491,7 @@ The [`InitChain` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x * [`checkState` and `deliverState`](#state-updates) via `setState`. * The [block gas meter](/docs/sdk/v0.47/learn/beginner/gas-fees#block-gas-meter), with infinite gas to process genesis transactions. -Finally, the `InitChain(req abci.RequestInitChain)` method of `BaseApp` calls the [`initChainer()`](/docs/sdk/v0.47/learn/beginner/app-anatomy#initchainer) of the application in order to initialize the main state of the application from the `genesis file` and, if defined, call the [`InitGenesis`](/docs/sdk/v0.47/build/building-modules/genesis#initgenesis) function of each of the application's modules. +Finally, the `InitChain(req abci.RequestInitChain)` method of `BaseApp` calls the [`initChainer()`](/docs/sdk/v0.47/learn/beginner/overview-app#initchainer) of the application in order to initialize the main state of the application from the `genesis file` and, if defined, call the [`InitGenesis`](/docs/sdk/v0.47/build/building-modules/genesis#initgenesis) function of each of the application's modules. ### BeginBlock @@ -4681,13 +4681,13 @@ The [`BeginBlock` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37. * Initialize the [block gas meter](/docs/sdk/v0.47/learn/beginner/gas-fees#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()`](/docs/sdk/v0.47/learn/beginner/app-anatomy#beginblocker-and-endblock), which mainly runs the [`BeginBlocker()`](/docs/sdk/v0.47/build/building-modules/beginblock-endblock#beginblock) method of each of the application's modules. +* Run the application's [`beginBlocker()`](/docs/sdk/v0.47/learn/beginner/overview-app#beginblocker-and-endblock), which mainly runs the [`BeginBlocker()`](/docs/sdk/v0.47/build/building-modules/beginblock-endblock#beginblock) method of each of the application's modules. * Set the [`VoteInfos`](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_methods.md#voteinfo) of the application, i.e. the list of validators whose *precommit* for the previous block was included by the proposer of the current block. This information is carried into the [`Context`](/docs/sdk/v0.47/learn/advanced/context) so that it can be used during `DeliverTx` and `EndBlock`. ### EndBlock -The [`EndBlock` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_basic_concepts.md#method-overview) is sent from the underlying CometBFT engine after [`DeliverTx`](#delivertx) as been run for each transaction in the block. It allows developers to have logic be executed at the end of each block. In the Cosmos SDK, the bulk `EndBlock(req abci.RequestEndBlock)` method is to run the application's [`EndBlocker()`](/docs/sdk/v0.47/learn/beginner/app-anatomy#beginblocker-and-endblock), which mainly runs the [`EndBlocker()`](/docs/sdk/v0.47/build/building-modules/beginblock-endblock#beginblock) method of each of the application's modules. +The [`EndBlock` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_basic_concepts.md#method-overview) is sent from the underlying CometBFT engine after [`DeliverTx`](#delivertx) as been run for each transaction in the block. It allows developers to have logic be executed at the end of each block. In the Cosmos SDK, the bulk `EndBlock(req abci.RequestEndBlock)` method is to run the application's [`EndBlocker()`](/docs/sdk/v0.47/learn/beginner/overview-app#beginblocker-and-endblock), which mainly runs the [`EndBlocker()`](/docs/sdk/v0.47/build/building-modules/beginblock-endblock#beginblock) method of each of the application's modules. ### Commit diff --git a/docs/sdk/v0.47/learn/advanced/cli.mdx b/docs/sdk/v0.47/learn/advanced/cli.mdx index c2a6a7f1..bba68484 100644 --- a/docs/sdk/v0.47/learn/advanced/cli.mdx +++ b/docs/sdk/v0.47/learn/advanced/cli.mdx @@ -4,7 +4,7 @@ title: Command-Line Interface **Synopsis** -This document describes how command-line interface (CLI) works on a high-level, for an [**application**](/docs/sdk/v0.47/learn/beginner/app-anatomy). A separate document for implementing a CLI for a Cosmos SDK [**module**](/docs/sdk/v0.47/build/building-modules/intro) can be found [here](/docs/sdk/v0.47/build/building-modules/module-interfaces#cli). +This document describes how command-line interface (CLI) works on a high-level, for an [**application**](/docs/sdk/v0.47/learn/beginner/overview-app). A separate document for implementing a CLI for a Cosmos SDK [**module**](/docs/sdk/v0.47/build/building-modules/intro) can be found [here](/docs/sdk/v0.47/build/building-modules/module-interfaces#cli). ## Command-Line Interface diff --git a/docs/sdk/v0.47/learn/advanced/context.mdx b/docs/sdk/v0.47/learn/advanced/context.mdx index 1ec0dacc..99d01d6c 100644 --- a/docs/sdk/v0.47/learn/advanced/context.mdx +++ b/docs/sdk/v0.47/learn/advanced/context.mdx @@ -11,7 +11,7 @@ The `context` is a data structure intended to be passed from function to functio ### Pre-requisites Readings -* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.47/learn/beginner/app-anatomy) +* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.47/learn/beginner/overview-app) * [Lifecycle of a Transaction](/docs/sdk/v0.47/learn/beginner/tx-lifecycle) diff --git a/docs/sdk/v0.47/learn/advanced/encoding.mdx b/docs/sdk/v0.47/learn/advanced/encoding.mdx index 6af0df63..a3fb7d3c 100644 --- a/docs/sdk/v0.47/learn/advanced/encoding.mdx +++ b/docs/sdk/v0.47/learn/advanced/encoding.mdx @@ -11,7 +11,7 @@ While encoding in the Cosmos SDK used to be mainly handled by `go-amino` codec, ### Pre-requisite Readings -* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.47/learn/beginner/app-anatomy) +* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.47/learn/beginner/overview-app) diff --git a/docs/sdk/v0.47/learn/advanced/events.mdx b/docs/sdk/v0.47/learn/advanced/events.mdx index 7e198215..3284bfa8 100644 --- a/docs/sdk/v0.47/learn/advanced/events.mdx +++ b/docs/sdk/v0.47/learn/advanced/events.mdx @@ -11,7 +11,7 @@ title: Events ### Pre-requisite Readings -* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.47/learn/beginner/app-anatomy) +* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.47/learn/beginner/overview-app) * [CometBFT Documentation on Events](https://docs.cometbft.com/v0.37/spec/abci/abci++_basic_concepts#events) diff --git a/docs/sdk/v0.47/learn/advanced/node.mdx b/docs/sdk/v0.47/learn/advanced/node.mdx index 152086a0..150eda1e 100644 --- a/docs/sdk/v0.47/learn/advanced/node.mdx +++ b/docs/sdk/v0.47/learn/advanced/node.mdx @@ -11,7 +11,7 @@ The main endpoint of a Cosmos SDK application is the daemon client, otherwise kn ### Pre-requisite Readings -* [Anatomy of an SDK application](/docs/sdk/v0.47/learn/beginner/app-anatomy) +* [Anatomy of an SDK application](/docs/sdk/v0.47/learn/beginner/overview-app) @@ -1321,7 +1321,7 @@ Application ) ``` -In practice, the [constructor of the application](/docs/sdk/v0.47/learn/beginner/app-anatomy#constructor-function) is passed as the `appCreator`. +In practice, the [constructor of the application](/docs/sdk/v0.47/learn/beginner/overview-app#constructor-function) is passed as the `appCreator`. ```go expandable package cmd diff --git a/docs/sdk/v0.47/learn/advanced/store.mdx b/docs/sdk/v0.47/learn/advanced/store.mdx index db4f7435..81bb01ba 100644 --- a/docs/sdk/v0.47/learn/advanced/store.mdx +++ b/docs/sdk/v0.47/learn/advanced/store.mdx @@ -11,7 +11,7 @@ A store is a data structure that holds the state of the application. ### Pre-requisite Readings -* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.47/learn/beginner/app-anatomy) +* [Anatomy of a Cosmos SDK application](/docs/sdk/v0.47/learn/beginner/overview-app) diff --git a/docs/sdk/v0.47/learn/advanced/transactions.mdx b/docs/sdk/v0.47/learn/advanced/transactions.mdx index 2bcd08e7..2aff25d9 100644 --- a/docs/sdk/v0.47/learn/advanced/transactions.mdx +++ b/docs/sdk/v0.47/learn/advanced/transactions.mdx @@ -11,7 +11,7 @@ title: Transactions ### Pre-requisite Readings -* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.47/learn/beginner/app-anatomy) +* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.47/learn/beginner/overview-app) diff --git a/docs/sdk/v0.47/learn/beginner/accounts.mdx b/docs/sdk/v0.47/learn/beginner/accounts.mdx index f9205fad..58b15cea 100644 --- a/docs/sdk/v0.47/learn/beginner/accounts.mdx +++ b/docs/sdk/v0.47/learn/beginner/accounts.mdx @@ -11,7 +11,7 @@ This document describes the in-built account and public key system of the Cosmos ### Pre-requisite Readings -* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.47/learn/beginner/app-anatomy) +* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.47/learn/beginner/overview-app) diff --git a/docs/sdk/v0.47/learn/beginner/gas-fees.mdx b/docs/sdk/v0.47/learn/beginner/gas-fees.mdx index feaf98d0..e07d985f 100644 --- a/docs/sdk/v0.47/learn/beginner/gas-fees.mdx +++ b/docs/sdk/v0.47/learn/beginner/gas-fees.mdx @@ -11,7 +11,7 @@ This document describes the default strategies to handle gas and fees within a C ### Pre-requisite Readings -* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.47/learn/beginner/app-anatomy) +* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.47/learn/beginner/overview-app) diff --git a/docs/sdk/v0.47/learn/beginner/tx-lifecycle.mdx b/docs/sdk/v0.47/learn/beginner/tx-lifecycle.mdx index 6edb6eef..87f121e0 100644 --- a/docs/sdk/v0.47/learn/beginner/tx-lifecycle.mdx +++ b/docs/sdk/v0.47/learn/beginner/tx-lifecycle.mdx @@ -11,7 +11,7 @@ This document describes the lifecycle of a transaction from creation to committe ### Pre-requisite Readings -* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.47/learn/beginner/app-anatomy) +* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.47/learn/beginner/overview-app) ## Creation @@ -157,8 +157,8 @@ must be in this proposer's mempool. The next step of consensus is to execute the transactions to fully validate them. All full-nodes that receive a block proposal from the correct proposer execute the transactions by calling the ABCI functions -[`BeginBlock`](/docs/sdk/v0.47/learn/beginner/app-anatomy#beginblocker-and-endblocker), `DeliverTx` for each transaction, -and [`EndBlock`](/docs/sdk/v0.47/learn/beginner/app-anatomy#beginblocker-and-endblocker). While each full-node runs everything +[`BeginBlock`](/docs/sdk/v0.47/learn/beginner/overview-app#beginblocker-and-endblocker), `DeliverTx` for each transaction, +and [`EndBlock`](/docs/sdk/v0.47/learn/beginner/overview-app#beginblocker-and-endblocker). While each full-node runs everything locally, this process yields a single, unambiguous result, since the messages' state transitions are deterministic and transactions are explicitly ordered in the block proposal. @@ -208,7 +208,7 @@ to during consensus. Under the hood, `DeliverTx` is almost identical to `CheckTx Instead of using their `checkState`, full-nodes use `deliverState`: * **Decoding:** Since `DeliverTx` is an ABCI call, `Tx` is received in the encoded `[]byte` form. - Nodes first unmarshal the transaction, using the [`TxConfig`](/docs/sdk/v0.47/learn/beginner/app-anatomy#register-codec) defined in the app, then call `runTx` in `runTxModeDeliver`, which is very similar to `CheckTx` but also executes and writes state changes. + Nodes first unmarshal the transaction, using the [`TxConfig`](/docs/sdk/v0.47/learn/beginner/overview-app#register-codec) defined in the app, then call `runTx` in `runTxModeDeliver`, which is very similar to `CheckTx` but also executes and writes state changes. * **Checks and `AnteHandler`:** Full-nodes call `validateBasicMsgs` and `AnteHandler` again. This second check happens because they may not have seen the same transactions during the addition to Mempool stage diff --git a/docs/sdk/v0.47/learn/intro/sdk-design.mdx b/docs/sdk/v0.47/learn/intro/sdk-design.mdx index ecbbb546..52aa0fe8 100644 --- a/docs/sdk/v0.47/learn/intro/sdk-design.mdx +++ b/docs/sdk/v0.47/learn/intro/sdk-design.mdx @@ -13,7 +13,7 @@ Here is a simplified view of how transactions are handled by an application buil ## `baseapp` -`baseapp` is the boilerplate implementation of a Cosmos SDK application. It comes with an implementation of the ABCI to handle the connection with the underlying consensus engine. Typically, a Cosmos SDK application extends `baseapp` by embedding it in [`app.go`](/docs/sdk/v0.47/learn/beginner/app-anatomy#core-application-file). +`baseapp` is the boilerplate implementation of a Cosmos SDK application. It comes with an implementation of the ABCI to handle the connection with the underlying consensus engine. Typically, a Cosmos SDK application extends `baseapp` by embedding it in [`app.go`](/docs/sdk/v0.47/learn/beginner/overview-app#core-application-file). Here is an example of this from `simapp`, the Cosmos SDK demonstration app: diff --git a/docs/sdk/v0.47/user/run-node/keyring.mdx b/docs/sdk/v0.47/user/run-node/keyring.mdx index f02b717b..3675b3ba 100644 --- a/docs/sdk/v0.47/user/run-node/keyring.mdx +++ b/docs/sdk/v0.47/user/run-node/keyring.mdx @@ -4,7 +4,7 @@ title: Setting up the keyring **Synopsis** -This document describes how to configure and use the keyring and its various backends for an [**application**](/docs/sdk/v0.47/learn/beginner/app-anatomy). +This document describes how to configure and use the keyring and its various backends for an [**application**](/docs/sdk/v0.47/learn/beginner/overview-app). The keyring holds the private/public keypairs used to interact with a node. For instance, a validator key needs to be set up before running the blockchain node, so that blocks can be correctly signed. The private key can be stored in different locations, called "backends", such as a file or the operating system's own key storage. diff --git a/docs/sdk/v0.47/user/run-node/run-node.mdx b/docs/sdk/v0.47/user/run-node/run-node.mdx index 2ba7961f..5416b6ea 100644 --- a/docs/sdk/v0.47/user/run-node/run-node.mdx +++ b/docs/sdk/v0.47/user/run-node/run-node.mdx @@ -10,7 +10,7 @@ Now that the application is ready and the keyring populated, it's time to see ho **Pre-requisite Readings** -* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.47/learn/beginner/app-anatomy) +* [Anatomy of a Cosmos SDK Application](/docs/sdk/v0.47/learn/beginner/overview-app) * [Setting up the keyring](/docs/sdk/v0.47/user/run-node/keyring) diff --git a/docs/sdk/v0.50/learn/advanced/encoding.mdx b/docs/sdk/v0.50/learn/advanced/encoding.mdx index 08fad7a9..7158f2a5 100644 --- a/docs/sdk/v0.50/learn/advanced/encoding.mdx +++ b/docs/sdk/v0.50/learn/advanced/encoding.mdx @@ -47,7 +47,7 @@ via Protobuf. This means that modules may use Protobuf encoding, but the types m implement `ProtoMarshaler`. If modules wish to avoid implementing this interface for their types, this is autogenerated via [buf](https://buf.build/) -If modules use [Collections](/docs/sdk/v0.50/build/packages/collections) or [ORM](/docs/sdk/v0.50/build/packages/orm), encoding and decoding are handled, marshal and unmarshal should not be handled manually unless for specific cases identified by the developer. +If modules use [Collections](/docs/sdk/v0.50/build/packages/collections) or [ORM](/docs/sdk/v0.50/build/architecture/adr-055-orm), encoding and decoding are handled, marshal and unmarshal should not be handled manually unless for specific cases identified by the developer. ### Gogoproto diff --git a/docs/sdk/v0.53/build/migrations/intro.mdx b/docs/sdk/v0.53/build/migrations/intro.mdx index 501af8cd..53d6dcdc 100644 --- a/docs/sdk/v0.53/build/migrations/intro.mdx +++ b/docs/sdk/v0.53/build/migrations/intro.mdx @@ -10,4 +10,4 @@ Additionally, the SDK includes in-place migrations for its core modules. These i Migration from a version older than the last two major releases is not supported. -When migrating from a previous version, refer to the [`UPGRADING.md`](/docs/sdk/v0.53/build/migrations/upgrading) and the `CHANGELOG.md` of the version you are migrating to. +When migrating from a previous version, refer to the [`UPGRADING.md`](/docs/sdk/v0.53/build/migrations/upgrade-guide) and the `CHANGELOG.md` of the version you are migrating to. From 706094d4164aa6c45eeb915170a4d1d4f8a60791 Mon Sep 17 00:00:00 2001 From: Cordt Date: Fri, 24 Oct 2025 08:52:50 -0600 Subject: [PATCH 10/10] update nav --- docs.json | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/docs.json b/docs.json index 496a7686..a45ed1b6 100644 --- a/docs.json +++ b/docs.json @@ -71,7 +71,6 @@ } ] }, - "docs/evm/v0.5.0/documentation/getting-started/index", "docs/evm/v0.5.0/documentation/getting-started/faq" ] }, @@ -371,7 +370,6 @@ } ] }, - "docs/evm/next/documentation/getting-started/index", "docs/evm/next/documentation/getting-started/faq" ] }, @@ -955,7 +953,7 @@ { "group": "x/auth", "pages": [ - "docs/sdk/v0.50/build/modules/auth/authre", + "docs/sdk/v0.50/build/modules/auth/auth", "docs/sdk/v0.50/build/modules/auth/vesting", "docs/sdk/v0.50/build/modules/auth/tx" ] @@ -1278,7 +1276,7 @@ { "group": "x/auth", "pages": [ - "docs/sdk/v0.47/build/modules/auth/aut", + "docs/sdk/v0.47/build/modules/auth/auth", "docs/sdk/v0.47/build/modules/auth/vesting", "docs/sdk/v0.47/build/modules/auth/tx" ]