Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ICS02] Unclear role of ClientTypePath and respectively store_client_type method #592

Closed
Farhad-Shabani opened this issue Mar 31, 2023 · 1 comment · Fixed by #642
Closed
Assignees
Labels
A: breaking Admin: breaking change that may impact operators O: usability Objective: aims to enhance user experience (UX) and streamline product usability S: specs Scope: related to IBC protocol specifications
Milestone

Comments

@Farhad-Shabani
Copy link
Member

Farhad-Shabani commented Mar 31, 2023

Problem Statement

  1. Looking into the ICS24, there should be a provable store for ClientType in the ClientTypePath and provable stores are required to provide methods needed for getting, setting, and deleting a value.

  2. According to the ICS02 ClientTypePath is utilized during client creation to ensure that the client type is absent in the respective path before proceeding.

  3. Our API only offer the store_client_type method, which stores a client type without any usage or providing a means to retrieve or remove it. Although we have yet to encounter a need for this interface among consumers like Namada, Basecoin, and Mock, Having it necessitate to add a get_client_type interface to enable us checking the existence of a client type in the respective path (as specified in the specs).

  4. Meanwhile, with the counter mechanism in place, which never fails and increments the client ID, we can be confident that every client creation process results in a new path. This means we don't need to check whether the client already exists in the ClientTypePath and the whole interaction with the ClientTypePath becomes unnecessary.

  5. I checked the IBC-go implementation in this regard and couldn’t find any ClientTypePath there. (I have reached out to them for clarification)

Proposal

Considering points 4 & 5, it seems logical to eliminate the store_client_type interface and move away from ClientTypePath even though it is somewhat inconsistent with the specs!

Remarks

  • When a MsgCreateClient is processed through the decode_client_state operation, the host implicitly checks if the client type is supported or allowed. It would have been ideal if we could separate the decoding process from the list of supported clients, but, it looks like it’s not possible to decouple them with our curren design.

  • Ran into this issue upon working on Disallow creation of frozen clients #178

@Farhad-Shabani Farhad-Shabani added O: usability Objective: aims to enhance user experience (UX) and streamline product usability S: specs Scope: related to IBC protocol specifications labels Mar 31, 2023
@Farhad-Shabani Farhad-Shabani moved this to 📥 To Do in ibc-rs Mar 31, 2023
@Farhad-Shabani Farhad-Shabani self-assigned this Apr 3, 2023
@Farhad-Shabani
Copy link
Member Author

Upon investigation in contact with IBC-go team, the concept of client type will soon be removed! cosmos/ibc#956

@Farhad-Shabani Farhad-Shabani added the A: breaking Admin: breaking change that may impact operators label Apr 20, 2023
@github-project-automation github-project-automation bot moved this from 📥 To Do to ✅ Done in ibc-rs Apr 24, 2023
@Farhad-Shabani Farhad-Shabani added this to the v0.38.0 milestone Apr 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A: breaking Admin: breaking change that may impact operators O: usability Objective: aims to enhance user experience (UX) and streamline product usability S: specs Scope: related to IBC protocol specifications
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

1 participant