How Seven Teams Collaborated To Deliver The Biggest Software Upgrade In The Cosmos Universe

Note: The Cosmos ecosystem is constantly growing and expanding. This article’s content is now outdated. For the latest content, see https://cosmos.network/.

Summary

Complex software development coordinated by remote teams is a challenge to avoid the dreaded delays. In the crypto ecosystems, failures to ship can negatively impact community perception as well as token value. The successful release of the Cosmos Stargate software upgrade is a testament to a hard-won victory over this challenge. More than seven teams contributed to ship the Cosmos Stargate release. We asked the leading teams involved to contribute their insights into their journey to ship the Cosmos Stargate release. These teams included the Cosmos SDK team, the IBC and Tendermint Core teams at Interchain GmbH, Tendermint Inc Team, the Relayer team, the Informal Systems team, as well as Iqlusion.

Below is an in-depth case study of success in teamwork and coordination unique to the Cosmos community. We are excited to share with the community our experience on this journey of what we did, what we learned and what is next as we launch the final version of the Cosmos Stargate.

Iqlusion Team

What we did

In July of 2020, we at Iqlusion engaged the ICF team to organize and deliver a Cosmos Stargate proposal to the Hub that would ask the community to signal their desire to bring the Cosmos Stargate to the Hub. We were aware that the Stargate version would impact integrations from ecosystem partners. These partners would be exposed to certain risk of breaking changes due to the Stargate changes.

Initial Partner integrations

In July, the Iqlusion team initialized slack channels with leading Cosmos integration partners that included exchanges and wallets. Initial partners included leading cryptocurrency exchanges, Cosmos wallets as well as the top Cosmos validators. In addition to outlining the breaking changes, we asked each partner to share with us their requirements for successful integration testing of Cosmos Stargate.

Response to initial requests for help

Feedback from partners mainly focused on their desire to understand the breaking changes from Amino to Protobuf, as well as the implications of IBC for exchanges. Iqlusion wanted to provide as much support for key partners and the community around the Amino endpoint changes and produced an Amino audit document AminoREST and You which consisted of endpoint behavior testing and updates from the Tendermint team and wallet partners. The Iqlusion team supported exchanges with an IBC Readiness Matrix document that would help exchanges understand the impact of IBC features in Cosmos Stargate and empower their decision making process.

The iqlusion team is in active conversation with virtually all the major exchanges, custodians and wallets in the cosmos ecosystem.

The Cosmos Stargate Gaia release

Iqlusion tracked the releases of Cosmos stargate upgrades to deliver the first gaia version of Cosmos Stargate. So far there are three versions of the initial Cosmos Stargate Gaia binaries. Iqlusion provided instructions for the community to download and access the testnet versions here: https://github.com/cosmosdevs/stargate. Now that the final release candidates for Tendermint, SDK, and IBC are available, Iqlusion will build and release the Cosmos Stargate RC testnet.

What we learned

The top three lessons for Iqlusion center around the great quality of code delivered to minimize the impact of breaking changes on exchange and wallet partner infrastructure.

• Lesson 1: Amino RPC endpoints. The team implemented a side-by-side view of each RPC JSON output. Comparisons of each of the outputs highlighted the excellent preservation of legacy endpoints by the Cosmos SDK team. Only one endpoint, QueryTxByHash, endpoint showed a high risk of query results breakage.
  Iqlusion learned through its infrastructure partners that they had the expertise to stress test their Stargate queries. Their feedback and the positive response to Stargate tests showed that they were ready to handle legacy Amino as well as prepare for the new protobuf endpoints. See our Amino audit document AminoREST and You and make sure that you have coverage for your Amino queries in the coming Cosmos Stargate as well.
