Module ibc::core

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:

1. the client state of the client running on the counterparty chain
2. 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 and OpenAck
• we call “chain B” the chain that runs OpenTry and OpenConfirm
• In variable names,
  • on_a implies “stored on chain A”
  • of_a implies “of light client for chain A” So client_state_of_a_on_b means “the client state of light client for chain A stored on chain B”

Modules

ics02_client

ICS 02: Client implementation for verifying remote IBC-enabled chains.

ics03_connection

ICS 03: Connection implementation for connecting a client on the local chain with a client on a remote chain.

ics04_channel

ICS 04: Channel implementation that facilitates communication between applications and the chains those applications are built upon.

ics05_port

ICS 05: Port implementation specifies the allocation scheme used by modules to bind to uniquely named ports.

ics23_commitment

ICS 23: Commitment implementation of a cryptographic scheme that verifies state transitions between chains.

ics24_host

ICS 24: Host defines the minimal set of interfaces that a state machine hosting an IBC-enabled chain must implement.

ics26_routing

ICS 26: Routing module keeps a lookup table of modules for looking the appropriate module to relay to when a packet is received.