chore: upate documenation from cosmos-sdk/docs (#159)

chore: Sync docs from cosmos-sdk/docs

Co-authored-by: tac0turtle <[email protected]>
Co-authored-by: samricotta <[email protected]>

docs/build/building-apps/01-app-go-v2.md

@@ -7,13 +7,13 @@ sidebar_position: 1
 :::note Synopsis
 
 The Cosmos SDK allows much easier wiring of an `app.go` thanks to App Wiring and [`depinject`](../packages/01-depinject.md).
-Learn more about the rationale of App Wiring in [ADR-057](../../architecture/adr-057-app-wiring.md).
+Learn more about the rationale of App Wiring in [ADR-057](../architecture/adr-057-app-wiring.md).
 
 :::
 
 :::note Pre-requisite Readings
 
-* [ADR 057: App Wiring](../../architecture/adr-057-app-wiring.md)
+* [ADR 057: App Wiring](../architecture/adr-057-app-wiring.md)
 * [Depinject Documentation](../packages/01-depinject.md)
 * [Modules depinject-ready](../building-modules/15-depinject.md)
 

docs/build/building-modules/03-msg-services.md

@@ -19,7 +19,7 @@ A Protobuf `Msg` service processes [messages](./02-messages-and-queries.md#messa
 
 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](../../architecture/adr-031-msg-service.md), this approach has the advantage of clearly specifying return types and generating server and client code.
+As further described in [ADR 031](../architecture/adr-031-msg-service.md), this approach has the advantage of clearly specifying return types and generating server and client code.
 
 Protobuf generates a `MsgServer` interface based on the 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 `transaction.Msg`. As an example, here is the generated `MsgServer` interface for `x/bank`, which exposes two `transaction.Msg`s:
 
@@ -33,7 +33,7 @@ When possible, the existing module's [`Keeper`](./06-keeper.md) should implement
 https://github.com/cosmos/cosmos-sdk/blob/28fa3b8/x/bank/keeper/msg_server.go#L16-L19
 ```
 
-`msgServer` methods can retrieve the auxillary information or services using the environment variable, it is always located in the keeper:
+`msgServer` methods can retrieve the auxiliary information or services using the environment variable, it is always located in the keeper:
 
 Environment: 
 

docs/build/building-modules/11-structure.md

@@ -83,7 +83,7 @@ x/{module_name}
 * `module/`: The module's `AppModule` implementation.
     * `autocli.go`: The module [autocli](https://docs.cosmos.network/main/core/autocli) options.
 * `simulation/`: The module's [simulation](./14-simulator.md) package defines functions used by the blockchain simulator application (`simapp`).
-* `README.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](../../spec/SPEC_MODULE.md).
+* `README.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](../spec/SPEC_MODULE.md).
 * 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.

docs/build/building-modules/13-upgrade.md

@@ -62,4 +62,4 @@ func (m Migrator) Migrate1to2(ctx sdk.Context) 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.50.0-alpha.0/x/bank/migrations/v2/store.go#L55-L76). 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](../../architecture/adr-028-public-key-addresses.md).
+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.50.0-alpha.0/x/bank/migrations/v2/store.go#L55-L76). 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](../architecture/adr-028-public-key-addresses.md).

docs/build/building-modules/17-preblock.md

@@ -21,4 +21,4 @@ There are two semantics around the new lifecycle method:
 * It runs before the `BeginBlocker` of all modules
 * It can modify consensus parameters in storage, and signal the caller through the return value.
 
-Modules are required to get the consensus params from the consensus module. Consensus params located in `sdk.Context` were depreacted and should be treated as unsafe. `sdk.Context` is deprecated due to it being a global state within the entire state machine, it has been replaced with `appmodule.Environment`.
+Modules are required to get the consensus params from the consensus module. Consensus params located in `sdk.Context` were deprecated and should be treated as unsafe. `sdk.Context` is deprecated due to it being a global state within the entire state machine, it has been replaced with `appmodule.Environment`.

docs/learn/advanced/07-cli.md

@@ -172,7 +172,7 @@ Flags are added to commands directly (generally in the [module's CLI file](../..
 
 ## Environment variables
 
-Each flag is bound to its respective named environment variable. Then name of the environment variable consist of two parts - capital case `basename` followed by flag name of the flag. `-` must be substituted with `_`. For example flag `--home` for application with basename `GAIA` is bound to `GAIA_HOME`. It allows reducing the amount of flags typed for routine operations. For example instead of:
+Each flag is bound to its respective named environment variable. Then name of the environment variable consist of two parts - capital case `basename` followed by flag name of the flag. `-` must be substituted with `_`. For example flag `--node` for application with basename `GAIA` is bound to `GAIA_NODE`. It allows reducing the amount of flags typed for routine operations. For example instead of:
 
 ```shell
 gaia --home=./ --node=<node address> --chain-id="testchain-1" --keyring-backend=test tx ... --from=<key name>
@@ -182,7 +182,7 @@ this will be more convenient:
 
 ```shell
 # define env variables in .env, .envrc etc
-GAIA_HOME=<path to home>
+NODE_HOME=<path to home>
 GAIA_NODE=<node address>
 GAIA_CHAIN_ID="testchain-1"
 GAIA_KEYRING_BACKEND="test"

versioned_docs/version-0.50/learn/advanced/07-cli.md

@@ -153,7 +153,7 @@ Flags are added to commands directly (generally in the [module's CLI file](../..
 
 ## Environment variables
 
-Each flag is bound to its respective named environment variable. Then name of the environment variable consist of two parts - capital case `basename` followed by flag name of the flag. `-` must be substituted with `_`. For example flag `--home` for application with basename `GAIA` is bound to `GAIA_HOME`. It allows reducing the amount of flags typed for routine operations. For example instead of:
+Each flag is bound to its respective named environment variable. Then name of the environment variable consist of two parts - capital case `basename` followed by flag name of the flag. `-` must be substituted with `_`. For example flag `--node` for application with basename `GAIA` is bound to `GAIA_NODE`. It allows reducing the amount of flags typed for routine operations. For example instead of:
 
 ```shell
 gaia --home=./ --node=<node address> --chain-id="testchain-1" --keyring-backend=test tx ... --from=<key name>
@@ -163,7 +163,7 @@ this will be more convenient:
 
 ```shell
 # define env variables in .env, .envrc etc
-GAIA_HOME=<path to home>
+NODE_HOME=<path to home>
 GAIA_NODE=<node address>
 GAIA_CHAIN_ID="testchain-1"
 GAIA_KEYRING_BACKEND="test"