• Lesson 2: IBC functionality is especially important for Cosmos infrastructure partners such as cryptocurrency exchanges. Exchanges expect IBC to unleash exciting new capabilities, but are not clear how demand will emerge as IBC features become more widespread. In order for exchanges to feel confident about these features, Iqlusion developed an IBC Readiness Matrix and flow of funds diagram to demonstrate how IBC would understand the flow of a hypothetical transmission of tokens from one Cosmos chain to another, while using an exchange-wallet.
  We expect that exchanges will start with limited features, but increase their IBC Skill levels as they get comfortable with Cosmos Stargate and as their users demand their wallets interact with IBC assets.
• Lesson 3: There are many more features in Cosmos Stargate that are of interest to infrastructure partners, including the automated migration and fast state sync. This means that these features will be in high demand on the Cosmos hub and will benefit the Hub as the leading blockchain for all Cosmos chains.

What is next

Iqlusion will announce the Cosmos Stargate Release testnet on its github for partners to give a final round of integration testing activity. Iqlusion will also work with the various Tendermint teams to scope and launch a Cosmos Stargate bug bounty program. The goal will be to begin stress testing the component and Gaia releases with incentives to highlight bugs and issues in the release candidates.

Iqlusion plans to also showcase a live demo of Cosmos Stargate testnet auto-migration feature for non-chain halt upgrades. Once this is complete, Iqlusion will prepare its Halloween October 31, 2020, proposal for upgrading the Cosmos Hub to Cosmos Stargate.

Tendermint Core Team (Interchain GmbH)

What we did

Tendermint Core 0.34, the version of Tendermint Core which supports the Stargate upgrade, contains a number of new features that have been in the works for months, if not years. These include a new light client, which will provide more safety to IBC; updated evidence handling, to hold nodes accountable for attempts to fool this light client; a migration to protocol buffers for serialization; and the state sync feature, which allows new nodes to join pre-existing networks in a matter of minutes instead of days. Collectively, these features mean that we expect Tendermint Core 0.34 to be the safest, fastest, and most usable version of Tendermint to date.

New Light Client

Tendermint Core 0.34 introduces a new implementation of the light client. This new light client introduces a number of changes, but most critically, it has weak subjectivity, meaning that it only trusts block headers from within the unbonding period. This is an important stipulation for light clients operating in proof-of-stake networks, and is key to the security of IBC.

For more, including details on how to operate the light client, see our post on the new light client: Everything you need to know about the Tendermint Light Client.

Updated Evidence Handling

The introduction of a new light client also expands the potential surface area for attackers. Light clients need to be able to identify suspicious behavior, package up the evidence from that suspicious behavior, and submit it back to full nodes so that they can verify it and then hold any misbehaving nodes accountable. For more on the new evidence handling lifecycle and types, see ADR 59. For more on specific attacks on the light client, see ADR 56.

Protocol Buffer Migration

Along with the other projects in the Cosmos stack, Tendermint Core 0.34 adopts Protocol Buffers for serialization, replacing a custom and under-supported encoding format. We expect this change will bring an orders-of-magnitude improvement in performance to Tendermint and its downstream dependencies, in addition to big improvements in maintainability, readability and stability. For more on this migration, see our blog post: Tendermint 0.34, Protocol Buffers, and You.

State Sync

Tendermint Core 0.34 introduces the new state sync feature. This allows new full nodes to join pre-existing networks without replaying consensus block-by-block. Instead, they can sync application state directly from other full nodes. For the Cosmos Hub, and other long-lived networks, this can reduce the time for a new node to come online from days to minutes. State sync is a major usability improvement, and has been requested for years. We are delighted to finally ship it in Tendermint 0.34!

Additional Features and Improvements

Along with many of the major features mentioned above, Tendermint Core 0.34 includes a number of smaller features and bug fixes. These include fixing the hashing of empty data sets, allowing the application to return the app hash from InitChain, fixing a bug in the validator proposer schedule, and allowing chains to start at an arbitrary initial height.

What we learned

