Preparing for IBC 1.0

by Interchain GmbH

Introduction

The upcoming Stargate upgrade will include version 1.0 of the Inter-Blockchain Communication protocol (IBC), the mechanism for interoperability between heterogeneous chains, which forms the connective substrate for the Cosmos Network. IBC has been in design and development since the release of the original Cosmos whitepaper. In suitable fashion for a technical interoperability protocol, interoperability between many organizations and individual contributors has been essential in bringing IBC to where it is today — Tendermint, Agoric, Informal Systems, Chorus One, Iqlusion, Interchain GmbH, and the Interchain Foundation have all contributed resources & personnel to the design, specification, and implementation of IBC. Many community contributors outside of those organizations have found bugs, submitted specification proposals, and provided invaluable quality assurance testing for the software. The 1.0 release of IBC is the culmination of years of diligent work by these organizations & individuals, but it is also the beginning of the next chapter in the trajectory of the Cosmos Network, and the inflection point at which the driving force behind protocol development & adoption must shift from a relatively tight-knit coalition of firms to a much wider community of blockchain developers, proof-of-stake validators, and protocol users.

This blog post outlines what the 1.0 release of IBC will consist of, enumerates the expected sequence of steps for testing & deployment of IBC as part of the larger Stargate upgrade process, briefly catalogs ongoing IBC-related work which is not formally part of the 1.0 release process but will be of interest soon, and sketches a few nascent ideas for the future development of IBC after Stargate & the 1.0 release, some of which will also be outlined in greater detail in a future post.

Ingredients for the 1.0 IBC release

IBC has been developed “specification-first”, meaning that we first designed & wrote down a complete, canonical specification of the abstractions & logic utilized in the protocol before writing any code. The specification is designed to provide a sufficient level of detail so that properties of the protocol can be reasoned about in the abstract, and so that implementations in different languages or frameworks which are faithful to the types & procedures in the specification will correctly realize these properties and interoperate seamlessly with each other. The IBC specification is available in full form on Github and in condensed form as a paper. The 1.0 IBC release will include a canonical 1.0 specification version, which can be implemented by any blockchain for specification-compliant IBC support.

The first implementation of the IBC protocol has been developed in Golang using the Cosmos SDK. This implementation adheres to the aforementioned specification and includes dynamic capabilities for runtime port & channel permission management, Tendermint light clients for interoperation with any Tendermint blockchain, solo machine clients for interoperation with solo machines identified by a public key, a generalized Merkle proof system for integration with different back-end blockchain data stores, and an ICS-20 module for cross-chain fungible token transfer. If you are interested in playing around with the Go code or integrating it into your blockchain, check out the documentation. The 1.0 IBC release will include a specification-compliant 1.0 IBC implementation in the Cosmos SDK, which can be imported directly by any Cosmos SDK for plug-and-play IBC support.

In order to facilitate data transport between sovereign chains, IBC requires the existence of off-chain relayer processes, which monitor the state of chains for outgoing packets and submit them to the appropriate destinations. Anyone with accounts to pay transaction fees and the ability to monitor state & submit transactions can be a relayer, and in order to automate the logic involved, we have developed a Golang relayer which can automatically set up light clients, run the handshake process to create connections & channels, and scan & relay IBC packets from one chain to another. The 1.0 IBC release will include a specification-compliant 1.0 Golang relayer release, which can be easily configured & operated by anyone wishing to relay IBC packets.

IBC pre-flight check sequence ✈️

Interchain GmbH is currently in the final steps of testing & finalizing the Golang IBC implementation in the Cosmos SDK, with a particular eye towards ensuring that future upgrades, both of blockchains utilizing the IBC protocol and of the IBC protocol itself, can proceed smoothly with minimal disruption to users. Once complete, this work will be released in Cosmos SDK v0.40, in conjunction with Tendermint v0.34, as described in the Stargate Upgrade Proposal.

The Stargate upgrade bundles together a lot of changes, and it will likely be necessary to go through several release candidates and intensive sequences of testnets in order to ensure that the software is ready to deploy to production. The first Stargate testnets will focus mostly on preparing users & integrated services for the protobuf encoding changes, but zones and potential relayers will be able to individually start preparing for IBC integration and test out the release candidate software if they wish. A public bug bounty program will be operated for any bugs found in the aforementioned IBC specification & software release candidates. Subsequent Stargate testnets will specifically focus on multi-chain IBC interoperation. Zones that wish to support IBC are highly encouraged to participate. Finally, the Stargate testnet sequence will test the non-disruptive in-place upgrade sequence using the Cosmos SDK upgrade module and ensure that it does not disrupt in-progress IBC operation in a multi-chain topology.

