Expand description
The designs and logic pertaining to the transport, authentication, and ordering layers of the IBC protocol.
Naming is hard in the IBC handlers, since we deal with a client on a counterparty chain, which is itself a light client of self (the chain the handler is currently running on). So depending on the frame of reference chosen, e.g. counterparty_client_state could mean:
- the client state of the client running on the counterparty chain
- or the state of the “counterparty client” (that is, the client that we run of the counterparty chain) running on the host chain
We remove such ambiguity by adopting the following conventions:
- we call “chain A” the chain that runs
OpenInit
andOpenAck
- we call “chain B” the chain that runs
OpenTry
andOpenConfirm
- In variable names,
on_a
implies “stored on chain A”of_a
implies “of light client for chain A” Soclient_state_of_a_on_b
means “the client state of light client for chain A stored on chain B”
Modules
ICS 02: Client implementation for verifying remote IBC-enabled chains.
ICS 03: Connection implementation for connecting a client
on the local chain with a client on a remote chain.
ICS 04: Channel implementation that facilitates communication between
applications and the chains those applications are built upon.
ICS 05: Port implementation specifies the allocation scheme used by modules to
bind to uniquely named ports.
ICS 23: Commitment implementation of a cryptographic scheme that verifies
state transitions between chains.
ICS 24: Host defines the minimal set of interfaces that a
state machine hosting an IBC-enabled chain must implement.
ICS 26: Routing module keeps a lookup table of modules for looking
the appropriate module to relay to when a packet is received.