• Lesson 1: Invest in coordination with the research team.
  The evidence handling work was a collaboration between the research team, at Informal Systems, and the Tendermint Core team, at Interchain GmbH. The team at Informal often takes the lead on designing and specifying protocol-heavy work, such as evidence handling, while the Interchain GmbH team is responsible for implementing and polishing this work. But there was an early miscommunication when the Interchain GmbH team started working on the evidence handling work: The Interchain team believed that the evidence handling specifications had been ratified when they had not; and implementation began prematurely. Consequently, there were several rewrites of both the specification and the implementation, and this delayed the release of Tendermint Core 0.34.
  In order to ensure that there’s smoother collaboration in the future, we’re investing in our coordination with the research team, beginning with a unified specification repo which will act as a single source of truth for all Tendermint specifications. We’re also working on shared roadmaps that can highlight protocol dependencies for upcoming Tendermint Core features.
• Lesson 2: It’s time for some serious end-to-end tests.
  One of the early release candidates for Tendermint Core 0.34 contained a bug that was caught by our friends at Oasis Labs. Oasis has been a fantastic integration partner for many reasons, but in part because they run their own extensive end-to-end tests. Although Tendermint Core has had solid unit test coverage, and has been thoroughly tested through both incentivized and more casual testnets, it had lacked a true end-to-end testing framework that could put the software through its paces in a variety of configurations and environments. The bug found in the release candidate was one of our motivations for building our own end-to-end testing system. You can read more about the plan for this work — which is now nearly completed — in our end-to-end testing RFC.

What is next

We are currently planning the next two substantial Tendermint Core releases, which will focus on performance, correctness, and, above all else, stability. Over these two releases, we will stabilize the block protocol, as well as all exposed APIs, including Go APIs, in preparation for Tendermint Core 1.0. We envision Tendermint Core 1.0 as a piece of stable and trusted infrastructure.

Stay tuned for a more detailed roadmap soon!

Regen & the Cosmos SDK Team

What we did

Regen Network took over the role of lead maintainer in March/April of 2020. Our plan was to work slowly to upgrade the Cosmos SDK to become a lean and powerful base to connect to the ecosystem of custom modules that is evolving. There were several key barriers to the SDK performing in the way chain builders like Regen needed. On a practical level, this has meant a large refactoring of the Cosmos SDK’s encoding & serialization format from Amino to Protocol Buffers. This vastly improved the performance and developer experience of the SDK.

What is Protobuf Encoding? “Protocol buffers is a language-neutral, platform-neutral, extensible mechanism for serializing structured data — think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages.” — From the google protobuf page

On the other hand, despite the legacy CosmosSDK encoding system, amino, becoming a major barrier for developer and user adoption, amino based encoding is used by 100% of the Cosmos Hub community of users. These users include major exchanges, wallets, and forcing them all to jump into a massive breaking change didn’t seem wise. We also wanted to preserve legacy access to amino encoding for users who prefer using that format for other reasons. Therefore our team worked extremely hard to make it possible to choose the encoding format. This means that the legacy amino format is supported, as well as the new protobuf format. Ensuring that in the journey to Stargate and IBC, if users chose to stick with amino in the short term to cut down on developer time and risk, they can. Other users who want to play with the more highly performant protobuf encoding format can choose that.

What we learned

One of our biggest learnings over the course of working on the Stargate upgrade was that things are a lot harder when trying to maintain backwards compatibility. There are many places in which it would have been technically easier and quicker for us to rip Amino out entirely, and only build in a working Protobuf based Cosmos SDK, but because we wanted to preserve the legacy Amino transaction path (to make it easier for client migrations), we had to spend a significant amount of time on abstracting over the serialization format, and hand tuning in several areas the different implementations in both Amino and Protocol Buffers.

A second key learning is that when doing a big refactor, it’s incredibly hard to know all of the scope up front. There were a lot of unknowns with the protobuf migration, and several instances where a seemingly small & straightforward task ballooned in scope and pushed the release date back weeks. Be conservative with estimations, doing accurate estimations on big refactors is HARD!

