Merge branch 'main' into julien/export

docs/architecture/adr-065-store-v2.md

@@ -79,13 +79,11 @@ We propose to build upon some of the great ideas introduced in [ADR-040](./adr-0
 while being a bit more flexible with the underlying implementations and overall
 less intrusive. Specifically, we propose to:
 
-* Separate the concerns of state commitment (**SC**), needed for consensus, and
-  state storage (**SS**), needed for state machine and clients.
 * Reduce layers of abstractions necessary between the RMS and underlying stores.
 * Remove unnecessary store types and implementations such as `CacheKVStore`.
-* Simplify the branching logic.
+* Remove the branching logic from the store package.
 * Ensure the `RootStore` interface remains as lightweight as possible.
-* Allow application developers to easily swap out SS and SC backends.
+* Allow application developers to easily swap out SC backends.
 
 Furthermore, we will keep IAVL as the default [SC](https://cryptography.fandom.com/wiki/Commitment_scheme)
 backend for the time being. While we might not fully settle on the use of IAVL in
@@ -95,18 +93,12 @@ to change the backing commitment store in the future should evidence arise to
 warrant a better alternative. However there is promising work being done to IAVL
 that should result in significant performance improvement <sup>[1,2]</sup>.
 
-Note, we will provide applications with the ability to use IAVL v1 and IAVL v2 as
+Note, we will provide applications with the ability to use IAVL v1,  IAVL v2 and MemIAVL as
 either SC backend, with the latter showing extremely promising performance improvements
 over IAVL v0 and v1, at the cost of a state migration.
 
-### Separating SS and SC
 
-By separating SS and SC, it will allow for us to optimize against primary use cases
-and access patterns to state. Specifically, The SS layer will be responsible for
-direct access to data in the form of (key, value) pairs, whereas the SC layer (e.g. IAVL)
-will be responsible for committing to data and providing Merkle proofs.
-
-#### State Commitment (SC)
+### State Commitment (SC)
 
 A foremost design goal is that SC backends should be easily swappable, i.e. not
 necessarily IAVL.  To this end, the scope of SC has been reduced, it must only:
@@ -121,45 +113,6 @@ due to the time and space constraints, but since store v2 defines an API for his
 proofs there should be at least one configuration of a given SC backend which
 supports this.
 
-#### State Storage (SS)
-
-The goal of SS is to provide a modular storage backend, i.e. multiple implementations,
-to facilitate storing versioned raw key/value pairs in a fast embedded database.
-The responsibility and functions of SS include the following:
-
-* Provided fast and efficient queries for versioned raw key/value pairs
-* Provide versioned CRUD operations
-* Provide versioned batching functionality
-* Provide versioned iteration (forward and reverse) functionality
-* Provide pruning functionality
-
-All of the functionality provided by an SS backend should work under a versioned
-scheme, i.e. a user should be able to get, store, and iterate over keys for the latest
-and historical versions efficiently and a store key, which is used for name-spacing
-purposes.
-
-We propose to have three defaulting SS backends for applications to choose from:
-
-* RocksDB
-    * CGO based
-    * Usage of User-Defined Timestamps as a built-in versioning mechanism
-* PebbleDB
-    * Native
-    * Manual implementation of MVCC keys for versioning
-* SQLite
-    * CGO based
-    * Single table for all state
-
-Since operators might want pruning strategies to differ in SS compared to SC,
-e.g. having a very tight pruning strategy in SC while having a looser pruning
-strategy for SS, we propose to introduce an additional pruning configuration,
-with parameters that are identical to what exists in the SDK today, and allow
-operators to control the pruning strategy of the SS layer independently of the
-SC layer.
-
-Note, the SC pruning strategy must be congruent with the operator's state sync
-configuration. This is so as to allow state sync snapshots to execute successfully,
-otherwise, a snapshot could be triggered on a height that is not available in SC.
 
 #### State Sync
 
@@ -179,7 +132,7 @@ the primary interface for the application to interact with. The `RootStore` will
 be responsible for housing SS and SC backends. Specifically, a `RootStore` will
 provide the following functionality:
 
-* Manage commitment of state (both SS and SC)
+* Manage commitment of state 
 * Provide modules access to state
 * Query delegation (i.e. get a value for a <key, height> tuple)
 * Providing commitment proofs
@@ -197,12 +150,7 @@ solely provide key prefixing/namespacing functionality for modules.
 
 #### Proofs
 
-Since the SS layer is naturally a storage layer only, without any commitments
-to (key, value) pairs, it cannot provide Merkle proofs to clients during queries.
-
-So providing inclusion and exclusion proofs, via a `CommitmentOp` type, will be
-the responsibility of the SC backend. Retrieving proofs will be done through the
-a `RootStore`, which will internally route the request to the SC backend.
+Providing a `CommitmentOp` type, will be the responsibility of the SC backend. Retrieving proofs will be done through the a `RootStore`, which will internally route the request to the SC backend.
 
 #### Commitment
 
@@ -231,9 +179,6 @@ and storage backends for further performance, in addition to a reduced amount of
 abstraction around KVStores making operations such as caching and state branching
 more intuitive.
 
-However, due to the proposed design, there are drawbacks around providing state
-proofs for historical queries.
-
 ### Backwards Compatibility
 
 This ADR proposes changes to the storage implementation in the Cosmos SDK through
@@ -243,17 +188,14 @@ be broken or modified.
 
 ### Positive
 
-* Improved performance of independent SS and SC layers
+* Improved performance of SC layers
 * Reduced layers of abstraction making storage primitives easier to understand
-* Atomic commitments for SC
 * Redesign of storage types and interfaces will allow for greater experimentation
   such as different physical storage backends and different commitment schemes
   for different application modules
 
 ### Negative
 
-* Providing proofs for historical state is challenging
-
 ### Neutral
 
 * Removal of OCAP-based store keys in favor of simple strings for state retrieval

docs/build/building-apps/00-runtime.md

@@ -5,5 +5,23 @@ sidebar_position: 1
 # What is `runtime`?
 
 The `runtime` package is the Cosmos SDK package that combines the building blocks of your blockchain together. It wires together the modules, the applications, the codecs, and the stores.
+It is a layer of abstraction between `baseapp` and the application modules that simplifies the process of building a Cosmos SDK application.
 
+## Modules wiring
+
+Runtime is responsible for wiring the modules together. It uses `depinject` to inject the dependencies of the modules.
+
+## App wiring
+
+Runtime is the base boilerplate of a Cosmos SDK application.
 A user only needs to import `runtime` in their `app.go` and instantiate a `runtime.App`.
+
+## Services
+
+Modules have access to a multitude of services that are provided by the runtime.
+These services include the `store`, the `event manager`, the `context`, and the `logger`.
+As runtime is doing the wiring of modules, it can ensure that the services are scoped to their respective modules.
+
+```go reference
+https://github.com/cosmos/cosmos-sdk/blob/v0.52.0-beta.2/runtime/module.go#L250-L279
+```

docs/build/building-modules/00-intro.md

@@ -58,6 +58,13 @@ While there are no definitive guidelines for writing modules, here are some impo
 * **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](https://docs.cosmos.network/main/learn/advanced/ocap#ocaps-in-practice) 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`](./06-keeper.md). 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`.
 
+## Core APIs for Modules
+
+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. 
+
+Learn more about the core APIs for modules [here](../../learn/advanced/02-core.md).
+
 ## Main Components of Cosmos SDK Modules
 
 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:

docs/build/building-modules/01-module-manager.md

@@ -217,11 +217,9 @@ The module manager is used throughout the application whenever an action on a co
 * `InitGenesis(ctx context.Context, genesisData map[string]json.RawMessage)`: Calls the [`InitGenesis`](./08-genesis.md#initgenesis) function of each module when the application is first started, in the order defined in `OrderInitGenesis`. Returns an `abci.InitChainResponse` to the underlying consensus engine, which can contain validator updates.
 * `ExportGenesis(ctx context.Context)`: Calls the [`ExportGenesis`](./08-genesis.md#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, 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`](../../learn/advanced/00-baseapp.md#beginblock) and, in turn, calls the [`BeginBlock`](./06-preblock-beginblock-endblock.md) function of each modules implementing the `appmodule.HasBeginBlocker` interface, in the order defined in `OrderBeginBlockers`. It creates a child [context](../../learn/advanced/02-context.md) with an event manager to aggregate [events](../../learn/advanced/08-events.md) emitted from each modules.
-* `EndBlock(ctx context.Context) error`: At the end of each block, this function is called from [`BaseApp`](../../learn/advanced/00-baseapp.md#endblock) and, in turn, calls the [`EndBlock`](./06-preblock-beginblock-endblock.md) function of each modules implementing the `appmodule.HasEndBlocker` interface, in the order defined in `OrderEndBlockers`. It creates a child [context](../../learn/advanced/02-context.md) with an event manager to aggregate [events](../../learn/advanced/08-events.md) 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`](../../learn/advanced/00-baseapp.md#endblock) and, in turn, calls the [`EndBlock`](./06-preblock-beginblock-endblock.md) function of each modules implementing the `module.HasABCIEndBlock` interface, in the order defined in `OrderEndBlockers`. It creates a child [context](../../learn/advanced/02-context.md) with an event manager to aggregate [events](../../learn/advanced/08-events.md) 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`](../../learn/advanced/00-baseapp.md#commit), this function is called from `BaseApp` immediately before the [`deliverState`](../../learn/advanced/00-baseapp.md#state-updates) is written to the underlying [`rootMultiStore`](../../learn/advanced/04-store.md#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](../../learn/advanced/02-context.md) where the underlying `CacheMultiStore` is that of the newly committed block's [`finalizeblockstate`](../../learn/advanced/00-baseapp.md#state-updates).
-* `PrepareCheckState(ctx context.Context)`: During [`Commit`](../../learn/advanced/00-baseapp.md#commit), this function is called from `BaseApp` immediately after the [`deliverState`](../../learn/advanced/00-baseapp.md#state-updates) is written to the underlying [`rootMultiStore`](../../learn/advanced/04-store.md#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](../../learn/advanced/02-context.md) where the underlying `CacheMultiStore` is that of the next block's [`checkState`](../../learn/advanced/00-baseapp.md#state-updates). Writes to this state will be present in the [`checkState`](../../learn/advanced/00-baseapp.md#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`](../../learn/advanced/00-baseapp.md#beginblock) and, in turn, calls the [`BeginBlock`](./06-preblock-beginblock-endblock.md) function of each modules implementing the `appmodule.HasBeginBlocker` interface, in the order defined in `OrderBeginBlockers`.
+* `EndBlock(ctx context.Context) error`: At the end of each block, this function is called from [`BaseApp`](../../learn/advanced/00-baseapp.md#endblock) and, in turn, calls the [`EndBlock`](./06-preblock-beginblock-endblock.md) function of each modules implementing the `appmodule.HasEndBlocker` interface, in the order defined in `OrderEndBlockers`.
+* `EndBlock(context.Context) ([]abci.ValidatorUpdate, error)`: At the end of each block, this function is called from [`BaseApp`](../../learn/advanced/00-baseapp.md#endblock) and, in turn, calls the [`EndBlock`](./06-preblock-beginblock-endblock.md) function of each modules implementing the `appmodule.HasABCIEndBlock` interface, in the order defined in `OrderEndBlockers`. Extended implementation for modules that need to update the validator set (typically used by the staking module).
 * (Optional) `RegisterLegacyAminoCodec(cdc *codec.LegacyAmino)`: Registers the [`codec.LegacyAmino`s](../../learn/advanced/05-encoding.md#amino) of each of the application module. This function is usually called early on in the [application's construction](../../learn/beginner/00-app-anatomy.md#constructor).
 * `RegisterInterfaces(registry codectypes.InterfaceRegistry)`: Registers interface types and implementations of each of the application's `AppModule`.
 * (Optional) `RegisterGRPCGatewayRoutes(clientCtx client.Context, rtr *runtime.ServeMux)`: Registers gRPC routes for modules.

docs/build/building-modules/05-protobuf-annotations.md

@@ -2,9 +2,9 @@
 sidebar_position: 1
 ---
 
-# ProtocolBuffer Annotations
+# Protocol buffer Annotations
 
-This document explains the various protobuf scalars that have been added to make working with protobuf easier for Cosmos SDK application developers
+This document explains the various protobuf scalars that have been added to make working with protobuf easier for Cosmos SDK application developers.
 
 ## Signer
 
@@ -85,7 +85,7 @@ option (cosmos_proto.method_added_in) = "simapp v24.0.0";
 The amino codec was removed in `v0.50+`, this means there is not a need register `legacyAminoCodec`. To replace the amino codec, Amino protobuf annotations are used to provide information to the amino codec on how to encode and decode protobuf messages. 
 
 :::note
-Amino annotations are only used for backwards compatibility with amino. New modules are not required use amino annotations.
+Amino annotations are only used for backwards compatibility with amino.
 :::
 
 The below annotations are used to provide information to the amino codec on how to encode and decode protobuf messages in a backwards compatible manner.