Cosmos Development Update — July 2019

by All in Bits (Tendermint Inc)

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

Gaia 1.0, Cosmos SDK 0.36, and IBC Spec 1.0

Hello Cosmonauts, the development team has been hard at work since the last network upgrade and there are some really exciting things coming down the pipe in the coming months. This post is an update on that work and the drive towards IBC. It also includes an outline of the major features in the Gaia 1.0 release that is currently in the RC (release candidate) phase. With the successful upgrade of the testnet on 22 July, the release is on track to be deployed on mainnet as cosmoshub-3. Let’s review some of the upcoming changes below:

LTS Guarantee

This release of the Cosmos SDK is the first where Tendermint Inc will be offering a Long Term Service (LTS) Guarantee. This means in practice that Tendermint Inc will guarantee for six months that we will backport security critical updates for the 0.36.x line. In addition, we pledge to not break the REST and CLI APIs on this release line. The SDK development team will also ship a guide for applications updating to the next LTS release from the 0.36.x line.

Dev Process Changes

The LTS Guarantee doesn’t come in a vacuum. There were a number of internal processes that matured over the last few months to enable that pledge:

• Gaia Repository — Gaia, the hub application has been split into its own repository. This is important because it decouples the release of Gaia from the release of the SDK and allows the two products to evolve independently. This will allow us to start shipping regular releases of the Cosmos SDK with bug fixes for chains relying on it. This change should also go a long way to relieve the confusion of new users. It also helps them differentiate between Gaia and the Cosmos SDK.
• Reproducible Builds — This guarantees that the Gaia suite can always be built from source, provide independently verifiable executables, and allow anyone to protect themselves from targeted attacks.
• Branching Strategy — Previously all of our projects had a separate `master` and `develop` branch. We have switched to a branching strategy using just the `master` branch and then separate long-lived branches for each release that will enable us to more easily support prior releases.

Governance Proposals

There have been 4 governance proposals that passed since the last hard fork. Those changes have been incorporated into Gaia for this network upgrade. A brief summary follows:

1. Community Fund Proposals — A community fund has been approved to enable governance to spend funds from the community pool. The full proposal can be found here.
2. Only Burn Governance Deposit On Vetoed Proposals — Previously, governance proposals that were submitted and rejected burned the deposits for those that submitted them. This proposal changes that so deposits for rejected proposals aren’t burned unless vetoed.
3. Security Hard Fork — This governance proposal is for the upgrade to the 0.34.6 release. That release was for a critical security issue that is covered in much more detail in this post by Jessy Irwin, our Head of Security.
4. Increase Max Validator Set Size — This proposal which recently passed will increase the number of validators from 100 to 125. This will reduce the amount of ATOM collateral required for a validator to be included in the voting set. At the time of writing this amounts to roughly ~$170,000 of collateral bonded to a validator for that validator to be in the voting set.

Major Features

There were a number of bug fixes, features, refactors and other changes shipped as a part of the 0.36.0 release for Gaia. You can read the full details in the CHANGELOG.md, but here is an overview of the major features that are shipping in this release:

Parameter Change Proposals

The Cosmos SDK now supports the ability to create and vote on governance proposals that modify on-chain parameters without having to halt or fork the network. Not only this, but the governance module has been refactored such that now any module can register and set up its own proposal process. Such a process has also been incorporated into the distribution module to allow the spending of community funds. We will be publishing a more thorough writeup of this feature in the near future.

Module Refactor

Since conception, the Cosmos SDK has been defined as a modular framework for building blockchain-based applications, but it has not always been as modular as it could have been. Because we were developing the SDK and Gaia in the same repository, sometimes, features were shipped at the expense of modularity. Over time, a tight web of cross-linked dependencies grew, making development with the SDK much more difficult.

This issue was one that we identified quickly after launch as a major pain point for developers and one that we could solve. Some initial work was done to decouple cross-linked dependencies between our internal modules. Once this was complete, a golang interface was created that explicitly defines what is needed when implementing a Cosmos SDK module. You can find this interface defined here.

Supply Module

The supply module allows a chain to passively keep track of the total supply of coins. The total supply is updated every time a coin is minted (eg: as part of the inflation mechanism) or burned (eg: due to slashing or if a governance proposal is vetoed).

It also introduces a new type of account, ModuleAccount, which can be used by modules as an escrow to allocate tokens and keep track of coins flowing in and out of a module. Module accounts can be granted a set of permissions to perform certain actions related to supply, such as mint or burn coins. The staking keeper shows good usage of this pattern in action.