Lastly, it’s better to bite the bullet and do things the right way the first time when faced with the choice between tackling a problem now or later. We bit the bullet when we ported many of the SDK modules’ integration tests to the SDK, which previously only lived in the Gaia repo. After copying most of the integration tests, we later decided to refactor the way integration tests were done, into an in-process test network testing framework. This led to a lot of duplicated work — porting all of the integration tests a second time to the new framework, and would have been much cleaner if we started with building the new testing framework, and then ported over all the tests just once.

What is next:

Vision:

Our vision of 1.0 is that the cosmos sdk offers a stable platform for a thriving and interoperable module ecosystem. It will offer a level of stability for long lived decentralized apps to operate. We want to make using blockchain applications accessible to a much broader group of users through better key and fee management.

Achieving a 1.0 of the Cosmos SDK has been a sometime contentious and always elusive concept. However it seems like there is an emerging consensus about a lean, modular and secure core SDK and an ecosystem of application specific modules that is the manifestation of the original vision of the SDK coming into sight. Check out this conversation between Alessio Treglia, Ethan Frey and Aaron Craelius about how we can achieve a stable 1.0 version of the Cosmos SDK.

The Regen team, in partnership with ICF and Tendermint alongside other fantastic ecosystem teams, is implementing a well organized protocol for contributions and decision making about additions to the Cosmos SDK, as well as publishing a high level 2021 roadmap that is public and can be commented on.

The SDK team has biweekly architecture review calls, and a monthly Cosmos SDK User community call.

Akash & The Relayer Team

What we did

Akash Network took over the maintenance of the Golang IBC Relayer starting in July 2020. Prior to that Jack Zampolin, working with Iqlusion, wrote the initial implementation that showcased how to use IBC. That relayer was featured in The Game of Zones competition, starting in March, which showed the community how close this signature piece of infrastructure is to being ready for use.

After moving to Akash, Jack continued to work on the relayer and closed a contract with the ICF in August to ensure that this crucial piece of IBC infrastructure is in working order for the launch of the protocol. Since then, the Akash team has been working closely with both Interchain Berlin and the ICF team to ensure the readiness of the relayer for stargate.

What we learned

Our biggest learning from developing the relayer has been what an amazing, supportive and productive community Cosmos is: the Agoric team, instrumental in helping turn IBC from an idea into a reality, the AiB team tirelessly improving the developer experience, the Interchain Berlin team doing the heavy lifting of specifying and implementing the protocol as well as the new features in tendermint, the Iqlusion team providing project management, crucial code contributions and most importantly leadership, the ICF bringing funding and vision, the Informal team with critical work on the light client and the rust relayer, the Regen team leading the SDK and introducing protobuf, and all the individual contributors combining to make IBC a reality. This small group, already a mouthful to acknowledge, is quickly growing so large that if this article was written in a month or so would include another 20–30 teams.

What is next

There are a number of exciting features coming to a relayer near you soon!

• Misbehavior monitoring and automatic submission
• Relayer metrics such as wallet balances, amount of fees paid, packets relayed, etc… exported via a Prometheus server for quick and easy metrics.
• REST server that exposes the functionality from the CLI to make automated relayer configuration and operation easy for exchanges and other high volume use cases
• Further development of the event driven relayer functionality including event driven connection/channel creation. We have submitted an ADR to the SDK to support this work
• Features to support applications relying on IBC in production: if you are running an IBC enabled chain, and you require features from the relayer, please reach out!

Informal Systems Team

What we did

Formal Specification, Protocol Review, and Model Based Testing

The Informal Systems team has been leading the formal specification effort for critical elements of the Cosmos technology stack, using TLA+ to formally specify protocols and their properties, and using our in-house model checker, Apalache, to verify those properties. We completed extensive specifications for the Tendermint Light Client in English and TLA+, which guided the implementation effort for both the Go and Rust teams. We’ve also been carefully reviewing the existing English IBC specification and have nearly completed TLA+ specs for the entire IBC protocol. These may be some of the largest public TLA+ specs, ever! Our protocol review and specification efforts have surfaced numerous bugs throughout the process in both the light-client and IBC, which have since been fixed, and we continue to be active in the security of Tendermint and IBC through code reviews and joint management of the Bug Bounty program.

