From 62ae007a24a2a02fb6f5a3839deecb5f0b611022 Mon Sep 17 00:00:00 2001 From: Ocenka Date: Tue, 17 Dec 2024 09:42:29 +0000 Subject: [PATCH] Fix: Correct Typographical Errors in Documentation (#7693) * typos 02-integration.md * typos 00-intro.md * typos 00-intro.md * typos 00-intro.md * typos 00-intro.md * typos 05-v3-to-v4.md * typos 00-intro.md * typos 00-intro.md * typos 10-roadmap.md * chore: fix n -> a typo --------- Co-authored-by: Damian Nolan --- docs/docs/01-ibc/02-integration.md | 2 +- docs/docs/01-ibc/05-upgrades/00-intro.md | 2 +- .../version-v4.6.x/01-ibc/05-upgrades/00-intro.md | 2 +- .../version-v5.4.x/01-ibc/05-upgrades/00-intro.md | 2 +- .../version-v6.3.x/01-ibc/05-upgrades/00-intro.md | 2 +- docs/versioned_docs/version-v6.3.x/04-migrations/05-v3-to-v4.md | 2 +- .../version-v7.8.x/01-ibc/05-upgrades/00-intro.md | 2 +- .../version-v8.5.x/01-ibc/05-upgrades/00-intro.md | 2 +- docs/versioned_docs/version-v8.5.x/01-ibc/10-roadmap.md | 2 +- 9 files changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/docs/01-ibc/02-integration.md b/docs/docs/01-ibc/02-integration.md index def03102de0..4a2a771590d 100644 --- a/docs/docs/01-ibc/02-integration.md +++ b/docs/docs/01-ibc/02-integration.md @@ -255,7 +255,7 @@ app.ModuleManager = module.NewManager( ### Application ABCI ordering -One addition from IBC is the concept of `HistoricalInfo` which is stored in the Cosmos SDK `x/staking` module. The number of records stored by `x/staking` is controlled by the `HistoricalEntries` parameter which stores `HistoricalInfo` on a per height basis. +One addition from IBC is the concept of `HistoricalInfo` which is stored in the Cosmos SDK `x/staking` module. The number of records stored by `x/staking` is controlled by the `HistoricalEntries` parameter which stores `HistoricalInfo` on a per-height basis. Each entry contains the historical information for the `Header` and `ValidatorSet` of this chain which is stored at each height during the `BeginBlock` call. The `HistoricalInfo` is required to introspect a blockchain's prior state at a given height in order to verify the light client `ConsensusState` during the connection handshake. diff --git a/docs/docs/01-ibc/05-upgrades/00-intro.md b/docs/docs/01-ibc/05-upgrades/00-intro.md index 61711d35f01..d9b8ef25fae 100644 --- a/docs/docs/01-ibc/05-upgrades/00-intro.md +++ b/docs/docs/01-ibc/05-upgrades/00-intro.md @@ -9,7 +9,7 @@ slug: /ibc/upgrades/intro This directory contains information on how to upgrade an IBC chain without breaking counterparty clients and connections. -IBC-connected chains must be able to upgrade without breaking connections to other chains. Otherwise there would be a massive disincentive towards upgrading and disrupting high-value IBC connections, thus preventing chains in the IBC ecosystem from evolving and improving. Many chain upgrades may be irrelevant to IBC, however some upgrades could potentially break counterparty clients if not handled correctly. Thus, any IBC chain that wishes to perform a IBC-client-breaking upgrade must perform an IBC upgrade in order to allow counterparty clients to securely upgrade to the new light client. +IBC-connected chains must be able to upgrade without breaking connections to other chains. Otherwise there would be a massive disincentive towards upgrading and disrupting high-value IBC connections, thus preventing chains in the IBC ecosystem from evolving and improving. Many chain upgrades may be irrelevant to IBC, however some upgrades could potentially break counterparty clients if not handled correctly. Thus, any IBC chain that wishes to perform an IBC-client-breaking upgrade must perform an IBC upgrade in order to allow counterparty clients to securely upgrade to the new light client. 1. The [quick-guide](./01-quick-guide.md) describes how IBC-connected chains can perform client-breaking upgrades and how relayers can securely upgrade counterparty clients using the SDK. 2. The [developer-guide](./02-developer-guide.md) is a guide for developers intending to develop IBC client implementations with upgrade functionality. diff --git a/docs/versioned_docs/version-v4.6.x/01-ibc/05-upgrades/00-intro.md b/docs/versioned_docs/version-v4.6.x/01-ibc/05-upgrades/00-intro.md index 3ff92aba64f..8d2b85c6f30 100644 --- a/docs/versioned_docs/version-v4.6.x/01-ibc/05-upgrades/00-intro.md +++ b/docs/versioned_docs/version-v4.6.x/01-ibc/05-upgrades/00-intro.md @@ -9,7 +9,7 @@ slug: /ibc/upgrades/intro This directory contains information on how to upgrade an IBC chain without breaking counterparty clients and connections. -IBC-connnected chains must be able to upgrade without breaking connections to other chains. Otherwise there would be a massive disincentive towards upgrading and disrupting high-value IBC connections, thus preventing chains in the IBC ecosystem from evolving and improving. Many chain upgrades may be irrelevant to IBC, however some upgrades could potentially break counterparty clients if not handled correctly. Thus, any IBC chain that wishes to perform a IBC-client-breaking upgrade must perform an IBC upgrade in order to allow counterparty clients to securely upgrade to the new light client. +IBC-connnected chains must be able to upgrade without breaking connections to other chains. Otherwise there would be a massive disincentive towards upgrading and disrupting high-value IBC connections, thus preventing chains in the IBC ecosystem from evolving and improving. Many chain upgrades may be irrelevant to IBC, however some upgrades could potentially break counterparty clients if not handled correctly. Thus, any IBC chain that wishes to perform an IBC-client-breaking upgrade must perform an IBC upgrade in order to allow counterparty clients to securely upgrade to the new light client. 1. The [quick-guide](./01-quick-guide.md) describes how IBC-connected chains can perform client-breaking upgrades and how relayers can securely upgrade counterparty clients using the SDK. 2. The [developer-guide](./02-developer-guide.md) is a guide for developers intending to develop IBC client implementations with upgrade functionality. diff --git a/docs/versioned_docs/version-v5.4.x/01-ibc/05-upgrades/00-intro.md b/docs/versioned_docs/version-v5.4.x/01-ibc/05-upgrades/00-intro.md index 14c82d3ff0d..4fd3f740ca7 100644 --- a/docs/versioned_docs/version-v5.4.x/01-ibc/05-upgrades/00-intro.md +++ b/docs/versioned_docs/version-v5.4.x/01-ibc/05-upgrades/00-intro.md @@ -2,7 +2,7 @@ This directory contains information on how to upgrade an IBC chain without breaking counterparty clients and connections. -IBC-connnected chains must be able to upgrade without breaking connections to other chains. Otherwise there would be a massive disincentive towards upgrading and disrupting high-value IBC connections, thus preventing chains in the IBC ecosystem from evolving and improving. Many chain upgrades may be irrelevant to IBC, however some upgrades could potentially break counterparty clients if not handled correctly. Thus, any IBC chain that wishes to perform a IBC-client-breaking upgrade must perform an IBC upgrade in order to allow counterparty clients to securely upgrade to the new light client. +IBC-connnected chains must be able to upgrade without breaking connections to other chains. Otherwise there would be a massive disincentive towards upgrading and disrupting high-value IBC connections, thus preventing chains in the IBC ecosystem from evolving and improving. Many chain upgrades may be irrelevant to IBC, however some upgrades could potentially break counterparty clients if not handled correctly. Thus, any IBC chain that wishes to perform an IBC-client-breaking upgrade must perform an IBC upgrade in order to allow counterparty clients to securely upgrade to the new light client. 1. The [quick-guide](./01-quick-guide.md) describes how IBC-connected chains can perform client-breaking upgrades and how relayers can securely upgrade counterparty clients using the SDK. 2. The [developer-guide](./02-developer-guide.md) is a guide for developers intending to develop IBC client implementations with upgrade functionality. diff --git a/docs/versioned_docs/version-v6.3.x/01-ibc/05-upgrades/00-intro.md b/docs/versioned_docs/version-v6.3.x/01-ibc/05-upgrades/00-intro.md index 3ff92aba64f..8d2b85c6f30 100644 --- a/docs/versioned_docs/version-v6.3.x/01-ibc/05-upgrades/00-intro.md +++ b/docs/versioned_docs/version-v6.3.x/01-ibc/05-upgrades/00-intro.md @@ -9,7 +9,7 @@ slug: /ibc/upgrades/intro This directory contains information on how to upgrade an IBC chain without breaking counterparty clients and connections. -IBC-connnected chains must be able to upgrade without breaking connections to other chains. Otherwise there would be a massive disincentive towards upgrading and disrupting high-value IBC connections, thus preventing chains in the IBC ecosystem from evolving and improving. Many chain upgrades may be irrelevant to IBC, however some upgrades could potentially break counterparty clients if not handled correctly. Thus, any IBC chain that wishes to perform a IBC-client-breaking upgrade must perform an IBC upgrade in order to allow counterparty clients to securely upgrade to the new light client. +IBC-connnected chains must be able to upgrade without breaking connections to other chains. Otherwise there would be a massive disincentive towards upgrading and disrupting high-value IBC connections, thus preventing chains in the IBC ecosystem from evolving and improving. Many chain upgrades may be irrelevant to IBC, however some upgrades could potentially break counterparty clients if not handled correctly. Thus, any IBC chain that wishes to perform an IBC-client-breaking upgrade must perform an IBC upgrade in order to allow counterparty clients to securely upgrade to the new light client. 1. The [quick-guide](./01-quick-guide.md) describes how IBC-connected chains can perform client-breaking upgrades and how relayers can securely upgrade counterparty clients using the SDK. 2. The [developer-guide](./02-developer-guide.md) is a guide for developers intending to develop IBC client implementations with upgrade functionality. diff --git a/docs/versioned_docs/version-v6.3.x/04-migrations/05-v3-to-v4.md b/docs/versioned_docs/version-v6.3.x/04-migrations/05-v3-to-v4.md index d916ec51252..859e135b1d6 100644 --- a/docs/versioned_docs/version-v6.3.x/04-migrations/05-v3-to-v4.md +++ b/docs/versioned_docs/version-v6.3.x/04-migrations/05-v3-to-v4.md @@ -157,4 +157,4 @@ if err := k.icaControllerKeeper.RegisterInterchainAccount(ctx, msg.ConnectionId, When using the `DenomTrace` gRPC, the full IBC denomination with the `ibc/` prefix may now be passed in. -Crossing hellos are no longer supported by core IBC for 03-connection and 04-channel. The handshake should be completed in the logical 4 step process (INIT, TRY, ACK, CONFIRM). +Crossing hellos are no longer supported by core IBC for 03-connection and 04-channel. The handshake should be completed in the logical 4-step process (INIT, TRY, ACK, CONFIRM). diff --git a/docs/versioned_docs/version-v7.8.x/01-ibc/05-upgrades/00-intro.md b/docs/versioned_docs/version-v7.8.x/01-ibc/05-upgrades/00-intro.md index d97ac898277..3b979ea9c9f 100644 --- a/docs/versioned_docs/version-v7.8.x/01-ibc/05-upgrades/00-intro.md +++ b/docs/versioned_docs/version-v7.8.x/01-ibc/05-upgrades/00-intro.md @@ -9,7 +9,7 @@ slug: /ibc/upgrades/intro This directory contains information on how to upgrade an IBC chain without breaking counterparty clients and connections. -IBC-connnected chains must be able to upgrade without breaking connections to other chains. Otherwise there would be a massive disincentive towards upgrading and disrupting high-value IBC connections, thus preventing chains in the IBC ecosystem from evolving and improving. Many chain upgrades may be irrelevant to IBC, however some upgrades could potentially break counterparty clients if not handled correctly. Thus, any IBC chain that wishes to perform a IBC-client-breaking upgrade must perform an IBC upgrade in order to allow counterparty clients to securely upgrade to the new light client. +IBC-connnected chains must be able to upgrade without breaking connections to other chains. Otherwise there would be a massive disincentive towards upgrading and disrupting high-value IBC connections, thus preventing chains in the IBC ecosystem from evolving and improving. Many chain upgrades may be irrelevant to IBC, however some upgrades could potentially break counterparty clients if not handled correctly. Thus, any IBC chain that wishes to perform an IBC-client-breaking upgrade must perform an IBC upgrade in order to allow counterparty clients to securely upgrade to the new light client. 1. The [quick-guide](./01-quick-guide.md) describes how IBC-connected chains can perform client-breaking upgrades and how relayers can securely upgrade counterparty clients using the SDK. 2. The [developer-guide](./02-developer-guide.md) is a guide for developers intending to develop IBC client implementations with upgrade functionality. diff --git a/docs/versioned_docs/version-v8.5.x/01-ibc/05-upgrades/00-intro.md b/docs/versioned_docs/version-v8.5.x/01-ibc/05-upgrades/00-intro.md index 61711d35f01..d9b8ef25fae 100644 --- a/docs/versioned_docs/version-v8.5.x/01-ibc/05-upgrades/00-intro.md +++ b/docs/versioned_docs/version-v8.5.x/01-ibc/05-upgrades/00-intro.md @@ -9,7 +9,7 @@ slug: /ibc/upgrades/intro This directory contains information on how to upgrade an IBC chain without breaking counterparty clients and connections. -IBC-connected chains must be able to upgrade without breaking connections to other chains. Otherwise there would be a massive disincentive towards upgrading and disrupting high-value IBC connections, thus preventing chains in the IBC ecosystem from evolving and improving. Many chain upgrades may be irrelevant to IBC, however some upgrades could potentially break counterparty clients if not handled correctly. Thus, any IBC chain that wishes to perform a IBC-client-breaking upgrade must perform an IBC upgrade in order to allow counterparty clients to securely upgrade to the new light client. +IBC-connected chains must be able to upgrade without breaking connections to other chains. Otherwise there would be a massive disincentive towards upgrading and disrupting high-value IBC connections, thus preventing chains in the IBC ecosystem from evolving and improving. Many chain upgrades may be irrelevant to IBC, however some upgrades could potentially break counterparty clients if not handled correctly. Thus, any IBC chain that wishes to perform an IBC-client-breaking upgrade must perform an IBC upgrade in order to allow counterparty clients to securely upgrade to the new light client. 1. The [quick-guide](./01-quick-guide.md) describes how IBC-connected chains can perform client-breaking upgrades and how relayers can securely upgrade counterparty clients using the SDK. 2. The [developer-guide](./02-developer-guide.md) is a guide for developers intending to develop IBC client implementations with upgrade functionality. diff --git a/docs/versioned_docs/version-v8.5.x/01-ibc/10-roadmap.md b/docs/versioned_docs/version-v8.5.x/01-ibc/10-roadmap.md index 962108bbde7..0ebf3ea6f51 100644 --- a/docs/versioned_docs/version-v8.5.x/01-ibc/10-roadmap.md +++ b/docs/versioned_docs/version-v8.5.x/01-ibc/10-roadmap.md @@ -33,7 +33,7 @@ Follow the progress with the [alpha milestone](https://github.com/cosmos/ibc-go/ ### Conditional clients -Conditional clients are light clients which are dependent on another client in order to verify or update state. Conditional clients are essential for integration with modular blockchains which break up consensus and state management, such as rollups. Currently, light clients receive a single provable store they maintain. There is an unidirectional communication channel with 02-client: the 02-client module will call into the light client, without allowing for the light client to call into the 02-client module. But modular blockchains break up a logical blockchain into many constituent parts, so in order to accurately represent these chains and also to account for various types of shared security primitives that are coming up, we need to introduce dependencies between clients. In the case of optimistic rollups, for example, in order to prove execution (allowing for fraud proofs), you must prove data availability and sequencing. A potential solution to this problem is that a light client may optionally specify a list of dependencies and the 02-client module would lookup read-only provable stores for each dependency and provide this to the conditional client to perform verification. Please see [this issue](https://github.com/cosmos/ibc-go/issues/5112) for more details. +Conditional clients are light clients which are dependent on another client in order to verify or update state. Conditional clients are essential for integration with modular blockchains which break up consensus and state management, such as rollups. Currently, light clients receive a single provable store they maintain. There is a unidirectional communication channel with 02-client: the 02-client module will call into the light client, without allowing for the light client to call into the 02-client module. But modular blockchains break up a logical blockchain into many constituent parts, so in order to accurately represent these chains and also to account for various types of shared security primitives that are coming up, we need to introduce dependencies between clients. In the case of optimistic rollups, for example, in order to prove execution (allowing for fraud proofs), you must prove data availability and sequencing. A potential solution to this problem is that a light client may optionally specify a list of dependencies and the 02-client module would lookup read-only provable stores for each dependency and provide this to the conditional client to perform verification. Please see [this issue](https://github.com/cosmos/ibc-go/issues/5112) for more details. ## v10.0.0