Client Refactor: Laying the Groundwork for IBC to Expand Across Ecosystems

ibc-go v7.0.0, tentatively scheduled for release in Q1 2023, will incorporate the 02-client refactor work. The refactor aims to make light client development significantly easier.

The security properties of the Inter Blockchain Communication (IBC) protocol are defined by the security properties of light clients (see here for a primer on how IBC works). As of today, IBC supports three different client types — tendermint, solo machine, and localhost.

For the Interchain vision to materialize, IBC needs to support chains that are not just tendermint-based. This naturally requires the development of light clients that can track a variety of different consensus algorithms.

Therefore, the client refactor aims to reduce the friction surrounding light client development in order to extend IBC to multiple ecosystems.

How does the refactor benefit me as a light client developer?

• Flexibility with respect to verification and storage (chains can now use custom trie implementations, batch updates, etc.)
• Reduced code complexity
• Generic verification functions as opposed to specific ones
• Solo machines will now be able to process timeouts
• Well-defined interfaces and their required functionality
• Future-proof for client/connection/channel upgradability features that are yet to be implemented

Motivation

In the initial design of IBC, each client type (tendermint, solomachine and localhost) was hardcoded within the 02-client submodule as shown in the code example below:

Adding code directly to the 02-client submodule every time a new client type needed to be supported was not scalable. Issue #6064 addressed this problem by generalizing the interaction between 02-client and different client types via an interface.

While this introduced a more modular design, developers faced significant challenges every time a change was required to one but not all client types (see here for more information regarding some of these issues).

What changes does the refactor introduce?

As part of the client refactor, the most important decision made was to require light clients to handle all management of client state (contains the parameters required to verify headers) and consensus state (contains the header with the application’s root hash, next validator set hash, and timestamp).

As discussed in the previous section, currently the client and consensus states are set within the 02-client submodule. By moving these responsibilities from the 02-client level to the individual light client implementations, including the setting of updated client state and consensus state in the client store, provides light client developers with a greater degree of flexibility with respect to storage and verification.

For instance, clients will be able to perform batch updates, i.e. setting many consensus states in a single update/header.

For new clients such as the BEEFY light client developed by Composable Finance, batch updates are useful since one instance of a BEEFY client can receive headers from all parachains in a single update and mutate state. Doing so reduces the overhead associated with storage and costs for header verification.

The refactor also introduces the following changes:

1. Merging Header/Misbehaviour interfaces and renaming to ClientMessage: reduces code complexity. A ClientMessagecould be a Header, Misbehaviour, or a batch update.

2. Splitting CheckHeaderAndUpdateStateinto 4 functions

3. Adding GetTimestampAtHeightto the client state interface: solves the problem of solo machines not being able to process timeouts correctly. See here to learn more.

4. Adding generic verification functions: allows for the clear distinction of light clients, core IBC, and applications so that any one of these components can be upgraded independently without having to make changes to the others. Refer to this issue for more information.

Conclusion

By moving functionality from the 02-client submodule level to the specific light client implementations, the client refactor work is an important milestone towards making light client development easier.

These changes will allow IBC to extend interoperability to chains with varied consensus algorithms, data structures, and cryptographic primitives. Paving the way for a universal, secure and reliable interoperability standard for blockchains.

If you’re a chain developer looking to build your custom IBC light client, and have any questions, comments or feedback regarding the topics discussed in this blog post, feel free to reach out to us here.

IBC is a fundamental paradigm shift in interoperability by allowing for arbitrary data transfer across blockchains in a trust-minimized, secure, and extensible manner. Refer to our Interchain Developer Academy material to learn more about IBC.

About the Author:

Adi Ravi Raj works at Interchain GmbH and is the Protocol Analyst for the IBC team.

Shoutout to Susannah Evans, Carlos Rodriguez and Thomas Dekeyser for the feedback and review.