We are also now using Apalache to automatically generate complex tests for both Go and Rust implementations of the Tendermint light client and IBC directly from the TLA+ specs — so-called “Model Based Testing”. This has the potential to greatly improve test coverage, reduce test maintenance efforts, and ensure the specifications and software remain aligned.

tenermint-rs

Tendermint-rs is a Rust implementation of core Tendermint data structures, used primarily in the Tendermint Key Management System, but also by public Tendermint-based networks like Crypto.com. We have upgraded the library in the upcoming v0.17 release to be compatible with Stargate and v0.34 of Tendermint Core, essentially gutting all traces of Amino in favour of Protocol Buffers, and refactoring the code to improve developer ergonomics by separating the protobuf serialization types from the in-memory “domain types”. We have also implemented a complete light-client in Rust, which can be compiled to WebAssembly, and a new WebSocket client for communicating with Tendermint full nodes.

ibc-rs

Ibc-rs is a Rust implementation of the IBC protocol and relayer. While development began pre Stargate, the latest v0.0.4 release has been upgraded for Stargate compatibility. The codebase is still in an early stage, but the IBC client and connection handlers have been implemented and the first traces of a relayer and protobuf-compatible transaction signing are beginning to appear!

What we learned

Formal Verification must be in service of Software Development

We originally began with the premise of “Verification Driven Development”, an approach to software development that would be motivated fundamentally by the concerns of formal verification. However, as we progressed, we found ourselves wanting a more Development Driven Verification. In the end, building and verifying software, especially in a multi-entity context, is a delicate dance requiring continuous feedback between protocol researchers and software engineers. At the end of the day, the most important thing is working software, and if verification isn’t in service of that, then what’s it really good for? While formally specifying the protocols has helped us think more clearly about them and surface a number of important bugs, the most valuable artifact is likely to be the model-based testing — complex test cases generated directly from the TLA+ specifications that can be run against any implementation.

Serialization is the Ultimate Implementation Detail

At one point, one of our research engineers asked, “what’s a protobuf and why do we spend so much time talking about them?” This was a stark demonstration of the gaps that can arise between the concerns of software and research engineering. To the latter, serialization is just an implementation detail. But in some sense, it is the Ultimate Implementation Detail, as it defines compatibility with other implementations and provides the physical instantiation of the protocol outside the computer’s memory. The choice of Amino early in the life of Cosmos has made multiple implementations exceedingly difficult, and it’s been a monumental effort by many teams to overhaul Amino and replace it with the standardized protocol buffers. We’re sure the effort will pay off in spades. We’ve also learned how important it is to separate serialization code from the rest of your logic — pushing it as far to the edges of your software as possible. This frees developers from having to worry too much about serialization, makes it easier to provide backwards compatibility, and simplifies the work of upgrading the serialization in the future. Check out how tendermint-rs implemented its domain types, separate from its protobuf types, as an example of this.

What is next

Complete Model Based Testing

We’ve seen great initial results generating tests for the Rust light client, which are now also being applied to the Go light client. There’s lots more work to do in defining how the tests should be generated and what kind of cases should be explored, and in augmenting the model-based tests with additional forms of fuzzing. We’re also looking forward to generating tests for all aspects of IBC and using them to ensure compatibility between the Go and Rust implementations, and future implementations in other languages.

Full IBC Handlers and Relayer in Rust

Now that we’re over the Amino hump and the Cosmos-SDK has stabilized, we’re working towards a complete IBC relayer in Rust. The Rust relayer will complement the excellent work done for the Go relayer. A major focus of the Rust relayer is capturing edge cases and failure modes, especially caused by relayer races and malicious relayers. It will also provide some client diversity to the growing Cosmos ecosystem, enabling more integration points in Rust, and will target compilation into WebAssembly. We’re also working towards complete implementations of the IBC handlers in Rust, allowing other blockchain applications written in Rust to easily integrate into the Cosmos Network via IBC.

Tendermint Full Node in Rust

