It’s time for the usual update from the Informal Systems’ Cosmos Hub team. As the last update was for September, we decided to do a Q4 update including the months of October, November and December. Here are some of the highlights: We released the cryptographic equivocation verification function, which is currently running on the Cosmos Hub since the v14 upgrade. We are close to wrapping up the Gaia upgrade to SDK v0.47, which is targeted for the v15 upgrade planned for January. We upgraded ICS to SDK v0.50. We enabled a first iteration of Model Based Testing (MBT) on Replicated Security. We finalized the design of Partial Set Security, which we plan to implement starting from next quarter.
During October, the Cosmos Hub upgraded to Gaia v13.0.0. This upgrade completely removes the Gravity DEX module and introduces a governance proposal to add consumer reward denominations, which was added to give the community more control over what denominations are accepted as ICS rewards. In addition this fixes a small security vulnerability – the previous mechanism to add consumer reward denominations through a transaction was opening a potential DOS attack vector on the Hub. This fix was part of the workflow with Amulet.
We released Gaia v13.0.1 with a fix for a security vulnerability found in the packet forward middleware module. We coordinated with the validator community to ensure that more than 2/3 of the voting power upgraded in order to avoid a potential network halt. This work was part of the workflow with Amulet.
We released Gaia v14.1.0 that contains ICS with cryptographic equivocation verification. This release required a few iterations in order to fix some issues related to the 818 proposal. As a result, Gaia v14.0.0 is deprecated and should never be used in production.
During December, the Cosmos Hub upgraded to Gaia v14.1.0. The upgrade went smoothly with around 12 minutes of downtime. This upgrade brings the cryptographic equivocation verification feature and deprecates the equivocation proposals. To enable automatic reporting of equivocation infractions on the consumer chains, we recommend all Hermes relayer operators to use Hermes v1.7.3. Note that equivocation infractions can be reported also through the CLI. For more details, please refer to the ICS documentation.
We are in the final stages of upgrading Gaia to SDK v0.47. The plan is to release it in January as part of Gaia v15.
The audit of SDK v0.47 performed by Oak Security was completed with the recommended fixes already added to the code. This was something we wanted to see before putting it on the Hub. Thanks to both Oak Security and Binary Builders for completing this audit.
Other two prerequisites for the Gaia upgrade are the Liquid Staking Module (LSM) and the cryptographic equivocation verification feature. We upgraded both to SDK v0.47. For more details, see the sections below.
The Liquid Staking Module (LSM) was added to the Cosmos Hub as part of the v12 upgrade (as requested by the community in proposal 790). LSM facilitates users liquid staking their ATOMs by allowing them to be moved to liquid staking without an unbonding period. LSM was developed as a collaboration between Iqlusion and Stride, while the integration to Gaia was a collaboration between Iqlusion, Stride, Binary Builders, and Informal Systems.
The integration to Gaia required moving the Hub on a special branch of the SDK (i.e., v0.45.16-ics-lsm). Note that the Hub has been using a special branch of SDK since the ICS release in the v9 upgrade. Having LSM on a special branch of SDK means though that LSM is not being automatically upgraded with mainline SDK. Thus, LSM requires continuous maintenance until it gets added to mainline SDK. For this reason, we upgraded LSM to SDK v0.47. Currently, the upgrade is in review and we are working on Gaia integration.
We finished the design and implementation of the cryptographic equivocation verification feature. This is important because it allows the Hub to immediately slash validators who misbehave on consumer chains, instead of the previous governance-gated process, which required a vote to verify the slashing. For more details, please have a look at ADR-005 and ADR-013. The cryptographic equivocation feature is a collaboration between the Cosmos Hub, Comet, and Hermes teams at Informal.
As a prerequisite for the Gaia upgrade to SDK v0.47, we ported the cryptographic equivocation verification feature to SDK v0.47. We plan to release it soon as part of ICS v3.3.0.
We upgraded ICS to SDK v0.50 and IBC v8.0.0. This upgrade enables consumer chains (like Neutron and Stride) to upgrade to the latest version of SDK. During the update process, we identified and fixed a minor issue with the SDK state streaming. This work was done in collaboration with All in Bits. The upgrade is being tested and we plan to cut a final release soon.
We improved the documentation for ICS releases, backwards compatibility, and existing features, in order to facilitate integration (especially on consumer chains) and increase confidence in our releases. In addition, we are working on restructuring our ICS e2e testing infrastructure to enable backwards compatibility tests as part of our CI (for more details, see ADR-011). Note that this will complement the testing work done by Hypha for every ICS release.
On this note, we already released ICS v3.2.0 with the consumer-side changes for Jail Throttling v2 (cf. ADR 008). We also plan to release soon
ICS v3.3.0 with the cryptographic equivocation verification feature (which will end up in Gaia v15)
ICS v4.0.0 with the provider-side changes for Jail Throttling v2 (cf. ADR 008) – this release will be compatible with consumers >= v3.2.0
ICS v5.0.0 with SDK 0.50
We upgraded CometMock to CometBFT v0.38, which contains ABCI++ and is compatible with SDK 0.50. This is a prerequisite for upgrading Replicated Security to SDK 0.50.
We enabled the first iteration of Model Based Testing (MBT) on Replicated Security. For the last year or so, we were using differential testing to increase the confidence of the Replicated Security implementation. In a nutshell, differential testing consists of a TypeScript reference implementation of Replicated Security that is used to model the protocol and generate traces (i.e., events) that can be provided to a driver in order to generate tests. The name “differential” comes from the fact that the states resulting from executing the reference implementation and the actual implementation were checked against each other. This approach enabled us to find very subtle bugs, especially during the development of Replicated Security v1.
The issue is that the TypeScript reference implementation is very detailed. Consequently, it is very hard to maintain and since it lagged behind the actual implementation, we had to disable differential testing. Our solution was to create a Quint model of Replicated Security. The model is based on a high-level TLA+ specification of Replicated Security and we believe it is much easier to maintain.
We updated the driver and MBT is currently running in our CI.
Throughout the quarter, we looked into simplifying the Replicate Security protocol by removing one of the three message types – the VSCMaturedPackets. The idea came from a discussion we had with Jae Kwon a year ago. The benefits are twofold. First, it would simplify the protocol (and consequently the implementation), which would make it easier to iterate and bring improvements, such as Partial Set Security. Second, it would be a necessary step for making Replicated Security a read only protocol – the Cosmos Hub regularly publishes validator updates and consumer chains subscribe to these updates. This would remove the dependency between the liveness of undelegation operations on the Hub and the liveness of consumer chains. For example, it would avoid scenarios where a user has to wait more than 3 weeks for their unstaked ATOMs due to a consumer chain being down.
Unfortunately, we believe that VSCMaturedPackets cannot be removed from the Replicated Security protocol without compromising the security of the system. This is due to the security model of IBC light clients. We documented our findings here and we plan to post it on the Hub forum for more discussion. Any feedback is more than welcome.
Throughout the quarter, we worked on the design of Partial Set Security that enables consumer chains to consume only a portion of the security provided by the Cosmos Hub (and consequently, allows only a subset of Hub validators to run physical nodes for consumer chains). We started with a discussion on the Hub forum, as part of the Cosmos Hub Improvement Proposals (CHIPs) process. The discussion resulted in the refinement of the Partial Set Security design, which we plan to implement starting from next quarter.
In October, we introduced the concept of Cosmos Hub Improvement Proposals (CHIPs). This consists of a framework that enables the Hub community to keep track of the progress of different Hub improvements. Since then, we started discussions on several CHIPs, such as Megablocks and Atomic IBC, Partial Set Security, Optimizing ICS reward distribution with per-chain commission, and Minimum Commission as a Function of Voting Power. We encourage everyone in the Cosmos Hub community to participate and give us feedback.