Explain IBC in a very simple way

Vishwas1 commented 2 years ago

Remittance

IBC resembles with International Wire transfer

	Remittance	IBC
	Source Country	Source Blockchain
	Destination Country	Destination Blockchain
	Bank Account	Wallets
	Amount	Amount
	Providers (western union)	Relayers
	SWIFT / FedWire	Channel
	Sending USD to US bank account	Locking coins in Source chain
	Receiving INR from Indian bank account	Minting vouchers at destination chain

https://www.investopedia.com/terms/w/wiretransfer.asp

Vishwas1 commented 2 years ago

Relayers

In the IBC architecture, blockchains are not directly sending messages to each other over networking infrastructure, but rather are creating messages to be sent which are then physically relayed from one ledger to another by monitoring “relayer processes”.
IBC assumes the existence of a set of relayers with access to an underlying network protocol stack (likely TCP/IP, UDP/IP, or QUIC/IP) and physical interconnect infrastructure.
These relayers continuously scan the state of ledgers that implement the IBC protocol and relay packets when these packets are present.
Relayers CANNOT modify IBC packets, as each IBC packet is verified using light-clients by the receiving chain before being committed.
Anyone can run a relayer and may be rewarded with a small transaction fee depending on the implementation fo each ledger.

Relayers Implementations

Vishwas1 commented 2 years ago

Light Clients

IBC Clients are light clients (identified by a unique client-id) that track the consensus states of other blockchains, along with the proof spec necessary to properly verify proofs against the client's consensus state. -A client may be associated with any number of connections to multiple chains.

Connections

The connection handshake is responsible for verifying that the light clients on each chain are correct for their respective counterparties.
Connections, once established, are responsible for facilitating all cross-chain verification of IBC state. A connection can be associated with any number of channels.

In IBC, blockchains do not directly pass messages to each other over the network.

Channel

A channel can then be conceptualized as an IP connection, with the IBC portID is like an IP port, and the IBC channelID is like an IP address.
An IBC channel can be established between two IBC ports.
A port is exclusively owned by a single module.
IBC packets are sent over channels.
Just as IP packets contain the destination IP address, IP port, the source IP address, and source IP port, IBC packets contain the destination portID, channelID, the source portID, and channelID.
The IBC packets enable IBC to correctly route the packets to the destination module, while also allowing modules receiving packets to know the sender module.
Modules may choose which channels they wish to communicate over with.
IBC expects modules to implement callbacks that are called during the channel handshake. These callbacks may do custom channel initialization logic. If an error is returned, the channel handshake fails. By returning errors on callbacks, modules can programmatically reject and accept channels.

If all of these actions happen successfully, the channel is open on both sides.

Packets

Modules communicate with each other by sending packets over IBC channels.

IBC packets contains

{
   destinationPortId,
   destinationChannelId,
   sourcePortId,
   sourceChannelId,
   TimeoutTimestamp,
   TimeoutHeight,
   Data [] byte
}

These port and channels allow the modules to know the sender module of a given packet.
Timeout values determine the deadline before which the receiving module must process a packet.
Modules send custom application data to each other inside the Data []byte field of the IBC packet.
Packet data is completely opaque to IBC handlers. The sender module must encode their application-specific packet information into the Data field of packets.
The receiver module must decode that Data back to the original application data.

Receipts and Timeouts

- IBC handles the case where a packet does not get sent to its destination in a timely manner or at all. Packets must specify a timeout height or timeout timestamp after which a packet can no longer be successfully received on the destination chain.
If the timeout is reached, then a proof-of-packet timeout can be submitted to the original chain which can then perform application-specific logic to timeout the packet, perhaps by rolling back the packet send changes (refunding senders any locked funds, and so on).

So because of TimeoutTimestamp field in packets, there is no worry of loosing funds. Since in case any mishaps happens during IBC, like relayer going offline or something, post timeout, the funds will be any way unlocked at the source chain.

Acknowledgment

After the acknowledgement has been written by the receiving chain, a relayer relays the acknowledgement back to the original sender module which then executes application-specific acknowledgment logic using the contents of the acknowledgement. This acknowledgement can involve rolling back packet-send changes in the case of a failed acknowledgement (refunding senders).
After an acknowledgement is received successfully on the original sender the chain, the IBC module deletes the corresponding packet commitment as it is no longer needed.

One questions - as a IBC app developer, I do not have to worry about any of the concepts of IBC like connections, channels etc, Its being abstracted out to us. All I should care about, a) what goes into Data field of the packet - specific to my usecase b) IBC callback - what I would do once the success full IBC transfer happens. Is that correct ?

Modules

IBC handler.

IBC handles the creation of a handshake based connection and the authentication, transport, and ordering (TAO) of opaque data packets relayed between modules on separate ledgers. Ledgers can be run on solo machines, replicated by many nodes running a consensus algorithm, or constructed by any process whose state can be verified. The protocol is designed for safe simultaneous use between any number of modules on any number of ledgers connected in arbitrary topologies.

hypersign-protocol / whitepaper