Height Queries

Height queries, i.e. the ability to query the state of the network at an arbitrary block height, are now supported in the REST and CLI clients. Height queries can be invoked against any full node, however, if a full node has pruning enabled, a query may fail if the node has that height pruned. Thus, it is advisable to only invoke height queries against archive nodes (non-pruning full nodes).

Events Refactor

The SDK now supports a richer feature set with regard to events, which were formerly known as tags. Previously Tendermint ABCI only allowed tags to be returned from transactions and ABCI methods, such as BeginBlock and Endblock, in a very limited fashion. For example, duplicate keys were not supported. This created many challenges when needing to query for aggregate data points such as reward distributions and slashing events.

With the new events refactor come two main advantages. First, this brings a massive improvement to developer ergonomics. Application developers do not have to worry about returning events from their message, BeginBlocker, or EndBlock handlers. Instead, developers may simply emit events through the SDK, specifically the EventManager. This allows for a cleaner interface abstraction and improved workflow. Second, the SDK now uses this new EventManager to emit aggregate events such as slashings and reward distributions. This allows clients and other upstream applications to query for and subscribe to more aggregate data points. Here is an example of usage of the EventManager in the distribution module.

Each module emits its own set of unique events. The exact events emitted can be found in each module’s respective spec directory, e.g. the distribution events.

Paying Down Technical Debt

If you take a peek at the CHANGELOG, there are a lot more items that have been discussed above. There are features like adding configurable timeouts for the REST server and refactors like that of the CLIContext and the Bank Module. This work went back and fixed known issues and will enable faster and less error-prone development moving forward.

Potential Upgrade Timeline

Since our first upgrade from cosmoshub-1 to cosmoshub-2, as a community, we have had a number of discussions about hub upgrade procedure, but have not come to a consensus around exactly how upgrades to the hub get approved. This draft proposal from the Figment Networks folks contains a written explanation of roughly the method we used last time. Using that as a guide, below is a potential timeline for upgrading the Cosmos Hub to the Gaia 1.0 software. Please note that this is contingent upon the community voting and agreeing to deploy these changes.

• Testnet Upgrade: Completed successfully on 23 July
• 1st governance vote posted: 25 July
• 2 weeks of testnet stability: 7 August
• 1st governance vote passes: 9 August
• 2nd governance vote posted: 9 August
• Network upgrade at time/height to be set by 2nd governance vote

Upcoming Features

• IBC Support — The ICS process has been in full swing for a couple of months and has just delivered the 1.0 version of the specifications and a working implementation is under active development. There are some changes to both Tendermint and the SDK, especially around the lite client implementation that will be required for support. The release will add the ability for other chains to connect via IBC to the hub.
• No Downtime State Machine Upgrades for Gaia — Aaron from the Regen Networks team has been working on an implementation of on-chain upgrades. We will be working with them to incorporate those changes into the Cosmos SDK and the hub. The reproducible builds and module refactor work are key to enabling an approach to this feature.
• Subkeys — This feature will allow the creation of “subkeys” that have a subset of permissions for a given chain. Sunny Aggarwal kicked off the conversation with an initial specification. This work was picked up by B-Harvest and Aaron Craelius from the Regen team who have been working on a complete spec and implementation.
• Amino Protobuf Compatibility — Work to make amino (our encoding format) fully protobuf compatible is wrapping up. Once that is complete we will provide canonical .proto files for each type encoded in the SDK and Tendermint. This will allow for much easier interactions from a client perspective when working with lite client proofs and transactions.
• Income Reporting — With the upgraded events system and the addition of height queries the creation of detailed income reports for validators based on on-chain data is now trivial. We will include a version of this for validators in our standard tooling in an effort to ease reporting.
• New Modules — Work is currently being done on a number of modules. The most exciting example is the WASM module that was started during HackAtom Berlin and is being completed by that team, courtesy of an ICF grant for this work. Also in the works are a uniswap style exchange module, an NFT module, and an EVM module, both of which are under active development.
• You can track the development of these and other features in the next SDK Milestone — v0.37.0.

Thank you to the Cosmos SDK development team and all of the outside contributors who push code to make this release possible.

If you are building on the Cosmos SDK or interested in learning more about it, join our Cosmos SDK community call here that takes place bi-weekly.

The views and details expressed in this blog post are those of All In Bits Inc (dba Tendermint Inc), and do not necessarily represent the opinions or actions of the Interchain Foundation.