chore: typos fixes by cosmos-sdk bot (#18689)

Co-authored-by: github-merge-queue <github-merge-queue@users.noreply.github.com> Co-authored-by: Julien Robert <julien@rbrt.fr> Co-authored-by: marbar3778 <marbar3778@yahoo.com>
2023-12-11 13:03:19 +00:00
parent 39865d852f
commit 8f0d5b15f0
113 changed files with 195 additions and 202 deletions
@@ -8,7 +8,7 @@

 ## What is an ADR? 

-An ADR is a document to document an implementation and design that may or may not have been discussed in an RFC. While an RFC is meant to replace synchoronus communication in a distributed environment, an ADR is meant to document an already made decision. An ADR wont come with much of a communication overhead because the discussion was recorded in an RFC or a synchronous discussion. If the consensus came from a synchoronus discussion then a short excerpt should be added to the ADR to explain the goals. 
+An ADR is a document to document an implementation and design that may or may not have been discussed in an RFC. While an RFC is meant to replace synchoronus communication in a distributed environment, an ADR is meant to document an already made decision. An ADR won't come with much of a communication overhead because the discussion was recorded in an RFC or a synchronous discussion. If the consensus came from a synchoronus discussion then a short excerpt should be added to the ADR to explain the goals. 

 ## ADR life cycle

@@ -49,7 +49,7 @@ Griefing, the act of intentionally getting oneself slashed in order to make anot

 ### Implementation

-In the slashing module, we will add two queues that will track all of the recent slash events.  For double sign faults, we will define "recent slashes" as ones that have occurred within the last `unbonding period`.  For liveness faults, we will define "recent slashes" as ones that have occurred withing the last `jail period`.
+In the slashing module, we will add two queues that will track all of the recent slash events.  For double sign faults, we will define "recent slashes" as ones that have occurred within the last `unbonding period`.  For liveness faults, we will define "recent slashes" as ones that have occurred within the last `jail period`.

 ```go
 type SlashEvent struct {
@@ -27,7 +27,7 @@ There is a new `Msg` type called `MsgExtendVotingPeriod`, which can be sent by a

 So for example, if the `MaxVotingPeriodExtension` is set to 100 Days, then anyone with 1% of voting power can extend the voting power by 1 day.  If 33% of voting power has sent the message, the voting period will be extended by 33 days.  Thus, if absolutely everyone chooses to extend the voting period, the absolute maximum voting period will be `MinVotingPeriod + MaxVotingPeriodExtension`.

-This system acts as a sort of distributed coordination, where individual stakers choosing to extend or not, allows the system the guage the conentiousness/complexity of the proposal.  It is extremely unlikely that many stakers will choose to extend at the exact same time, it allows stakers to view how long others have already extended thus far, to decide whether or not to extend further.
+This system acts as a sort of distributed coordination, where individual stakers choosing to extend or not, allows the system the gauge the conentiousness/complexity of the proposal.  It is extremely unlikely that many stakers will choose to extend at the exact same time, it allows stakers to view how long others have already extended thus far, to decide whether or not to extend further.

 ### Dealing with Unbonding/Redelegation

@@ -176,7 +176,7 @@ service Query {
 }
 ```

-grpc-gateway will work direcly against the GRPC proxy described above which will
+grpc-gateway will work directly against the GRPC proxy described above which will
 translate requests to ABCI queries under the hood. grpc-gateway can also
 generate Swagger definitions automatically.

@@ -40,7 +40,7 @@ in `x/gov`,  `MsgSubmitProposal` returns the proposal ID as a big-endian `uint64
 This isn’t really documented anywhere and clients would need to know the internals
 of the Cosmos SDK to parse that value and return it to users.

-Also, there may be cases where we want to use these return values programatically.
+Also, there may be cases where we want to use these return values programmatically.
 For instance, https://github.com/cosmos/cosmos-sdk/issues/7093 proposes a method for
 doing inter-module Ocaps using the `Msg` router. A well-defined return type would
 improve the developer UX for this approach.
@@ -82,7 +82,7 @@ the intent of the [protobuf spec](https://developers.google.com/protocol-buffers
 With this approach, we would get an auto-generated `MsgServer` interface:

 In addition to clearly specifying return types, this has the benefit of generating client and server code. On the server
-side, this is almost like an automatically generated keeper method and could maybe be used intead of keepers eventually
+side, this is almost like an automatically generated keeper method and could maybe be used instead of keepers eventually
 (see [\#7093](https://github.com/cosmos/cosmos-sdk/issues/7093)):

 ```go
@@ -118,7 +118,7 @@ We propose to add a `msg_service_router` in BaseApp. This router is a key/value

 When a transaction is processed by BaseApp (in CheckTx or in DeliverTx), its `TxBody.messages` are decoded as `Msg`s. Each `Msg`'s `type_url` is matched against an entry in the `msg_service_router`, and the respective `Msg` service method handler is called.

-For backward compatibility, the old handlers are not removed yet. If BaseApp receives a legacy `Msg` with no correspoding entry in the `msg_service_router`, it will be routed via its legacy `Route()` method into the legacy handler.
+For backward compatibility, the old handlers are not removed yet. If BaseApp receives a legacy `Msg` with no corresponding entry in the `msg_service_router`, it will be routed via its legacy `Route()` method into the legacy handler.

 ### Module Configuration

@@ -22,7 +22,7 @@ Currently in the Cosmos SDK, events are defined in the handlers for each message

 Currently in the Cosmos SDK, events are defined in the handlers for each message, meaning each module doesn't have a canonical set of types for each event. Above all else this makes these events difficult to consume as it requires a great deal of raw string matching and parsing. This proposal focuses on updating the events to use **typed events** defined in each module such that emitting and subscribing to events will be much easier. This workflow comes from the experience of the Akash Network team.

-[Our platform](http://github.com/ovrclk/akash) requires a number of programatic on chain interactions both on the provider (datacenter - to bid on new orders and listen for leases created) and user (application developer - to send the app manifest to the provider) side. In addition the Akash team is now maintaining the IBC [`relayer`](https://github.com/ovrclk/relayer), another very event driven process. In working on these core pieces of infrastructure, and integrating lessons learned from Kubernetes development, our team has developed a standard method for defining and consuming typed events in Cosmos SDK modules. We have found that it is extremely useful in building this type of event driven application.
+[Our platform](http://github.com/ovrclk/akash) requires a number of programmatic on chain interactions both on the provider (datacenter - to bid on new orders and listen for leases created) and user (application developer - to send the app manifest to the provider) side. In addition the Akash team is now maintaining the IBC [`relayer`](https://github.com/ovrclk/relayer), another very event driven process. In working on these core pieces of infrastructure, and integrating lessons learned from Kubernetes development, our team has developed a standard method for defining and consuming typed events in Cosmos SDK modules. We have found that it is extremely useful in building this type of event driven application.

 As the Cosmos SDK gets used more extensively for apps like `peggy`, other peg zones, IBC, DeFi, etc... there will be an exploding demand for event driven applications to support new features desired by users. We propose upstreaming our findings into the Cosmos SDK to enable all Cosmos SDK applications to quickly and easily build event driven apps to aid their core application. Wallets, exchanges, explorers, and defi protocols all stand to benefit from this work.

@@ -308,7 +308,7 @@ func PublishChainTxEvents(ctx context.Context, client cmtclient.EventsClient, bu
        return err
 	})

-    // Exit on error or context cancelation
+    // Exit on error or context cancellation
    return g.Wait()
 }
 ```
@@ -50,7 +50,7 @@ An account that has had its pubkey changed cannot be automatically pruned from s
 	ctx.GasMeter().ConsumeGas(amount, "pubkey change fee")
 ```

-Everytime a key for an address is changed, we will store a log of this change in the state of the chain, thus creating a stack of all previous keys for an address and the time intervals for which they were active.  This allows dapps and clients to easily query past keys for an account which may be useful for features such as verifying timestamped off-chain signed messages.
+Every time a key for an address is changed, we will store a log of this change in the state of the chain, thus creating a stack of all previous keys for an address and the time intervals for which they were active.  This allows dapps and clients to easily query past keys for an account which may be useful for features such as verifying timestamped off-chain signed messages.

 ## Consequences

@@ -7,7 +7,7 @@
 * 10/14/2022:
    * Add `ListenCommit`, flatten the state writes in a block to a single batch.
    * Remove listeners from cache stores, should only listen to `rootmulti.Store`.
-    * Remove `HaltAppOnDeliveryError()`, the errors are propagated by default, the implementations should return nil if don't want to propogate errors.
+    * Remove `HaltAppOnDeliveryError()`, the errors are propagated by default, the implementations should return nil if don't want to propagate errors.
 * 26/05/2023: Update with ABCI 2.0

 ## Status
@@ -354,7 +354,7 @@ var Handshake = plugin.HandshakeConfig{
    MagicCookieValue: "ef78114d-7bdf-411c-868f-347c99a78345",
 }

-// ListenerPlugin is the base struc for all kinds of go-plugin implementations
+// ListenerPlugin is the base struct for all kinds of go-plugin implementations
 // It will be included in interfaces of different Plugins
 type ABCIListenerPlugin struct {
    // GRPCPlugin must still implement the Plugin interface
@@ -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 outweights 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
@@ -134,7 +134,7 @@ app.UpgradeKeeper.SetUpgradeHandler("my-plan", func(ctx sdk.Context, plan upgrad
 Assuming a chain upgrades at block `n`, the procedure should run as follows:

 * the old binary will halt in `BeginBlock` when starting block `N`. In its store, the ConsensusVersions of the old binary's modules are stored.
-* the new binary will start at block `N`. The UpgradeHandler is set in the new binary, so will run at `BeginBlock` of the new binary. Inside `x/upgrade`'s `ApplyUpgrade`, the `VersionMap` will be retrieved from the (old binary's) store, and passed into the `RunMigrations` functon, migrating all module stores in-place before the modules' own `BeginBlock`s.
+* the new binary will start at block `N`. The UpgradeHandler is set in the new binary, so will run at `BeginBlock` of the new binary. Inside `x/upgrade`'s `ApplyUpgrade`, the `VersionMap` will be retrieved from the (old binary's) store, and passed into the `RunMigrations` function, migrating all module stores in-place before the modules' own `BeginBlock`s.

 ## Consequences

@@ -22,7 +22,7 @@ The legacy amino multi-signature mechanism of the Cosmos SDK has certain limitat
 * It requires `legacy_amino` sign mode ([#8141](https://github.com/cosmos/cosmos-sdk/issues/8141)).

 While the group module is not meant to be a total replacement for the current multi-signature accounts, it provides a solution to the limitations described above, with a more flexible key management system where keys can be added, updated or removed, as well as configurable thresholds.
-It's meant to be used with other access control modules such as [`x/feegrant`](./adr-029-fee-grant-module.md) ans [`x/authz`](adr-030-authz-module.md) to simplify key management for individuals and organizations.
+It's meant to be used with other access control modules such as [`x/feegrant`](./adr-029-fee-grant-module.md) and [`x/authz`](adr-030-authz-module.md) to simplify key management for individuals and organizations.

 The proof of concept of the group module can be found in https://github.com/regen-network/regen-ledger/tree/master/proto/regen/group/v1alpha1 and https://github.com/regen-network/regen-ledger/tree/master/x/group.

@@ -72,7 +72,7 @@ This mechanism can be easily composed with prioritization mechanisms:
 * we can add extra tiers out of a user control:
    * Example 1: user can set tier 0, 10 or 20, but the protocol will create tiers 0, 1, 2 ... 29. For example IBC transactions will go to tier `user_tier + 5`: if user selected tier 1, then the transaction will go to tier 15.
    * Example 2: we can reserve tier 4, 5, ... only for special transaction types. For example, tier 5 is reserved for evidence tx. So if submits a bank.Send transaction and set tier 5, it will be delegated to tier 3 (the max tier level available for any transaction). 
-    * Example 3: we can enforce that all transactions of a sepecific type will go to specific tier. For example, tier 100 will be reserved for evidence transactions and all evidence transactions will always go to that tier.
+    * Example 3: we can enforce that all transactions of a specific type will go to specific tier. For example, tier 100 will be reserved for evidence transactions and all evidence transactions will always go to that tier.

 ### `min-gas-prices`

@@ -31,7 +31,7 @@ acting as a delimiter between extensions. As the chunk hashes should be able to
 a delimiter to mark the end of the snapshot stream.

 Besides, we provide `Snapshotter` and `ExtensionSnapshotter` interface for modules to implement snapshotters, which will handle both taking 
-snapshot and the restoration. Each module could have mutiple snapshotters, and for modules with additional state, they should
+snapshot and the restoration. Each module could have multiple snapshotters, and for modules with additional state, they should
 implement `ExtensionSnapshotter` as extension snapshotters. When setting up the application, the snapshot `Manager` should call 
 `RegisterExtensions([]ExtensionSnapshotter…)` to register all the extension snapshotters.

@@ -72,7 +72,7 @@ or needs to be present only for signature integrity (see below).
 We require that the rendering of the transaction be invertible:
 there must be a parsing function such that for every transaction,
 when rendered to the textual representation,
-parsing that representation yeilds a proto message equivalent
+parsing that representation yields a proto message equivalent
 to the original under proto equality.

 Note that this inverse function does not need to perform correct
@@ -145,7 +145,7 @@ type SignDocTextual struct {
 ```

 We do not plan to use protobuf serialization to form the sequence of bytes
-that will be tranmitted and signed, in order to keep the decoder simple.
+that will be transmitted and signed, in order to keep the decoder simple.
 We will use [CBOR](https://cbor.io) ([RFC 8949](https://www.rfc-editor.org/rfc/rfc8949.html)) instead.
 The encoding is defined by the following CDDL ([RFC 8610](https://www.rfc-editor.org/rfc/rfc8610)):

@@ -81,7 +81,7 @@ The Cosmos SDK also provides a couple of other sign modes for particular use cas

 #### `SIGN_MODE_DIRECT_AUX`

-`SIGN_MODE_DIRECT_AUX` is a sign mode released in the Cosmos SDK v0.46 which targets transactions with multiple signers. Whereas `SIGN_MODE_DIRECT` expects each signer to sign over both `TxBody` and `AuthInfo` (which includes all other signers' signer infos, i.e. their account sequence, public key and mode info), `SIGN_MODE_DIRECT_AUX` allows N-1 signers to only sign over `TxBody` and _their own_ signer info. Morever, each auxiliary signer (i.e. a signer using `SIGN_MODE_DIRECT_AUX`) doesn't
+`SIGN_MODE_DIRECT_AUX` is a sign mode released in the Cosmos SDK v0.46 which targets transactions with multiple signers. Whereas `SIGN_MODE_DIRECT` expects each signer to sign over both `TxBody` and `AuthInfo` (which includes all other signers' signer infos, i.e. their account sequence, public key and mode info), `SIGN_MODE_DIRECT_AUX` allows N-1 signers to only sign over `TxBody` and _their own_ signer info. Moreover, each auxiliary signer (i.e. a signer using `SIGN_MODE_DIRECT_AUX`) doesn't
 need to sign over the fees:

 ```protobuf reference
@@ -71,7 +71,7 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/simapp/simd/cmd/root_v

 :::tip
 Use the `EnhanceRootCommand()` from the AutoCLI options to automatically add auto-generated commands from the modules to the root command.
-Additionnally it adds all manually defined modules commands (`tx` and `query`) as well.
+Additionally it adds all manually defined modules commands (`tx` and `query`) as well.
 Read more about [AutoCLI](https://docs.cosmos.network/main/core/autocli) in its dedicated section.
 :::

@@ -4,7 +4,7 @@ sidebar_position: 1

 # RunTx recovery middleware

-`BaseApp.runTx()` function handles Go panics that might occur during transactions execution, for example, keeper has faced an invalid state and paniced.
+`BaseApp.runTx()` function handles Go panics that might occur during transactions execution, for example, keeper has faced an invalid state and panicked.
 Depending on the panic type different handler is used, for instance the default one prints an error log message.
 Recovery middleware is used to add custom panic recovery for Cosmos SDK application developers.

@@ -16,7 +16,7 @@ With the separation of CometBFT and Cosmos-SDK, there is a lack of control of wh

 The acceptance of this RFC would move validation within `ValidateBasic` to the message server in modules, update tutorials and docs to remove mention of using `ValidateBasic` in favour of handling all validation for a message where it is executed.

-We can and will still support the `Validatebasic` function for users and provide an extension interface of the function once `sdk.Msg` is depreacted. 
+We can and will still support the `Validatebasic` function for users and provide an extension interface of the function once `sdk.Msg` is deprecated. 

 > Note: This is how messages are handled in VMs like Ethereum and CosmWasm. 

@@ -32,7 +32,7 @@
 > path and fall into the same pitfalls that we've since matured from. Abandoned ideas are a way to recognize that path 
 > and explain the pitfalls and why they were abandoned.

-## Descision
+## Decision

 > This section describes alternative designs to the chosen design. This section
 > is important and if an adr does not have any alternatives then it should be
@@ -16,6 +16,6 @@ In the Cosmos network, keys and addresses may refer to a number of different rol

 While all user facing interfaces to Cosmos software should exposed Bech32 interfaces, many internal interfaces encode binary value in hex or base64 encoded form.

-To covert between other binary representation of addresses and keys, it is important to first apply the Amino encoding process before Bech32 encoding.
+To convert between other binary representation of addresses and keys, it is important to first apply the Amino encoding process before Bech32 encoding.

 A complete implementation of the Amino serialization format is unnecessary in most cases. Simply prepending bytes from this [table](https://github.com/cometbft/cometbft/blob/main/spec/blockchain/encoding.md) to the byte string payload before Bech32 encoding will sufficient for compatible representation.
@@ -110,7 +110,7 @@ When there are multiple slashes, you just account for the accumulated slash fact
 In practice this will not really be an efficiency hit, as the number of slashes is expected to be 0 or 1 for most validators.
 Validators that get slashed more will naturally lose their delegators.
 A malicious validator that gets itself slashed many times would increase the gas to withdraw linearly, but the economic loss of funds due to the slashes is expected to far out-weigh the extra overhead the honest withdrawer must pay for due to the gas.
-(TODO: frame that above sentence in terms of griefing factors, as thats more correct)
+(TODO: frame that above sentence in terms of griefing factors, as that's more correct)

 \subsection{Inflation}
 Inflation is the idea that we want every staked coin to create more staking tokens as time progresses.