# Interblockchain Communication Protocol (IBC): Summary
This set of notes hopes to give a quick overview of the IBC [paper] (https://github.com/cosmos/ibc/raw/old/papers/2020-05/build/paper.pdf).*(in progress)*

## Introduction

IBC provides a mechanism by which separate, sovereign replicated ledgers can safely, voluntarily interact with a minimum requisite common interface.

Ledgers hosting IBC are required to provide functions for
- consensus transcript verification
- cryptographic commitment proof generation

In fact, ledgers in IBC are defined as their light client consensus validation functions, thus broadening the scope of what a "ledger" could mean in the context of IBC.

Modules on each ledger determine semantics of the packets which are sent between them, thus enabling data payloads in IBC packets to be opaque to the protocol. As a pertinent example for Het Paxos, packets could contain vote information where accounts **(?)** on one ledger vote in ballots of another.

**TCP/IP for blockchains**: Just as TCP/IP defines the protocol which which two hosts may communicate, leaving the construction of complex topologies to higher protocols, IBC defines a protocol by which two ledgers communication while higher-level protocols may establish multiple bidirectional links between ledgers for multi-ledger applications.

Furthering the analogy to TCP/IP, payload data is opaque to IBC packets and IBC allows one ledger to reason about the state of a module on another.

## Protocol scope and properties
### Scope
The protocol is defined between modules on two ledgers, but is designed for safe simultaneous use between any number of modules on any number of ledgers in arbitrary topologies.
### Interfaces
IBC provides modules a set of functions similar to those provided to interact with another module on the same ledger: opening and closing connections/channels, choosing connection/channel/packet delivery options, sending/receiving data packets on an established connection and channel and inspecting connection/channel status.

It requires that the underlying ledgers enjoy finality properties and have cheaply-verifiable consensus transcripts (so as to be verifiable by a light client with much less computation or storage than a full node). For the network, IBC only stipulates eventual data delivery, no authentication, synchrony or ordering properties are assumed.

### Operation

1. Data relay: Messages are physically realayed from one ledger to another by monitoring "relayer processes", which monitor a set of ledgers implementing IBC scanning for state changes and requesting transaction execution on another ledger when outgoing packets are committed.

2. Data confidentiality and legibility: Only the minimum data for correct operation of IBC need be made available. **add table describing data**

3. Reliability: The protocol assigns a sequence number to each packet sent over an IBC channelwhich is checked by the IBC handler on the receiving ledger, and provides a method for the sending ledger to verify receipt of a packet. The sending ledger also cryptographically commits to the sent packets which the receiving ledger verifies. Datagrams altered in transit are consequently rejected. IBC also supports unordered channels.

4. Flow control: IBC *does not* provide specific protocol-level provisions for compute-level or economic-level flow control. It may however reject packets based on stipulations by higher-level protocols.

5. Authentication: The sending ledger must commit to its outgoing packet, which the receiving ledger verifies.

6. Statefulness: Points 3, 4 and 5 require that IBC initialize and maintain state information for each datastream, which is split between clients, connections and channels. A client object contains information about the consensus state of the counterparty ledger. A connection object contains a specific pair of named identifiers agreed upon by both ledgers, which uniquely identifies the connection between them. A channel object contains information concerning negotiated encoding and multiplexing options as well as state and sequence numbers (see point 3). These three objects are described in detail in the next section.

7. Multiplexing: IBC allows any number of channels to be associated with a single connection, with each channel having a uniquely identified data-stream over which packets may be sent. Channels may be one-to-many or many-to-one (in terms of modules), and the number of channels per connection is in principle unbounded.

## Host ledger requirements
1. Module system: Self-contained, potentially mutually distrusting packages of code should be able to be safely executed on the same ledger, and be identified and manipulated by a controller module/execution environment.

2. Key/value store interface: Values should be able to be read, written and deleted.

3. Consensus state introspection: Host ledgers must be able to determine their current height, consensus state and a bounded number of previous consensus states.

4. Timestamp access: To support timeouts, host ledgers should provide a current Unix-style timestamp.

5. Port system: The IBC handler should be able to allow different modules to bind to uniquely named ports. Ports are allocated on a FIFO basis and cannot be bound to more than one module at a time, but a module may bind to multiple ports. Reserved ports are also supported when the ledger is first started.

6. Exception/rollback: A transcation can abort execution and revert to a previous state, excluding gas and fees.

7. Host ledgers must be have eventual data-availability.

## Protocol Structure

### Clients

The client encapsulates the properties that consensus algorithms of ledgers implementing IBC need to satisfy. A *validity predicate* is an algorithm used to verify the consensus transcript and state-subcomponents of another ledger.

> validity predicate + state (assumed correct) = light client

A light client is used to verify updates to the state of another ledger which the other ledger's consensus algo has agreed upon and reject any possible updates which the other ledger's consensus algo has not agreed upon.

IBC is agnostic to internal operations of ledgers as well as their consensus algorithms. Light client verifications must have *finality* i.e. verified blocks cannot be reverted.