Thread by @jack_zampolin

A quick thread on the primitives that make up #ibc. There are four major ones:
1. Clients
2. Connections
3. Channels
4. Packets

🚀👨‍🚀🌔👩‍🚀👇

In IBC, a "Client" is an instance of a lite client for another chain that is committed to state. This piece is fundamental to the function of #ibc. All other primitives rely on clients to prove their data was included in the counterparty chain.

github.com/cosmos/ics/tre…

Once we have a client to prove data, we create a "Connection". This requires 4 transactions, 2 on each chain. The clients are updated throughout to prove the newly committed state on both chains.

github.com/cosmos/ics/tre…

Once this authorization has been completed, we create a "Channel". This contains the specifics of which module in the chain to send the data (the "Port") as well as ordering semantics and application protocol versioning.

github.com/cosmos/ics/tre…

The first three primitives make up a persistent link between chains that can be endlessly reused to send "Packets" which hold application data. But, the clients on each chain need to be updated at least once every unbonding period (~3 weeks), or we could no longer trust it.

Sending a "Packet" requires at least two transactions, one on the sending chain and one on the receiving chain. The #ibc spec also contains ack (confirming receipt and processing) and timeout packets.

During the sending of a packet, the receiving client gets updated so it can prove that the sending chain actually made the required state transitions, so links that are active will be frequently updated.

Understanding these four primitives will make #ibc much less confusing. To get started playing around with them, go check out the relayer I've been building! It allows you to dig into as much or as little detail as you would like while sending data between chains.

github.com/iqlusioninc/re…