Bump github.com/cosmos/gaia/v9 from 9.0.1 to 9.1.0

[dependabot]

Bumps github.com/cosmos/gaia/v9 from 9.0.1 to 9.1.0.

Release notes

Sourced from github.com/cosmos/gaia/v9's releases.

v9.1.0

Gaia v9.1.0 Release Notes

Note: This release is consensus breaking and will be applied in a coordinated upgrade

This upgrade is proposed to take place at height 15,21,3800. The date/time of the upgrade is subject to change as blocks are not generated at a constant interval. You can stay up-to-date using this live countdown page.

The chain id will remain cosmoshub-4.

For full upgrade instructions please see Discord for the following settings/scenarios.

• Golang version --> v1.18.x
• Halt Height settings --> MUST be manually set to 15213800
• Avoiding double signing errors --> Avoid being tombstoned and slashed
• Dealing with stuck nodes

Be sure to monitor the #cosmos-hub-validators-verified channel in the Cosmos Hub Developers Discord as the estimated height approaches

What's Changed

• (fix!) cosmos/gaia#2474 Multisig and distribution fix in Interchain-Security. Bump Interchain-Security to v1.1.0-multiden.

This release combines two fixes that we judged were urgent to get onto the Cosmos Hub before the launch of the first ICS consumer chain. Please note that user funds were not at risk and these fixes pertain to the liveness of the Hub and consumer chains.

The first fix is to enable the use of multisigs and Ledger devices when assigning keys for consumer chains. The second is to prevent a possible DOS vector involving the reward distribution system.

Multisig fix

On April 25th (a week and a half ago), we began receiving reports that validators using multisigs and Ledger devices were getting errors reading Error: unable to resolve type URL /interchain_security.ccv.provider.v1.MsgAssignConsumerKey: tx parse error when attempting to assign consensus keys for consumer chains.

This was surprising because we had never seen this error before, even though we have done many testnets. The reason for this is probably because people don’t bother to use high security key management techniques in testnets.

We quickly narrowed the problem down to issues having to do with using the PubKey type directly in the MsgAssignConsumerKey transaction, and Amino (a deprecated serialization library still used in Ledger devices and multisigs) not being able to handle this. We attempted to fix this with the assistance of the Cosmos-SDK team, but after making no headway for a few days, we decided to simply use a JSON representation of the PubKey in the transaction. This is how it is usually represented anyway. We have verified that this fixes the problem.

Distribution fix

The ICS distribution system works by allowing consumer chains to send rewards to a module address on the Hub called the FeePoolAddress. From here they are automatically distributed to all validators and delegators through the distribution system that already exists to distribute Atom staking rewards. The FeePoolAddress is usually blocked so that no tokens can be sent to it, but to enable ICS distribution we had to unblock it.

We recently realized that unblocking the FeePoolAddress could enable an attacker to send a huge number of different denoms into the distribution system. The distribution system would then attempt to distribute them all, leading to out of memory errors. Fixing a similar attack vector that existed in the distribution system before ICS led us to this realization.

To fix this problem, we have re-blocked the FeePoolAddress and created a new address called the ConsumerRewardsPool. Consumer chains now send rewards to this new address. There is also a new transaction type called RegisterConsumerRewardDenom. This transaction allows people to register denoms to be used as rewards from consumer chains. It costs 10 Atoms to run this transaction.The Atoms are transferred to the community pool. Only denoms registered with this command are then transferred to the FeePoolAddress and distributed out to delegators and validators.

Note: The fee of 10 Atoms was originally intended to be a parameter that could be changed by governance (10 Atoms might cost too much in the future). However, we ran into some problems creating a new parameter as part of an emergency upgrade. After consulting with the Cosmos-SDK team, we learned that creating new parameters is only supported as part of a scheduled upgrade. So in the current code, the number of Atoms is hardcoded. It will turn into a parameter in the next scheduled upgrade.

Consumer fixes

There is a similar denom issue in the consumer module which we also fix in this release. However, this module is not imported by the Cosmos Hub (it is used only by consumer chains), so we will not cover this fix in these release notes.

Code review guide

... (truncated)

Changelog

Sourced from github.com/cosmos/gaia/v9's changelog.

[v9.1.0] - 2023-05-08

• (fix) #2474 Multisig and distribution fix in Interchain-Security. Bump Interchain-Security to v1.1.0-multiden.

This release combines two fixes that we judged were urgent to get onto the Cosmos Hub before the launch of the first ICS consumer chain. Please note that user funds were not at risk and these fixes pertain to the liveness of the Hub and consumer chains.

The first fix is to enable the use of multisigs and Ledger devices when assigning keys for consumer chains. The second is to prevent a possible DOS vector involving the reward distribution system.

Multisig fix

On April 25th (a week and a half ago), we began receiving reports that validators using multisigs and Ledger devices were getting errors reading Error: unable to resolve type URL /interchain_security.ccv.provider.v1.MsgAssignConsumerKey: tx parse error when attempting to assign consensus keys for consumer chains.

