It’s time for the usual update from the Informal Systems’ Cosmos Hub team. Here are some of the highlights:
Cosmos Hub v19 upgrade.
Working on the integration and testnet phases for Gaia v20.
Completed the signaling phase and started the implementation phase for Permissionless ICS.
Completed the signaling phase and continued the implementation phase for Forge.
Made significant progress towards the Hydro launch.
Note that we use CHIPs to track the progress of our work. Hence, throughout this update, we refer to different phases of the CHIPs framework.
Before going into the updates from the previous month, we want to clarify the ICS terminology. Recently, you might have heard multiple ICS related names / terms used in the community. The following definitions should reduce the confusion:
Forge (formerly known as the Permissionless ICS Frontend) is the product that makes the Cosmos Hub the best place to launch a chain
Interchain Security (ICS) is an IBC protocol for shared security that powers Forge. The cosmos/interchain-security github repo contains an open-source implementation of the ICS protocol.
Replicated Security is a major feature of ICS that enables Consumer Chains to fully replicate the security of the Provider Chain, i.e., use the entire validator set of the Provider Chain. Replicated Security is in production since the Cosmos Hub v9 upgrade.
Partial Set Security (PSS) is a major feature of ICS that enables Consumer Chains to use only a subset of the Provider Chain’s validator set. This subset can be determined by the top N% validators by voting power (top-N Consumer Chains) or by validators opting in to validate (opt-in Consumer Chains). PSS allows for more flexible security tradeoffs than Replicated Security. Note that top-N with N=100 is equivalent to Replicated Security. PSS has been in production since the Cosmos Hub v17 upgrade.
Permissionless ICS is a major feature of ICS that enables users to permissionlessly launch an opt-in Consumer Chain on the Provider Chain (i.e., on the Cosmos Hub). Permissionless ICS will be launched in production with the Cosmos Hub v20 upgrade.
On August 21st, the Cosmos Hub upgraded to Gaia v19.1.0 (as per prop 948). This is a major release that upgraded the Cosmos Hub to the latest versions of the Interchain Stack:
Cosmos SDK v0.50 — the Cosmos Hub will use v0.50.9-lsm, a special Cosmos SDK branch with support for LSM
IBC v8.4.0
CometBFT v0.38.11
Interchain Security v5.1.1
Packet Forward Middleware v8.0.2
IBC Rate Limiting v8.0.0
Fee Market v1.1.0
CosmWasm/wasmd to v0.51.0
This is part of a larger initiative to make the Cosmos Hub the reference chain for the Interchain Stack and is a collaboration with Binary Builders. This initiative aims to improve the upgrade process to newer versions of the Interchain Stack, which will consequently enhance the adoption within the Cosmos ecosystem. Additionally, the Cosmos Hub community will gain access to the new Interchain Stack features sooner, resulting in faster product development. Finally, by being on par with the latest releases of the Interchain Stack, the Cosmos Hub community can more actively contribute to the development of the Interchain Stack by asking for new features to be added in the subsequent releases. You can read more about what the upgrade entails here.
It is important to recognize that running the latest version of the Interchain Stack is a natural part of the agile development process. While the code may not be as battle-tested yet, this is an expected phase as we move quickly and strategically. Any bugs will be promptly identified and addressed through necessary upgrades, ensuring continuous improvement. This approach allows us to stay ahead while remaining diligent, and rest assured; our goal is to catch every issue to deliver the most robust and reliable system possible.
We thank the Cosmos Hub community for voting on the software upgrade proposal and the validator community for a smooth upgrade with around 30 minutes of downtime.
The v19 software upgrade proposal was for upgrading the Cosmos Hub to Gaia v19.0.0. However, due to a security vulnerability in the Fee Market module, the v19 upgrade used Gaia v19.1.0, which bumped the Fee Market module to v1.1.0. The vulnerability affected both the Cosmos Hub and Neutron chains. Thus, the security fix was coordinated with the Skip, Neutron, and Amulet teams. We thank everybody involved, especially the Cosmos Hub validators who successfully patched both networks.
Throughout August, we worked on the integration and testnet phases for Gaia v20, a release that will add the following features to the Cosmos Hub:
ICS with Inactive Validators (as per prop 930) enables validators from outside the Hub’s active set to validate on Consumer Chains. This feature brings the following benefits: it reduces the entry barrier for projects to launch as Consumer Chains since more validators will be allowed to opt in; it enables validators outside the Hub’s active set to compete by providing their services to interesting projects; and it reduces the risk of all the validators of a Consumer Chain opting out, which would require the chain to leave ICS.
Permissionless ICS (as per prop 945) enables users to launch opt-in Consumer Chains on the Cosmos Hub permissionlessly. Given that validators are free to choose whether they want to run a given opt-in Consumer Chain, it is only natural to also enable projects to launch as opt-in Consumer Chains by simply submitting transactions to the Cosmos Hub and, thus, avoiding the need to go through the process of governance.
The removal of Unbonding Pausing from ICS (as described by ADR 018) reduces the complexity of the ICS protocol and removes the dependency between the liveness of undelegation operations on the Cosmos Hub and the liveness of consumer chains. See the section below for more details.
Bump CosmWasm/wasmd to v0.53.0 fixes two issues with the current CosmWasm deployment.
Zellic successfully completed the audit of the ICS with Inactive Validators feature. We fixed all the minor and medium severity issues during the audit, and no major severity issues were found. Next, we will publish the audit report once it is finalized.
We completed the signaling phase for the Permissionless ICS feature. We thank the Cosmos Hub community for voting on the signaling proposal.
We also made substantial progress on completing the implementation (the main logic is done) and started the integration into Gaia. This enabled us to begin testing Gaia v20 (with Hypha) and integrating with Forge, the front-end platform that allows the Cosmos Hub to be the best place to launch a chain. Next, we are improving existing e2e tests and adding new ones to increase testing coverage.
Finally, we are working with Simply Staking to source a third-party audit.
At the end of last year, we looked into simplifying ICS by removing one of the three message types – the VSCMaturedPackets. The VSCMaturedPackets are sent by consumer chains to acknowledge that their unbonding period elapses and the corresponding stake on the provider (i.e., the Cosmos Hub) can be unlocked. Consequently, the VSCMaturedPackets add a dependency between the liveness of undelegation operations on the Hub and the liveness of consumer chains. We refer to this as unbonding pausing. For example, if the VSCMaturedPackets from one of the consumer chains are delayed sufficiently long, then ATOM delegators will need to wait for more than three weeks to undelegate their ATOMs.
In February, we published a blog post — Learning to Live with “Unbonding Pausing” — describing our understanding at that time on why VSCMaturedPackets are necessary for the system's security. In a nutshell, the reasoning was the security model of IBC light clients. However, this analysis overlooked an inconsistency between the original design of the ICS protocol and the ICS implementation. The original ICS protocol guarantees the following property that is needed for IBC client verification:
The stake securing a consumer chain is locked until the unbonding period of that consumer chain elapses.
This means that if the consumer chain halts, the unlocking of that stake will be delayed. Moreover, if the chain is removed, the stake can never be unlocked. This is not feasible in practice. Thus, in the ICS implementation, a halted consumer chain is eventually removed from ICS, and once a consumer chain is removed, the stake securing it is eventually unlocked. Note that a consumer chain must be halted for weeks before this happens. The ICS implementation relies on more synchrony assumptions than the ICS protocol. For more details on this inconsistency, check out the Context section of ADR 018.
To address this inconsistency, we split the work in two parts.
First, we remove the VSCMaturedPackets. The reason is twofold. First, VSCMaturedPackets provides a "false" sense of correctness concerning synchrony assumptions. Second, VSCMaturedPackets add considerable complexity to the ICS protocol, i.e., an extra message plus the pausing of unbonding operations that can affect the user experience. The changes necessary for this removal are described in ADR 018. The Cosmos Hub v20 upgrade will contain the provider-side changes. Once the Cosmos Hub is upgraded, we are going to release the consumer-side changes that will remove the VSCMaturedPackets completely.
Second, we introduce Consumer Chain IBC clients. These are IBC conditional clients that enable a third-party chain to verify the state of a consumer chain by querying the provider (i.e., the Cosmos Hub) for the status of the locked stake that secures the consumer chain. For more details, check out
Forge, is a comprehensive front-end platform designed to streamline the deployment of new projects as Consumer Chains. This initiative aims to dramatically simplify the process of launching and managing Consumer Chains within the Cosmos ecosystem.
We completed the signaling phase for Forge. We thank the Cosmos Hub community for voting on the signaling proposal.
We also made significant progress towards launching Forge, focusing on the delegator experience that will enable Cosmos Hub users to see the list of validators opted in to each Consumer Chain and delegate their ATOMs to them directly. The plan is to launch Forge together with the release of Permissionless ICS (i.e., the v20 Cosmos Hub upgrade).
Hydro is a bidding and governance platform for efficient deployment of liquidity across the Interchain and an important part of the ATOM Wars strategy. Throughout the last month, we made significant progress towards the Hydro launch.
We published a revised version of the forum post on Seeding Hydro’s buckets that takes into account the feedback received from the Cosmos Hub community. The new blog post — ATOM Wars: Re-routing PoL deployments through Hydro — is a signaling proposal for rerouting the existing protocol-owned liquidity deployments to the Hydro committee instead of exporting any additional funds from the Cosmos Hub community pool. The new blog post also proposed the following changes to the Hydro contract: dynamic LST buckets based on market demands and locking of Liquid Staking Module (LSM) shares (i.e., semi-fungible derivatives of staked ATOMs) instead of stATOM for voting. We submitted the signaling proposal on-chain.
We completed adapting the Hydro contract to use LSM shares instead of stATOM. A major complexity in this work is that shares from different validators are not fungible, and in particular different validators shares can be worth different amounts of underlying, staked ATOM, depending on whether validators were ever slashed before. We split the work on integrating the LSM shares into the Hydro contract into two parts:
We adapted the Hydro contract to handle multiple different voting tokens with different weights. This involves storing the individual token-to-power ratios, which we then take into account when computing the voting power of users and the scores of proposals.
We integrated Neutrons Interchain Queries in order to let the Hydro contract (deployed on Neutron) obtain the ratio of shares to underlying staked ATOM from the Cosmos Hub.
The implementation of both parts and internal testing of the modified contract was successfully completed. As a result, we started testing the contract and the integration with the Hydro front-end platform.
This month's developments further strengthen the Cosmos Hub's position as the cornerstone of the Interchain ecosystem:
Cutting-Edge Technology: We've positioned the Cosmos Hub as the reference chain in the Interchain by upgrading to the latest Interchain Stack versions, enabling faster feature adoption across the ecosystem.
Streamlined Chain Deployment: Permissionless ICS and Forge significantly lower entry barriers for new projects, fostering innovation within the Cosmos ecosystem. Enhanced Participation: ICS with Inactive Validators broadens the validator base, improving decentralization and security.
Improved User Experience: Removing Unbonding Pausing from ICS simplifies operations and enhances reliability for ATOM holders.
Optimized Liquidity: Hydro's imminent launch creates a more flexible mechanism for liquidity deployment across the Interchain.
These advancements collectively reinforce the Cosmos Hub's role as the premier platform for launching and managing blockchain projects. We're excited about these new capabilities and look forward to continued growth and innovation in the coming months.