docs: fix typos and wording in learn and README docs (#25668)

Author: maradini77

blockstm/README.md

@@ -38,4 +38,4 @@ The internal data structures are also adapted with multiple stores in mind.
 
 ### Attribution
 
-This package was originally authored in [go-block-stm](https://github.com/crypto-org-chain/go-block-stm). We have brought the full source tree into the SDK so that we can natively incorporate the library and required changes into the SDK. Over time we expect to incoporate optimizations and deviations from the upstream implementation.
+This package was originally authored in [go-block-stm](https://github.com/crypto-org-chain/go-block-stm). We have brought the full source tree into the SDK so that we can natively incorporate the library and required changes into the SDK. Over time we expect to incorporate optimizations and deviations from the upstream implementation.

blockstm/utils.go

@@ -37,7 +37,7 @@ func IncrAtomic(a *atomic.Uint64) {
 	a.Add(1)
 }
 
-// FetchIncr increaes the atomic value by 1 and returns the old value
+// FetchIncr increases the atomic value by 1 and returns the old value
 func FetchIncr(a *atomic.Uint64) uint64 {
 	return a.Add(1) - 1
 }

client/v2/autocli/query_test.go

@@ -339,7 +339,7 @@ func TestMap(t *testing.T) {
 	assert.ErrorContains(t, err, "invalid argument \"bar=123.9\" for \"--map-string-uint32\" flag: strconv.ParseUint: parsing \"123.9\": invalid syntax")
 }
 
-// TestEveything tests all the different types of flags are correctly read and as well as correctly returned
+// TestEverything tests all the different types of flags are correctly read and as well as correctly returned
 // This tests the flag binding and the message building
 func TestEverything(t *testing.T) {
 	fixture := initFixture(t)

docs/README.md

@@ -6,7 +6,7 @@ The documentation for Cosmos SDK is hosted at https://docs.cosmos.network and bu
 It is built using the following stack:
 
 * [Docusaurus 2](https://docusaurus.io)
-* Vuepress (pre v0.47)
+* VuePress (pre v0.47)
 * [Algolia DocSearch](https://docsearch.algolia.com/)
 
   ```js
@@ -23,11 +23,11 @@ It is built using the following stack:
 ## Docs Build Workflow
 
 The docs are built and deployed automatically on GitHub Pages by a [GitHub Action workflow](../.github/workflows/build-docs.yml).
-The workflow is triggered on every push to the `main` and `release/v**` branches, every time documentations or specs are modified.
+The workflow is triggered on every push to the `main` and `release/v**` branches, every time documentation or specs are modified.
 
 ### How It Works
 
-There is a GitHub Action listening for changes in the `/docs` directory for the `main` branch and each supported version branch (e.g. `release/v0.46.x`). Any updates to files in the `/docs` directory will automatically trigger a website deployment. Under the hood, the private website repository has a `make build-docs` target consumed by a Github Action within that repository.
+There is a GitHub Action listening for changes in the `/docs` directory for the `main` branch and each supported version branch (e.g. `release/v0.46.x`). Any updates to files in the `/docs` directory will automatically trigger a website deployment. Under the hood, the private website repository has a `make build-docs` target consumed by a GitHub Action within that repository.
 
 ## How to Build the Docs Locally
 
@@ -47,7 +47,7 @@ npm start
 It runs `pre.sh` scripts to get all the docs that are not already in the `docs/docs` folder.
 It also runs `post.sh` scripts to clean up the docs and remove unnecessary files when quitting.
 
-Note, the command above only build the docs for the current versions.
+Note, the command above only builds the docs for the current versions.
 With the drawback that none of the redirections works. So, you'll need to go to /main to see the docs.
 
 To build all the docs (including versioned documentation), run:
@@ -56,7 +56,7 @@ To build all the docs (including versioned documentation), run:
 make build-docs
 ```
 
-## What to for new major SDK versions
+## What to do for new major SDK versions
 
 When a new major version of the SDK is released, the following steps should be taken:
 
@@ -75,6 +75,6 @@ When a new major version of the SDK is released, the following steps should be t
 
 * Add the new version sidebar to the list of versioned sidebar and add the version to `versions.json`.
 * Update the latest version (`presets[1].docs.lastVersion`) in `docusaurus.config.js`.
-* Add the new version with in `presets[1].docs.versions` in `docusaurus.config.js`.
+* Add the new version within `presets[1].docs.versions` in `docusaurus.config.js`.
 
 Learn more about [versioning](https://docusaurus.io/docs/versioning) in Docusaurus.

docs/docs/learn/advanced/00-baseapp.md

@@ -234,10 +234,10 @@ The [Application-Blockchain Interface](https://github.com/cometbft/cometbft/blob
 
 The consensus engine handles two main tasks:
 
-* The networking logic, which mainly consists in gossiping block parts, transactions and consensus votes.
+* The networking logic, which mainly consists of gossiping block parts, transactions and consensus votes.
 * The consensus logic, which results in the deterministic ordering of transactions in the form of blocks.
 
-It is **not** the role of the consensus engine to define the state or the validity of transactions. Generally, transactions are handled by the consensus engine in the form of `[]bytes`, and relayed to the application via the ABCI to be decoded and processed. At keys moments in the networking and consensus processes (e.g. beginning of a block, commit of a block, reception of an unconfirmed transaction, ...), the consensus engine emits ABCI messages for the state-machine to act on.
+It is **not** the role of the consensus engine to define the state or the validity of transactions. Generally, transactions are handled by the consensus engine in the form of `[]bytes`, and relayed to the application via the ABCI to be decoded and processed. At key moments in the networking and consensus processes (e.g. beginning of a block, commit of a block, reception of an unconfirmed transaction, ...), the consensus engine emits ABCI messages for the state-machine to act on.
 
 Developers building on top of the Cosmos SDK need not implement the ABCI themselves, as `BaseApp` comes with a built-in implementation of the interface. Let us go through the main ABCI messages that `BaseApp` implements:
 

docs/docs/learn/advanced/01-transactions.md

@@ -83,7 +83,7 @@ need to sign over the fees:
 https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/proto/cosmos/tx/v1beta1/tx.proto#L68-L93
 ```
 
-The use case is a multi-signer transaction, where one of the signers is appointed to gather all signatures, broadcast the signature and pay for fees, and the others only care about the transaction body. This generally allows for a better multi-signing UX. If Alice, Bob and Charlie are part of a 3-signer transaction, then Alice and Bob can both use `SIGN_MODE_DIRECT_AUX` to sign over the `TxBody` and their own signer info (no need an additional step to gather other signers' ones, like in `SIGN_MODE_DIRECT`), without specifying a fee in their SignDoc. Charlie can then gather both signatures from Alice and Bob, and
+The use case is a multi-signer transaction, where one of the signers is appointed to gather all signatures, broadcast the signature and pay for fees, and the others only care about the transaction body. This generally allows for a better multi-signing UX. If Alice, Bob and Charlie are part of a 3-signer transaction, then Alice and Bob can both use `SIGN_MODE_DIRECT_AUX` to sign over the `TxBody` and their own signer info (no need for an additional step to gather other signers' ones, like in `SIGN_MODE_DIRECT`), without specifying a fee in their SignDoc. Charlie can then gather both signatures from Alice and Bob, and
 create the final transaction by appending a fee. Note that the fee payer of the transaction (in our case Charlie) must sign over the fees, so must use `SIGN_MODE_DIRECT` or `SIGN_MODE_LEGACY_AMINO_JSON`.
 
 
@@ -128,7 +128,7 @@ While messages contain the information for state transition logic, a transaction
 
 ### Transaction Generation
 
-The `TxBuilder` interface contains data closely related with the generation of transactions, which an end-user can set to generate the desired transaction:
+The `TxBuilder` interface contains data closely related to the generation of transactions, which an end-user can set to generate the desired transaction:
 
 ```go reference
 https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/client/tx_config.go#L39-L57

docs/docs/learn/beginner/00-app-anatomy.md

@@ -147,7 +147,7 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/simapp/params/encoding.go#L9-L
 
 Here are descriptions of what each of the four fields means:
 
-* `InterfaceRegistry`: The `InterfaceRegistry` is used by the Protobuf codec to handle interfaces that are encoded and decoded (we also say "unpacked") using [`google.protobuf.Any`](https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/any.proto). `Any` could be thought as a struct that contains a `type_url` (name of a concrete type implementing the interface) and a `value` (its encoded bytes). `InterfaceRegistry` provides a mechanism for registering interfaces and implementations that can be safely unpacked from `Any`. Each application module implements the `RegisterInterfaces` method that can be used to register the module's own interfaces and implementations.
+* `InterfaceRegistry`: The `InterfaceRegistry` is used by the Protobuf codec to handle interfaces that are encoded and decoded (we also say "unpacked") using [`google.protobuf.Any`](https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/any.proto). `Any` could be thought of as a struct that contains a `type_url` (name of a concrete type implementing the interface) and a `value` (its encoded bytes). `InterfaceRegistry` provides a mechanism for registering interfaces and implementations that can be safely unpacked from `Any`. Each application module implements the `RegisterInterfaces` method that can be used to register the module's own interfaces and implementations.
     * You can read more about `Any` in [ADR-019](../../build/architecture/adr-019-protobuf-state-encoding.md).
     * To go more into details, the Cosmos SDK uses an implementation of the Protobuf specification called [`gogoprotobuf`](https://github.com/cosmos/gogoproto). By default, the [gogo protobuf implementation of `Any`](https://pkg.go.dev/github.com/cosmos/gogoproto/types) uses [global type registration](https://github.com/cosmos/gogoproto/blob/master/proto/properties.go#L540) to decode values packed in `Any` into concrete Go types. This introduces a vulnerability where any malicious module in the dependency tree could register a type with the global protobuf registry and cause it to be loaded and unmarshaled by a transaction that referenced it in the `type_url` field. For more information, please refer to [ADR-019](../../build/architecture/adr-019-protobuf-state-encoding.md).
 * `Codec`: The default codec used throughout the Cosmos SDK. It is composed of a `BinaryCodec` used to encode and decode state, and a `JSONCodec` used to output data to the users (for example, in the [CLI](#cli)). By default, the SDK uses Protobuf as `Codec`.
@@ -255,7 +255,7 @@ The Cosmos SDK also provides a development endpoint to generate [Swagger](https:
 The main interface is the [Command-Line Interface](../advanced/07-cli.md). The CLI of a Cosmos SDK application is built by aggregating [CLI commands](#cli) defined in each of the modules used by the application. The CLI of an application is the same as the daemon (e.g. `appd`), and is defined in a file called `appd/main.go`. The file contains the following:
 
 * **A `main()` function**, which is executed to build the `appd` interface client. This function prepares each command and adds them to the `rootCmd` before building them. At the root of `appd`, the function adds generic commands like `status`, `keys`, and `config`, query commands, tx commands, and `rest-server`.
-* **Query commands**, which are added by calling the `queryCmd` function. This function returns a Cobra command that contains the query commands defined in each of the application's modules (passed as an array of `sdk.ModuleClients` from the `main()` function), as well as some other lower level query commands such as block or validator queries. Query command are called by using the command `appd query [query]` of the CLI.
+* **Query commands**, which are added by calling the `queryCmd` function. This function returns a Cobra command that contains the query commands defined in each of the application's modules (passed as an array of `sdk.ModuleClients` from the `main()` function), as well as some other lower level query commands such as block or validator queries. Query commands are called by using the command `appd query [query]` of the CLI.
 * **Transaction commands**, which are added by calling the `txCmd` function. Similar to `queryCmd`, the function returns a Cobra command that contains the tx commands defined in each of the application's modules, as well as lower level tx commands like transaction signing or broadcasting. Tx commands are called by using the command `appd tx [tx]` of the CLI.
 
 See an example of an application's main command-line file from the [Cosmos Hub](https://github.com/cosmos/gaia).

docs/docs/learn/beginner/01-tx-lifecycle.md

@@ -98,7 +98,7 @@ through several steps, beginning with decoding `Tx`.
 
 ### Decoding
 
-When `Tx` is received by the application from the underlying consensus engine (e.g. CometBFT ), it is still in its [encoded](../advanced/05-encoding.md) `[]byte` form and needs to be unmarshaled in order to be processed. Then, the [`runTx`](../advanced/00-baseapp.md#runtx-antehandler-runmsgs-posthandler) function is called to run in `runTxModeCheck` mode, meaning the function runs all checks but exits before executing messages and writing state changes.
+When `Tx` is received by the application from the underlying consensus engine (e.g. CometBFT), it is still in its [encoded](../advanced/05-encoding.md) `[]byte` form and needs to be unmarshaled in order to be processed. Then, the [`runTx`](../advanced/00-baseapp.md#runtx-antehandler-runmsgs-posthandler) function is called to run in `runTxModeCheck` mode, meaning the function runs all checks but exits before executing messages and writing state changes.
 
 ### ValidateBasic (deprecated)
 

docs/docs/learn/beginner/02-query-lifecycle.md

@@ -47,7 +47,7 @@ One such tool is [grpcurl](https://github.com/fullstorydev/grpcurl), and a gRPC
 
 ```bash
 grpcurl \
-    -plaintext                                           # We want results in plain test
+    -plaintext                                           # We want results in plain text
     -import-path ./proto \                               # Import these .proto files
     -proto ./proto/cosmos/staking/v1beta1/query.proto \  # Look into this .proto file for the Query protobuf service
     -d '{"address":"$MY_DELEGATOR"}' \                   # Query arguments
@@ -76,7 +76,7 @@ The first thing that is created in the execution of a CLI command is a `client.C
 * **Codec**: The [encoder/decoder](../advanced/05-encoding.md) used by the application, used to marshal the parameters and query before making the CometBFT RPC request and unmarshal the returned response into a JSON object. The default codec used by the CLI is Protobuf.
 * **Account Decoder**: The account decoder from the [`auth`](../../build/modules/auth/README.md) module, which translates `[]byte`s into accounts.
 * **RPC Client**: The CometBFT RPC Client, or node, to which requests are relayed.
-* **Keyring**: A [Key Manager]../beginner/03-accounts.md#keyring) used to sign transactions and handle other operations with keys.
+* **Keyring**: A [Key Manager](../beginner/03-accounts.md#keyring) used to sign transactions and handle other operations with keys.
 * **Output Writer**: A [Writer](https://pkg.go.dev/io/#Writer) used to output the response.
 * **Configurations**: The flags configured by the user for this command, including `--height`, specifying the height of the blockchain to query, and `--indent`, which indicates to add an indent to the JSON response.
 
@@ -134,7 +134,7 @@ Once a result is received from the querier, `baseapp` begins the process of retu
 
 ## Response
 
-Since `Query()` is an ABCI function, `baseapp` returns the response as an [`abci.ResponseQuery`](https://docs.cometbft.com/master/spec/abci/abci.html#query-2) type. The `client.Context` `Query()` routine receives the response and.
+Since `Query()` is an ABCI function, `baseapp` returns the response as an [`abci.ResponseQuery`](https://docs.cometbft.com/master/spec/abci/abci.html#query-2) type. The `client.Context` `Query()` routine receives the response.
 
 ### CLI Response
 

docs/docs/learn/beginner/03-accounts.md

@@ -75,7 +75,7 @@ The Cosmos SDK supports the following digital key schemes for creating digital s
 * `secp256r1`, as implemented in the [Cosmos SDK's `crypto/keys/secp256r1` package](https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/crypto/keys/secp256r1/pubkey.go).
 * `tm-ed25519`, as implemented in the [Cosmos SDK `crypto/keys/ed25519` package](https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/crypto/keys/ed25519/ed25519.go). This scheme is supported only for the consensus validation.
 
-|              | Address length in bytes | Public key length in bytes | Used for transaction authentication | Used for consensus (cometbft) |
+|              | Address length in bytes | Public key length in bytes | Used for transaction authentication | Used for consensus (CometBFT) |
 | :----------: | :---------------------: | :------------------------: | :---------------------------------: | :-----------------------------: |
 | `secp256k1`  |           20            |             33             |                 yes                 |               no                |
 | `secp256r1`  |           32            |             33             |                 yes                 |               no                |
@@ -167,7 +167,7 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/proto/cosmos/tx/v1beta1/tx.pro
 
 ### Create New Key Type
 
-To create a new key type for using in keyring, `keyring.SignatureAlgo` interface must be fulfilled.
+To create a new key type for use in the keyring, the `keyring.SignatureAlgo` interface must be fulfilled.
 
 ```go reference
 https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/crypto/keyring/signing_algorithms.go#L11-L16
@@ -194,7 +194,7 @@ First a new function to create a private key from a secret number is needed in t
 ```go
 // cosmos-sdk/crypto/keys/secp256r1/privkey.go
 
-// NewPrivKeyFromSecret creates a private key derived for the secret number
+// NewPrivKeyFromSecret creates a private key derived from the secret number
 // represented in big-endian. The `secret` must be a valid ECDSA field element.
 func NewPrivKeyFromSecret(secret []byte) (*PrivKey, error) {
 	var d = new(big.Int).SetBytes(secret)