It's time for the usual update from the Informal Systems' Cosmos Hub team. Here are some of the highlights:
We had our kickoff meeting with the oversight committee.
We are almost done with the integration phase of Gaia v15.
We released ICS v4.0.0.
We created an ADR for Partial Set Security.
We started the discussion on ATOM Wars.
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.
On January 8, 2024, the Hub teams at Informal and Hypha met with the Oversight committee. The purpose of the meeting was to discuss Informal's and Hypha's Q1 plans. We published a summary of the meeting on the Hub forum. We thank the Oversight Committee members for their time and engaging discussions.
We finished the upgrade of the Liquid Staking Module (LSM) to SDK v0.47. This resulted in a special SDK branch that will be used by Gaia, starting with v15. Thanks to Zaki Manian and Sam Pochyly for thorough reviews.
We are about to finish the integration phase of Gaia v15 — the release that will upgrade the Cosmos Hub to SDK 0.47 — and move to the testnet phase. A big chunk of the integration work for Gaia v15 consisted of updating Gaia to use the SDK 0.47 branch with support for LSM. In addition, we added several state migrations that will occur on the v15 upgrade:
Set the min commission rate staking parameter to 5% (cf. prop 826). In addition, it updates the commission rate for all validators that are below 5%.
Move the unvested funds from the vesting account cosmos145hytrc49m0hn6fphp8d5h4xspwkawcuzmx498 to the community pool (cf. prop 860). The already vested funds are left in the original account.
Add the missing address to the signing_info state of the slashing module. This fixes an existing bug in the state of the Cosmos Hub.
Set the min initial deposit ratio governance parameter to 10%. This parameter was added to SDK 0.47 to address the gov spamming issue. Note that this doesn't change the existing behavior as the gov spam prevention mechanism was already implemented in Gaia as a temporary fix until the 0.47 upgrade.
In the context of state migrations, we removed the addDenomReverseIndex migration from the bank module as it is prohibitively expensive to run on the Cosmos Hub — it took more than 5h on a machine with 128 GB of RAM. As a consequence, we disabled the DenomOwners query.
Finally, we backported several fixes for issues discovered during the Oak Security audit of SDK 0.47. Consequently, deposits must be in the same denoms as those in the min deposit governance parameter (i.e., for Cosmos Hub, that's ATOM). Also, a new governance parameter is added — min deposit ratio — that enables the community to set a minimum value for a governance proposal deposit; the default value is 0.01, meaning that for the current value for min deposit of 250 ATOM, a deposit of at least 2.5 ATOM is required. In addition to these backports, we addressed a potential DOS attack by only allowing votes on governance proposals from accounts with at least one ATOM staked.
We released ICS v3.3.0 with the cryptographic equivocation verification feature. This ICS release is going to be used by Gaia v15.
We also released ICS v4.0.0, which contains the provider-side changes for jail throttling with retries, and, as a result, it fully enables the jail throttling with retries feature. In addition, this ICS release sets the minimum required version of Go to 1.21 and fixes the following two bugs:
A bug in the soft opt-out protocol which leads to some validators being jailed immediately once they move into the top 95% of voting power and consequently can no longer opt out from validating consumer chains. The fix ensures a warm-up period for validators once they get in the top 95% before they can get jailed for downtime on consumer chains. Thanks to @freak12techno for notifying us of this unexpected behavior.
A bug in the consumer downtime logic related to marshaling using Bech32. Thanks to the Neutron team for bringing this issue to our attention.
Although neither of the bugs is a security vulnerability, we recommend all consumer chains upgrade to ICS v4.0.0 as soon as possible.
At the end of last year, we enabled Model-Based Testing (MBT) for ICS (it is currently part of our CI). We published a blog post describing our approach to using MBT in the context of Cosmos Hub.
We also added the key assignment feature to the Quint model of ICS and integrated it with MBT. Key assignment is a non-trivial feature of ICS; having it covered by MBT increases the confidence of our releases. In addition, this enables us to test how new features, such as ICS epochs (see below), interact with the rest of the protocol. We will continue to expand the MBT functionality — next is adding consumer-initiated slashing to the Quint model, and we are also expanding the model as we continue to spec out Partial Set Security — so stay tuned.
We updated the ICS e2e test infrastructure to enable backward compatibility tests. The new infrastructure supports running the e2e tests against different provider/consumer versions. We also created a GitHub workflow for building and publishing ICS docker images. As a final step, we are currently adapting the existing tests to the new framework.
We wrote an ADR for ICS epochs that addresses the high cost of relaying needs for ICS. Currently, in every block that the provider validator set changes, a VSCPacket must be sent to every consumer, and a corresponding VSCMaturedPacket must be returned. Given that the validator powers may often change on the Cosmos Hub, this approach results in a significant workload for relayers. ICS epochs enable the Cosmos Hub to send validator updates to consumer chains only once per epoch (which consists of multiple blocks). Next, we plan to add ICS epochs to the Quint model (as part of the spike phase), enabling us to move to the implementation phase. The plan is to deploy ICS epochs on the Hub as part of the Gaia v16 upgrade.
We continued the discussion on Partial Set Security (PSS) with a series of posts on the Cosmos Hub forum.
First, we updated the original post by incorporating feedback from validators, consumer chains, and community members. The outcome is a simplified design that removes the concept of validator delegations.
Second, we started a discussion on how to launch opt-in consumer chains — permissionless vs. permissioned-lite. In the first iteration of PSS, we decided to go with permissioned-lite — using the existing governance interface to launch opt-in consumer chains, and only validators who voted YES would be opted in to run a consumer chain.
Third, we started a discussion on different types of top-n consumer chains — inclusive top-n, exclusive top-n, inclusive top-n plus custom active set. We decided to go with inclusive top-n — any active Cosmos Hub validator can opt-in on any top-n chain, regardless of their voting power.
We also wrote an ADR of PSS that describes the steps needed to implement the first iteration of PSS, and have already started with the implementation.
We started the spike phase of Megablocks. We implemented an example of a Comet BFT application and an e2e testing environment. We are currently working on the implementation of an ABCI multiplexer shim.
We posted a description of ATOM Wars on the Cosmos Hub forum — a new governance platform for liquidity injections. In a nutshell, this feature will allow ATOM holders to lock up their stake for up to one year and, in exchange, get boosted decision power regarding the allocation of liquidity injections into third-party projects.
We started a discussion on setting the validator minimum commission as a function of the voting power. This is a potential solution for the concentration of voting power in the Cosmos Hub validator set. In a nutshell, such an approach would have the following benefits:
Encourages a decrease in voting power concentration.
Shields small validators from intense competition with larger validators.
Does not hinder the ability of small validators to compete.
Mitigates Sybil attacks.