We are planning for tendermint-rs to evolve into a full fledged Tendermint full node implementation in Rust. We’re working closely with the Tendermint Core team on our plans to ensure our roadmaps stay aligned and our mutual efforts feedback constructively to one another. We plan to start with a simple P2P seed node in Rust that will help with peer discovery on Stargate networks, and look forward to working with the Tendermint Core team on much anticipated upgrades to the entire Tendermint P2P subsystem.

Protocol Security Review

We are continuing to carefully review key Cosmos protocols with an eye towards formally specifying them and improving test coverage of the implementations. As the ecosystem continues to grow, more and more protocols will be coming online, from bridges to other blockchains, to automated market makers, staking derivatives, interchain staking, extensions to IBC, and more. Informal plans to participate in protocol and implementation review for these critical components to help maintain the high quality standard for software that Cosmos is so well known for.

Tendermint Inc

Tendermint Inc and friends!

What we did

Enhanced Developer Experience

We at Tendermint Inc have put ourselves in the shoes of Cosmos SDK client application developers and focused on improving their development experience.

First has been acknowledging that the pace of the Go API evolution has been relentless and has left developers playing constant catch-up. To address this, and in collaboration with Confio and Regen Networks, we launched the Cosmos-SDK v0.39 “Launchpad” release series. This has two aims: to provide a stable platform for use by Cosmos-SDK application developers and provide a smooth migration path to Stargate.

Second, we believe that developing and deploying blockchain applications should be as easy as writing traditional web applications. Our new product — Starport — is designed to do — and is doing — exactly that. The feedback from the community has been overwhelming.

Adoption

We’ve decisively thrown our weight behind the Cosmos Community at large. We supported developers in migrating their code to Cosmos SDK v0.39 Launchpad by submitting patches and opening pull requests for their code base, provided them with unprecedented high quality technical support (on a case-by-case basis).

Core Development

We have

• Delivered a more secure implementation of the keyring that applications use to store users’ keys.
• Integrated the Cosmos Upgrade Manager into the Cosmos SDK.
• Implemented Coinbase’s Rosetta API specifications into Cosmos SDK.
• Optimised the Cosmos SDK build system’s internals, written tests (tons of tests!).
• Contributed to the design of the new testing tools for integration testing.

Awareness and Community

To support the Stargate initiative and raise awareness around the new features coming to Cosmos, Tendermint has built a website https://stargate.cosmos.network/ The beautifully designed website provides an overview of the changes being introduced with Stargate, includes a detailed view of the running testnets and features a progress tracker. Since launch in mid July the website has generated over 13,000 unique impressions. Average time on page: 5 min.

In addition to providing design assets that have been supporting the awareness around the Stargate event, the Tendermint Inc team has also been at the forefront of providing updates to the community through the use of various initiatives like the Engineering updates or Today in Cosmos reviews. By managing and populating the social channels with constant updates on the state of the Cosmos Ecosystem development, we were able to communicate effectively with our larger community and keep them up to date with the teams’ progress.

What we learned

The value of the team, community and persistence.

The Stargate’s development cycle has proven to be challenging for our organization, yet the team stayed focused on the Cosmos Hub and its community, ultimately turning stumbling blocks into stepping stones to new opportunities. Stargate has been an introspective journey that led us to re-discover our passion.

We learned the importance of actively listening to the Community. We have debated, argued, come to agreements, and most importantly built upon their feedback. We believe that Starport is possibly the most prominent example of how to turn feedback into action.

Lastly, we learned that collaboration is at the heart of successful ambitious technologies like IBC. Partnering with so many teams across the globe to launch Stargate has been a unique experience that we enjoyed fully.

What is next

Firstly, we intend to continue putting our over-15 year-long experience and expertise in systems development on the line in the development of the Cosmos SDK.

In collaboration with B-Harvest, we’ve started to work on an Automated Market Making (AMM) module within the Cosmos SDK, and thereby bring the concept of Decentralized Exchanges to the Cosmos network.

