docs: fix several typos (#1506)

* fixing typos

* run make proto-gen

* more typos

* and more typos

* one more typo

.changelog/epilogue.md

@@ -81,7 +81,7 @@ Some PRs from v2.0.0 may reappear from other releases below. This is due to the
 
 * (feat!) Add DistributionTransmissionChannel to ConsumerAdditionProposal [#965](https://github.com/cosmos/interchain-security/pull/965)
 * (feat/fix) limit vsc matured packets handled per endblocker [#1004](https://github.com/cosmos/interchain-security/pull/1004)
-* (fix) cosumer key prefix order to avoid complex migrations [#963](https://github.com/cosmos/interchain-security/pull/963) and [#991](https://github.com/cosmos/interchain-security/pull/991). The latter PR is the proper fix.
+* (fix) consumer key prefix order to avoid complex migrations [#963](https://github.com/cosmos/interchain-security/pull/963) and [#991](https://github.com/cosmos/interchain-security/pull/991). The latter PR is the proper fix.
 * (feat) v1->v2 migrations to accommodate a bugfix having to do with store keys, introduce new params, and deal with consumer genesis state schema changes [#975](https://github.com/cosmos/interchain-security/pull/975) and [#997](https://github.com/cosmos/interchain-security/pull/997)
 * (deps) Bump github.com/cosmos/ibc-go/v4 from 4.4.0 to 4.4.2 [#982](https://github.com/cosmos/interchain-security/pull/982)
 * (fix) partially revert key assignment type safety PR [#980](https://github.com/cosmos/interchain-security/pull/980)

.github/workflows/deploy-docs.yml

@@ -1,5 +1,5 @@
 name: Deploy docs
-# This job builds and deploys documenation to github pages.
+# This job builds and deploys documentation to github pages.
 # It runs on every push to main with a change in the docs folder.
 on:
   workflow_dispatch:

CHANGELOG.md

@@ -161,9 +161,9 @@ Date: June 1st, 2023
 
 Unlike prior releases, the ICS `v2.0.0` release will be based on the main branch. `v2.0.0` will contain all the accumulated PRs from the various releases below, along with other PRs that were merged, but not released to production. After `v2.0.0`, we plan to revamp release practices, and how we modularize the repo for consumer/provider.
 
-Upgrading a provider from `v1.1.0-multiden` to `v2.0.0` will require state migrations. See [migration.go](x/ccv/provider/keeper/migration.go). See the provider module's `ConsensusVersion` in [module](x/ccv/provider/module.go)
+Upgrading a provider from `v1.1.0-multiden` to `v2.0.0` will require state migrations. See [migration.go](./x/ccv/provider/keeper/migration.go). See the provider module's `ConsensusVersion` in [module](./x/ccv/provider/module.go)
 
-Upgrading a consumer from `v1.2.0-multiden` to `v2.0.0` will NOT require state migrations. See the consumer module's `ConsensusVersion` in [module](x/ccv/consumer/module.go)
+Upgrading a consumer from `v1.2.0-multiden` to `v2.0.0` will NOT require state migrations. See the consumer module's `ConsensusVersion` in [module](./x/ccv/consumer/module.go)
 
 Some PRs from v2.0.0 may reappear from other releases below. This is due to the fact that ICS v1.1.0 deviates from the commit ordering of the main branch, and other releases thereafter are based on v1.1.0.
 
@@ -178,7 +178,7 @@ Some PRs from v2.0.0 may reappear from other releases below. This is due to the
 
 * (feat!) Add DistributionTransmissionChannel to ConsumerAdditionProposal [#965](https://github.com/cosmos/interchain-security/pull/965)
 * (feat/fix) limit vsc matured packets handled per endblocker [#1004](https://github.com/cosmos/interchain-security/pull/1004)
-* (fix) cosumer key prefix order to avoid complex migrations [#963](https://github.com/cosmos/interchain-security/pull/963) and [#991](https://github.com/cosmos/interchain-security/pull/991). The latter PR is the proper fix.
+* (fix) consumer key prefix order to avoid complex migrations [#963](https://github.com/cosmos/interchain-security/pull/963) and [#991](https://github.com/cosmos/interchain-security/pull/991). The latter PR is the proper fix.
 * (feat) v1->v2 migrations to accommodate a bugfix having to do with store keys, introduce new params, and deal with consumer genesis state schema changes [#975](https://github.com/cosmos/interchain-security/pull/975) and [#997](https://github.com/cosmos/interchain-security/pull/997)
 * (deps) Bump github.com/cosmos/ibc-go/v4 from 4.4.0 to 4.4.2 [#982](https://github.com/cosmos/interchain-security/pull/982)
 * (fix) partially revert key assignment type safety PR [#980](https://github.com/cosmos/interchain-security/pull/980)

TESTING.md

@@ -94,7 +94,7 @@ NOTE: versions < v9.0.0 are not compatible with ICS.
 
 ## Linters and Static Analysis
 
-Several analyzers are used on the code including [CodeQL](https://codeql.github.com/), [SonarCloud](https://sonarcloud.io/), [golangci-lint](https://golangci-lint.run/) and [gosec](https://github.com/securego/gosec). Some of these are run on github when committing to PRs ect, but some tools are also applicable locally, and are built into golang.
+Several analyzers are used on the code including [CodeQL](https://codeql.github.com/), [SonarCloud](https://sonarcloud.io/), [golangci-lint](https://golangci-lint.run/) and [gosec](https://github.com/securego/gosec). Some of these are run on github when committing to PRs etc, but some tools are also applicable locally, and are built into golang.
 
 ```bash
 # gofmt to format and simplify code (https://pkg.go.dev/cmd/gofmt)

app/consumer-democracy/app.go

@@ -986,10 +986,10 @@ func GetMaccPerms() map[string][]string {
 func initParamsKeeper(appCodec codec.BinaryCodec, legacyAmino *codec.LegacyAmino, key, tkey storetypes.StoreKey) paramskeeper.Keeper {
 	paramsKeeper := paramskeeper.NewKeeper(appCodec, legacyAmino, key, tkey)
 
-	paramsKeeper.Subspace(authtypes.ModuleName).WithKeyTable(authtypes.ParamKeyTable()) //nolint:staticcheck // TODO: remove this temorary solution
+	paramsKeeper.Subspace(authtypes.ModuleName).WithKeyTable(authtypes.ParamKeyTable()) //nolint:staticcheck // TODO: remove this temporary solution
 	paramsKeeper.Subspace(banktypes.ModuleName)
 	paramsKeeper.Subspace(stakingtypes.ModuleName)
-	paramsKeeper.Subspace(minttypes.ModuleName).WithKeyTable(minttypes.ParamKeyTable()) //nolint:staticcheck // TODO: remove this temorary solution
+	paramsKeeper.Subspace(minttypes.ModuleName).WithKeyTable(minttypes.ParamKeyTable()) //nolint:staticcheck // TODO: remove this temporary solution
 	paramsKeeper.Subspace(distrtypes.ModuleName)
 	paramsKeeper.Subspace(slashingtypes.ModuleName)
 	paramsKeeper.Subspace(govtypes.ModuleName).WithKeyTable(gov.ProvideKeyTable())

app/params/doc.go

@@ -3,9 +3,9 @@ Package params defines the simulation parameters in the gaia.
 
 It contains the default weights used for each transaction used on the module's
 simulation. These weights define the chance for a transaction to be simulated at
-any gived operation.
+any given operation.
 
-You can repace the default values for the weights by providing a params.json
+You can replace the default values for the weights by providing a params.json
 file with the weights defined for each of the transaction operations:
 
 	{

docs/docs/consumer-development/changeover-procedure.md

@@ -56,7 +56,7 @@ RevisionNumber: 0, RevisionHeight: 111
 * `distribution_transmission_channel` **should be set**.
 
 :::note
-Populating `distribution_transmission_channel` will enable the standalone chain to re-use one of the existing channels to the provider for consumer chain rewards distribution. This will preserve the `ibc denom` that may already be in use.
+Populating `distribution_transmission_channel` will enable the standalone chain to reuse one of the existing channels to the provider for consumer chain rewards distribution. This will preserve the `ibc denom` that may already be in use.
 
 If the parameter is not set, a new channel will be created.
 :::
@@ -84,7 +84,7 @@ Otherwise, the upgrade is indistinguishable from a regular on-chain upgrade prop
 
 ### 3. spawn time is reached
 
-When the `spawn_time` is reached on the `provider` it will generate a `ConsumerGenesis` that contains the validator set that will supercede the `standalone` validator set.
+When the `spawn_time` is reached on the `provider` it will generate a `ConsumerGenesis` that contains the validator set that will supersede the `standalone` validator set.
 
 This `ConsumerGenesis` must be available on the standalone chain during the on-chain upgrade.
 
@@ -93,7 +93,7 @@ This `ConsumerGenesis` must be available on the standalone chain during the on-c
 Performing the on-chain upgrade on the standalone chain will add the `ccv/consumer` module and allow the chain to become a `consumer` of replicated security.
 
 :::caution
-The `ConsumerGenesis` must be exported to a file and placed in the correct folder on the standalone chain before the upgade.
+The `ConsumerGenesis` must be exported to a file and placed in the correct folder on the standalone chain before the upgrade.
 
 The file must be placed at the exact specified location, otherwise the upgrade will not be executed correctly.
 

docs/docs/consumer-development/consumer-genesis-transformation.md

@@ -5,7 +5,7 @@ sidebar_position: 6
 # Consumer Genesis Transformation
 
 Preparing a consumer chain for onboarding requires some information explaining how to run your chain. This includes a genesis file with CCV data where the CCV data is exported from the provider chain and added to the consumers genesis file (for more details check the documentation on [Onboarding](./onboarding.md) and [Changeover](./changeover-procedure.md)).
-In case that the provider chain is running an older version of the InterChainSecurity (ICS) module than the consumer chain the exported CCV data might need to be transformed to the format supported by the ICS implementation run on the consumer chain. This is the case if the cosumer chain runs version 4 of ICS or later and the provider is running version 3 or older of the ICS module.
+In case that the provider chain is running an older version of the InterChainSecurity (ICS) module than the consumer chain the exported CCV data might need to be transformed to the format supported by the ICS implementation run on the consumer chain. This is the case if the consumer chain runs version 4 of ICS or later and the provider is running version 3 or older of the ICS module.
 
 To transform such CCV data follow the instructions below
 
@@ -15,7 +15,7 @@ To transform such CCV data follow the instructions below
 - interchain-security-cd application complies to the version run on the consumer chain
 
 ## 2. Export the CCV data
-Export the CCV data from the provider chain as descibed in the [Onboarding](./onboarding.md) and [Changeover](./changeover-procedure.md)) your following.
+Export the CCV data from the provider chain as described in the [Onboarding](./onboarding.md) and [Changeover](./changeover-procedure.md)) your following.
 As a result the CCV data will be stored in a file in JSON format.
 
 ## 3. Transform CCV data

docs/old/quality_assurance.md

@@ -86,7 +86,7 @@ The main concern addressed in this section is the correctness of the provider ch
 | 4.07 | A validator cannot get slashed multiple times for downtime on the same consumer chain without requesting to `Unjail` itself on the provider chain in between | `Scheduled` | `NA` | `Partial coverage` <br> [TestSendSlashPacket](../../tests/integration/slashing.go) | `Partial coverage` | `Scheduled` | `NA` |
 | 4.08 | A validator can be slashed multiple times for downtime on different chains | `Scheduled` | `NA` | `Future work` | `NA` | `Scheduled` | `NA` |
 | 4.09 | The provider chain can easily be restarted with IS enabled <br> - `ExportGenesis` & `InitGenesis`  <br> - requires https://github.com/informalsystems/hermes/issues/1152| `Scheduled` | `Done` <br> [TestInitAndExportGenesis](../../x/ccv/provider/keeper/genesis_test.go#L20) | `Future work` | `Future work` | `Scheduled` | `NA` |
-| 4.10 | The provider chain can graciously handle a CCV packet timing out (without shuting down) <br> - expected outcome: consumer chain shuts down and its state in provider CCV module is removed | `Scheduled` | `Scheduled` | `NA` | `Future work` | `Scheduled` | `NA` |
+| 4.10 | The provider chain can graciously handle a CCV packet timing out (without shutting down) <br> - expected outcome: consumer chain shuts down and its state in provider CCV module is removed | `Scheduled` | `Scheduled` | `NA` | `Future work` | `Scheduled` | `NA` |
 | 4.11 | The provider chain can graciously handle a `ConsumerRemovalProposal` <br> - expected outcome: consumer chain shuts down and its state in provider CCV module is removed | `Scheduled` | `Done` <br> [TestHandleConsumerRemovalProposal](../../x/ccv/provider/keeper/proposal_test.go#L313) | `NA` | `Future work` | `Scheduled` | `NA` |
 | 4.12 | The provider chain can graciously handle a `ConsumerAdditionProposal` <br> - expected outcome: a consumer chain is registered and a client is created | `Scheduled` |`Done` <br> [TestHandleConsumerAdditionProposal](../../x/ccv/provider/keeper/proposal_test.go#L31) | `NA` | `Future work` | `Scheduled` | `NA` |
 

docs/src/css/custom.css

@@ -1,5 +1,5 @@
 /*
-  Slighlty modified version of https://github.com/ignite/cli/blob/develop/docs/src/css/custom.css
+  Slightly modified version of https://github.com/ignite/cli/blob/develop/docs/src/css/custom.css
 */
 
 @import "tailwindcss/base";

proto/interchain_security/ccv/consumer/v1/genesis.proto

@@ -70,7 +70,7 @@ message OutstandingDowntime { string validator_consensus_address = 1; }
 
 // LastTransmissionBlockHeight is the last time validator holding
 // pools were transmitted to the provider chain. This type is used internally
-// to the consumer CCV modul.
+// to the consumer CCV module.
 message LastTransmissionBlockHeight { int64 height = 1; }
 
 // MaturingVSCPacket represents a vsc packet that is maturing internal to the

proto/interchain_security/ccv/consumer/v1/query.proto

@@ -44,7 +44,7 @@ message NextFeeDistributionEstimate {
   string distribution_fraction = 4;
   // total accruead fees at the time of querying
   string total = 5;
-  // amount distibuted to provider chain
+  // amount distributed to provider chain
   string toProvider = 6;
   // amount distributed (kept) by consumer chain
   string toConsumer = 7;

proto/interchain_security/ccv/provider/v1/genesis.proto

@@ -77,7 +77,7 @@ message ConsumerState {
 }
 
 // ValsetUpdateIdToHeight defines the genesis information for the mapping
-// of each valset udpate id to a block height
+// of each valset update id to a block height
 message ValsetUpdateIdToHeight {
   uint64 valset_update_id = 1;
   uint64 height = 2;

proto/interchain_security/ccv/provider/v1/provider.proto

@@ -81,7 +81,7 @@ message ConsumerAdditionProposal {
   // channel is created on top of the same connection as the CCV channel.
   // Note that transfer_channel_id is the ID of the channel end on the consumer
   // chain. it is most relevant for chains performing a sovereign to consumer
-  // changeover in order to maintan the existing ibc transfer channel
+  // changeover in order to maintain the existing ibc transfer channel
   string distribution_transmission_channel = 14;
 }
 

proto/interchain_security/ccv/v1/wire.proto

@@ -107,7 +107,7 @@ message SlashPacketDataV1 {
   InfractionType infraction = 3;
 }
 
-// InfractionType indicates the infraction type a validator commited.
+// InfractionType indicates the infraction type a validator committed.
 // Note ccv.InfractionType to maintain compatibility between ICS versions
 // using different versions of the cosmos-sdk and ibc-go modules.
 enum InfractionType {

tests/difference/core/docs/METHOD.md

@@ -45,7 +45,7 @@ We have three major components, a model and driver, and the SUT. The creation of
 2. Figure out which API calls influence that state.
 3. Create the simplest possible implementation of those API calls that results in the correct state. This is the raw model.
 4. Randomly make API calls against your model. You might need some heuristics or bespoke logic to make sure these random calls result in good coverage (see [Limitations](#limitations)).
-5. Record the random API calls made ('actions') and obervations of the state made at regular intervals. Together this data forms a trace. Repeated many times from the zero state you obtain *traces*.
+5. Record the random API calls made ('actions') and observations of the state made at regular intervals. Together this data forms a trace. Repeated many times from the zero state you obtain *traces*.
 6. Create a 'driver': some code that wraps the API of the SUT and can interpret traces and 'test' those traces against the SUT. For each tested trace, setup the SUT to a suitable zero state, and make each API call as in the trace. For each state observation in the trace, check that the SUT state corresponds.
 
 ## Benefits
@@ -99,7 +99,7 @@ The model could be the spec, if you want it to be. All the dependencies should b
 
 ### Creating many implementations from a single model
 
-The same model can be used to create drivers for, and test, many different implementations of the system in any language, environment ect
+The same model can be used to create drivers for, and test, many different implementations of the system in any language, environment etc
 
 ## Comparison to Model Based Testing
 
@@ -109,7 +109,7 @@ Informal Systems uses the term model based testing to refer to, essentially diff
 Example languages: [TLA+](https://en.wikipedia.org/wiki/TLA%2B), [Quint](https://github.com/informalsystems/quint). Example semantic: [Temporal Logic of Actions](https://en.wikipedia.org/wiki/Temporal_logic_of_actions). Example techniques: [SAT Solving](https://en.wikipedia.org/wiki/SAT_solver), [Symbolic Model Checking](https://blog.acolyer.org/2019/11/29/tla-model-checking-made-symbolic/), [State Enumerating Model Checking](https://en.wikipedia.org/wiki/State_space_enumeration). Example tools: [TLC](https://github.com/tlaplus/tlaplus), [Apalache](https://apalache.informal.systems/).
 - The model is explored not by randomness and heuristics but by using a [*model checker*](https://en.wikipedia.org/wiki/Model_checking). Model checkers pull on a massive field of research and they're about applying efficient techniques for exploring program behaviors. While modern model checkers are highly optimized and capable, they are not silver bullets, as they all suffer from the [State Space Explosion Problem](https://en.wikipedia.org/wiki/Combinatorial_explosion). See [this wiki page](https://en.wikipedia.org/wiki/Model_checking#Techniques) for more info.
 
-Why not use model checking? They require expert knowledge which is hard to onboard, the State Space Explosion Problem can be very real in practice, and the tooling e.g TLA+ is generally not industrial strength in terms of maintainability ect.
+Why not use model checking? They require expert knowledge which is hard to onboard, the State Space Explosion Problem can be very real in practice, and the tooling e.g TLA+ is generally not industrial strength in terms of maintainability etc.
 
 Note that the Apalache team at Informal is working hard to make MBT a powerful practical tool. They have made leaps and bounds in the last year since diff testing began in April 2022. In particular they have created a new programming language called Quint which should be an industrial strength formal specification language. They have also added powerful exploration capabilities (see [::simulate](https://apalache.informal.systems/docs/apalache/running.html?highlight=simulate#running-the-tool)) which combines random exploration with optimized model checker based exploration.
 

tests/difference/core/driver/setup.go

@@ -617,7 +617,7 @@ func GetZeroState(
 	simibc.BeginBlock(b.consumer(), initState.BlockInterval)
 
 	// Update clients to the latest header. Now everything is ready to go!
-	// Ignore errors for brevity. Everything is checked in Assuptions test.
+	// Ignore errors for brevity. Everything is checked in Assumptions test.
 	_ = simibc.UpdateReceiverClient(b.consumerEndpoint(), b.providerEndpoint(), lastConsumerHeader)
 	_ = simibc.UpdateReceiverClient(b.providerEndpoint(), b.consumerEndpoint(), lastProviderHeader)
 

tests/difference/core/model/src/common.ts

@@ -9,7 +9,7 @@ enum Status {
 }
 
 /**
- * All the data needed to represent an undelegation occuring
+ * All the data needed to represent an undelegation occurring
  * in the sdk staking module.
  */
 interface Undelegation {
@@ -25,7 +25,7 @@ interface Undelegation {
 
 /**
  * All the data needed to represent an unbonding validator
- * occuring in the sdk staking module.
+ * occurring in the sdk staking module.
  */
 interface Unval {
   val: Validator;

tests/difference/core/model/src/properties.ts

@@ -102,7 +102,7 @@ class PartialOrder {
    *
    * @param chain chain of block
    * @param height height of block
-   * @returns Returns the height of the least successing block on the counterparty
+   * @returns Returns the height of the least successor block on the counterparty
    * chain if it exists, else undefined.
    */
   getLeastSucc = (chain: Chain, height: number): number | undefined => {