Disparate blockchains need to have a way to communicate so that users can interact with data and assets on multiple blockchains easily and thus the Inter-Blockchain Communication (IBC) protocol was established to function as a transport layer between blockchains. The Cosmos ecosystem adopted IBC first, but as it is a generalizable protocol, IBC has found its way into many other ecosystems.

ICS-02 outlines the requirements for light client construction, including how IBC manages light client data. Clients are needed for IBC to work, which are arbitrary verification algorithms to prove information on-chain, which is usually encoded in IBC format, from one place to another.

From the perspective of IBC, each chain is normally identified by its light client. The most common verification occurs between two communicating state machines; using a light client, a source chain is able to verify updates from a destination chain without downloading its entire data. Because light clients are a versatile tool, they can use multiple methods to do state verification.

Consensus Proof Verification

A Note On Consensus Algorithms

Blockchain consensus makes sure that all the nodes that participate in a network are in sync. Using consensus verification, the light client proves that a sufficient number of validators signed the header. This type of verification is the most popular use of IBC.

Consensus algorithms typically vary in their rulesets and what they prioritize. However, the heterogeneity in two different consensus algorithms might make it difficult for chains to communicate over IBC. For example, Cosmos chains use the Tendermint consensus algorithm which has single-slot finality, otherwise known as fast finality. On the other hand, Ethereum consensus does not have single-slot finality and thus slower finality because it values liveness over security while IBC is most compatible with consensus algorithms that value security. Because of this difference in when blocks are considered ‘final’, there is difficulty in how the two chains are able to send and verify blocks between each other.

In such a case, a virtual light client can be implemented that can have a view into the light client at a certain block height before finality is reached. Initially IBC focused on its adoption within chains that are Tendermint-based, which was evident in how the client specification and implementation were defined. After this initial phase, the Client Refactor increased flexibility and ease in developing light clients for chains with other consensus algorithms and features.

Light Clients: State Machines

A “state machine” can be an entire blockchain (replicated ledger) or a single process that signs operations with a private key (minimal consensus), such as a laptop or mobile phone.

Commonly, we think of state machines as blockchains with distributed ledgers, so when establishing IBC between blockchains, a destination chain’s light client is hosted by the source chain. The source chain also maintains a trusted state of the destination chain, which is established by a connection handshake between the two chains. The IBC protocol uses a validity predicate, which is an algorithm that checks if state updates of a destination chain are valid. To function, a light client needs a validity predicate and a trusted state for the source chain.

client “type” vs. client “instance”

Light clients are designed to be as efficient as possible to support a large number of client instances for many chains. To achieve this, the light client algorithm does not replay all state transitions, which would otherwise make it a full node.

Light Clients: Solo Machines

A solo machine is a device such as a laptop, web interface, mobile phone, or an off-chain process. A solo machine can establish communication with a replicated ledger if that blockchain uses IBC for transport.

As an example, IBC can enable a custodial transfer protocol that lowers the integration costs for new chains. This is important because centralized custodians face a tedious and expensive process when integrating new networks which requires running a full node and RPC infrastructure for each integrated chain. Instead, the custodian can operate a solo machine client which facilitates cross-chain transfers, mints/burns. Verification would be conducted by the client of the connected machine run by the custodian.

Solo machine clients showcase how IBC opens up connectivity outside of just blockchains. In the above example, it can allow institutions to easily interact with public blockchains via IBC. This is just one example of business lines that touch blockchains without having to spin up an entire chain or maintain heavy hardware to work with them.

Verification Beyond Consensus Proofs

Though there is work being done to make clients easy to implement and update, there is the option to conduct verification with validity or fraud proofs.

Optimistic IBC: Clients can optimistically accept incoming headers via an off-chain relayer that executes a program on some virtual machine. In this scenario, there is a challenge window where a fraud proof can be submitted. The positive is that Optimistic IBC reduces the cost of the entire system. The downsides include the long fraud challenge period and depending on the network, there could be high base costs to transferring assets – for Ethereum, this is 21,000 units of gas.

ZK-IBC: Client computations occur off-chain and verified on-chain via ZKPs. There is no minimum latency and cost is lower than naive verification. But, ZK verification can be expensive on-chain and there’s no maximum latency, which means a user might be waiting for a while to get confirmation. There might also be incompatibility issues if the signing scheme is not SNARK-friendly.

Because the separate systems above can have some prohibitive cons, Optimistic ZK is proposed to borrow benefits from both. The benefits of using both lowers cost of connection maintenance and introduces a maximum latency bound via incentivizing relayers.

Optimistic ZK: The source chain accepts headers optimistically on-chain (there is possibly a staking mechanism in place for security). Then, ZKPs are used as fraud proofs in case of misbehavior or validity proofs to dynamically reduce the latency of the connection.

Security and Misbehavior

IBC does not require any third-party trust assumptions, which externally verified interoperability protocols often take on. It is simply a transport protocol and its security properties depend on the underlying client and connection types and not the chain itself. It also depends on connection’s use of fraud proofs, honest majority assumptions, shared security via common data availability, etc. The IBC protocol does not need to know the identities of the chains on either side of a connection, as long as the IBC clients are kept in sync with valid updates.

In the event that there is misbehavior, i.e. the consensus rules set by the destination chain are broken by the client on a source chain, the client on the host chain would be frozen if proof of the misbehavior is verified on the source chain. The party that saw this, such as the relayer, can send a message with evidence of this misbehavior. The misbehavior predicate is an algorithm that is called in situations such as this: if misbehavior is proven, the client gets frozen and hopefully there is a governance system in place to take action. The repercussions of misbehavior is decided on by participating chains.

Building With Light Clients

Though IBC can require some technical proficiency in the underlying chain’s consensus and internals, not all the intricacies are crucial in order to build using IBC – another goal we have with these series of articles. The takeaway here is that IBC is a powerful tool given the various verification implementations that clients can take on.

The IBC ecosystem is actively working to make IBC an easy solution for builders to adopt. Some of the initiatives we have discussed include client refactor and virtual clients. For example, if a chain wants to upgrade consensus, it will need to upgrade every chain it’s connected to and their light clients to stay connected, which is an expensive on-chain governance process. WASM clients are being developed to make developing and upgrading light clients simple via client instances deployed as smart contracts. This makes it easier to upgrade light clients without halting the chain and to create clients in languages like Rust, which is a popular choice amongst several state machines.

The parting takeaway is that IBC clients can be used by anyone and any machine to verify state across any blockchain, making them a powerful catalyst for novel businesses and services in crypto.

This article was sponsored by Polymer to support community education around IBC and truly decentralized interoperability.

Polymer Labs, composed of skilled distributed systems and infrastructure engineers, crypto pioneers, and accomplished business operators, is at the forefront of advancing Ethereum interoperability with IBC. With technical values based on TCP/IP, Polymer’s mission is to establish the next generation of the internet by ensuring that the interoperability layer of the decentralized web is neutral, open, permissionless, and uniform across ecosystems. As the creators of the Ethereum Interoperability Hub, the first Layer 2 focused on enabling IBC interoperability, Polymer sets a new standard in blockchain technology.

Disclaimer：

1. This article is reprinted from [eshitanandini]. All copyrights belong to the original author [ESHITA]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.