From b49b39dd4096f8014379cff71de90f82cadcf003 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Thu, 7 Mar 2024 09:55:16 +0100 Subject: [PATCH] docs: fix typos (#5930) * fix typo * fix typos * fix typo * fix typos --------- Co-authored-by: DimitrisJim --- docs/README.md | 2 +- .../requirements/channel-upgradability-requirements.md | 2 +- docs/requirements/ics08-requirements.md | 10 +++++----- docs/requirements/ics27-v2-requirements.md | 4 ++-- 4 files changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/README.md b/docs/README.md index 00e11144e3e..c8b1e4d6ce2 100644 --- a/docs/README.md +++ b/docs/README.md @@ -183,7 +183,7 @@ Technically, there are four docs being maintained in this repo: When referencing a markdown file, you should use relative file paths if they are in the same docs directory from above. For example, if you are in `docs/docs/01-ibc` and want to link to `docs/docs/02-apps/01-transfer/01-overview.md`, you should use the relative link `../02-apps/01-transfer/01-overview.md`. -If the file you are referencing is in a different docs directory, you should use a absolute URL. For example, if you are in `docs/docs/01-ibc` and want to link to `docs/architecture/adr-001-coin-source-tracing.md`, you should use the absolute URL (not absolute file path), in this case `/architecture/adr-001-coin-source-tracing`. You can find the absolute URL by looking at the slug in the frontmatter of the markdown file you want to link to. If the frontmatter slug is not set (such as in `docs/architecture/adr-001-coin-source-tracing.md`), you should use the url that docusaurus generates for it. You can find this by looking at the url of the page in the browser. +If the file you are referencing is in a different docs directory, you should use an absolute URL. For example, if you are in `docs/docs/01-ibc` and want to link to `docs/architecture/adr-001-coin-source-tracing.md`, you should use the absolute URL (not absolute file path), in this case `/architecture/adr-001-coin-source-tracing`. You can find the absolute URL by looking at the slug in the frontmatter of the markdown file you want to link to. If the frontmatter slug is not set (such as in `docs/architecture/adr-001-coin-source-tracing.md`), you should use the url that docusaurus generates for it. You can find this by looking at the url of the page in the browser. Note that when referencing any file outside of the parent `docs/` directory, you should always use a hyperlink. diff --git a/docs/requirements/channel-upgradability-requirements.md b/docs/requirements/channel-upgradability-requirements.md index 87093b989b6..8d706f54e4c 100644 --- a/docs/requirements/channel-upgradability-requirements.md +++ b/docs/requirements/channel-upgradability-requirements.md @@ -152,7 +152,7 @@ Sample exception flows: | 3.04 | The `ChanUpgradeAck` datagram informs the chain of the timeout period specified by the counterparty for the upgrade process to complete | TBD | `Drafted` | | 3.05 | When channel is in `FLUSHING` state, no new packets are allowed to be sent | TBD | `Drafted` | | 3.06 | When channel is in `FLUSHING` state, it is only allowed to receive packets with sequence number smaller or equal than the sequence number of the last packet sent on the counterparty when the channel moved to `FLUSHING` state | TBD | `Drafted` | -| 3.07 | When channel is in `FLUSHING` state and packets are acknowledged or timed out, if the counterparty-specified timeoud is reached, then the channel will be restored to its initial state, an error receipt will be written and the upgrade will be aborted | TBD | `Drafted` | +| 3.07 | When channel is in `FLUSHING` state and packets are acknowledged or timed out, if the counterparty-specified timeout is reached, then the channel will be restored to its initial state, an error receipt will be written and the upgrade will be aborted | TBD | `Drafted` | | 3.08 | Once in-flight packets have been flushed, the channel state shall change from `FLUSHING` to `FLUSHCOMPLETE` | TBD | `Drafted` | | 3.09 | A relayer must initiate the `ChanUpgradeConfirm` datagram on the counterparty to inform of the timeout period specified by the counterparty for the upgrade process to complete | TBD | `Drafted` | | 3.10 | Successful execution of the `ChanUpgradeConfirm` datagram when the channel state is `FLUSHCOMPLETE` changes the channel state to `OPEN` | TBD | `Drafted` | diff --git a/docs/requirements/ics08-requirements.md b/docs/requirements/ics08-requirements.md index 34c5a4d51c7..7c4e9e3f70b 100644 --- a/docs/requirements/ics08-requirements.md +++ b/docs/requirements/ics08-requirements.md @@ -32,11 +32,11 @@ it becomes a proper solution to port the code for ibc-go to interpret without re ## Objectives -The objective of this module is to have allow two chains with heterogenous consensus algorithms being connected through light clients that are not necesarily written in Go, but compiled to Wasm instead. +The objective of this module is to have allow two chains with heterogenous consensus algorithms being connected through light clients that are not necessarily written in Go, but compiled to Wasm instead. ## Scope -The scope of this feature is to allow any implemention written in Wasm to be compliant with the interface +The scope of this feature is to allow any implementation written in Wasm to be compliant with the interface expressed in [02-client `ClientState` interface](https://github.com/cosmos/ibc-go/blob/main/modules/core/exported/client.go#L44-L139). | Features | Release | @@ -44,7 +44,7 @@ expressed in [02-client `ClientState` interface](https://github.com/cosmos/ibc-g | Store light client contract bytecode by means of a governance proposal. | v1 | | Dispatch messages to a light client written in Wasm following the `ClientState` interface. | v1 | | Migrate the contract instance of a light client to a newer contract bytecode. | v1 | -| Remove checksums from the list of allowed checksums to dissalow contract instantiation. | v1 | +| Remove checksums from the list of allowed checksums to disallow contract instantiation. | v1 | | Support GRANDPA light client. | v1 | # User requirements @@ -108,7 +108,7 @@ The first use case that this module will enable is the connection between GRANDP | ID | Description | Verification | Status | Release | | -- | ----------- | ------------ | ------ | ------- | -| 6.01 | The 08-wasm module must ensure that the contracts do not remove or corrupt the the stored client state state. | See [here](https://github.com/cosmos/ibc-go/blob/modules/light-clients/08-wasm/v0.1.0%2Bibc-go-v8.0-wasmvm-v1.5/modules/light-clients/08-wasm/types/vm.go#L227). | `Verified` | v0.1.0 | +| 6.01 | The 08-wasm module must ensure that the contracts do not remove or corrupt the stored client state state. | See [here](https://github.com/cosmos/ibc-go/blob/modules/light-clients/08-wasm/v0.1.0%2Bibc-go-v8.0-wasmvm-v1.5/modules/light-clients/08-wasm/types/vm.go#L227). | `Verified` | v0.1.0 | | 6.02 | The 08-wasm module must ensure that the contracts do not include in the response to sudo, instantiate or migrate calls messages, events or attributes. | See [here](https://github.com/cosmos/ibc-go/blob/modules/light-clients/08-wasm/v0.1.0%2Bibc-go-v8.0-wasmvm-v1.5/modules/light-clients/08-wasm/types/vm.go#L300). | `Verified` | v0.1.0 | # External interface requirements @@ -121,4 +121,4 @@ The first use case that this module will enable is the connection between GRANDP | -- | ----------- | ------------ | ------ | ------- | | 6.01 | There shall be a CLI command available to query the bytecode of a light client Wasm contract by checksum. | See [here](https://github.com/cosmos/ibc-go/blob/modules/light-clients/08-wasm/v0.1.0%2Bibc-go-v8.0-wasmvm-v1.5/modules/light-clients/08-wasm/keeper/grpc_query.go#L23). | `Verified` | v0.1.0 | | 7.02 | There shall be a CLI command available to query the checksums for all deployed light client Wasm contracts. | See [here](https://github.com/cosmos/ibc-go/blob/modules/light-clients/08-wasm/v0.1.0%2Bibc-go-v8.0-wasmvm-v1.5/modules/light-clients/08-wasm/keeper/grpc_query.go#L49). | `Verified` | v0.1.0 | - \ No newline at end of file + diff --git a/docs/requirements/ics27-v2-requirements.md b/docs/requirements/ics27-v2-requirements.md index d3acdc5fd60..dded8bd6b7e 100644 --- a/docs/requirements/ics27-v2-requirements.md +++ b/docs/requirements/ics27-v2-requirements.md @@ -4,7 +4,7 @@ ## Problem -We believe that the lack of controller chains so far have been because: +We believe that the lack of controller chains so far has been because: - We did not develop a standardized authentication module, which created a bottleneck for chains looking to integrate the controller submodule. - We did not have a clear understanding of all the use cases ICA would facilitate. @@ -66,7 +66,7 @@ See section [Definitions](https://github.com/cosmos/ibc/blob/main/spec/app/ics-0 | ID | Description | Verification | Status | Release | | --- | ----------- | ------------ | ------ | ------- | -| 2.01 | An application shall have the ability to use an RPC endpoint to submit transactions to be executed on the host chain on the behalf of the interchain account. | [Acceptance test](https://github.com/cosmos/ibc-go/blob/v6.0.0/modules/apps/27-interchain-accounts/controller/keeper/msg_server_test.go#L31) | `Verified` | v6.0.0 | +| 2.01 | An application shall have the ability to use an RPC endpoint to submit transactions to be executed on the host chain on behalf of the interchain account. | [Acceptance test](https://github.com/cosmos/ibc-go/blob/v6.0.0/modules/apps/27-interchain-accounts/controller/keeper/msg_server_test.go#L31) | `Verified` | v6.0.0 | # Non-functional requirements