Explore a lightweight, Eureka-inspired IBC architecture

[Farhad-Shabani]

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

• Decide on IBC v2 codebase structure #1366
  • 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 #1371
  • 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 #1367
  • Experiment with merging client and channel IDs into a single identifier for both source and destination, simplifying identification.
• Implement v2 packet structure #1364
  • 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 #1368
  • 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.
• Experiment removing acknowledgement
  • Experiment with the removal of acknowledgements as surfaced in Consider whether to remove IBC acknowledgement in IBC v2 ibc#1150 and run tests to assess the potential impact and implications of this change.
• Investigate v2 packet commitment
  • 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