Description

Ref: #2 As one of the applications of CNS, we wanted to provide a balance query which identifies the chain from which the token was transferred. This is a wrapper around bank's GetBalance in order to make it easier for users to understand which token they have rather than looking at hash e.g.. 100ibc/C053D637CCA2A2BA030E2C5EE1B28A16F71CCB0E45E8BE52766DC1B241B77878 will be resolved as 100ibc/stake/testchain1

Problem:

Let's say there's C1 and C2. C1 is registered as part of CNS and mapped to a particular chain, but C2 was used for the transfer. We want to prove both C1 and C2 belong to the same chain and thereby resolve the token hash

The plan was to compare client states of both C1 and C2 with custom fields zeroed out. In order to ensure that C2 is not from a chain which duplicated original chain's parameters, we're trying to compare the consensus states of C1 and C2. The problem is we have the consensus states at different heights which make it impossible to compare consenus states.

Proposed Solutions:

1. We store a primary client ID in CNS and resolve it accordingly by doing a query for consensus states Pros: This approach is straight forward and won't require any changes from ibc modules Cons: The main issue being this may not be suitable for all use-cases as this involve multiple queries This helps only wallets/explorers to resolve the ibc denom hashes as belonging to a particular chain

2. Alternatively we can have a hook on cns side to register every client created to it's respective chain Id. Pros: This helps all users to be able to query their balances using cns, provided the chain is registered in cns Cons: For this we expect all the necessary implementation to be present in ibc module. We may also need to iterate over all the chain info registered to establish the link. This may also register in a significant increase in state size of cns module, though we want to encourage reuse of clients for transfers.

Is there a preferred method on how we want to do this, or any practices suggested by ibc team on what's the best way to utilise ibc module in applications like cns?

cc\ @fadeev @okwme @hxrts @cwgoes @AdityaSripal @colin-axner

Currently the spec makes no mention of RPC endpoints. Because we need them for relayer, wallet and statesync operation I think we should include them in the spec.

Phase-0 Chain Directory

By the end of Phase-0, we want to deliver a directory of chain names for Cosmos SDK chains that currently exist. For expediency, we plan on setting up a multisig that initially has the authority to modify information about blockchains on the CNS. After all existing major blockchains are recorded on the CNS and M-0 is completed the multisig will hand off these chain names one by one to trusted parties from the various sovereign Cosmos chain communities.

• [x] Implementation Spec
• [x] Types Definition - #7
• [x] Keeper implementation - #8
• [ ] Genesis State definition
• [x] CLI - #13
• [ ] Simulations