Announcing the IBC 1.0 implementation release candidate
Note: The Cosmos ecosystem is constantly growing and expanding. This article’s content is now outdated. For the latest content, see https://cosmos.network/.
Introduction
Since the last IBC update earlier this year, the IBC team at Interchain GmbH has been hard at work finalising the 1.0 specification-compliant implementation in the Cosmos SDK. Working in close collaboration with our friends and colleagues at Informal Systems, Agoric, Akash, Iqlusion, Chorus One, Tendermint, and more, we’ve managed to squeeze in a few last-minute features, pinpoint and fix several bugs, add extensive unit tests, and document the codebase comprehensively. About a month ago, we finished the 1.0 implementation milestone. Since then, we’ve been engaged in an intensive internal code audit conducted jointly with Informal Systems, and just a few days ago we finalised and merged the last of the audit fixes, meaning that IBC is now ready-to-go for the upcoming ecosystem-wide Stargate upgrade.
This blog post enumerates the most significant protocol and implementation changes in the past few months, describes the expected two-phase Stargate IBC rollout, and lastly outlines how you can get involved!
Feature additions and bug-fixes
The last-minute feature additions have been focused on satisfying requirements of early IBC applications and paving the way for future upgrades of both blockchains utilising IBC and the IBC protocol itself. A few highlights:
Asynchronous acknowledgements
Specification changes, SDK PR.
We’ve restructured the acknowledgement model of IBC to support asynchronous packet processing, such that the receipt of packets is immediately acknowledged but acknowledgements can be written some unspecified amount of time later after processing has occurred, not necessarily in the same transaction or even in the same block. This is particularly useful for asynchronous contract execution models such as utilised by the Agoric platform. The previous synchronous acknowledgement functionality can be recovered by simply acknowledging packets immediately as soon as they are received.
Height abstraction and upgrade support
Specification overview, specification changes, SDK PR.
We’ve attempted to craft procedures for maintaining IBC functionality with minimal disruption to applications when upgrading a ledger which utilises IBC to send & receive messages from other ledgers. Two broad kinds of upgrades are covered: upgrades to light clients for a particular chain (both “non-breaking”, e.g. a change in chain ID, and “breaking”, e.g. a change in Tendermint header structure), and upgrades to the IBC protocol itself. The former are handled using an “upgradeClient” function which allows the validator set to sign over a serialised representation of the new client state before executing the upgrade, and the latter are handled using version negotiation in the connection handshake, allowing chains implementing newer versions of the IBC protocol (e.g. supporting new channel types) to continue communicating with old versions.
Version negotiation fixes
Specification changes, SDK PR.
Informal Systems’ ongoing work modeling and verifying the IBC protocol caught a mistake in the version negotiation subprotocol utilised in the connection and channel handshakes whereby a malicious relayer could halt the handshake or cause chains to end up with incorrect (disagreeing) versions. Working closely with Informal’s research team, we’ve updated the version negotiation protocol in both handshakes to prevent this from occurring while retaining flexible version selection.
Governance-based client recovery
In order to avoid cases of accidentally locked tokens (ICS 20) or other isolated application state due to accidentally expired clients or accidental misbehaviour, we’ve implemented a mechanism by which IBC light clients can be created with an option which allows the governance system (e.g. of the Cosmos Hub) to put in place a new client state if the client is expired or frozen, after the usual proposal process and proposal period. Allowing such governance overrides is optional, chosen at the time of client creation.
Cross-chain transfer denomination tracking
In order to allow arbitrarily long chains of cross-chain token transfers without running up against denomination size limitations, we’ve implemented a denomination tracking scheme for ICS 20 (token transfers). Upon receiving an incoming transfer, the ICS 20 module calculates a constant-size denomination using a hash function, stores the reverse mapping to token path (port and channel identifier), and uses the newly calculated denomination for internal tracking within the bank module. The ICS 20 security model and user interactions are unaffected.
Per-connection packet delay period
Specification changes, SDK PR.
In order to allow time for evidence of misbehaviour to be submitted and appropriately handled before packets are processed (potentially resulting in state changes), in proper accordance with the Tendermint light client security model, we’ve implemented a per-connection delay period which enforces a specified delay between when headers are processed and when packets can be processed. This issue was discovered and the fix designed and implemented with assistance from Informal Systems’ research team.
Deterministic identifier selection
Specification changes part I, part II, SDK PR.
In order to prevent malicious relayer denial-of-service of particular identifiers, and in order to simplify the relayer user experience and remove ambiguity in protocol semantics, client, connection, and channel identifiers are now chosen deterministically during the client creation, connection handshake, and channel handshake processes respectively. This issue was discovered and the fix designed and implemented with assistance from Informal Systems’ research team.
Two-phase Stargate IBC rollout
From the perspective of the IG team, the IBC implementation is ready-to-go for Stargate. We’ve also been working in collaboration with Akash to update the Golang IBC relayer for the latest upstream SDK changes, which is close to finished, but further testing (especially from potential relayer operators) is most welcome. The Stargate proposal sequence itself is out of the scope of this blog post, several testnets are still in progress. Whoever creates the final proposal should note that several important parameters must be chosen — specifically, we recommend setting historical header info retention for the Cosmos Hub to at least a day, recv/send enabled for IBC to false, and permitted light clients to only Tendermint.
Once the Stargate upgrade has been completed on the Cosmos Hub, it will be possible for anyone to create IBC clients, connections, and channels, but not yet possible to transfer tokens to and from the Hub using IBC’s fungible token transfer protocol (ICS 20). A second parameter change proposal must be passed by Hub governance in order to activate cross-chain transfers, and it will be up to governance to decide when they are ready to do so. Once so activated, IBC transfers are completely permissionless.
Get involved
Coordination for multiple testnets is still in progress — watch the Stargate repository and join the Cosmos Discord to stay updated. As previously announced, the Stargate bug bounty is now active and previous bounty amounts have been doubled — so if you have a clever eye for bug hunting, time’s a wastin’.
Thanks for reading — see you on the other side of interchain communication!
