From 0bc93c90b0511df4cb67280fab6094cf21260380 Mon Sep 17 00:00:00 2001 From: Farhad Shabani Date: Tue, 14 Nov 2023 11:55:43 -0800 Subject: [PATCH 1/5] docs: write ADR for ibc crate restructure --- ... => adr-007-light-client-contexts copy.md} | 0 .../adr-008-restructure-ibc-crate.md | 122 ++++++++++++++++++ 2 files changed, 122 insertions(+) rename docs/architecture/{adr-007-light-client-contexts.md => adr-007-light-client-contexts copy.md} (100%) create mode 100644 docs/architecture/adr-008-restructure-ibc-crate.md diff --git a/docs/architecture/adr-007-light-client-contexts.md b/docs/architecture/adr-007-light-client-contexts copy.md similarity index 100% rename from docs/architecture/adr-007-light-client-contexts.md rename to docs/architecture/adr-007-light-client-contexts copy.md diff --git a/docs/architecture/adr-008-restructure-ibc-crate.md b/docs/architecture/adr-008-restructure-ibc-crate.md new file mode 100644 index 000000000..9bad5fa51 --- /dev/null +++ b/docs/architecture/adr-008-restructure-ibc-crate.md @@ -0,0 +1,122 @@ +# ADR 008: RESTRUCTURE `ibc` CRATE + +## Context + +The current state of the **`ibc`** crate exhibits a mix of different implementation layers. From a module-based perspective, it encompasses essential elements like ibc core, clients, applications, along with testing facilities. However, an architectural view reveals a fusion of diverse layers of type definitions, interfaces (APIs), and handler functions, resulting in a mix of dependencies and features that may lead to potential conflicts or unnecessary imports for users. + +As of [this pull request](https://github.com/cosmos/ibc-rs/pull/954), we've separated our mock testing kit into the standalone **`ibc-testkit`** library. This decoupling from the main **`ibc`** crate sets the stage for the objectives of this ADR. + +The primary goals here are twofold: firstly, to reduce interdependence within the codebase among various components such as ibc core, clients, and applications, and secondly, to improve the overall usability of the `ibc-rs` implementation. The overarching aim is to empower users to selectively import specific IBC layers, mitigating potential conflicts related to dependencies or features that may arise in the context of a monolithic library and letting `ibc-rs` be used in the following scenarios: + +1. **Selective Module Import** + - Users cannot import only the necessary components/modules for their projects. For instance, importing only the **`ics07_tendermint`** implementation is impractical. +2. **Selective Types Import** + - Relayers, like Hermes, or any off-chain consumers cannot import their desired layer of implementation like ibc types without pulling in unnecessary dependencies into their project. +3. **Smoother IBC Core Integration with Hosts** + - Integrating ibc core with host chains without introducing light client or app dependencies is currently not straightforward, impeding smooth integration. +4. **Easier Development of CosmWasm Contracts** + - For developing a CosmWasm tendermint light client, we ideally should only be dependent on implementation under the **`ics07_tendermint`** and also be importing relevant parts from the **`ibc-core-client`** layer without pulling in all the ibc codebase and dependencies. + +This ADR aims to enhance both the usability and practicality of `ibc-rs` by restructuring the codebase and organizing it under multiple sub-libraries, as stated in the [decision](#decision) section. This will make different parts of `ibc-rs` accessible to users, positioning it as a more comprehensive, one-stop solution catering to diverse users groups, whether for on-chain or off-chain use cases. + +## Decision + +For the library organization, the first stage of separation is to split off the codebase of each IBC applications, clients, and core implementation, decoupling them from each other. The top-level libraries and the naming schema would look like as follow: + +```markdown +. +├── ibc -> Primarily re-exports sub-libraries +├── ibc-core +│ ├── ibc-core-client (contains the implementation + Re-exports types) +│ ├── ibc-core-connection +│ ├── ibc-core-channel +│ ├── ibc-core-commitment +│ └── ibc-core-host +│ └── . +├── ibc-clients +│ ├── ibc-client-tendermint +│ ├── ibc-client-tendermint-cw +│ └── . +├── ibc-apps +│ ├── ibc-app-transfer +│ ├── ibc-app-ica +│ │ └── . +│ └── . +├── ibc-preludes +├── ibc-testkit (previously mock module + `test-utils` feature) +├── ibc-query +└── ibc-derive +``` + +With this restructure, the main `ibc` crate primarily re-exports types, interfaces, and implementation of all the sub-libraries. Therefore, if someone only wants to depend on the `ibc` crate without caring about this granularity, they can do so. + +Afterward, we split off data structure of each IBC layer into a separate sub-library under a `types` folder, still maintained under the directory of that relevant component/module. As an example, the `ibc-core-client` crate’s tree and the naming schema looks like this: + +```markdown +ibc-core +└── ibc-core-client (dir: ibc-core/ics02-client) + └── ibc-core-client-types (dir: ibc-core/ics02-client/types) + ├── msgs + ├── events + └── . +``` + +This way, the main crate of each IBC module contains all the necessary APIs and implementation to integrate with host chains, along with re-exporting the sub-library types. This allows projects to selectively import types (e.g. `ibc-core-client-types`), often required by off-chain users such as relayers. Or to pick the library containing the entire implementation of that particular module (e.g. `ibc-core-client`), typically more convenient for host chains or smart contract developers to integrate with their end. + +By this restructuring, the **directory tree** of the repo would look like as follow: + +```markdown +ibc +ibc-core +├── ics02-client +| ├── src +| ├── types +| | ├── src +| | ├── README.md +| | └── cargo.toml +| ├── README.md +| └── cargo.toml +├── ics03-connection +| └── . +├── ics04-channel +| └── . +├── ics23-commitment +| └── . +└── ics24-host + └── . +ibc-clients +├── ics07-tendermint +├── ics08-wasm +└── . +ibc-apps +├── ics20-transfer +├── ics27-ica +└── . +ibc-preludes +ibc-testkit +ibc-query +ibc-derive +``` + +To implement this change efficiently and for more organization, we use the workspace inheritance feature and will add an initial README for each of these newly added libraries. + +Later, to streamline our release process, it is crucial to come up with a Github action to automate and simplify the release process. + +## **Status** + +Proposed + +## **Consequences** + +We should acknowledge this restructuring, while a significant step forward, will not completely address all existing design couplings. Subsequent improvements in implementation logic will be necessary to completely decouple ibc core, clients, and applications from each other and make the entire logic as chain-agnostic as possible. For an instance, currently, our `IbcEvent` type depends on the Tendermint events in their conversion, which needs to be addressed afterward. There may be other mix-ups as well, but the new repository structure significantly simplifies their handling and ensures `ibc-rs` evolves into a more adaptable, modular, and composable implementation that can serve various use cases. + +### **Positive** + +- Opens up a range of new use cases for `ibc-rs` +- Facilitates moving toward more chain-agnostic and flexible design and interfaces +- Simplifies development on top of each layer of `ibc-rs` implementation + +### **Negative** + +- Multiple libraries are more challenging to maintain +- Enforces current users to update a large number of their import paths from `ibc` crates From 7636ead9dbcd800e14bf2567a4774c24b239ab5c Mon Sep 17 00:00:00 2001 From: Farhad Shabani Date: Tue, 14 Nov 2023 20:32:12 -0800 Subject: [PATCH 2/5] fix: mistaken adr007 file naming --- ...t-client-contexts copy.md => adr-007-light-client-contexts.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename docs/architecture/{adr-007-light-client-contexts copy.md => adr-007-light-client-contexts.md} (100%) diff --git a/docs/architecture/adr-007-light-client-contexts copy.md b/docs/architecture/adr-007-light-client-contexts.md similarity index 100% rename from docs/architecture/adr-007-light-client-contexts copy.md rename to docs/architecture/adr-007-light-client-contexts.md From f36a06e12bc7e7b988bf87f38507a582a7c0d6b4 Mon Sep 17 00:00:00 2001 From: Farhad Shabani Date: Wed, 15 Nov 2023 06:36:31 -0800 Subject: [PATCH 3/5] chore: markdown adjustment --- .../adr-008-restructure-ibc-crate.md | 108 ++++++++++++++---- 1 file changed, 84 insertions(+), 24 deletions(-) diff --git a/docs/architecture/adr-008-restructure-ibc-crate.md b/docs/architecture/adr-008-restructure-ibc-crate.md index 9bad5fa51..4a4705dc1 100644 --- a/docs/architecture/adr-008-restructure-ibc-crate.md +++ b/docs/architecture/adr-008-restructure-ibc-crate.md @@ -2,26 +2,58 @@ ## Context -The current state of the **`ibc`** crate exhibits a mix of different implementation layers. From a module-based perspective, it encompasses essential elements like ibc core, clients, applications, along with testing facilities. However, an architectural view reveals a fusion of diverse layers of type definitions, interfaces (APIs), and handler functions, resulting in a mix of dependencies and features that may lead to potential conflicts or unnecessary imports for users. - -As of [this pull request](https://github.com/cosmos/ibc-rs/pull/954), we've separated our mock testing kit into the standalone **`ibc-testkit`** library. This decoupling from the main **`ibc`** crate sets the stage for the objectives of this ADR. - -The primary goals here are twofold: firstly, to reduce interdependence within the codebase among various components such as ibc core, clients, and applications, and secondly, to improve the overall usability of the `ibc-rs` implementation. The overarching aim is to empower users to selectively import specific IBC layers, mitigating potential conflicts related to dependencies or features that may arise in the context of a monolithic library and letting `ibc-rs` be used in the following scenarios: +The current state of the **`ibc`** crate exhibits a mix of different +implementation layers. From a module-based perspective, it encompasses essential +elements like ibc core, clients, applications, along with testing facilities. +However, an architectural view reveals a fusion of diverse layers of type +definitions, interfaces (APIs), and handler functions, resulting in a mix of +dependencies and features that may lead to potential conflicts or unnecessary +imports for users. + +As of [this pull request](https://github.com/cosmos/ibc-rs/pull/954), we've +separated our mock testing kit into the standalone **`ibc-testkit`** library. +This decoupling from the main **`ibc`** crate sets the stage for the objectives +of this ADR. + +The primary goals here are twofold: firstly, to reduce interdependence within +the codebase among various components such as ibc core, clients, and +applications, and secondly, to improve the overall usability of the `ibc-rs` +implementation. The overarching aim is to empower users to selectively import +specific IBC layers, mitigating potential conflicts related to dependencies or +features that may arise in the context of a monolithic library and letting +`ibc-rs` be used in the following scenarios: 1. **Selective Module Import** - - Users cannot import only the necessary components/modules for their projects. For instance, importing only the **`ics07_tendermint`** implementation is impractical. + - Users cannot import only the necessary components/modules for their + projects. For instance, importing only the **`ics07_tendermint`** + implementation is impractical. 2. **Selective Types Import** - - Relayers, like Hermes, or any off-chain consumers cannot import their desired layer of implementation like ibc types without pulling in unnecessary dependencies into their project. + - Relayers, like Hermes, or any off-chain consumers cannot import their + desired layer of implementation like ibc types without pulling in + unnecessary dependencies into their project. 3. **Smoother IBC Core Integration with Hosts** - - Integrating ibc core with host chains without introducing light client or app dependencies is currently not straightforward, impeding smooth integration. + - Integrating ibc core with host chains without introducing light client or + app dependencies is currently not straightforward, impeding smooth + integration. 4. **Easier Development of CosmWasm Contracts** - - For developing a CosmWasm tendermint light client, we ideally should only be dependent on implementation under the **`ics07_tendermint`** and also be importing relevant parts from the **`ibc-core-client`** layer without pulling in all the ibc codebase and dependencies. - -This ADR aims to enhance both the usability and practicality of `ibc-rs` by restructuring the codebase and organizing it under multiple sub-libraries, as stated in the [decision](#decision) section. This will make different parts of `ibc-rs` accessible to users, positioning it as a more comprehensive, one-stop solution catering to diverse users groups, whether for on-chain or off-chain use cases. + - For developing a CosmWasm tendermint light client, we ideally should only + be dependent on implementation under the **`ics07_tendermint`** and also + be importing relevant parts from the **`ibc-core-client`** layer without + pulling in all the ibc codebase and dependencies. + +This ADR aims to enhance both the usability and practicality of `ibc-rs` by +restructuring the codebase and organizing it under multiple sub-libraries, as +stated in the [decision](#decision) section. This will make different parts of +`ibc-rs` accessible to users, positioning it as a more comprehensive, one-stop +solution catering to diverse users groups, whether for on-chain or off-chain use +cases. ## Decision -For the library organization, the first stage of separation is to split off the codebase of each IBC applications, clients, and core implementation, decoupling them from each other. The top-level libraries and the naming schema would look like as follow: +For the library organization, the first stage of separation is to split off the +codebase of each IBC applications, clients, and core implementation, decoupling +them from each other. The top-level libraries and the naming schema would look +like as follow: ```markdown . @@ -48,9 +80,15 @@ For the library organization, the first stage of separation is to split off the └── ibc-derive ``` -With this restructure, the main `ibc` crate primarily re-exports types, interfaces, and implementation of all the sub-libraries. Therefore, if someone only wants to depend on the `ibc` crate without caring about this granularity, they can do so. +With this restructure, the main `ibc` crate primarily re-exports types, +interfaces, and implementation of all the sub-libraries. Therefore, if someone +only wants to depend on the `ibc` crate without caring about this granularity, +they can do so. -Afterward, we split off data structure of each IBC layer into a separate sub-library under a `types` folder, still maintained under the directory of that relevant component/module. As an example, the `ibc-core-client` crate’s tree and the naming schema looks like this: +Afterward, we split off data structure of each IBC layer into a separate +sub-library under a `types` folder, still maintained under the directory of that +relevant component/module. As an example, the `ibc-core-client` crate’s tree and +the naming schema looks like this: ```markdown ibc-core @@ -61,9 +99,16 @@ ibc-core └── . ``` -This way, the main crate of each IBC module contains all the necessary APIs and implementation to integrate with host chains, along with re-exporting the sub-library types. This allows projects to selectively import types (e.g. `ibc-core-client-types`), often required by off-chain users such as relayers. Or to pick the library containing the entire implementation of that particular module (e.g. `ibc-core-client`), typically more convenient for host chains or smart contract developers to integrate with their end. +This way, the main crate of each IBC module contains all the necessary APIs and +implementation to integrate with host chains, along with re-exporting the +sub-library types. This allows projects to selectively import types (e.g. +`ibc-core-client-types`), often required by off-chain users such as relayers. Or +to pick the library containing the entire implementation of that particular +module (e.g. `ibc-core-client`), typically more convenient for host chains or +smart contract developers to integrate with their end. -By this restructuring, the **directory tree** of the repo would look like as follow: +By this restructuring, the **directory tree** of the repo would look like as +follow: ```markdown ibc @@ -72,9 +117,7 @@ ibc-core | ├── src | ├── types | | ├── src -| | ├── README.md | | └── cargo.toml -| ├── README.md | └── cargo.toml ├── ics03-connection | └── . @@ -82,8 +125,11 @@ ibc-core | └── . ├── ics23-commitment | └── . -└── ics24-host - └── . +├── ics24-host +| └── . +├── src +├── cargo.toml +└── README.md ibc-clients ├── ics07-tendermint ├── ics08-wasm @@ -98,9 +144,13 @@ ibc-query ibc-derive ``` -To implement this change efficiently and for more organization, we use the workspace inheritance feature and will add an initial README for each of these newly added libraries. +To implement this change efficiently and for more organization, we use the +workspace inheritance feature and will add a top-level README for main library +groups like `ibc-core`, `ibc-clients`, etc serving as a guide for users to +understand the purpose and structure of their sub libraries. -Later, to streamline our release process, it is crucial to come up with a Github action to automate and simplify the release process. +Later, to streamline our release process, it is crucial to come up with a Github +action to automate and simplify the release process. ## **Status** @@ -108,7 +158,16 @@ Proposed ## **Consequences** -We should acknowledge this restructuring, while a significant step forward, will not completely address all existing design couplings. Subsequent improvements in implementation logic will be necessary to completely decouple ibc core, clients, and applications from each other and make the entire logic as chain-agnostic as possible. For an instance, currently, our `IbcEvent` type depends on the Tendermint events in their conversion, which needs to be addressed afterward. There may be other mix-ups as well, but the new repository structure significantly simplifies their handling and ensures `ibc-rs` evolves into a more adaptable, modular, and composable implementation that can serve various use cases. +We should acknowledge this restructuring, while a significant step forward, will +not completely address all existing design couplings. Subsequent improvements in +implementation logic will be necessary to completely decouple ibc core, clients, +and applications from each other and make the entire logic as chain-agnostic as +possible. For an instance, currently, our `IbcEvent` type depends on the +Tendermint events in their conversion, which needs to be addressed afterward. +There may be other mix-ups as well, but the new repository structure +significantly simplifies their handling and ensures `ibc-rs` evolves into a more +adaptable, modular, and composable implementation that can serve various use +cases. ### **Positive** @@ -119,4 +178,5 @@ We should acknowledge this restructuring, while a significant step forward, will ### **Negative** - Multiple libraries are more challenging to maintain -- Enforces current users to update a large number of their import paths from `ibc` crates +- Enforces current users to update a large number of their import paths from + `ibc` crates From a2db7007a81ff44c1c4a26fdf4c3504dc9469e19 Mon Sep 17 00:00:00 2001 From: Farhad Shabani Date: Wed, 15 Nov 2023 07:31:25 -0800 Subject: [PATCH 4/5] fix: apply suggestions from code review Co-authored-by: Sean Chen Signed-off-by: Farhad Shabani --- .../adr-008-restructure-ibc-crate.md | 26 +++++++++---------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/docs/architecture/adr-008-restructure-ibc-crate.md b/docs/architecture/adr-008-restructure-ibc-crate.md index 4a4705dc1..9ea69483c 100644 --- a/docs/architecture/adr-008-restructure-ibc-crate.md +++ b/docs/architecture/adr-008-restructure-ibc-crate.md @@ -45,15 +45,13 @@ This ADR aims to enhance both the usability and practicality of `ibc-rs` by restructuring the codebase and organizing it under multiple sub-libraries, as stated in the [decision](#decision) section. This will make different parts of `ibc-rs` accessible to users, positioning it as a more comprehensive, one-stop -solution catering to diverse users groups, whether for on-chain or off-chain use +solution catering to diverse user groups, whether for on-chain or off-chain use cases. ## Decision -For the library organization, the first stage of separation is to split off the -codebase of each IBC applications, clients, and core implementation, decoupling -them from each other. The top-level libraries and the naming schema would look -like as follow: +For the library organization, the first stage of separation is to split the +codebase so that each IBC application, client, and core implementation is decoupled from one another. The top-level libraries and the naming schema would look as follows: ```markdown . @@ -81,11 +79,11 @@ like as follow: ``` With this restructure, the main `ibc` crate primarily re-exports types, -interfaces, and implementation of all the sub-libraries. Therefore, if someone +interfaces, and implementations of all the sub-libraries. Therefore, if someone only wants to depend on the `ibc` crate without caring about this granularity, they can do so. -Afterward, we split off data structure of each IBC layer into a separate +Afterward, we split off the data structures of each IBC layer into a separate sub-library under a `types` folder, still maintained under the directory of that relevant component/module. As an example, the `ibc-core-client` crate’s tree and the naming schema looks like this: @@ -100,15 +98,14 @@ ibc-core ``` This way, the main crate of each IBC module contains all the necessary APIs and -implementation to integrate with host chains, along with re-exporting the +implementations to integrate with host chains, along with re-exporting the sub-library types. This allows projects to selectively import types (e.g. `ibc-core-client-types`), often required by off-chain users such as relayers. Or to pick the library containing the entire implementation of that particular module (e.g. `ibc-core-client`), typically more convenient for host chains or -smart contract developers to integrate with their end. +smart contract developers to integrate with on their end. -By this restructuring, the **directory tree** of the repo would look like as -follow: +Once the restructuring is complete, the **directory tree** of the repo would look as follows: ```markdown ibc @@ -128,7 +125,7 @@ ibc-core ├── ics24-host | └── . ├── src -├── cargo.toml +├── Cargo.toml └── README.md ibc-clients ├── ics07-tendermint @@ -162,8 +159,9 @@ We should acknowledge this restructuring, while a significant step forward, will not completely address all existing design couplings. Subsequent improvements in implementation logic will be necessary to completely decouple ibc core, clients, and applications from each other and make the entire logic as chain-agnostic as -possible. For an instance, currently, our `IbcEvent` type depends on the -Tendermint events in their conversion, which needs to be addressed afterward. +possible. +For instance, currently, our `IbcEvent` type depends on the +Tendermint events in their conversion, which can only be addressed once this restructuring is complete. There may be other mix-ups as well, but the new repository structure significantly simplifies their handling and ensures `ibc-rs` evolves into a more adaptable, modular, and composable implementation that can serve various use From e2c56f5a6fdb6ebdfbde1643bd8b8d80c097ef0e Mon Sep 17 00:00:00 2001 From: Farhad Shabani Date: Mon, 20 Nov 2023 21:14:01 -0800 Subject: [PATCH 5/5] docs: explanation for *-types interaction with ibc-proto --- .../adr-008-restructure-ibc-crate.md | 50 +++++++++++-------- 1 file changed, 30 insertions(+), 20 deletions(-) diff --git a/docs/architecture/adr-008-restructure-ibc-crate.md b/docs/architecture/adr-008-restructure-ibc-crate.md index 9ea69483c..45c7be6e8 100644 --- a/docs/architecture/adr-008-restructure-ibc-crate.md +++ b/docs/architecture/adr-008-restructure-ibc-crate.md @@ -51,7 +51,9 @@ cases. ## Decision For the library organization, the first stage of separation is to split the -codebase so that each IBC application, client, and core implementation is decoupled from one another. The top-level libraries and the naming schema would look as follows: +codebase so that each IBC application, client, and core implementation is +decoupled from one another. The top-level libraries and the naming schema would +look as follows: ```markdown . @@ -72,7 +74,7 @@ codebase so that each IBC application, client, and core implementation is decoup │ ├── ibc-app-ica │ │ └── . │ └── . -├── ibc-preludes +├── ibc-primitives ├── ibc-testkit (previously mock module + `test-utils` feature) ├── ibc-query └── ibc-derive @@ -83,10 +85,10 @@ interfaces, and implementations of all the sub-libraries. Therefore, if someone only wants to depend on the `ibc` crate without caring about this granularity, they can do so. -Afterward, we split off the data structures of each IBC layer into a separate -sub-library under a `types` folder, still maintained under the directory of that -relevant component/module. As an example, the `ibc-core-client` crate’s tree and -the naming schema looks like this: +Afterward, we split off data structure (domain types) of each IBC layer into a +separate sub-library under a `types` folder, still maintained under the +directory of that relevant component/module. As an example, the +`ibc-core-client` crate’s tree and the naming schema would look like this: ```markdown ibc-core @@ -105,7 +107,8 @@ to pick the library containing the entire implementation of that particular module (e.g. `ibc-core-client`), typically more convenient for host chains or smart contract developers to integrate with on their end. -Once the restructuring is complete, the **directory tree** of the repo would look as follows: +Once the restructuring is complete, the **directory tree** of the repo would +look as follows: ```markdown ibc @@ -114,8 +117,8 @@ ibc-core | ├── src | ├── types | | ├── src -| | └── cargo.toml -| └── cargo.toml +| | └── Cargo.toml +| └── Cargo.toml ├── ics03-connection | └── . ├── ics04-channel @@ -135,19 +138,27 @@ ibc-apps ├── ics20-transfer ├── ics27-ica └── . -ibc-preludes +ibc-primitives ibc-testkit ibc-query ibc-derive ``` -To implement this change efficiently and for more organization, we use the +In the refactored codebase, there will be several `*-types` crates that rely on +the `ibc-proto` library. This library acts as an upstream crate, facilitating +the conversion to and from proto types. Each `*-types` crate also re-exports +crucial proto types for added user convenience. This approach ensures a seamless +experience for users downstream, sparing them the necessity of directly +including the `ibc-proto` dependency in their projects. Consequently, the +`*-types` crates serve as comprehensive, battery-included libraries. + +To implement this ADR efficiently and for more organization, we use the workspace inheritance feature and will add a top-level README for main library groups like `ibc-core`, `ibc-clients`, etc serving as a guide for users to understand the purpose and structure of their sub libraries. -Later, to streamline our release process, it is crucial to come up with a Github -action to automate and simplify the release process. +Later, it is crucial to come up with a Github action to automate and simplify +the release process as well. ## **Status** @@ -159,13 +170,12 @@ We should acknowledge this restructuring, while a significant step forward, will not completely address all existing design couplings. Subsequent improvements in implementation logic will be necessary to completely decouple ibc core, clients, and applications from each other and make the entire logic as chain-agnostic as -possible. -For instance, currently, our `IbcEvent` type depends on the -Tendermint events in their conversion, which can only be addressed once this restructuring is complete. -There may be other mix-ups as well, but the new repository structure -significantly simplifies their handling and ensures `ibc-rs` evolves into a more -adaptable, modular, and composable implementation that can serve various use -cases. +possible. For instance, currently, our `IbcEvent` type depends on the Tendermint +events in their conversion, which can only be addressed once this restructuring +is complete. There may be other mix-ups as well, but the new repository +structure significantly simplifies their handling and ensures `ibc-rs` evolves +into a more adaptable, modular, and composable implementation that can serve +various use cases. ### **Positive**