We’ve initiated a new project sponsored by Interchain Foundation called Cosmos Cash. This is focused on the tools required to deliver decentralised, digital and universal payments systems based on a network of authorised issuers. The intention? A secure, efficient and universal method for accessing services and purchasing goods in frictionless and borderless fashion.

Last but not least, we’re getting bigger and stronger. In the last three months, the Engineering and DevX team have doubled and trebled in size respectively, ready for the next development cycle of the Cosmos technology core stack, products, and partners’ technologies.

IBC Team (Interchain GmbH)

What we did

The Inter Blockchain Communication protocol (IBC) has been the core value proposition for Cosmos since first introduced on the whitepaper. The Cosmos SDK’s Stargate release finally delivers the promise of an ecosystem of interconnected blockchains with the first version of IBC.

IBC Specification

Interchain GmbH has led the creation of a canonical specification for the IBC protocol during the past year. This specification outlines the data-structures and interfaces required by a chain that supports IBC (core protocol and applications on top of it). The specification has been developed by a number of stakeholders (Interchain GmbH, Tendermint Inc, Agoric, Informal Systems and others) and consolidated in a set of Interchain Standards (ICS).

IBC Golang Implementation

The first implementation of the protocol has been developed in Golang, as a Cosmos SDK module. The implementation consisted in several features:

• Core IBC: Implementation of the IBC specification for transport, ordering and authentication of packets (TAO). Supports light client state interfaces, connection and channel handshakes, packet handling and hostname validation.
• Light client states: Each implementation includes client creation, client update, upgrade handling, proof verification and misbehaviour handling. The supported clients for IBC v1 on the stargate release are: solo machine client, Tendermint Core client and localhost client.
• IBC applications: The IBC module supports fungible token transfers between connected chains.
• Testing package: A developer friendly testing package that eases unit and end to end testing of IBC core data structures, user flows and IBC applications.
• Client services: Support for CLI and gRPC services for interacting with the core protocol and application layers.
• Protobuf compatibility: IBC v1 will only support protobuf as the encoding format (i.e no support for legacy amino).
• Capability module: The IBC team also developed an object capability module that supports IBC port binding. It was built as a standalone module that supports other SDK modules and applications.

What we learned

• Lesson 1: Developer UX.

After Game of Zones concluded, we focused on redesigning the clients and UX around the relayer. This resulted in the creation of new queries, and the implementation of the IBC app module interface and callbacks. These additions allowed us to provide an easy way for developers to create custom applications on top of IBC.

• Lesson 2: Handling chain upgrades and client recovery.

A chain upgrade must account for special edge cases for both planned and unscheduled upgrades (e.g., when a chain halts due to a bug that needs to be patched) that can contain breaking changes or not. Some of these edge cases that are included in the implementation were: preventing upgrades to expired clients, integration with the upgrade module to check what the latest scheduled upgrade plan is, and modifying the light client states to include both the version number (epoch) and the block height. Additionally, we added the option to update frozen or expired clients via governance proposal. This allows for previously locked funds to be unlocked again with a valid block header. For more on client recovery mechanisms, see ADR26.

• Lesson 3: Modularity for future light clients.

The core IBC client implementation had to be refactored after we started the implementation of the solomachine client, as we realized that our implementation wasn’t modular enough to support new light client states. The IBC implementation on the Stargate release has been refactored to support additional BFT chains light clients such as Polkadot’s GRANDPA client.

What is next

The IBC team is planning the next set of features for the IBC implementation, both on a core protocol level and as IBC applications. The most notable core features include cross-chain validation for shared security, multi-hop packet routing (i.e channels with more than one connection), NFT over IBC, etc. We expect additional feature requests to be included as the community interacts with the protocol.

Interchain Foundation Team

What we did

We paid for it.

What we learned

The bazaar is stronger than the cathedral.

What is next

Cosmos SDK v1.0, more governance capabilities, improved UX on key and account management, fee delegations, IBC on other networks, multi-chain wallets, burner chains…. The Internet of Blockchains