It’s time for the usual update from the Informal Systems’ Cosmos Hub team. Here are some of the highlights:
Coordinated the Cosmos Hub emergency upgrade to Gaia v14.2.0.
Coordinated the Cosmos Hub v15 upgrade.
Continue working on the integration phase for Gaia v16.
Completed the work on adding Model-Based Testing to ICS.
Completed the implementation of ICS Epochs.
Completed the first draft of the ICS 2.0 implementation.
Completed the spike phase of Megablocks.
Note that we use CHIPs to track the progress of our work. Hence, throughout this update, we make several references to different phases of the CHIPs framework.
At the beginning of March, the Cosmos Hub underwent an emergency upgrade to Gaia v14.2.0. This emergency upgrade was necessary to fix a vulnerability in the Packet Forward Middleware module. For details, check out the advisory. Thanks to the Strangelove team for fixing the issue, Amulet for bringing it to our attention, and the validator community for a smooth upgrade.
During March, the Cosmos Hub upgraded to Gaia v15.1.0. This upgrade is a significant milestone for the Hub as it upgraded to Cosmos SDK v0.47. This upgrade moved the Hub away from SDK v0.45 (marked as end-of-life) and enables a series of new integrations, such as the Skip Block SDK (requested by the community in prop 842).
As expected, the upgrade took longer than usual (around 2h) due to the vast amount of state migrations necessary to upgrade from Cosmos SDK v0.45 to v0.47. As the Hub stores a non-trivial amount of data regarding delegations and the number of accounts, any large database migration will take time. Note that software upgrades that use the same version of Cosmos SDK are usually much faster because there are no large database migrations to execute.
In addition to the state migration, there was confusion regarding the Gaia version required for the update. Due to the v14.2.0 emergency upgrade that happened while the v15 software upgrade proposal was online, it was necessary to use a different Gaia release (v15.1.0) instead of the one mentioned in the proposal (v15.0.0). Thanks to the validator community for the upgrade; we appreciate the feedback.
After the upgrade to SDK v0.47, the metadata length for gov proposals was set to the default of 255, which affects the description field. As a workaround, proposals need to use IPFS links in the description (see the ICS 2.0 signaling proposal as an example). To fix this issue (and restore the previous behavior), we cut a new release for Gaia v15 (see the release candidate here) and scheduled a coordinated upgrade on April 10th.
Throughout the month, we worked on the next major release of Gaia — v16 — which will integrate several features made possible by the upgrade to SDK v0.47.
First, we finished integrating the ICA controller and adding e2e tests. This first iteration of the ICA controller on the Hub will enable Hub users to perform actions on other chains using their Hub accounts. This is done by creating interchain accounts on other chains (with the ICA host enabled) and using the ICA controller module to send messages directly from the Hub. In a future release, we plan to enable additional use cases, for example, allowing the NTRNs in the community pool to participate in Neutron’s governance.
Second, we finished integrating the Stride Labs’ implementation of the IBC Rate Limit module and adding e2e tests. This module will add an extra layer of protection to IBC transfer channels in case of an exploited vulnerability. We also devised initial rate limits for the Cosmos Hub, started a discussion on the forum, and submitted a signaling proposal. The proposal passed, and so we’ll work next on adding these initial rate limits to the v16 upgrade handler.
Finally, while working to integrate the Skip Block SDK and include the EIP-1559 fee market lane (cf. prop 842), we realized that some changes are needed to the fee market module. First, we need to align the implementation of the minimum base fee with Cosmos SDK to avoid a considerable increase in the transaction fees. Second, given that EIP-1559 will change the current behavior — base fees will be collected in a separate pool instead of being distributed to the validators and their delegators — we need to add gov-gated mechanism to either burn or move to the community pool the collected base fees. Depending on the time it takes to make and test these changes, we might push the Skip Block SDK and the fee market module to a future Gaia release.
The work on v16 can be tracked in this EPIC.
We cut an alpha release for ICS v5 in March that uses Cosmos SDK v0.50. First, upgrading ICS to SDK v0.50 is a prerequisite of upgrading Gaia to SDK v0.50. Second, this enables consumer chains to start integrating the ICS consumer module, which increases the adoption of SDK v0.50.
At the end of last year, we enabled the first iteration of Model-Based Testing (MBT) on Interchain Security using Quint. This work aims to increase the confidence in our implementation and, consequently, development velocity — the more confidence we have in our releases, the faster we can ship new ICS features. Throughout this last quarter, we expanded the Quint model of ICS by adding existing features that were missing, such as key assignment and consumer-initiated slashing, and new features, such as epochs and partial set security. We are happy to say that we completed this work, and MBT is part of our CI. Next, we want to summarize and apply what we have learned to improve confidence in our releases.
We completed the implementation of ICS epochs and released it as part of ICS v4.1.0 (see the release candidate here). The main benefit of epochs is reducing the cost of relaying for ICS. In addition, epochs introduce a new functionality — power shaping — that allows the manipulation of validator sets and consequently increases the velocity of ICS development. It already proved to facilitate the implementation of partial set security and it also simplified the key assignment logic. We plan to add ICS v4.1.0 (with epochs) to Gaia v16, so it will be part of the next major Cosmos Hub upgrade.
We completed the first draft of the ICS 2.0 implementation that contains the main features described in ADR 015:
Enable consumer chains to join as either
Top N
(the top N% of the voting power on the Hub must validate the consumer) or
Opt-In
(validation on the consumer is completely optional).
Enable validators to opt-in and out of validating any given consumer chain.
Send partial validator sets to the consumer chains.
Distribute consumer rewards only to opted-in validators.
The code is already running on a devnet that we are running together with Hypha. The devnet is an excellent opportunity to improve UX and minor issues in preparation for the ICS 2.0 incentivized testnet. We also submitted a signaling proposal to ask the Cosmos Hub community for approval. Next, we will continue coordinating with Hypha on the incentivized testnet and working on addition features, such as fraud proofs.
We completed the spike phase of Megablocks. We created a prototype — an ABCI multiplexer shim — that allows multiple Cosmos SDK applications to run on a single instance of CometBFT. This enables parallel execution and is a building block for Atomic IBC (a form of atomic composability). For more details on this architecture, look at this forum post. We also created a screencast showing how Megablocks works, which we’ll publish soon.
There were two other achievements, which, although they are not major rocks on our roadmap, we think are significant enough to be mentioned.
First, we fixed an issue in the Liquid Staking Module (LSM) — vesting account users could not tokenize already vested delegations and, consequently, could not convert them into liquid stake. Thanks to Billy Rennekamp for bringing this issue to our attention. The fix was added to the special Cosmos SDK release used by the Cosmos Hub and will be part of Gaia v16.
Second, we helped resolve a relaying issue on ICS: On the Hub side of the ICS channel between Cosmos Hub and Stride, a lot of ICS packets were pending (not being cleared out by relayers). As a result, the SlashPackets sent by Stride were not acknowledged, which triggered the downtime throttling mechanism and blocked the sending of all ICS packets from Stride. Although this behavior is expected (see ADR 008 for more details), if left unchecked, it might affect the UX on the Hub — the delays introduced in VSCMaturedPackets could lead to unbonding operations (e.g., Undelegations) on the Hub to be delayed. Once the Informal Systems validator team started using Hermes with clear_interval enabled all the packets got cleared, and the issue was solved. To facilitate monitoring of such scenarios, we added a new query to ICS — oldest_unconfirmed_vsc — that enables operators to query on the Hub the send timestamp of the oldest unconfirmed VSCPacket by consumer chain ID. We will add the query to Gaia v16.
This month’s increment of work heavily supported the delivery of our long-term roadmap with the following notable highlights:
We are moving into testnet next for Partial Set Security and looking good to launch ICS 2.0 in Q2, which is an exciting milestone for the future vision of the Hub.
The equal amount of attention we give to developing and coordinating releases of regular upgrades and rapid vulnerability patching ensures that the Hub remains one of the safest crypto chains on the planet.
An increased focus on collaboration across multiple customer groups (e.g., validators and partner development organizations) allows us to strengthen the community around the Cosmos Hub and get closer feedback on our product roadmap and plans.
Our roadmap for Q2 will be released in April, which will detail our primary objectives for the quarter and how they ladder up to making the Cosmos Hub the best place to launch a chain.