diff --git a/docs/build/architecture/adr-033-protobuf-inter-module-comm.md b/docs/build/architecture/adr-033-protobuf-inter-module-comm.md index 1929975c9..b85bf9095 100644 --- a/docs/build/architecture/adr-033-protobuf-inter-module-comm.md +++ b/docs/build/architecture/adr-033-protobuf-inter-module-comm.md @@ -378,7 +378,7 @@ replacing `Keeper` interfaces altogether. * an alternative to keepers which can more easily lead to stable inter-module interfaces * proper inter-module OCAPs -* improved module developer DevX, as commented on by several particpants on +* improved module developer DevX, as commented on by several participants on [Architecture Review Call, Dec 3](https://hackmd.io/E0wxxOvRQ5qVmTf6N_k84Q) * lays the groundwork for what can be a greatly simplified `app.go` * router can be setup to enforce atomic transactions for module-to-module calls diff --git a/docs/build/building-modules/00-intro.md b/docs/build/building-modules/00-intro.md index bd8e78a42..b301e92ae 100644 --- a/docs/build/building-modules/00-intro.md +++ b/docs/build/building-modules/00-intro.md @@ -63,6 +63,8 @@ While there are no definitive guidelines for writing modules, here are some impo The SDK provides a set of APIs that a module can implement, and a set of services that a module can use. Those APIs are defined in the `cosmossdk.io/core/appmodule` package, and are used to defined the module capabilities, which is used by `runtime` during the wiring of the application. +Whenever possible, a module should strive to use only the core APIs (`cosmossdk.io/core`) and not import the `github.com/cosmos/cosmos-sdk` module. This makes modules reusable across SDK versions and reduces the risk of breaking changes. + Learn more about the core APIs for modules [here](../../learn/advanced/02-core.md). ## Main Components of Cosmos SDK Modules diff --git a/docs/build/migrations/02-upgrading.md b/docs/build/migrations/02-upgrading.md index 1f9ae2647..4e6c67a61 100644 --- a/docs/build/migrations/02-upgrading.md +++ b/docs/build/migrations/02-upgrading.md @@ -498,6 +498,16 @@ This change was made to allow legacy proposals to be compatible with server/v2. If you wish to migrate to server/v2, you should update your proposal handler to take in a `context.Context` and use services. On the other hand, if you wish to keep using baseapp, simply unwrap the sdk context in your proposal handler. +#### `x/mint` + +The `x/mint` module has been updated to work with a mint function [`MintFn`](https://docs.cosmos.network/v0.52/build/modules/mint#mintfn). + +When using the default inflation calculation function and runtime, no change is required. The depinject configuration of mint automatically sets it if none is provided. However, when not using runtime, the mint function must be set in on the mint keeper: + +```diff ++ mintKeeper.SetMintFn(keeper.DefaultMintFn(types.DefaultInflationCalculationFn, stakingKeeper, mintKeeper)) +``` + #### `x/protocolpool` Introducing a new `x/protocolpool` module to handle community pool funds. Its store must be added while upgrading to v0.52.x. @@ -532,6 +542,10 @@ storetypes.StoreUpgrades{ Introducing `x/validate` a module that is solely used for registering default ante/post handlers and global tx validators when using runtime and runtime/v2. If you wish to set your custom ante/post handlers, no need to use this module. You can however always extend them by adding extra tx validators (see `x/validate` documentation). +#### `tools/benchmark` + +Introducing [`tools/benchmark`](https://github.com/cosmos/cosmos-sdk/tree/main/tools/benchmark) a Cosmos SDK module for benchmarking your chain. It is a standalone module that can be added to your chain to stress test it. This module should NOT be added in a production environment. + ## [v0.50.x](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.50.0-alpha.0) ### Migration to CometBFT (Part 2) diff --git a/docs/learn/beginner/00-app-anatomy.md b/docs/learn/beginner/00-app-anatomy.md index 151579967..3d73c38fd 100644 --- a/docs/learn/beginner/00-app-anatomy.md +++ b/docs/learn/beginner/00-app-anatomy.md @@ -59,7 +59,7 @@ 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](../../build/building-apps/00-runtime.md)** 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. +* **Embedding [runtime.App](../../build/building-apps/00-runtime.md)** 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/v1.0/spec/abci/) and the [routing logic](../advanced/00-baseapp.md#service-routers). * It configures automatically the **[module manager](../../build/building-modules/01-module-manager.md#manager)** based on the app wiring configuration. The module manager facilitates operations related to these modules, like registering their [`Msg` service](../../build/building-modules/03-msg-services.md) 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**](../../build/building-apps/00-runtime.md) 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 contains as well at which order the modules `InitGenesis`, `Pre/Begin/EndBlocker` should be executed. diff --git a/versioned_docs/version-0.52/build/architecture/adr-033-protobuf-inter-module-comm.md b/versioned_docs/version-0.52/build/architecture/adr-033-protobuf-inter-module-comm.md index 4f2769e67..83bb4dcb2 100644 --- a/versioned_docs/version-0.52/build/architecture/adr-033-protobuf-inter-module-comm.md +++ b/versioned_docs/version-0.52/build/architecture/adr-033-protobuf-inter-module-comm.md @@ -378,7 +378,7 @@ replacing `Keeper` interfaces altogether. * an alternative to keepers which can more easily lead to stable inter-module interfaces * proper inter-module OCAPs -* improved module developer DevX, as commented on by several particpants on +* improved module developer DevX, as commented on by several participants on [Architecture Review Call, Dec 3](https://hackmd.io/E0wxxOvRQ5qVmTf6N_k84Q) * lays the groundwork for what can be a greatly simplified `app.go` * router can be setup to enforce atomic transactions for module-to-module calls diff --git a/versioned_docs/version-0.52/build/building-modules/00-intro.md b/versioned_docs/version-0.52/build/building-modules/00-intro.md index bd8e78a42..b301e92ae 100644 --- a/versioned_docs/version-0.52/build/building-modules/00-intro.md +++ b/versioned_docs/version-0.52/build/building-modules/00-intro.md @@ -63,6 +63,8 @@ While there are no definitive guidelines for writing modules, here are some impo The SDK provides a set of APIs that a module can implement, and a set of services that a module can use. Those APIs are defined in the `cosmossdk.io/core/appmodule` package, and are used to defined the module capabilities, which is used by `runtime` during the wiring of the application. +Whenever possible, a module should strive to use only the core APIs (`cosmossdk.io/core`) and not import the `github.com/cosmos/cosmos-sdk` module. This makes modules reusable across SDK versions and reduces the risk of breaking changes. + Learn more about the core APIs for modules [here](../../learn/advanced/02-core.md). ## Main Components of Cosmos SDK Modules diff --git a/versioned_docs/version-0.52/build/migrations/02-upgrading.md b/versioned_docs/version-0.52/build/migrations/02-upgrading.md index 61641e571..a9aee57cf 100644 --- a/versioned_docs/version-0.52/build/migrations/02-upgrading.md +++ b/versioned_docs/version-0.52/build/migrations/02-upgrading.md @@ -455,6 +455,16 @@ This change was made to allow legacy proposals to be compatible with server/v2. If you wish to migrate to server/v2, you should update your proposal handler to take in a `context.Context` and use services. On the other hand, if you wish to keep using baseapp, simply unwrap the sdk context in your proposal handler. +#### `x/mint` + +The `x/mint` module has been updated to work with a mint function [`MintFn`](https://docs.cosmos.network/v0.52/build/modules/mint#mintfn). + +When using the default inflation calculation function and runtime, no change is required. The depinject configuration of mint automatically sets it if none is provided. However, when not using runtime, the mint function must be set in on the mint keeper: + +```diff ++ mintKeeper.SetMintFn(keeper.DefaultMintFn(types.DefaultInflationCalculationFn, stakingKeeper, mintKeeper)) +``` + #### `x/protocolpool` Introducing a new `x/protocolpool` module to handle community pool funds. Its store must be added while upgrading to v0.52.x. @@ -488,3 +498,7 @@ storetypes.StoreUpgrades{ Introducing `x/validate` a module that is solely used for registering default ante/post handlers and global tx validators when using runtime and runtime/v2. If you wish to set your custom ante/post handlers, no need to use this module. You can however always extend them by adding extra tx validators (see `x/validate` documentation). + +#### `tools/benchmark` + +Introducing [`tools/benchmark`](https://github.com/cosmos/cosmos-sdk/tree/main/tools/benchmark) a Cosmos SDK module for benchmarking your chain. It is a standalone module that can be added to your chain to stress test it. This module should NOT be added in a production environment. diff --git a/versioned_docs/version-0.52/learn/beginner/00-app-anatomy.md b/versioned_docs/version-0.52/learn/beginner/00-app-anatomy.md index 056a107f2..dd771bec7 100644 --- a/versioned_docs/version-0.52/learn/beginner/00-app-anatomy.md +++ b/versioned_docs/version-0.52/learn/beginner/00-app-anatomy.md @@ -59,7 +59,7 @@ 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](../../build/building-apps/00-runtime.md)** 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. +* **Embedding [runtime.App](../../build/building-apps/00-runtime.md)** 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/v1.0/spec/abci/) and the [routing logic](../advanced/00-baseapp.md#service-routers). * It configures automatically the **[module manager](../../build/building-modules/01-module-manager.md#manager)** based on the app wiring configuration. The module manager facilitates operations related to these modules, like registering their [`Msg` service](../../build/building-modules/03-msg-services.md) 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**](../../build/building-apps/00-runtime.md) 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 contains as well at which order the modules `InitGenesis`, `Pre/Begin/EndBlocker` should be executed.