Learn about the 09-localhost light client module.
The 09-localhost light client module implements a localhost loopback client with the ability to send and receive IBC packets to and from the same state machine.
In a multichain environment, application developers will be used to developing cross-chain applications through IBC. From their point of view, whether or not they are interacting with multiple modules on the same chain or on different chains should not matter. The localhost client module enables a unified interface to interact with different applications on a single chain, using the familiar IBC application layer semantics.
There exists a single sentinel
ClientState instance with the client identifier
To supplement this, a sentinel
ConnectionEnd is stored in core IBC state with the connection identifier
connection-localhost. This enables IBC applications to create channels directly on top of the sentinel connection which leverage the 09-localhost loopback functionality.
State verification for channel state in handshakes or processing packets is reduced in complexity, the
09-localhost client can simply compare bytes stored under the standardized key paths.
Localhost vs regular client
The localhost client aims to provide a unified approach to interacting with applications on a single chain, as the IBC application layer provides for cross-chain interactions. To achieve this unified interface though, there are a number of differences under the hood compared to a 'regular' IBC client (excluding
The table below lists some important differences:
|Number of clients||Many instances of a client type corresponding to different counterparties||A single sentinel client with the client identifier |
|Client creation||Relayer (permissionless)|
|Client updates||Relayer submits headers using ||Latest height is updated periodically through the ABCI |
|Number of connections||Many connections, 1 (or more) per client||A single sentinel connection with the connection identifier |
|Connection creation||Connection handshake, provided underlying client||Sentinel |
|Counterparty||Underlying client, representing another chain||Client with identifier |
|Performs proof verification using consensus state roots||Performs state verification using key-value lookups in the core IBC store|
|Integration||Expected to register codec types using the ||Registers codec types within the core IBC module|