IBC and ICS
IBC stands for inter-blockchain communication protocol proposed by Cosmos. As the name suggests, IBC was designed to allow communication between different chains. For seamless IBC implementation, the ICS (inter-chain standard) specification was defined. As long as each blockchain implements its modules in accordance with the ICS specification, it will be possible for every chain to communicate with one another.
Things to Solve
Currently in the year 2020, there are many blockchains out there, each with its own different protocols. However, it is still inconvenient to pass tokens between different chains. For example, if a person with Bitcoin wants to pass a token to an Ethereum user, they would not pass Bitcoin as it is, but sell their own Bitcoin to earn cash and then use that cash to buy Ether to make trades in the Ethereum chain. Of course, this process doesn’t actually move cash between the two chains; it simply makes transactions inside each respective chain to change the total amount held by a particular person. In addition, cash transactions are unnecessarily made twice, resulting in expensive fees and cumbersome procedures.
However, what if you can actually send tokens from one chain to another? Tokens are not something that can be physically carried and moved, so ‘send’ can be understood as verifying that each blockchain has recorded the token that you sent/received to the other party’s chain in a reliable manner. If the sending chain burns or locks the transmitted token and the receiving chain treats the new token or voucher as being created and records the new token on a block, the two users in each chain would have successfully transferred ‘value’ from one to another. In the cumbersome scenario explained earlier, the Bitcoin user can now simply send Bitcoin to the Ethereum chain. Of course, how the transferred tokens are utilized in other chains is a matter of freedom, and depending on the situation, you can even make Bitcoin-Ether exchanges with other Ethereum users.
However, communication between blockchains with completely different purposes or management is not the only use case. For instance, sidechains separated by shards can also conduct transactions with each other. In this case, in order to optimize the mainnet of a chain, the sidechains must be divided and communicate with one another via IBC.
Trade
Suppose that user P in chain A sends token X of chain A to user Q in chain B. The procedure is as follows:
- A locks P’s X. Locked tokens cannot be used.
- A creates a packet to send to B and commits the block after changing the state to reflect that it has sent the packet.
- A sends the packet created in step 2 and the respective state’s Merkle Proof to B.
- B confirms whether the received packet and proof are information actually contained in A or not.
- B gives Q a voucher for X.
- If B fails and times out, A will include a proof in its state that proves that B does not contain A’s packet amongst B’s newly added blocks since A sent its packet. Then, A will unlock P’s token.
- If not, continue to lock P’s token or burn it to consider it completely transferred from A to B.
Module
The process above proceeds under the premise that each chain reliably handles packets and they will be included in each chains’ states. In other words, the work of these upper layers are modularized and published in advance according to the ICS standard. IBC is strictly responsible for the communication between these modules, and each module changes the state in a deterministic way. In reality, there is a fixed amount of ways for the module to send and receive packets and change the state, and chains participating in the IBC need to reflect this in their blocks according to their structure.
Verification & Light Client
As mentioned above, the essential step for each chain to communicate is to verify its transmission and reception. It is up to each chain to construct a new block, but verifying that the actual counterpart included your packet or locked the token must be done separately.
In fact, verifying transactions/states is something that was originally done in the chain without the need for IBC. For example, it’s up to the user to see which transactions they’ve made and whether they’re really included in the chain. In general, nodes that verify and mine blocks in a chain, ie, full nodes, can verify this by looking it up in their own DB. However, in addition to such individual verification, the full node also manages the entire chain and verifies new incoming blocks as well. Therefore, the full node holds onto all the states and transactions in its DB, resulting in unnecessarily large disk usage. As a result, we needed a light node that specializes only in identifying transactions/states of interest. This is called a ‘light client’.
However, as mentioned earlier, IBC only needs to verify whether the state of the other chain reflects your packet, so this is exactly the same problem that the “light client” was dealing with. Rather than constructing a new subprotocol that verifies the other party’s chain, it is more efficient to apply and properly provide a light client that is implemented regardless of IBC, and that’s the method actually being used. IBC requires a light client of each chain, and if everything is well implemented, it will be able to quickly and lightly perform validation instead of the unnecessary and cumbersome way of running the full node of the other party.
The behavior of light clients varies from chain to chain, but what they all have in common is that it is possible to write Merkle roots in the header of a block and request for Merkle Proofs from nearby full nodes whenever you want to verify them. We’ll talk more about how the light client works in the next article.
Finality
The PoS family of consensus algorithms, such as Tendermint used in CodeChain, ensure finality. In other words, once a chain comes to a consensus, it is never reverted. On the other hand, PoW family consensus algorithms like Bitcoin provide a consensus of ‘probability’. In other words, depending on your luck, the chain you saw last can be invalid. IBC requires finality. This is because if you think you’ve successfully sent a token to your opponent’s chain but that chain ends up being changed, you just lost your tokens. Therefore, communication and transfer between PoS and PoW chains require special processing. By setting up a ‘peg zone’ that allows a limited amount of additional blocks, it is possible to verify finality.
Hub
The technology explained so far is already exceptional, but there is still room for improvement. All chains wishing to participate in IBC must implement each other’s light clients. The reason for this is that different blockchains have different protocols and specifications. For example, with N blockchains, you will need N * (N-1) implementations. However, if there is one blockchain that corresponds to a hub that mediates these transactions, everyone can directly perform IBC directly with the hubchain, and the hubchain can only serve to route the actual transactions. That is, with 2 * N light client implementations, all N chains can communicate with each other. This structure eases development and connectivity by reducing dependencies on each other even more than the light client. However, it is a complex process that requires additional protocols beyond IBC, so there are still many problems to solve.
Conclusion
Blockchain communication is fairly easily defined by the simple concept of releasing standardized modules and implementing light clients. However, it is still under discussion and the role it will play in the blockchain ecosystem is still unknown. CodeChain is currently planning to participate in Cosmos’ IBC to facilitate value exchange amongst humanity through active networking between different blockchains.
* This article is a preview of CodeChain TechTalk video. Anyone who is interested can freely access various tech intro videos of CodeChain.
