From 46a7f918d6d68097e8c214dc6e19cd8d4fe4ee2c Mon Sep 17 00:00:00 2001 From: viktorking7 <140458814+viktorking7@users.noreply.github.com> Date: Fri, 12 Dec 2025 01:01:30 +0100 Subject: [PATCH] fix: spelling/grammar across docs and tooling (#25677) Co-authored-by: Alex | Cosmos Labs --- README.md | 2 +- client/debug/main.go | 2 +- collections/README.md | 8 ++++---- contrib/x/group/internal/orm/README.md | 2 +- contrib/x/group/internal/orm/table.go | 2 +- .../adr-040-storage-and-smt-state-commitments.md | 4 ++-- docs/architecture/adr-048-consensus-fees.md | 2 +- docs/architecture/adr-049-state-sync-hooks.md | 2 +- docs/architecture/adr-060-abci-1.0.md | 2 +- docs/architecture/adr-064-abci-2.0.md | 2 +- docs/docs/user/run-node/06-run-production.md | 4 ++-- docs/rfc/rfc-001-tx-validation.md | 2 +- docs/spec/_ics/ics-030-signed-messages.md | 2 +- docs/spec/store/README.md | 8 ++++---- store/snapshots/manager.go | 2 +- store/snapshots/types/snapshotter.go | 2 +- telemetry/README.md | 3 +-- x/auth/README.md | 10 +++++----- x/bank/README.md | 2 +- x/distribution/README.md | 4 ++-- x/slashing/README.md | 2 +- 21 files changed, 34 insertions(+), 35 deletions(-) diff --git a/README.md b/README.md index a0acfdddf3..1de715c7b3 100644 --- a/README.md +++ b/README.md @@ -28,7 +28,7 @@ The Cosmos SDK is a modular, open-source blockchain SDK for building secure, hig The Cosmos SDK is tailored for building secure, sovereign application-specific blockchains. Developers building with the Cosmos SDK can use predefined modules that cover standard blockchain functionality or create custom modules for their specific use case. This composable architecture enables robust customization. The SDK provides abstractions for permissioning, governance, state management, account abstraction, tokenization processes, application logic, and more. -Cosmos SDK blockchains get interoperability out-of-the-box via a native integration with the [Inter-Blockchain Communication Protocol (IBC)](https://github.com/cosmos/ibc-go). Ibc-go is implemented as a Go module in the Cosmos SDK. +Cosmos SDK blockchains get interoperability out-of-the-box via a native integration with the [Inter-Blockchain Communication Protocol (IBC)](https://github.com/cosmos/ibc-go). ibc-go is implemented as a Go module in the Cosmos SDK. While the Cosmos SDK is plug-and-play with any consensus engine, we recommend using [CometBFT](https://github.com/cometbft/cometbft) for a fast, battle-tested, high-throughput, configurable BFT state machine. CometBFT is developed as part of the Cosmos Stack and its releases are updated alongside the SDK. diff --git a/client/debug/main.go b/client/debug/main.go index 6a3d44f852..c918b38af8 100644 --- a/client/debug/main.go +++ b/client/debug/main.go @@ -104,7 +104,7 @@ func PubkeyCmd() *cobra.Command { return &cobra.Command{ Use: "pubkey [pubkey]", Short: "Decode a pubkey from proto JSON", - Long: fmt.Sprintf(`Decode a pubkey from proto JSON and display it's address. + Long: fmt.Sprintf(`Decode a pubkey from proto JSON and display its address. Example: $ %s debug pubkey '{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"AurroA7jvfPd1AadmmOvWM2rJSwipXfRf8yD6pLbA2DJ"}' diff --git a/collections/README.md b/collections/README.md index d8f9c17e29..e3abe5ea97 100644 --- a/collections/README.md +++ b/collections/README.md @@ -122,7 +122,7 @@ var ( #### Rules -``collections.NewPrefix`` accepts either `uint8`, `string` or `[]bytes` it's good practice to use an always increasing `uint8`for disk space efficiency. +``collections.NewPrefix`` accepts either `uint8`, `string` or `[]bytes` it's good practice to use an always increasing `uint8` for disk space efficiency. A collection **MUST NOT** share the same prefix as another collection in the same module, and a collection prefix **MUST NEVER** start with the same prefix as another, examples: @@ -397,7 +397,7 @@ func (k Keeper) RemoveValidator(ctx sdk.Context, validator sdk.ValAddress) error } ``` -The first difference we notice is that `KeySet` needs use to specify only one type parameter: the key (`sdk.ValAddress` in this case). +The first difference we notice is that `KeySet` needs us to specify only one type parameter: the key (`sdk.ValAddress` in this case). The second difference we notice is that `KeySet` in its `NewKeySet` function does not require us to specify a `ValueCodec` but only a `KeyCodec`. This is because a `KeySet` only saves keys and not values. @@ -605,7 +605,7 @@ we specified in the range. Then we use again the `Values` method of the `Iterator` to collect all the results. `collections.Range` also offers a `Prefix` API which is not applicable to all keys types, -for example uint64 cannot be prefix because it is of constant size, but a `string` key +for example uint64 cannot be prefixed because it is of constant size, but a `string` key can be prefixed. #### IterateAccounts @@ -648,7 +648,7 @@ Let's see now how we can work with composite keys using collections. ### Example -In our example we will show-case how we can use collections when we are dealing with balances, similar to bank, +In our example we will showcase how we can use collections when we are dealing with balances, similar to bank, a balance is a mapping between `(address, denom) => math.Int` the composite key in our case is `(address, denom)`. ## Instantiation of a composite key collection diff --git a/contrib/x/group/internal/orm/README.md b/contrib/x/group/internal/orm/README.md index 766a26f020..c95435e1a8 100644 --- a/contrib/x/group/internal/orm/README.md +++ b/contrib/x/group/internal/orm/README.md @@ -24,7 +24,7 @@ A table can be built given a `codec.ProtoMarshaler` model type, a prefix to acce https://github.com/cosmos/cosmos-sdk/tree/release/v0.50.x/x/group/internal/orm/table.go#L30-L36 ``` -In the prefix store, entities should be stored by an unique identifier called `RowID` which can be based either on an `uint64` auto-increment counter, string or dynamic size bytes. +In the prefix store, entities should be stored by a unique identifier called `RowID` which can be based either on a `uint64` auto-increment counter, string or dynamic size bytes. Regular CRUD operations can be performed on a table, these methods take a `sdk.KVStore` as parameter to get the table prefix store. The `table` struct does not: diff --git a/contrib/x/group/internal/orm/table.go b/contrib/x/group/internal/orm/table.go index 3a72af6722..7d7be78405 100644 --- a/contrib/x/group/internal/orm/table.go +++ b/contrib/x/group/internal/orm/table.go @@ -21,7 +21,7 @@ var ( ) // table is the high level object to storage mapper functionality. Persistent -// entities are stored by an unique identifier called `RowID`. The table struct +// entities are stored by a unique identifier called `RowID`. The table struct // does not: // - enforce uniqueness of the `RowID` // - enforce prefix uniqueness of keys, i.e. not allowing one key to be a prefix diff --git a/docs/architecture/adr-040-storage-and-smt-state-commitments.md b/docs/architecture/adr-040-storage-and-smt-state-commitments.md index 3a7bc2dd58..a2768ca7a0 100644 --- a/docs/architecture/adr-040-storage-and-smt-state-commitments.md +++ b/docs/architecture/adr-040-storage-and-smt-state-commitments.md @@ -192,7 +192,7 @@ The presented workaround can be used until the IBC module is fully upgraded to s We consider a compression of prefix keys by creating a mapping from module key to an integer, and serializing the integer using varint coding. Varint coding assures that different values don't have common byte prefix. For Merkle Proofs we can't use prefix compression - so it should only apply for the `SS` keys. Moreover, the prefix compression should be only applied for the module namespace. More precisely: -* each module has it's own namespace; +* each module has its own namespace; * when accessing a module namespace we create a KVStore with embedded prefix; * that prefix will be compressed only when accessing and managing `SS`. @@ -279,7 +279,7 @@ We were discussing use case where modules can use a support database, which is n ## References * [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 it's state v0.15 +* [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) diff --git a/docs/architecture/adr-048-consensus-fees.md b/docs/architecture/adr-048-consensus-fees.md index 6fbaeef6eb..2dec11cf22 100644 --- a/docs/architecture/adr-048-consensus-fees.md +++ b/docs/architecture/adr-048-consensus-fees.md @@ -14,7 +14,7 @@ This ADR describes a flexible mechanism to maintain a consensus level gas prices ## Context -Currently, each validator configures it's own `minimal-gas-prices` in `app.yaml`. But setting a proper minimal gas price is critical to protect network from dos attack, and it's hard for all the validators to pick a sensible value, so we propose to maintain a gas price in consensus level. +Currently, each validator configures its own `minimal-gas-prices` in `app.yaml`. But setting a proper minimal gas price is critical to protect network from DoS attack, and it's hard for all the validators to pick a sensible value, so we propose to maintain a gas price in consensus level. Since tendermint 0.34.20 has supported mempool prioritization, we can take advantage of that to implement more sophisticated gas fee system. diff --git a/docs/architecture/adr-049-state-sync-hooks.md b/docs/architecture/adr-049-state-sync-hooks.md index 8b039d66fc..d426cbe19a 100644 --- a/docs/architecture/adr-049-state-sync-hooks.md +++ b/docs/architecture/adr-049-state-sync-hooks.md @@ -116,7 +116,7 @@ type ExtensionPayloadReader = func() ([]byte, error) type ExtensionPayloadWriter = func([]byte) error // ExtensionSnapshotter is an extension Snapshotter that is appended to the snapshot stream. -// ExtensionSnapshotter has an unique name and manages it's own internal formats. +// ExtensionSnapshotter has a unique name and manages its own internal formats. type ExtensionSnapshotter interface { // SnapshotName returns the name of snapshotter, it should be unique in the manager. SnapshotName() string diff --git a/docs/architecture/adr-060-abci-1.0.md b/docs/architecture/adr-060-abci-1.0.md index 01928e7b9c..0178d4769b 100644 --- a/docs/architecture/adr-060-abci-1.0.md +++ b/docs/architecture/adr-060-abci-1.0.md @@ -137,7 +137,7 @@ transactions entirely with other transactions. When evaluating transactions from `RequestPrepareProposal`, the application will ignore *ALL* transactions sent to it in the request and instead reap up to -`RequestPrepareProposal.max_tx_bytes` from it's own mempool. +`RequestPrepareProposal.max_tx_bytes` from its own mempool. Since an application can technically insert or inject transactions on `Insert` during `CheckTx` execution, it is recommended that applications ensure transaction diff --git a/docs/architecture/adr-064-abci-2.0.md b/docs/architecture/adr-064-abci-2.0.md index 67187eb781..cc9843195f 100644 --- a/docs/architecture/adr-064-abci-2.0.md +++ b/docs/architecture/adr-064-abci-2.0.md @@ -286,7 +286,7 @@ decision based on the vote extensions. > nor the vote extension verification mechanism described above is required for > applications to implement. In other words, a proposer is not required to verify > and propagate vote extensions along with their signatures nor are proposers -> required to verify those signatures. An application can implement it's own +> required to verify those signatures. An application can implement its own > PKI mechanism and use that to sign and verify vote extensions. #### Vote Extension Persistence diff --git a/docs/docs/user/run-node/06-run-production.md b/docs/docs/user/run-node/06-run-production.md index 6eee480870..6cf957b40d 100644 --- a/docs/docs/user/run-node/06-run-production.md +++ b/docs/docs/user/run-node/06-run-production.md @@ -40,10 +40,10 @@ Now when logging into the server, the non `root` user can be used. ### Go -1. Install the [Go](https://go.dev/doc/install) version preconized by the application. +1. Install the [Go](https://go.dev/doc/install) version recommended by the application. :::warning -In the past, validators [have had issues](https://github.com/cosmos/cosmos-sdk/issues/13976) when using different versions of Go. It is recommended that the whole validator set uses the version of Go that is preconized by the application. +In the past, validators [have had issues](https://github.com/cosmos/cosmos-sdk/issues/13976) when using different versions of Go. It is recommended that the whole validator set uses the version of Go that is recommended by the application. ::: ### Firewall diff --git a/docs/rfc/rfc-001-tx-validation.md b/docs/rfc/rfc-001-tx-validation.md index 80dc8e1f28..7b8f0005ad 100644 --- a/docs/rfc/rfc-001-tx-validation.md +++ b/docs/rfc/rfc-001-tx-validation.md @@ -22,4 +22,4 @@ We can and will still support the `ValidateBasic` function for users and provide ### Consequences -The consequence of updating the transaction flow is that transaction that may have failed before with the `ValidateBasic` flow will now be included in a block and the fees charged. +The consequence of updating the transaction flow is that transactions that may have failed before with the `ValidateBasic` flow will now be included in a block and the fees charged. diff --git a/docs/spec/_ics/ics-030-signed-messages.md b/docs/spec/_ics/ics-030-signed-messages.md index a7c56715b9..802eaef33b 100644 --- a/docs/spec/_ics/ics-030-signed-messages.md +++ b/docs/spec/_ics/ics-030-signed-messages.md @@ -152,7 +152,7 @@ more complex structures, apart from just string messages, and still be able to know exactly what they are signing (opposed to signing a bunch of arbitrary bytes). Thus, in the future, the Cosmos signing message specification will be expected -to expand upon it's canonical JSON structure to include such functionality. +to expand upon its canonical JSON structure to include such functionality. ## API diff --git a/docs/spec/store/README.md b/docs/spec/store/README.md index ec3573900e..933c3c0df5 100644 --- a/docs/spec/store/README.md +++ b/docs/spec/store/README.md @@ -29,9 +29,9 @@ with, which also provides the basis of most state storage and commitment operati is the `KVStore`. The `KVStore` interface provides basic CRUD abilities and prefix-based iteration, including reverse iteration. -Typically, each module has it's own dedicated `KVStore` instance, which it can +Typically, each module has its own dedicated `KVStore` instance, which it can get access to via the `sdk.Context` and the use of a pointer-based named key -- -`KVStoreKey`. The `KVStoreKey` provides pseudo-OCAP. How a exactly a `KVStoreKey` +`KVStoreKey`. The `KVStoreKey` provides pseudo-OCAP. How exactly a `KVStoreKey` maps to a `KVStore` will be illustrated below through the `CommitMultiStore`. Note, a `KVStore` cannot directly commit state. Instead, a `KVStore` can be wrapped @@ -194,7 +194,7 @@ a `BaseApp` instance which internally has a reference to a `CommitMultiStore` that is implemented by a `rootmulti.Store`. The application then registers one or more `KVStoreKey` that pertain to a unique module and thus a `KVStore`. Through the use of an `sdk.Context` and a `KVStoreKey`, each module can get direct access -to it's respective `KVStore` instance. +to its respective `KVStore` instance. Example: @@ -227,7 +227,7 @@ func NewApp(...) Application { The `rootmulti.Store` itself can be cache-wrapped which returns an instance of a `cachemulti.Store`. For each block, `BaseApp` ensures that the proper abstractions are created on the `CommitMultiStore`, i.e. ensuring that the `rootmulti.Store` -is cached-wrapped and uses the resulting `cachemulti.Store` to be set on the +is cache-wrapped and uses the resulting `cachemulti.Store` to be set on the `sdk.Context` which is then used for block and transaction execution. As a result, all state mutations due to block and transaction execution are actually held ephemerally until `Commit()` is called by the ABCI client. This concept is further diff --git a/store/snapshots/manager.go b/store/snapshots/manager.go index 19ef64eab0..ddccf43cbb 100644 --- a/store/snapshots/manager.go +++ b/store/snapshots/manager.go @@ -102,7 +102,7 @@ func (m *Manager) RegisterExtensions(extensions ...types.ExtensionSnapshotter) e return fmt.Errorf("duplicated snapshotter name: %s", name) } if !IsFormatSupported(extension, extension.SnapshotFormat()) { - return fmt.Errorf("snapshotter don't support it's own snapshot format: %s %d", name, extension.SnapshotFormat()) + return fmt.Errorf("snapshotter doesn't support its own snapshot format: %s %d", name, extension.SnapshotFormat()) } m.extensions[name] = extension } diff --git a/store/snapshots/types/snapshotter.go b/store/snapshots/types/snapshotter.go index 53a1594038..480840203e 100644 --- a/store/snapshots/types/snapshotter.go +++ b/store/snapshots/types/snapshotter.go @@ -40,7 +40,7 @@ type ExtensionPayloadReader = func() ([]byte, error) type ExtensionPayloadWriter = func([]byte) error // ExtensionSnapshotter is an extension Snapshotter that is appended to the snapshot stream. -// ExtensionSnapshotter has an unique name and manages its own internal formats. +// ExtensionSnapshotter has a unique name and manages its own internal formats. type ExtensionSnapshotter interface { // SnapshotName returns the name of snapshotter, it should be unique in the manager. SnapshotName() string diff --git a/telemetry/README.md b/telemetry/README.md index 9ce9b9a86f..2b1ce2eb11 100644 --- a/telemetry/README.md +++ b/telemetry/README.md @@ -79,7 +79,7 @@ For a full list of configurable options see: https://github.com/open-telemetry/o The node's `init` command will generate an empty otel file in the `~/./config` directory. Place your otel configuration here. -When the node's `start` command is ran, the OpenTelemetry SDK will be initialized using this file. +When the node's `start` command is run, the OpenTelemetry SDK will be initialized using this file. If left empty, all meters and tracers will be noop. ## OpenTelemetry Initialization @@ -107,4 +107,3 @@ NOTE: it is important to thread context.Context properly for spans and metrics t correlated correctly. When using the SDK's context type, spans must be started with Context.StartSpan to get an SDK context which has the span set correctly. - diff --git a/x/auth/README.md b/x/auth/README.md index bd9f18a37c..3898455cc0 100644 --- a/x/auth/README.md +++ b/x/auth/README.md @@ -249,7 +249,7 @@ simd query auth --help #### account -The `account` command allow users to query for an account by it's address. +The `account` command allows users to query for an account by its address. ```bash simd query auth account [address] [flags] @@ -504,7 +504,7 @@ A user can query the `auth` module using gRPC endpoints. #### Account -The `account` endpoint allow users to query for an account by it's address. +The `account` endpoint allows users to query for an account by its address. ```bash cosmos.auth.v1beta1.Query/Account @@ -687,7 +687,7 @@ A user can query the `auth` module using REST endpoints. #### Account -The `account` endpoint allow users to query for an account by it's address. +The `account` endpoint allows users to query for an account by its address. ```bash /cosmos/auth/v1beta1/account?address={address} @@ -695,7 +695,7 @@ The `account` endpoint allow users to query for an account by it's address. #### Accounts -The `accounts` endpoint allow users to query all the available accounts. +The `accounts` endpoint allows users to query all the available accounts. ```bash /cosmos/auth/v1beta1/accounts @@ -703,7 +703,7 @@ The `accounts` endpoint allow users to query all the available accounts. #### Params -The `params` endpoint allow users to query the current auth parameters. +The `params` endpoint allows users to query the current auth parameters. ```bash /cosmos/auth/v1beta1/params diff --git a/x/bank/README.md b/x/bank/README.md index 62a781da66..3cf08f1d5a 100644 --- a/x/bank/README.md +++ b/x/bank/README.md @@ -125,7 +125,7 @@ aforementioned state: ## Params -The bank module stores it's params in state with the prefix of `0x05`, +The bank module stores its params in state with the prefix of `0x05`, it can be updated with governance or the address with authority. * Params: `0x05 | ProtocolBuffer(Params)` diff --git a/x/distribution/README.md b/x/distribution/README.md index 0563c5d726..88fe1b9154 100644 --- a/x/distribution/README.md +++ b/x/distribution/README.md @@ -198,7 +198,7 @@ type ValidatorDistInfo struct { ### Delegation Distribution Each delegation distribution only needs to record the height at which it last -withdrew fees. Because a delegation must withdraw fees each time it's +withdrew fees. Because a delegation must withdraw fees each time its properties change (aka bonded tokens etc.) its properties will remain constant and the delegator's _accumulation_ factor can be calculated passively knowing only the height of the last withdrawal and its current properties. @@ -213,7 +213,7 @@ type DelegationDistInfo struct { ### Params -The distribution module stores it's params in state with the prefix of `0x09`, +The distribution module stores its params in state with the prefix of `0x09`, it can be updated with governance or the address with authority. * Params: `0x09 | ProtocolBuffer(Params)` diff --git a/x/slashing/README.md b/x/slashing/README.md index 5bf95b80fb..3eb7ba1feb 100644 --- a/x/slashing/README.md +++ b/x/slashing/README.md @@ -148,7 +148,7 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/slashing/v1be ### Params -The slashing module stores it's params in state with the prefix of `0x00`, +The slashing module stores its params in state with the prefix of `0x00`, it can be updated with governance or the address with authority. * Params: `0x00 | ProtocolBuffer(Params)`