[ICS02] Unclear role of ClientTypePath
and respectively store_client_type
method
#592
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
Problem Statement
Looking into the ICS24, there should be a provable store for
ClientType
in theClientTypePath
and provable stores are required to provide methods needed for getting, setting, and deleting a value.According to the ICS02
ClientTypePath
is utilized during client creation to ensure that the client type is absent in the respective path before proceeding.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 aget_client_type
interface to enable us checking the existence of a client type in the respective path (as specified in the specs).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 theClientTypePath
becomes unnecessary.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 fromClientTypePath
even though it is somewhat inconsistent with the specs!Remarks
When a
MsgCreateClient
is processed through thedecode_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
The text was updated successfully, but these errors were encountered: