docs: add a synopsis upgrade doc for 52 (backport #23097) (#23258)

Co-authored-by: Marko <[email protected]>
Co-authored-by: Julien Robert <[email protected]>

docs/architecture/adr-040-storage-and-smt-state-commitments.md

@@ -258,8 +258,6 @@ We change the storage layout of the state machine, a storage hard fork and netwo
 
 ## Alternative designs
 
-Most of the alternative designs were evaluated in [state commitments and storage report](https://paper.dropbox.com/published/State-commitments-and-storage-review--BDvA1MLwRtOx55KRihJ5xxLbBw-KeEB7eOd11pNrZvVtqUgL3h).
-
 Ethereum research published [Verkle Trie](https://dankradfeist.de/ethereum/2021/06/18/verkle-trie-for-eth1.html) - an idea of combining polynomial commitments with merkle tree in order to reduce the tree height. This concept has a very good potential, but we think it's too early to implement it. The current, SMT based design could be easily updated to the Verkle Trie once other research implement all necessary libraries. The main advantage of the design described in this ADR is the separation of state commitments from the data storage and designing a more powerful interface.
 
 ## Further Discussions
@@ -280,7 +278,6 @@ We were discussing use case where modules can use a support database, which is n
 
 * [IAVL What's Next?](https://github.com/cosmos/cosmos-sdk/issues/7100)
 * [IAVL overview](https://docs.google.com/document/d/16Z_hW2rSAmoyMENO-RlAhQjAG3mSNKsQueMnKpmcBv0/edit#heading=h.yd2th7x3o1iv) of its state v0.15
-* [State commitments and storage report](https://paper.dropbox.com/published/State-commitments-and-storage-review--BDvA1MLwRtOx55KRihJ5xxLbBw-KeEB7eOd11pNrZvVtqUgL3h)
 * [Celestia (LazyLedger) SMT](https://github.com/lazyledger/smt)
 * Facebook Diem (Libra) SMT [design](https://developers.diem.com/papers/jellyfish-merkle-tree/2021-01-14.pdf)
 * [Trillian Revocation Transparency](https://github.com/google/trillian/blob/master/docs/papers/RevocationTransparency.pdf), [Trillian Verifiable Data Structures](https://github.com/google/trillian/blob/master/docs/papers/VerifiableDataStructures.pdf).

docs/build/build.md

@@ -4,8 +4,8 @@ sidebar_position: 0
 
 # Build
 
-* [Building Apps](./building-apps/00-app-go.md) - The documentation in this section will guide you through the process of developing your dApp using the Cosmos SDK framework.
-* [Modules](./modules/README.md) - Information about the various modules available in the Cosmos SDK: Auth, Authz, Bank, Crisis, Distribution, Evidence, Feegrant, Governance, Mint, Params, Slashing, Staking, Upgrade, NFT, Consensus, Circuit, Genutil.
+* [Building Apps](./building-apps/00-runtime.md) - The documentation in this section will guide you through the process of developing your dApp using the Cosmos SDK framework.
+* [Modules](./modules/README.md) - Information about the various modules available in the Cosmos SDK: Accounts, Auth, Authz, Bank, Circuit, Consensus, Distribution, Epochs, Evidence, Feegrant, Genutil, Governance, Group, Mint, NFT, Protocolpool, Slashing, Staking, Tx, Upgrade, Validate.
 * [Migrations](./migrations/01-intro.md) - See what has been updated in each release the process of the transition between versions.
 * [Packages](./packages/README.md) - Explore a curated collection of pre-built modules and functionalities, streamlining the development process.
 * [Tooling](./tooling/README.md) - A suite of utilities designed to enhance the development workflow, optimizing the efficiency of Cosmos SDK-based projects.

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

@@ -134,7 +134,7 @@ An application only needs to call `AppBuilder.Build` to create a fully configure
 https://github.com/cosmos/cosmos-sdk/blob/v0.52.0-beta.2/runtime/builder.go#L36-L80
 ```
 
-More information on building applications can be found in the [next section](./02-app-building.md).
+More information on building applications can be found in the [next section](./02-app-go-di.md).
 
 ## Best Practices
 

docs/build/building-apps/upgrades/_category_.json

@@ -0,0 +1,5 @@
+{
+    "label": "Upgrade Tutorials",
+    "position": 0,
+    "link": null
+}

docs/build/building-modules/06-keeper.md

@@ -46,7 +46,7 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.52.0-beta.1/x/staking/keeper/keeper
 
 Let us go through the different parameters:
 
-* Environment is a struct that holds the necessary references to services available to the modules. This includes the [store services](../../advanced/04-store.md#store-services), the [event manager](../../learn/advanced/06-events.md) and more.
+* Environment is a struct that holds the necessary references to services available to the modules. This includes the [kvstore services](../../learn/advanced/02-core.md#kvstore-service), the [event manager](../../learn/advanced/02-core.md#event-service) and more.
 * 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.
 * `cdc` is the [codec](../../learn/advanced/05-encoding.md) used to marshal and unmarshal 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.

docs/build/building-modules/16-testing.md

@@ -61,7 +61,7 @@ The goal of these integration tests is to test how a component interacts with ot
 
 Integration tests interact with the tested module via the defined `Msg` and `Query` services. The result of the test can be verified by checking the state of the application, by checking the emitted events or the response. It is advised to combine two of these methods to verify the result of the test.
 
-The SDK provides small helpers for quickly setting up an integration tests. These helpers can be found at <https://github.com/cosmos/cosmos-sdk/blob/main/testutil/integration>.
+The SDK provides small helpers for quickly setting up an integration tests. These helpers can be found at <https://github.com/cosmos/cosmos-sdk/blob/main/testutil>.
 
 ### Example
 

docs/learn/advanced/00-baseapp.md

@@ -309,7 +309,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`. 
 
-The [`Context`](../advanced/02-context.md), which includes a `GasMeter` that tracks how much gas is used during the execution of `Tx`, is initialized at the beginning of `CheckTx`. The user-provided amount of gas for `Tx` is referred to as `GasWanted`. If `GasConsumed`, the amount of gas used during execution, exceeds `GasWanted`, the execution is halted and the changes made to the cached copy of the state are not committed. Otherwise, `CheckTx` sets `GasUsed` equal to `GasConsumed` and returns it in the result. After calculating the gas and fee values, validator-nodes ensure that the user-specified `gas-prices` exceed their locally defined `min-gas-prices`.
+The [`Core pkg`](../advanced/02-core.md), which includes a `GasService` that tracks how much gas is used during the execution of `Tx`, is initialized at the beginning of `CheckTx`. The user-provided amount of gas for `Tx` is referred to as `GasWanted`. If `GasConsumed`, the amount of gas used during execution, exceeds `GasWanted`, the execution is halted and the changes made to the cached copy of the state are not committed. Otherwise, `CheckTx` sets `GasUsed` equal to `GasConsumed` and returns it in the result. After calculating the gas and fee values, validator-nodes ensure that the user-specified `gas-prices` exceed their locally defined `min-gas-prices`.
 
 In the Cosmos SDK, after [decoding transactions](./05-encoding.md), `CheckTx()` is implemented
 to do the following checks:

docs/learn/advanced/04-store.md

@@ -189,12 +189,6 @@ When methods of the parent `KVStore` are called, `GasKv.Store` automatically con
 https://github.com/cosmos/cosmos-sdk/blob/store/v1.1.1/store/types/gas.go#L220-L229
 ```
 
-By default, all `KVStores` are wrapped in `GasKv.Stores` when retrieved. This is done in the `KVStore()` method of the [`context`](./02-context.md):
-
-```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.52.0-beta.2/types/context.go#L339-L342
-```
-
 `KVStores` can be accessed in their corresponding modules by using the [`kvStoreService` and `memStoreService`](./02-core.md#kvstore-service).
 
 ### `TraceKv` Store

docs/user/run-node/06-run-production.md

@@ -48,7 +48,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](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.