chore: update documenation from cosmos-sdk/docs (#167)

docs/build/architecture/PROCESS.md

@@ -2,7 +2,7 @@
 
 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.
+3. Make sure the context and solution is clear and well documented.
 4. Add an entry to a list in the [README](./README.md) file.
 5. Create a Pull Request to propose a new ADR.
 

docs/build/architecture/adr-004-split-denomination-keys.md

@@ -74,7 +74,7 @@ This will result in the balances being indexed by the byte representation of
 
 `DelegateCoins()` and `UndelegateCoins()` will be altered to only load each individual
 account balance by denomination found in the (un)delegation amount. As a result,
-any mutations to the account balance by will made by denomination.
+any mutations to the account balance will made by denomination.
 
 `SubtractCoins()` and `AddCoins()` will be altered to read & write the balances
 directly instead of calling `GetCoins()` / `SetCoins()` (which no longer exist).

docs/build/architecture/adr-008-dCERT-group.md

@@ -113,7 +113,7 @@ tokens, then the tokens are no longer staked and unable to be slashed.
 
 Additionally in the case of an emergency situation of a colluding and malicious
 dCERT group, the community needs the capability to disband the entire dCERT
-group and likely fully slash them. This could be achieved though a special new
+group and likely fully slash them. This could be achieved through a special new
 proposal type (implemented as a general governance proposal) which would halt
 the functionality of the dCERT group until the proposal was concluded. This
 special proposal type would likely need to also have a fairly large wager which

docs/build/architecture/adr-043-nft-module.md

@@ -253,7 +253,7 @@ message QuerySupplyResponse {
   uint64 amount = 1;
 }
 
-// QueryNFTstRequest is the request type for the Query/NFTs RPC method
+// QueryNFTsRequest is the request type for the Query/NFTs RPC method
 message QueryNFTsRequest {
   string                                class_id   = 1;
   string                                owner      = 2;

docs/build/architecture/adr-070-unordered-transactions.md

@@ -261,15 +261,35 @@ func (d *DedupTxDecorator) AnteHandle(ctx sdk.Context, tx sdk.Tx, simulate bool,
     return nil, errorsmod.Wrapf(sdkerrors.ErrLogic, "unordered tx ttl exceeds %d", d.maxUnOrderedTTL)
   }
 
+  	// in order to create a deterministic hash based on the tx, we need to hash the contents of the tx with signature
+	// Get a Buffer from the pool
+	buf := bufPool.Get().(*bytes.Buffer)
+	// Make sure to reset the buffer
+	buf.Reset()
+
+	// Use the buffer
+	for _, msg := range tx.GetMsgs() {
+		// loop through the messages and write them to the buffer
+		// encoding the msg to bytes makes it deterministic within the state machine.
+		// Malleability is not a concern here because the state machine will encode the transaction deterministically.
+		bz, err := proto.Marshal(msg)
+		if err != nil {
+			return ctx, errorsmod.Wrap(sdkerrors.ErrInvalidRequest, "failed to marshal message")
+		}
+
+		buf.Write(bz)
+	}
+
   // check for duplicates
-  if d.m.Contains(tx.Hash()) {
-    return nil, errorsmod.Wrap(sdkerrors.ErrLogic, "tx is duplicated")
-  }
+ 	// check for duplicates
+	if d.txManager.Contains(txHash) {
+		return ctx, errorsmod.Wrap(sdkerrors.ErrInvalidRequest, "tx %X is duplicated")
+	}
 
-  if !ctx.IsCheckTx() {
-    // a new tx included in the block, add the hash to the unordered tx manager
-    d.m.Add(tx.Hash(), tx.TimeoutHeight())
-  }
+	if d.env.TransactionService.ExecMode(ctx) == transaction.ExecModeFinalize {
+		// a new tx included in the block, add the hash to the unordered tx manager
+		d.txManager.Add(txHash, ttl)
+	}
 
   return next(ctx, tx, simulate)
 }
@@ -282,10 +302,7 @@ encoding is not malleable. If a given transaction, which is otherwise valid, can
 be encoded to produce different hashes, which reflect the same valid transaction,
 then a duplicate unordered transaction can be submitted and included in a block.
 
-In order to prevent this, transactions should be encoded in a deterministic manner.
-[ADR-027](./adr-027-deterministic-protobuf-serialization.md) provides such a mechanism.
-However, it is important to note that the way a transaction is signed should ensure
-ADR-027 is followed. E.g. we want to avoid Amino signing.
+In order to prevent this, the decoded transaction contents is taken. Starting with the content of the transaction we marshal the transaction in order to prevent a client reordering the transaction. Next we include the gas and timeout height as part of the identifier. All these fields are signed over in the transaction payload. If one of them changes the signature will not match the transaction. 
 
 ### State Management
 

docs/build/building-apps/02-app-mempool.md

@@ -42,7 +42,7 @@ baseAppOptions = append(baseAppOptions, mempoolOpt)
 ### No-op Mempool
 
 A no-op mempool is a mempool where transactions are completely discarded and ignored when BaseApp interacts with the mempool.
-When this mempool is used, it assumed that an application will rely on CometBFT's transaction ordering defined in `RequestPrepareProposal`,
+When this mempool is used, it is assumed that an application will rely on CometBFT's transaction ordering defined in `RequestPrepareProposal`,
 which is FIFO-ordered by default.
 
 > Note: If a NoOp mempool is used, PrepareProposal and ProcessProposal both should be aware of this as

docs/build/building-apps/03-app-upgrade.md

@@ -22,7 +22,7 @@ This section is currently incomplete. Track the progress of this document [here]
 
 Let's assume we are running v0.38.0 of our software in our testnet and want to upgrade to v0.40.0.
 How would this look in practice? First of all, we want to finalize the v0.40.0 release candidate
-and there install a specially named upgrade handler (eg. "testnet-v2" or even "v0.40.0"). An upgrade
+and then install a specially named upgrade handler (eg. "testnet-v2" or even "v0.40.0"). An upgrade
 handler should be defined in a new version of the software to define what migrations
 to run to migrate from the older version of the software. Naturally, this is app-specific rather
 than module specific, and  must be defined in `app.go`, even if it imports logic from various

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

@@ -30,9 +30,8 @@ There are 2 main application module interfaces:
 
 The above interfaces are mostly embedding smaller interfaces (extension interfaces), that defines specific functionalities:
 
-<!-- TO UPDATE - THIS IS SEVERELY OUTDATED -->
+<!-- TO UPDATE - THIS IS SEVERELY OUTDATED appmodule / appmodulev2-->
 
-* (legacy) `module.HasName`: Allows the module to provide its own name for legacy purposes.
 * (legacy) [`module.HasGenesisBasics`](#modulehasgenesisbasics): The legacy interface for stateless genesis methods.
 * (legacy) [`module.HasGenesis`](#modulehasgenesis) for inter-dependent genesis-related module functionalities.
 * (legacy) [`module.HasABCIGenesis`](#modulehasabcigenesis) for inter-dependent genesis-related module functionalities.
@@ -72,19 +71,10 @@ https://github.com/cosmos/cosmos-sdk/blob/eee5e21e1c8d0995b6d4f83b7f55ec0b58d27b
 
 * `RegisterGRPCGatewayRoutes(client.Context, *runtime.ServeMux)`: Registers gRPC routes for the module.
 
-
-### `HasName`
-
-```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/types/module/module.go#L71-L73
-```
-
-* `HasName` is an interface that has a method `Name()`. This method returns the name of the module as a `string`.
-
 ### Genesis
 
 :::tip
-For easily creating an `AppModule` that only has genesis functionalities, implement `module.HasGenesis/HasABCIGenesis` and `module.HasName`.
+For easily creating an `AppModule` that only has genesis functionalities, implement `module.HasGenesis/HasABCIGenesis`.
 :::
 
 #### `module.HasGenesisBasics`

docs/build/modules/README.md

@@ -9,21 +9,22 @@ Here are some production-grade modules that can be used in Cosmos SDK applicatio
 * [Auth](./auth/README.md) - Authentication of accounts and transactions for Cosmos SDK applications.
 * [Authz](./authz/README.md) - Authorization for accounts to perform actions on behalf of other accounts.
 * [Bank](./bank/README.md) - Token transfer functionalities.
+* [Circuit](./circuit/README.md) - Circuit breaker module for pausing messages.
+* [Consensus](./consensus/README.md) - Consensus module for modifying CometBFT's ABCI consensus params.
 * [Distribution](./distribution/README.md) - Fee distribution, and staking token provision distribution.
 * [Epochs](./epochs/README.md) - Allow other modules to set that they would like to be signaled once every period
 * [Evidence](./evidence/README.md) - Evidence handling for double signing, misbehaviour, etc.
 * [Feegrant](./feegrant/README.md) - Grant fee allowances for executing transactions.
+* [Genutil](./genutil/README.md) - Genesis utilities for the Cosmos SDK.
 * [Governance](./gov/README.md) - On-chain proposals and voting.
 * [Mint](./mint/README.md) - Creation of new units of staking token.
+* [NFT](./nft/README.md) - NFT module implemented based on [ADR43](https://docs.cosmos.network/main/build/architecture/adr-043-nft-module).
 * [Params](./params/README.md) - Globally available parameter store.
 * [Protocolpool](./protocolpool/README.md) - Functionalities handling community pool funds.
 * [Slashing](./slashing/README.md) - Validator punishment mechanisms.
 * [Staking](./staking/README.md) - Proof-of-Stake layer for public blockchains.
+* [tx](./tx/README.md) - Tx utilities for the Cosmos SDK.
 * [Upgrade](./upgrade/README.md) - Software upgrades handling and coordination.
-* [NFT](./nft/README.md) - NFT module implemented based on [ADR43](https://docs.cosmos.network/main/build/architecture/adr-043-nft-module).
-* [Consensus](./consensus/README.md) - Consensus module for modifying CometBFT's ABCI consensus params.
-* [Circuit](./circuit/README.md) - Circuit breaker module for pausing messages.
-* [Genutil](./genutil/README.md) - Genesis utilities for the Cosmos SDK.
 
 To learn more about the process of building modules, visit the [building modules reference documentation](https://docs.cosmos.network/main/building-modules/intro).
 

docs/build/rfc/PROCESS.md

@@ -1,34 +1,34 @@
 # 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](./README.md) file.
-5. Create a Pull Request to propose a new ADR.
+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](./README.md) file.
+5. Create a Pull Request to propose a new RFC.
 
 ## What is an RFC?
 
-An RFC is a sort of async whiteboarding session. It is meant to replace the need for a distributed team to come together to make a decision. Currently, the Cosmos SDK team and contributors are distributed around the world. The team conducts working groups to have a synchronous discussion and an RFC can be used to capture the discussion for a wider audience to better understand the changes that are coming to the software. 
+An RFC is a sort of async whiteboarding session. It is meant to replace the need for a distributed team to come together to decide. Currently, the Cosmos SDK team and contributors are distributed around the world. The team conducts working groups to have a synchronous discussion, and an RFC can be used to capture the discussion for a wider audience to better understand the changes that are coming to the software.
 
-The main difference the Cosmos SDK is defining as a differentiation between RFC and ADRs is that one is to come to consensus and circulate information about a potential change or feature. An ADR is used if there is already consensus on a feature or change and there is not a need to articulate the change coming to the software. An ADR will articulate the changes and have a lower amount of communication .   
+The main difference the Cosmos SDK defines between RFCs and ADRs is that an RFC is to come to consensus and circulate information about a potential change or feature. An ADR is used if there is already consensus on a feature or change and there is no need to articulate the change coming to the software. An ADR will articulate the changes and require less communication.
 
 ## RFC life cycle
 
-RFC creation is an **iterative** process. An RFC is meant as a distributed collaboration session, it may have many comments and is usually the bi-product of no working group or synchronous communication 
+RFC creation is an **iterative** process. An RFC is meant as a distributed collaboration session, it may have many comments and is usually the by-product of no working group or synchronous communication.
 
-1. Proposals could start with a new GitHub Issue,  be a result of existing Issues or a discussion.
+1. Proposals could start with a new GitHub Issue, be a result of existing Issues or a discussion.
 
 2. An RFC doesn't have to arrive to `main` with an _accepted_ status in a single PR. If the motivation is clear and the solution is sound, we SHOULD be able to merge it and keep a _proposed_ status. It's preferable to have an iterative approach rather than long, not merged Pull Requests.
 
 3. If a _proposed_ RFC is merged, then it should clearly document outstanding issues either in the RFC document notes or in a GitHub Issue.
 
-4. The PR SHOULD always be merged. In the case of a faulty RFC, we still prefer to  merge it with a _rejected_ status. The only time the RFC SHOULD NOT be merged is if the author abandons it.
+4. The PR SHOULD always be merged. In the case of a faulty RFC, we still prefer to merge it with a _rejected_ status. The only time the RFC SHOULD NOT be merged is if the author abandons it.
 
 5. Merged RFCs SHOULD NOT be pruned.
 
-6. If there is consensus and enough feedback then the RFC can be accepted. 
+6. If there is consensus and enough feedback then the RFC can be accepted.
 
-> Note: An RFC is written when there is no working group or team session on the problem. RFC's are meant as a distributed white boarding session. If there is a working group on the proposal there is no need to have an RFC as there is synchronous whiteboarding going on. 
+> Note: An RFC is written when there is no working group or team session on the problem. RFCs are meant as a distributed whiteboarding session. If there is a working group on the proposal, there is no need to have an RFC as there is synchronous whiteboarding going on.
 
 ### RFC status
 
@@ -41,22 +41,22 @@ Status has two components:
 #### Consensus Status
 
 ```text
-DRAFT -> PROPOSED -> LAST CALL yyyy-mm-dd -> ACCEPTED | REJECTED -> SUPERSEDED by ADR-xxx
+DRAFT -> PROPOSED -> LAST CALL yyyy-mm-dd -> ACCEPTED | REJECTED -> SUPERSEDED by RFC-xxx
                   \        |
                    \       |
                     v      v
                      ABANDONED
 ```
 
-* `DRAFT`: [optional] an ADR which is work in progress, not being ready for a general review. This is to present an early work and get an early feedback in a Draft Pull Request form.
-* `PROPOSED`: an ADR covering a full solution architecture and still in the review - project stakeholders haven't reached an agreed yet.
-* `LAST CALL <date for the last call>`: [optional] clear notify that we are close to accept updates. Changing a status to `LAST CALL` means that social consensus (of Cosmos SDK maintainers) has been reached and we still want to give it a time to let the community react or analyze.
-* `ACCEPTED`: ADR which will represent a currently implemented or to be implemented architecture design.
-* `REJECTED`: ADR can go from PROPOSED or ACCEPTED to rejected if the consensus among project stakeholders will decide so.
-* `SUPERSEDED by ADR-xxx`: ADR which has been superseded by a new ADR.
-* `ABANDONED`: the ADR is no longer pursued by the original authors.
+* `DRAFT`: [optional] an RFC which is work in progress, not being ready for a general review. This is to present early work and get early feedback in a Draft Pull Request form.
+* `PROPOSED`: an RFC covering a full solution architecture and still in review - project stakeholders haven't reached an agreement yet.
+* `LAST CALL <date for the last call>`: [optional] clearly notify that we are close to accepting updates. Changing a status to `LAST CALL` means that social consensus (of Cosmos SDK maintainers) has been reached, and we still want to give it time to let the community react or analyze.
+* `ACCEPTED`: RFC which will represent a currently implemented or to be implemented architecture design.
+* `REJECTED`: RFC can go from PROPOSED or ACCEPTED to rejected if the consensus among project stakeholders decides so.
+* `SUPERSEDED by RFC-xxx`: RFC which has been superseded by a new RFC.
+* `ABANDONED`: the RFC is no longer pursued by the original authors.
 
 ## Language used in RFC
 
 * The background/goal should be written in the present tense.
-* Avoid using a first, personal form.
+* Avoid using a first-person form.

docs/learn/advanced/00-baseapp.md

@@ -146,7 +146,7 @@ To avoid unnecessary roundtrip to the main state, all reads to the branched stor
 
 ### CheckTx State Updates
 
-During `CheckTx`, the `checkState`, which is based off of the last committed state from the root
+During `CheckTx`, the `checkState`, which is based on the last committed state from the root
 store, is used for any reads and writes. Here we only execute the `AnteHandler` and verify a service router
 exists for every message in the transaction. Note, when we execute the `AnteHandler`, we branch
 the already branched `checkState`.

docs/learn/advanced/07-cli.md

@@ -182,7 +182,7 @@ this will be more convenient:
 
 ```shell
 # define env variables in .env, .envrc etc
-NODE_HOME=<path to home>
+GAIA_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

@@ -163,7 +163,7 @@ this will be more convenient:
 
 ```shell
 # define env variables in .env, .envrc etc
-NODE_HOME=<path to home>
+GAIA_HOME=<path to home>
 GAIA_NODE=<node address>
 GAIA_CHAIN_ID="testchain-1"
 GAIA_KEYRING_BACKEND="test"