From 1ac7619202a610c9e4e584b3376b64615d38ea64 Mon Sep 17 00:00:00 2001 From: Ocenka Date: Mon, 16 Dec 2024 14:21:55 +0000 Subject: [PATCH 01/10] typos 02-integration.md --- docs/docs/01-ibc/02-integration.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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. From 326999f8299aeb541452f1fbed97b69c92763ef4 Mon Sep 17 00:00:00 2001 From: Ocenka Date: Mon, 16 Dec 2024 14:22:52 +0000 Subject: [PATCH 02/10] typos 00-intro.md --- docs/docs/01-ibc/05-upgrades/00-intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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. From c2c1802b10d2460b4fbc08a75f65dfdf1dc052a2 Mon Sep 17 00:00:00 2001 From: Ocenka Date: Mon, 16 Dec 2024 14:23:18 +0000 Subject: [PATCH 03/10] typos 00-intro.md --- .../version-v4.6.x/01-ibc/05-upgrades/00-intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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. From 879eac5ef6cec806594d0279beaf1145171fc1b3 Mon Sep 17 00:00:00 2001 From: Ocenka Date: Mon, 16 Dec 2024 14:23:45 +0000 Subject: [PATCH 04/10] typos 00-intro.md --- .../version-v5.4.x/01-ibc/05-upgrades/00-intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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. From 2ed23c40ccb467ae961d1fe11e198b349d909b0d Mon Sep 17 00:00:00 2001 From: Ocenka Date: Mon, 16 Dec 2024 14:24:10 +0000 Subject: [PATCH 05/10] typos 00-intro.md --- .../version-v6.3.x/01-ibc/05-upgrades/00-intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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. From 4a2443ffa513352ffc08486980fc6c3b8f8112b4 Mon Sep 17 00:00:00 2001 From: Ocenka Date: Mon, 16 Dec 2024 14:24:40 +0000 Subject: [PATCH 06/10] typos 05-v3-to-v4.md --- docs/versioned_docs/version-v6.3.x/04-migrations/05-v3-to-v4.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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). From ed2b2e97b965b496a664f2fa0822612cefad8a4c Mon Sep 17 00:00:00 2001 From: Ocenka Date: Mon, 16 Dec 2024 14:25:14 +0000 Subject: [PATCH 07/10] typos 00-intro.md --- .../version-v7.8.x/01-ibc/05-upgrades/00-intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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. From eca48b7dfe6920fa34b5462455ea9cacec055245 Mon Sep 17 00:00:00 2001 From: Ocenka Date: Mon, 16 Dec 2024 14:25:42 +0000 Subject: [PATCH 08/10] typos 00-intro.md --- .../version-v8.5.x/01-ibc/05-upgrades/00-intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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. From 94129ba3a01424fa2b7ccec07be6f0457ecd0d3c Mon Sep 17 00:00:00 2001 From: Ocenka Date: Mon, 16 Dec 2024 14:26:27 +0000 Subject: [PATCH 09/10] typos 10-roadmap.md --- docs/versioned_docs/version-v8.5.x/01-ibc/10-roadmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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..425a2e3b27a 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 n 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 From 68e471274c093b6d5fbff7ad84badb9978f5ff1f Mon Sep 17 00:00:00 2001 From: Damian Nolan Date: Tue, 17 Dec 2024 10:31:35 +0100 Subject: [PATCH 10/10] chore: fix n -> a typo --- docs/versioned_docs/version-v8.5.x/01-ibc/10-roadmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 425a2e3b27a..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 n 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