You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue serves as a tracking point to explore and demonstrate the feasibility of a reduced-footprint IBC design, in the style of Eureka. The goal is to simplify the ibc-rs implementations while retaining essential functionality, focusing on a leaner structure as v2.
Tasks
Decide on IBC v2 codebase structure
Determine the structure for the IBC v2 codebase, aligning it with the current ibc-rs implementation. Along with setting up the necessary boilerplate for v2.
Remove unnecessary core modules
Streamline the IBC core by removing modules and crates that are no longer needed, particularly those related to connection and channel handshakes from IBC v1.
Simplify 24-host implementation
Streamline validation and execution context traits to fit the Eureka model.
Remove unnecessary paths, focusing only on essential packet flows.
Retain only the necessary identifiers and validations.
Combine/bind client and channel IDs
Experiment with merging client and channel IDs into a single identifier for both source and destination, simplifying identification.
Implement v2 packet structure
Implement the new v2 packet structure, including associated types, conversions, and helper methods. Packets will contain both a header and multi-payload data, with each payload featuring its own header and data section as discussed internally.
Implement v2 core handlers
Develop the first iteration of IBC v2 core handlers. This will function as a basic transport layer without any handshake processes or counterparty registration. Social consensus will be leveraged to establish canonical clients/channels, allowing free data exchange between channels on different chains without predefined registration.
Explore the ideal structure for v2 packet commitment, experiment with different implementations to determine the best approach.
Update module (Callbacks) trait
Adjust the module trait (callbacks) to integrate with the new v2 packet structure.
Modify ICS-26 routing module
Make the necessary changes to the ICS-26 router module to align with the new v2 architecture. Also, determine whether to use the application identifier and/or the port identifier.
Testing v2 with ibc-testkit
Use ibc-testkit to write unit and integration tests for the first iteration to ensure sound design choices.
Remarks
The initiative will move forward in the feature branch feat/ibc-eureka and won't be merged into the main until the specifications are finalized in collaboration with the IBC protocol team.
For the first iteration, we’re not concerned with backward compatibility with IBC v1
The text was updated successfully, but these errors were encountered:
Overview
This issue serves as a tracking point to explore and demonstrate the feasibility of a reduced-footprint IBC design, in the style of Eureka. The goal is to simplify the ibc-rs implementations while retaining essential functionality, focusing on a leaner structure as v2.
Tasks
ibc-rs
implementation. Along with setting up the necessary boilerplate for v2.module
(Callbacks) traitibc-testkit
to write unit and integration tests for the first iteration to ensure sound design choices.Remarks
The initiative will move forward in the feature branch
feat/ibc-eureka
and won't be merged into the main until the specifications are finalized in collaboration with the IBC protocol team.For the first iteration, we’re not concerned with backward compatibility with IBC v1
The text was updated successfully, but these errors were encountered: