Trying to understand the IBC via its paper

[Vishwas1]

Hey guys,
I am part of team Hypersign (introduced us a month back to the community), we are trying to come up with a ICS for DID resolution over IBC. But before that I am trying to understand IBC as deep as possible.

After reading the paper of IBC, I tried to visualize the IBC as shown in the image below.

However, I still have some confusions and unable to find out answers of it.

1. First question is, is this diagram makes sense or have I misunderstood something?
2. “Channel exists between modules” => Can channel exists between two disjoint modules? Does Alice’s Module1 have to be same (with respect to code) as Bob’s Module1 or they can be different?
3. As I understand from the paper that IBC does not care what this data/packet is about, it just helps to transfer it with cryptographic proofs, does it means - any arbitrary data transfer is possible via IBC?
4. When the packet P is transferred over IBC from chain Alice cA to chain Bob cB, then a new data is created and stored on cB? If that is the case then does the cB need to have same data structure to store this data P, right?
5. Follow up question of 4. Can it be possible that cB does not store the packet P but rather just use it and use it to do whatever action it was doing?

Few of these question might be very naive but kindly help me understand them.

TIA
Vishwas

[Thomas_Interchain]

Hi Vishwas!

Thanks for your questions and interest in IBC! Let me run by them:

1. Your diagram looks pretty okay to me, I believe you’ve grasped the main concepts. I will add an alternative representation below (from a presentation by Chris Goes, the paper’s main author).

I would suggest two additions to your diagram:

• First, I would add the relayer to it. Your diagram could make it seem as if the two chains are communicating directly with one another, while in reality this is provided by the relayers and is an invaluable part of the IBC infrastructure
• Second, I would like to point your attention to a distinction between the module on the ledger that implements IBC functionality with the IBC handler one the one hand and the module sending or receiving the packet, i.e. the application module. Mostly these will be separate modules and the application module will be identified by the port identifier.

2. The modules on either ledger can be different implementations. The IBC protocol aims to be minimalistic in its requirements for participating ledgers. So there is some freedom in how to implement the IBC modules as long as they provide the required functionality as described in the paper (mainly verifying connection/channel state, verifying proof of commitments, generating proof of commitment and sending the packet to the application module). But there is freedom in how to implement this, for example one chain can implement a module as in the Cosmos SDK, while another might use a smart-contract.
3. Yes, theoretically the packet data can be arbitrary. However, you need the receiving module to be able to understand the data to translate it into application logic. So in practice we will have standards, as you can already find in the IBC specs GitHub repo.
   So I would suggest interpreting the “payload-agnostic” characteristic more so as a separation of concerns, meaning that neither IBC core developers nor relayers need to understand the packet data - that would be up to IBC application developers and vice versa. Rather than arbitrary data being sent.
4. It’s not the packet data itself that is stored, but a shortened hash of the commitment data and timeout value. This proof of packet commitment/acknowledgement is being stored on-chain in the native structure of the chains, so they can have different structures. This is why we have the light client implemented for the counterparty chain, so that we can still understand and verify the state of the counterparty chain, even if they have a differing structure.
5. The application module acting on packet data without a proof of acknowledgement being stored on the chain, would be malicious behaviour from the receiving chain and when this is noticed by the client or relayer, the connection should be frozen asap. An important consideration in IBC is that we assume the counterparty chain is secure and trustworthy.
   
   

In case you have more questions, escpecially in case you’ve started development, feel free to post your question in our Cosmos Community Discord. We will probably be able to get back to you on shorter notice there!

Hope this answers the question you had!
Thomas | Developer Relations, Interchain