This was surprising because we had never seen this error before, even though we have done many testnets. The reason for this is probably because people don’t bother to use high security key management techniques in testnets.

We quickly narrowed the problem down to issues having to do with using the PubKey type directly in the MsgAssignConsumerKey transaction, and Amino (a deprecated serialization library still used in Ledger devices and multisigs) not being able to handle this. We attempted to fix this with the assistance of the Cosmos-SDK team, but after making no headway for a few days, we decided to simply use a JSON representation of the PubKey in the transaction. This is how it is usually represented anyway. We have verified that this fixes the problem.

Distribution fix

The ICS distribution system works by allowing consumer chains to send rewards to a module address on the Hub called the FeePoolAddress. From here they are automatically distributed to all validators and delegators through the distribution system that already exists to distribute Atom staking rewards. The FeePoolAddress is usually blocked so that no tokens can be sent to it, but to enable ICS distribution we had to unblock it.

We recently realized that unblocking the FeePoolAddress could enable an attacker to send a huge number of different denoms into the distribution system. The distribution system would then attempt to distribute them all, leading to out of memory errors. Fixing a similar attack vector that existed in the distribution system before ICS led us to this realization.

To fix this problem, we have re-blocked the FeePoolAddress and created a new address called the ConsumerRewardsPool. Consumer chains now send rewards to this new address. There is also a new transaction type called RegisterConsumerRewardDenom. This transaction allows people to register denoms to be used as rewards from consumer chains. It costs 10 Atoms to run this transaction.The Atoms are transferred to the community pool. Only denoms registered with this command are then transferred to the FeePoolAddress and distributed out to delegators and validators.

Note: The fee of 10 Atoms was originally intended to be a parameter that could be changed by governance (10 Atoms might cost too much in the future). However, we ran into some problems creating a new parameter as part of an emergency upgrade. After consulting with the Cosmos-SDK team, we learned that creating new parameters is only supported as part of a scheduled upgrade. So in the current code, the number of Atoms is hardcoded. It will turn into a parameter in the next scheduled upgrade.

[v9.0.3] - 2023-04-19

• (deps) #2399 Bump cosmos-sdk to [v0.45.15-ics](https://github.com/cosmos/cosmos sdk/releases/tag/v0.45.15-ics) and migrate to CometBFT.

[v9.0.2] - 2023-04-03

• (feat) Bump Interchain-Security v1.1.0 provider module. See the release notes for details.
• (feat) Add two more msg types /ibc.core.channel.v1.MsgTimeout and /ibc.core.channel.v1.MsgTimeoutOnClose to default bypass-min-fee-msg-types.
• (feat) Change the bypassing gas usage criteria. Instead of requiring 200,000 gas per bypass-min-fee-msg, we will now allow a maximum total usage of 1,000,000 gas for all bypassed messages in a transaction. Note that all messages in the transaction must be the bypass-min-fee-msg-types for the bypass min fee to take effect, otherwise, fee payment will still apply.
• (fix) #2087 Fix bypass-min-fee-msg-types parsing in app.toml. Parsing of bypass-min-fee-types is changed to allow node operators to use empty bypass list. Removing the bypass-min-fee-types from app.toml applies the default message types. See #2092 for details.

[v9.0.1] - 2023-03-09

• (feat) add spam prevention antehandler to alleviate recent governance spam issues.

[v9.0.0] - 2023-02-21

• (feat) Add Interchain-Security v1.0.0 provider module. See the ICS Spec for more details.
• (gaia) Bump cosmos-sdk to v0.45.13-ics. See CHANGELOG.md for details.
• (gaia) Bump ibc-go to v4.2.0. See v4.2 Release Notes for details.
• (gaia) Bump tendermint to 0.34.26. See CHANGELOG.md for details.
• (gaia) Bump packet-forward-middleware to v4.0.4.
• (tests) Add E2E ccv tests. Tests covering new functionality introduced by the provider module to add and remove a consumer chain via governance proposal.
• (tests) Add integration ccv tests. Imports Interchain-Security's TestCCVTestSuite and implements Gaia as the provider chain.
• (fix) #2017 Fix Gaiad binary build tag for ubuntu system. See #2018 for details.

... (truncated)

Commits

• 321d15a update changelog for v9.1.0
• c1d0fb5 fix!: multisig + distribution fix (#2474)
• 108cb9b deps: bump ICS to v1.1.1 (backport #2442) (#2454)
• 05b6b87 update changelog for rc 2 (backport #2421) (#2422)
• c38e4e7 update changelog for rc (#2418) (#2419)
• 9c7af12 remove logger in app.go (#2416) (#2417)
• 7e30d6f Update comet and sdk (#2399)
• ec88d59 Update makefile linting targets (#2377) (#2396)
• 56844d5 docs: update changelog for v9.0.0 (#2301) (#2395)
• fe36437 adding back trust wallet (#2384) (#2386)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

Superseded by #44.