Once stable software releases are achieved, and all tested features & sequences operate smoothly, a final upgrade proposal can be prepared for the Cosmos Hub which will execute a halt-restart upgrade to atomically switch from the current software to the Stargate release at a set height, similarly to how previous Hub upgrades have been performed. Stakeholders should carefully evaluate any such proposal, test the software themselves, and make an informed judgment as to the readiness of the software before voting.

If the Cosmos Hub decides to pass the final Stargate upgrade proposal, clients, connections, and channels will be enabled on the Hub along with the upgrade, facilitating set-up and testing with other chains that have also integrated the IBC implementation. Initially, ICS-20 cross-chain fungible token transfers will be disabled, in a similar fashion to how transfers were initially disabled when the Cosmos Hub first launched. Once Hub stakeholders are confident that the protocol is secure and safe to use, a second parameter-change proposal will be able to activate cross-chain transfers, after which tokens will be able to be sent from the Hub to any IBC-compatible chain, and from any IBC-compatible chain to the Hub. Because of the ability of the IBC protocol to safely handle dynamic chain topologies, it is not necessary to specify ahead of time any particular list of chains — the process of setting up a connection and a channel for token transfers is permissionless and does not expose any users who choose not to use that connection or channel to the fault risk of the counterparty chain.

At this point, the possibilities for interoperability are dependent not on the Hub or on the Stargate upgrade process, but on the integration of IBC by other chains, which they can do at their own pace, electing to use the Cosmos software implementations or not as they prefer. IBC is experimental, alpha software, and should be integrated & tested carefully before deployment. All usage of IBC is at your own risk. We encourage chains to ensure that user-facing software such as wallets or browser extensions clearly describes the risks and security model to users when performing any cross-chain operations.

Ongoing IBC-related work

We have intentionally elected to keep the scope of the Stargate release, already a large coordination effort, no larger than absolutely necessary, but a lot of fantastic IBC work is proceeding in parallel on independent timelines. This is by no means an exhaustive list.

• Informal Systems is working on formal verification of the IBC protocol, including handshakes, packet send & receive logic, light client behavior, and the relayer algorithm, with the model checker TLA+
• Informal Systems is also working on a complete IBC core protocol implementation and a complete IBC relayer implementation, both in Rust
• Confio is working on an integration of IBC handler logic into their WebAssembly smart contract system, which runs on the Cosmos SDK and comes with JS client support
• Chainapsis is working on the specification and implementation of the interchain account protocol, which will allow an account on one blockchain to control an account on another blockchain using IBC
• Chorus One is working on a Tendermint light client and Substrate light client, both in Rust and designed for compilation to WebAssembly & usage with IBC
• Althea is working on Peggy, a bridge from the Ethereum network to a Cosmos SDK-based blockchain which in conjunction with IBC will bridge the Cosmos & Ethereum ecosystems
• Agoric is working on the integration of IBC into the Agoric platform for secure smart contracts written in Javascript
• ChainSafe is working on the integration of IBC into Ethermint, which will allow EVM applications to run on Tendermint chains and connect to the Cosmos network over IBC
• Cdot is working on an implementation of IBC in Substrate (Rust), a GRANDPA client, and maintaining Chinese translations of the ICS specifications
• Akash is helping with maintenance of and working on features for the Golang relayer
• Nomic is working on a Bitcoin two-way peg / sidechain & Tendermint light client in JS
• Too many teams to list are helping test the software in incentivised testnets and find bugs prior to launch

Future directions

The 1.0 release, in conjunction with expected additional software releases later this year, marks an inflection point in the trajectory of IBC development: going forward, the successful adoption of IBC as an open, permissionless standard will be determined by the choices of sovereign blockchains, operators, and users. The core protocol is just the beginning — interoperability between applications over IBC will also depend on application-level standards describing particular packets, data encoding, and processing logic (such as ICS 20 & ICS 27). Additional implementations of IBC in different languages & frameworks will reduce the barrier-to-entry to the ecosystem and allow a diversity of heterogeneous use-cases to proliferate. New light clients & state verification procedures will enable different consensus algorithms and state machines to speak IBC. Protocol stacks on top of IBC, such as cross-chain validation, will provide advanced functionality and new security models composed of the primitives provided by the core protocol. Post-1.0 protocol versions may incorporate alternative causal ordering guarantees, new channel types, and automatic multi-hop routing. Future work on IBC will necessarily be a collective effort, emergent from a process of rough consensus-building and resource contributions by a multitude of organizations and individuals. We can’t wait to see what you’ll build.

You can follow IBC progress on Github, Twitter, Discord, or here on Medium.