From bf17b0636f04a5263de45e4293bf8b63cd704bb7 Mon Sep 17 00:00:00 2001 From: maksneprik <155268440+deus-labs@users.noreply.github.com> Date: Thu, 31 Jul 2025 18:26:50 +0200 Subject: [PATCH] docs: fix typos (#25065) --- docs/architecture/PROCESS.md | 2 +- docs/architecture/README.md | 2 +- docs/architecture/adr-034-account-rekeying.md | 2 +- docs/architecture/adr-039-epoched-staking.md | 2 +- docs/architecture/adr-043-nft-module.md | 2 +- docs/architecture/adr-044-protobuf-updates-guidelines.md | 2 +- docs/architecture/adr-045-check-delivertx-middlewares.md | 4 ++-- docs/architecture/adr-050-sign-mode-textual.md | 2 +- docs/architecture/adr-053-go-module-refactoring.md | 2 +- docs/architecture/adr-057-app-wiring.md | 4 +--- docs/architecture/adr-059-test-scopes.md | 2 +- docs/architecture/adr-063-core-module-api.md | 4 ++-- docs/docs/build/building-modules/02-messages-and-queries.md | 4 ++-- 13 files changed, 16 insertions(+), 18 deletions(-) diff --git a/docs/architecture/PROCESS.md b/docs/architecture/PROCESS.md index 0e9a34eb7a..f23c3b213d 100644 --- a/docs/architecture/PROCESS.md +++ b/docs/architecture/PROCESS.md @@ -20,7 +20,7 @@ ADR creation is an **iterative** process. Instead of having a high amount of com 3. If a _proposed_ ADR is merged, then it should clearly document outstanding issues either in ADR document notes or in a GitHub Issue. -4. The PR SHOULD always be merged. In the case of a faulty ADR, we still prefer to merge it with a _rejected_ status. The only time the ADR SHOULD NOT be merged is if the author abandons it. +4. The PR SHOULD always be merged. In the case of a faulty ADR, we still prefer to merge it with a _rejected_ status. The only time the ADR SHOULD NOT be merged is if the author abandons it. 5. Merged ADRs SHOULD NOT be pruned. diff --git a/docs/architecture/README.md b/docs/architecture/README.md index fa4ca02259..49c5f29e48 100644 --- a/docs/architecture/README.md +++ b/docs/architecture/README.md @@ -30,7 +30,7 @@ it stands today. If recorded decisions turned out to be lacking, convene a discussion, record the new decisions here, and then modify the code to match. -## Creating new ADR +## Creating a new ADR Read about the [PROCESS](./PROCESS.md). diff --git a/docs/architecture/adr-034-account-rekeying.md b/docs/architecture/adr-034-account-rekeying.md index 9e56053f99..58ec078c38 100644 --- a/docs/architecture/adr-034-account-rekeying.md +++ b/docs/architecture/adr-034-account-rekeying.md @@ -10,7 +10,7 @@ PROPOSED ## Abstract -Account rekeying is a process hat allows an account to replace its authentication pubkey with a new one. +Account rekeying is a process that allows an account to replace its authentication pubkey with a new one. ## Context diff --git a/docs/architecture/adr-039-epoched-staking.md b/docs/architecture/adr-039-epoched-staking.md index c343ac514f..9a2fd900f5 100644 --- a/docs/architecture/adr-039-epoched-staking.md +++ b/docs/architecture/adr-039-epoched-staking.md @@ -45,7 +45,7 @@ Applying it immediately can be viewed as offering greater consensus layer securi * For threshold based cryptography, this setting will have the threshold cryptography use the original epoch weights, while consensus has an update that lets it more rapidly benefit from additional security. If the threshold based cryptography blocks liveness of the chain, then we have effectively raised the liveness threshold of the remaining validators for the rest of the epoch. (Alternatively, jailed nodes could still contribute shares) This plan will fail in the extreme case that more than 1/3rd of the validators have been jailed within a single epoch. For such an extreme scenario, the chain already have its own custom incident response plan, and defining how to handle the threshold cryptography should be a part of that. * For light client efficiency, there can be a bit included in the header indicating an intra-epoch slash (ala https://github.com/tendermint/spec/issues/199). -* For fairness of deterministic leader election, applying a slash or jailing within an epoch would break the guarantee we were seeking to provide. This then re-introduces a new (but significantly simpler) problem for trying to provide fairness guarantees. Namely, that validators can adversarially elect to remove themself from the set of proposers. From a security perspective, this could potentially be handled by two different mechanisms (or prove to still be too difficult to achieve). One is making a security statement acknowledging the ability for an adversary to force an ahead-of-time fixed threshold of users to drop out of the proposer set within an epoch. The second method would be to parameterize such that the cost of a slash within the epoch far outweighs benefits due to being a proposer. However, this latter criterion is quite dubious, since being a proposer can have many advantageous side-effects in chains with complex state machines. (Namely, DeFi games such as Fomo3D) +* For fairness of deterministic leader election, applying a slash or jailing within an epoch would break the guarantee we were seeking to provide. This then re-introduces a new (but significantly simpler) problem for trying to provide fairness guarantees. Namely, that validators can adversarially elect to remove themself from the set of proposers. From a security perspective, this could potentially be handled by two different mechanisms (or prove to still be too difficult to achieve). One is making a security statement acknowledging the ability for an adversary to force an ahead-of-time fixed threshold of users to drop out of the proposer set within an epoch. The second method would be to parameterize such that the cost of a slash within the epoch far outweighs benefits due to being a proposer. However, this latter criterion is quite dubious, since being a proposer can have many advantageous side-effects in chains with complex state machines. (Namely, DeFi games such as Fomo3D) * For staking derivative design, there is no issue introduced. This does not increase the state size of staking records, since whether a slash has occurred is fully queryable given the validator address. ### Token lockup diff --git a/docs/architecture/adr-043-nft-module.md b/docs/architecture/adr-043-nft-module.md index 85d439f7ef..f3f2b7d8a8 100644 --- a/docs/architecture/adr-043-nft-module.md +++ b/docs/architecture/adr-043-nft-module.md @@ -315,7 +315,7 @@ No backward incompatibilities. ### Forward Compatibility -This specification conforms to the ERC-721 smart contract specification for NFT identifiers. Note that ERC-721 defines uniqueness based on (contract address, uint256 tokenId), and we conform to this implicitly because a single module is currently aimed to track NFT identifiers. Note: use of the (mutable) data field to determine uniqueness is not safe.s +This specification conforms to the ERC-721 smart contract specification for NFT identifiers. Note that ERC-721 defines uniqueness based on (contract address, uint256 tokenId), and we conform to this implicitly because a single module is currently aimed to track NFT identifiers. Note: use of the (mutable) data field to determine uniqueness is not safe. ### Positive diff --git a/docs/architecture/adr-044-protobuf-updates-guidelines.md b/docs/architecture/adr-044-protobuf-updates-guidelines.md index c2d41a1a37..595b16de0f 100644 --- a/docs/architecture/adr-044-protobuf-updates-guidelines.md +++ b/docs/architecture/adr-044-protobuf-updates-guidelines.md @@ -20,7 +20,7 @@ The Cosmos SDK maintains a set of [Protobuf definitions](https://github.com/cosm When making changes to these Protobuf definitions, the Cosmos SDK currently only follows [Buf's](https://docs.buf.build/) recommendations. We noticed however that Buf's recommendations might still result in breaking changes in the SDK in some cases. For example: -* Adding fields to `Msg`s. Adding fields is a not a Protobuf spec-breaking operation. However, when adding new fields to `Msg`s, the unknown field rejection will throw an error when sending the new `Msg` to an older node. +* Adding fields to `Msg`s. Adding fields is not a Protobuf spec-breaking operation. However, when adding new fields to `Msg`s, the unknown field rejection will throw an error when sending the new `Msg` to an older node. * Marking fields as `reserved`. Protobuf proposes the `reserved` keyword for removing fields without the need to bump the package version. However, by doing so, client backwards compatibility is broken as Protobuf doesn't generate anything for `reserved` fields. See [#9446](https://github.com/cosmos/cosmos-sdk/issues/9446) for more details on this issue. Moreover, module developers often face other questions around Protobuf definitions such as "Can I rename a field?" or "Can I deprecate a field?" This ADR aims to answer all these questions by providing clear guidelines about allowed updates for Protobuf definitions. diff --git a/docs/architecture/adr-045-check-delivertx-middlewares.md b/docs/architecture/adr-045-check-delivertx-middlewares.md index 60172977c9..ad4e39d806 100644 --- a/docs/architecture/adr-045-check-delivertx-middlewares.md +++ b/docs/architecture/adr-045-check-delivertx-middlewares.md @@ -18,7 +18,7 @@ This ADR replaces the current BaseApp `runTx` and antehandlers design with a mid BaseApp's implementation of ABCI `{Check,Deliver}Tx()` and its own `Simulate()` method call the `runTx` method under the hood, which first runs antehandlers, then executes `Msg`s. However, the [transaction Tips](https://github.com/cosmos/cosmos-sdk/issues/9406) and [refunding unused gas](https://github.com/cosmos/cosmos-sdk/issues/2150) use cases require custom logic to be run after the `Msg`s execution. There is currently no way to achieve this. -An naive solution would be to add post-`Msg` hooks to BaseApp. However, the Cosmos SDK team thinks in parallel about the bigger picture of making app wiring simpler ([#9181](https://github.com/cosmos/cosmos-sdk/discussions/9182)), which includes making BaseApp more lightweight and modular. +A naive solution would be to add post-`Msg` hooks to BaseApp. However, the Cosmos SDK team thinks in parallel about the bigger picture of making app wiring simpler ([#9181](https://github.com/cosmos/cosmos-sdk/discussions/9182)), which includes making BaseApp more lightweight and modular. ## Decision @@ -185,7 +185,7 @@ func (h myTxHandler) SimulateTx(ctx context.Context, req Request) (Response, err While BaseApp simply holds a reference to a `tx.Handler`, this `tx.Handler` itself is defined using a middleware stack. The Cosmos SDK exposes a base (i.e. innermost) `tx.Handler` called `RunMsgsTxHandler`, which executes messages. -Then, the app developer can compose multiple middlewares on top on the base `tx.Handler`. Each middleware can run pre-and-post-processing logic around its next middleware, as described in the section above. Conceptually, as an example, given the middlewares `A`, `B`, and `C` and the base `tx.Handler` `H` the stack looks like: +Then, the app developer can compose multiple middlewares on top of the base `tx.Handler`. Each middleware can run pre-and-post-processing logic around its next middleware, as described in the section above. Conceptually, as an example, given the middlewares `A`, `B`, and `C` and the base `tx.Handler` `H` the stack looks like: ```text A.pre diff --git a/docs/architecture/adr-050-sign-mode-textual.md b/docs/architecture/adr-050-sign-mode-textual.md index 8eec8e42b2..cf871bad22 100644 --- a/docs/architecture/adr-050-sign-mode-textual.md +++ b/docs/architecture/adr-050-sign-mode-textual.md @@ -312,7 +312,7 @@ The current specification is not set in stone, and future iterations are to be e Updates in the 1st category include changes of the `Screen` struct or its corresponding CBOR encoding. This type of updates require a modification of the hardware signer application, to be able to decode and parse the new types. Backwards-compatibility must also be guaranteed, so that the new hardware application works with existing versions of the SDK. These updates require the coordination of multiple parties: SDK developers, hardware application developers (currently: Zondax), and client-side developers (e.g. CosmJS). Furthermore, a new submission of the hardware device application may be necessary, which, depending on the vendor, can take some time. As such, we recommend to avoid this type of updates as much as possible. -Updates in the 2nd category include changes to any of the value renderers or to the transaction envelope. For example, the ordering of fields in the envelope can be swapped, or the timestamp formatting can be modified. Since SIGN_MODE_TEXTUAL sends `Screen`s to the hardware device, this type of change do not need a hardware wallet application update. They are however state-machine-breaking, and must be documented as such. They require the coordination of SDK developers with client-side developers (e.g. CosmJS), so that the updates are released on both sides close to each other in time. +Updates in the 2nd category include changes to any of the value renderers or to the transaction envelope. For example, the ordering of fields in the envelope can be swapped, or the timestamp formatting can be modified. Since SIGN_MODE_TEXTUAL sends `Screen`s to the hardware device, this type of change does not need a hardware wallet application update. They are however state-machine-breaking, and must be documented as such. They require the coordination of SDK developers with client-side developers (e.g. CosmJS), so that the updates are released on both sides close to each other in time. We define a spec version, which is an integer that must be incremented on each update of either category. This spec version will be exposed by the SDK's implementation, and can be communicated to clients. For example, SDK v0.50 might use the spec version 1, and SDK v0.51 might use 2; thanks to this versioning, clients can know how to craft SIGN_MODE_TEXTUAL transactions based on the target SDK version. diff --git a/docs/architecture/adr-053-go-module-refactoring.md b/docs/architecture/adr-053-go-module-refactoring.md index d15c390191..12b9978cfc 100644 --- a/docs/architecture/adr-053-go-module-refactoring.md +++ b/docs/architecture/adr-053-go-module-refactoring.md @@ -23,7 +23,7 @@ increase which technically creates a new go module (with a v2, v3, etc. suffix). [Keeping modules API compatible](https://go.dev/blog/module-compatibility) in -this way requires a fair amount of fair thought and discipline. +this way requires a fair amount of thought and discipline. The Cosmos SDK is a fairly large project which originated before go modules came into existence and has always been under a v0.x release even though diff --git a/docs/architecture/adr-057-app-wiring.md b/docs/architecture/adr-057-app-wiring.md index 9966ca2d99..824403fb07 100644 --- a/docs/architecture/adr-057-app-wiring.md +++ b/docs/architecture/adr-057-app-wiring.md @@ -38,7 +38,7 @@ In order to improve the current situation, a new "app wiring" paradigm has been involves: * declaration configuration of the modules in an app which can be serialized to JSON or YAML -* a dependency-injection (DI) framework for instantiating apps from the that configuration +* a dependency-injection (DI) framework for instantiating apps from the configuration ### Dependency Injection @@ -250,8 +250,6 @@ defined here are described in [ADR 063: Core Module API](./adr-063-core-module-a ### Registration of Inter-Module Hooks -### Registration of Inter-Module Hooks - Some modules define a hooks interface (ex. `StakingHooks`) which allows one module to call back into another module when certain events happen. diff --git a/docs/architecture/adr-059-test-scopes.md b/docs/architecture/adr-059-test-scopes.md index 8a1a855cda..99529d180d 100644 --- a/docs/architecture/adr-059-test-scopes.md +++ b/docs/architecture/adr-059-test-scopes.md @@ -242,7 +242,7 @@ demonstrated in [PR#12706](https://github.com/cosmos/cosmos-sdk/pull/12706). It may be useful if test suites could be run in integration mode (with mocked tendermint) or with e2e fixtures (with real tendermint and many nodes). Integration fixtures could be used -for quicker runs, e2e fixures could be used for more battle hardening. +for quicker runs, e2e fixtures could be used for more battle hardening. A PoC `x/gov` was completed in PR [#12847](https://github.com/cosmos/cosmos-sdk/pull/12847) is in progress for unit tests demonstrating BDD [Rejected]. diff --git a/docs/architecture/adr-063-core-module-api.md b/docs/architecture/adr-063-core-module-api.md index 1e6782e720..3605dc52e0 100644 --- a/docs/architecture/adr-063-core-module-api.md +++ b/docs/architecture/adr-063-core-module-api.md @@ -408,7 +408,7 @@ which modules can return in a provider: ```go func ProvideGrpcGateway() GrpcGatewayInfo { - return GrpcGatewayinfo { + return GrpcGatewayInfo { Handlers: []Handler {types.RegisterQueryHandlerClient} } } @@ -496,7 +496,7 @@ a dependency on `github.com/cosmos/cosmos-sdk` would no longer be required. In short, modules would depend primarily on `cosmossdk.io/core`, and each `cosmossdk.io/runtime/{consensus-engine}` would implement the `cosmossdk.io/core` functionality for that consensus engine. -On additional piece that would need to be resolved as part of this architecture is how runtimes relate to the server. +One additional piece that would need to be resolved as part of this architecture is how runtimes relate to the server. Likely it would make sense to modularize the current server architecture so that it can be used with any runtime even if that is based on a consensus engine besides Comet. This means that eventually the Comet runtime would need to encapsulate the logic for starting Comet and the ABCI app. diff --git a/docs/docs/build/building-modules/02-messages-and-queries.md b/docs/docs/build/building-modules/02-messages-and-queries.md index 872009bccf..c2b7b4c3ef 100644 --- a/docs/docs/build/building-modules/02-messages-and-queries.md +++ b/docs/docs/build/building-modules/02-messages-and-queries.md @@ -41,7 +41,7 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/proto/cosmos/bank/v1be `sdk.Msg` is a alias of `proto.Message`. -To attach a `ValidateBasic()` method to a message then you must add methods to the type adhereing to the `HasValidateBasic`. +To attach a `ValidateBasic()` method to a message then you must add methods to the type adhering to the `HasValidateBasic`. ```go reference https://github.com/cosmos/cosmos-sdk/blob/9c1e8b247cd47b5d3decda6e86fbc3bc996ee5d7/types/tx_msg.go#L84-L88 @@ -120,7 +120,7 @@ where: * `queryType` is used by the module's [`querier`](./04-query-services.md#legacy-queriers) to map the `query` to the appropriate `querier function` within the module. * `args` are the actual arguments needed to process the `query`. They are filled out by the end-user. Note that for bigger queries, you might prefer passing arguments in the `Data` field of the request `req` instead of the `path`. -The `path` for each `query` must be defined by the module developer in the module's [command-line interface file](./09-module-interfaces.md#query-commands).Overall, there are 3 mains components module developers need to implement in order to make the subset of the state defined by their module queryable: +The `path` for each `query` must be defined by the module developer in the module's [command-line interface file](./09-module-interfaces.md#query-commands). Overall, there are 3 mains components module developers need to implement in order to make the subset of the state defined by their module queryable: * A [`querier`](./04-query-services.md#legacy-queriers), to process the `query` once it has been [routed to the module](../../learn/advanced/00-baseapp.md#query-routing). * [Query commands](./09-module-interfaces.md#query-commands) in the module's CLI file, where the `path` for each `query` is specified.