|
| 1 | +--- |
| 2 | +parent: |
| 3 | + title: Understand IBC Denoms with Gaia |
| 4 | +order: 0 |
| 5 | +description: Send tokens with IBC, trace a denom, and understand how denoms work. |
| 6 | +--- |
| 7 | + |
| 8 | +# Understand IBC Denoms with Gaia |
| 9 | + |
| 10 | +One of the most powerful technologies when using the Cosmos SDK is the Interblockchain Communication Protocol (IBC). In the Cosmos ecosystem, every blockchain is intended to be sovereign and application-specific. With IBC, every blockchain can connect to another blockchain using the IBC protocol. This communication protocol will eventually create a system of sovereign _and_ connected blockchains. |
| 11 | + |
| 12 | +## Introduction |
| 13 | + |
| 14 | +The most used feature of IBC is to send tokens from one blockchain to another. When sending a token to another blockchain, a token `voucher` is generated on the other (target) blockchain. |
| 15 | + |
| 16 | +Imagine two blockchains, blockchain A and blockchain B. In the beginning, you have your token on blockchain A. |
| 17 | + |
| 18 | + |
| 19 | +*Sending token from blockchain A to blockchain B* |
| 20 | + |
| 21 | +The value that tokens represent can be transferred across chains, but the token itself cannot. When sending the tokens with IBC to another blockchain: |
| 22 | + |
| 23 | +1. - Blockchain A locks the tokens and relays proof to blockchain B |
| 24 | +2. - Blockchain B mints its own representative tokens in the form of _voucher_ replacement tokens |
| 25 | +3. - Blockchain B sends the voucher tokens back to blockchain A |
| 26 | +4. - The voucher tokens are destroyed (burned) on blockchain B |
| 27 | +5. - The locked tokens on blockchain A are unlocked |
| 28 | + |
| 29 | +The only way to unlock the locked tokens on blockchain A is to send the voucher token back from blockchain B. The result is that the voucher token on blockchain B is burned. The burn process purposefully takes the tokens out of circulation. |
| 30 | + |
| 31 | +In this tutorial, you learn the format of the voucher token on blockchain B. You learn what information the token voucher includes and what the token voucher looks like, and you learn how to make sense of them. The information of the token is described as an IBC denom. You can parse this IBC denom to receive information about the voucher and learn which blockchain the token voucher came from. |
| 32 | + |
| 33 | +**You will learn how to:** |
| 34 | + |
| 35 | +- Trace the IBC denom |
| 36 | +- Understand how denoms work |
| 37 | +- Find out which chain the token came from |
| 38 | + |
| 39 | +## Requirements |
| 40 | + |
| 41 | +Install the gaia binary: |
| 42 | + |
| 43 | +```bash |
| 44 | +git clone https://github.com/cosmos/gaia.git |
| 45 | +cd gaia |
| 46 | +git checkout v5.0.0 |
| 47 | +make install |
| 48 | + |
| 49 | +gaiad version |
| 50 | +``` |
| 51 | + |
| 52 | +The output of `gaiad version` should print: |
| 53 | + |
| 54 | +```bash |
| 55 | +v5.0.0 |
| 56 | +``` |
| 57 | + |
| 58 | +## What Is This IBC Denom |
| 59 | + |
| 60 | +The `voucher` tokens introduced in the asset transfer are called IBC Denominations (IBC denom). The voucher tokens are the result of a token transfer using IBC from one blockchain to another. The format of the voucher token is: |
| 61 | + |
| 62 | +`ibc/DENOMHASH`. |
| 63 | + |
| 64 | +Imagine that you've received a new `ibc/` token on blockchain B where you initially held `samoleans` and `stake` token. |
| 65 | + |
| 66 | +Your balance now looks like: |
| 67 | + |
| 68 | +`1000000ibc/CDC4587874B85BEA4FCEC3CEA5A1195139799A1FEE711A07D972537E18FDA39D,100000000000samoleans,99999977256stake` |
| 69 | + |
| 70 | +Just like `samoleans` or `stake`, `ibc/CDC458787...` is the denomination (denom) of the token received from IBC. After `ibc/CDC458787...` is a hash of the denom, the IBC port, and the channel. |
| 71 | + |
| 72 | +Why is `CDC458787...` a hash? |
| 73 | + |
| 74 | +- The hash contains paths that track the token on multiple hops from other blockchains to your account. |
| 75 | +- This path could potentially be unbearably long when directly printing the path. |
| 76 | +- The Cosmos SDK has a 64-character limit on the denomination of the token. |
| 77 | + |
| 78 | +The tradeoff of using a hash is that you must query a node to find out what the actual path and denomination is. This query is called the _denomtrace_. |
| 79 | + |
| 80 | +Follow along with the `gaiad` subcommands to query the denom and learn about the channel the tokens came from. |
| 81 | + |
| 82 | +```bash |
| 83 | +gaiad query ibc-transfer denom-trace CDC4587874B85BEA4FCEC3CEA5A1195139799A1FEE711A07D972537E18FDA39D --node https://rpc.testnet.cosmos.network:443 |
| 84 | +``` |
| 85 | + |
| 86 | +Response: |
| 87 | + |
| 88 | +```bash |
| 89 | +denom_trace: |
| 90 | + base_denom: moon |
| 91 | + path: transfer/channel-14 |
| 92 | +``` |
| 93 | + |
| 94 | +From the command output, you now know that there is an IBC port `transfer` and channel `channel-14`. But to know the IBC light client behind the port and channel, you need to perform another query. |
| 95 | + |
| 96 | +Why is it called a light client? Because it is a light client of the _other_ chain, keeping track of its blockhashes. The `ibc channel client-state transfer` command explains the details of the denom path. |
| 97 | + |
| 98 | +```bash |
| 99 | +gaiad query ibc channel client-state transfer channel-14 --node https://rpc.cosmos.network:443 |
| 100 | +``` |
| 101 | + |
| 102 | +Response: |
| 103 | + |
| 104 | +```bash |
| 105 | +client_id: 07-tendermint-18 |
| 106 | +client_state: |
| 107 | + '@type': /ibc.lightclients.tendermint.v1.ClientState |
| 108 | + allow_update_after_expiry: true |
| 109 | + allow_update_after_misbehaviour: true |
| 110 | + chain_id: mars |
| 111 | + frozen_height: |
| 112 | + revision_height: "0" |
| 113 | + revision_number: "0" |
| 114 | + latest_height: |
| 115 | + revision_height: "2207" |
| 116 | + revision_number: "0" |
| 117 | + max_clock_drift: 600s |
| 118 | + proof_specs: |
| 119 | + - inner_spec: |
| 120 | + child_order: |
| 121 | + - 0 |
| 122 | + - 1 |
| 123 | + child_size: 33 |
| 124 | + empty_child: null |
| 125 | + hash: SHA256 |
| 126 | + max_prefix_length: 12 |
| 127 | + min_prefix_length: 4 |
| 128 | + leaf_spec: |
| 129 | + hash: SHA256 |
| 130 | + length: VAR_PROTO |
| 131 | + prefix: AA== |
| 132 | + prehash_key: NO_HASH |
| 133 | + prehash_value: SHA256 |
| 134 | + max_depth: 0 |
| 135 | + min_depth: 0 |
| 136 | + - inner_spec: |
| 137 | + child_order: |
| 138 | + - 0 |
| 139 | + - 1 |
| 140 | + child_size: 32 |
| 141 | + empty_child: null |
| 142 | + hash: SHA256 |
| 143 | + max_prefix_length: 1 |
| 144 | + min_prefix_length: 1 |
| 145 | + leaf_spec: |
| 146 | + hash: SHA256 |
| 147 | + length: VAR_PROTO |
| 148 | + prefix: AA== |
| 149 | + prehash_key: NO_HASH |
| 150 | + prehash_value: SHA256 |
| 151 | + max_depth: 0 |
| 152 | + min_depth: 0 |
| 153 | + trust_level: |
| 154 | + denominator: "3" |
| 155 | + numerator: "1" |
| 156 | + trusting_period: 1209600s |
| 157 | + unbonding_period: 1814400s |
| 158 | + upgrade_path: |
| 159 | + - upgrade |
| 160 | + - upgradedIBCState |
| 161 | +``` |
| 162 | + |
| 163 | +That's a lot of information, but it doesn't answer the question: how do you know if this IBC client can be relied upon? |
| 164 | + |
| 165 | +### The Chain ID and the Client ID |
| 166 | + |
| 167 | +Anybody can start a chain with the same chain ID. However, the IBC client ID is generated by the [Cosmos SDK IBC Keeper module](https://github.com/cosmos/ibc-go/blob/e012a4af5614f8774bcb595962012455667db2cf/modules/core/02-client/keeper/keeper.go#L56) (ICS-02 does not specify a standard for IBC client IDs). A Chain Name Service and the not-so-decentralized Github chain-registrar repo can verify the combination of the chain ID and the client ID. Both the Chain Name Service and the chain-registrar repo are under development and are considered experimental. |
| 168 | + |
| 169 | +### Ensure the IBC Client Isn't Expired |
| 170 | + |
| 171 | +In the event that Tendermint consensus fails (if >1/3 of validators produce a conflicting block), _and_ proof of this consensus failure is submitted on-chain, the IBC client becomes frozen with a `frozen_height` that is nonzero. In the previous example, the output of `gaiad query ibc channel client-state` confirms the client status and you know the IBC client is not expired. |
| 172 | + |
| 173 | +The `latest_height.revision_height` is the block height when the IBC client was last updated. To ensure that the block height is still up to date, you would have to query the blockchain itself for the block height 2207, and ensure that the timestamp of that block + the `trusting_period` of 1209600s/336h/14d is after the current time. |
| 174 | + |
| 175 | +For example, you can verify the IBC client status using the query: |
| 176 | + |
| 177 | +```bash |
| 178 | +gaiad query block 5200792 --node https://rpc.cosmos.network:443 |
| 179 | +``` |
| 180 | + |
| 181 | +## Find the Path of Another Blockchain |
| 182 | + |
| 183 | +Being able to list all possible blockchain paths is still an unsolved problem. |
| 184 | + |
| 185 | +Any created blockchain can create a new `channel` to another blockchain without revealing too much of its information. |
| 186 | + |
| 187 | +Currently, channels must communicate with each other using a person-to-person protocol to be trustable. This person-to-person communication protocol uses an IBC denom so you can identify which tokens to accept for an app. |
| 188 | + |
| 189 | +One approach to solve this problem is to use a centralized or decentralized database of chain IDs and their nodes. There are two solutions under development: |
| 190 | + |
| 191 | +- Chain Name Service (decentralized) |
| 192 | + |
| 193 | + The [CNS](https://github.com/tendermint/cns) aims to be a Cosmos SDK module that the Cosmos Hub will one day run. As a hub through which cross-chain transactions go, it only makes sense for the Cosmos Hub to host the critical information on how to reach the other chain IDs. CNS is still new and under development. |
| 194 | + |
| 195 | +- Cosmos Registry (semi-decentralized) |
| 196 | + |
| 197 | + The [github.com/cosmos/registry](https://github.com/cosmos/registry) repo is a stopgap solution. Each chain ID has a folder describing its genesis and a list of peers. To claim their chain ID, a blockchain operator must fork the `registry` repo, create a branch with their chain ID, and submit a pull request to include their chain ID in the official `cosmos/registry` of chain IDs. |
| 198 | + |
| 199 | + Every chain ID is represented by a folder, and within that folder a `peers.json` file contains a list of nodes that you can connect to. |
| 200 | + |
| 201 | +- Cosmos Registrar (semi-decentralized) |
| 202 | + |
| 203 | + The [cosmos-registrar](https://github.com/apeunit/cosmos-registrar) is a tool that was started by Jack Zampolin and further developed by Ape Unit. The cosmos-registrar automates claiming and updating a chain ID. In this case, updating a chain ID means committing a fresh peerlist to the GitHub repository. This commit should be run with a cronjob. Its state is best described as v1.0, so go ahead and report any bugs as Github issues. |
| 204 | + |
| 205 | +Choose the approach that best suits you and your use case. |
0 commit comments