build(deps): Bump github.com/cosmos/cosmos-sdk from 0.46.0-rc3 to 0.46.0 in /cosmovisor

[dependabot]

Bumps github.com/cosmos/cosmos-sdk from 0.46.0-rc3 to 0.46.0.

Release notes

Sourced from github.com/cosmos/cosmos-sdk's releases.

v0.46.0

Cosmos SDK v0.46.0 Release Notes

This release introduces several new important updates to the Cosmos SDK. The release notes below provide an overview of the larger high-level changes introduced in the v0.46 release series.

That being said, this release does contain many more minor and module-level changes besides those mentioned below. For a comprehsive list of all breaking changes and improvements since the v0.45 release series, please see the CHANGELOG.

New Module: x/group

The previous v0.43 series focused on simplifying keys and fee management for SDK users, by adding x/feegrant and x/authz. v0.46 finishes this work by introducing x/group.

x/group provides functionality to define on-chain groups of people that can execute arbitrary messages based on agreed upon rules. A simple use-case of x/group is to create on-chain multisigs (with updateable members and thresholds), but x/group can also be used to create more complex DAOs.

The x/group module revolves around 3 concepts:

• A group is simply an aggregation of accounts with associated weights.
• A group policy is a group with a set of rules attached, called decision policy. The decision policy defines how voting and arbitrary message execution happens (e.g. does a proposal pass on 50% yes? 2/3 yes? is there a way to veto? etc). Each group policy has its own an on-chain account, so can hold funds. Managing group membership separately from decision policies results in the least overhead and keeps membership consistent across different policies.
• Any member of a group can submit a proposal for a group policy account to decide upon. A proposal consists of a set of messages that will be executed if the proposal passes voting.

If a proposal passes the decision policy's rules after its voting period, then any account can send a MsgExec against this proposal to execute the sdk.Msgs included in the proposal.

For more details about x/group, please refer to the SDK documentation and ADR-042.

The folder structure of x/group contains an internal folder, which holds a custom ORM used only by x/group (and which will be replaced by the new ORM) as well as a new implementation of Dec (for decimals) based on cockroachdb/apd, which serves as a proof-of-concept for the new sdk.Dec.

Msg-based Gov Proposals

In an effort to align x/gov with x/group, the SDK v0.46 release introduces a new Protobuf package: cosmos.gov.v1.

The biggest change compared to the previous cosmoss.gov.v1beta1 is in MsgSubmitProposal: instead of defining gov router proposal handlers, the v0.46 gov execution models is based on sdk.Msgs:

message MsgSubmitProposal {
-  google.protobuf.Any content                       = 1 [(cosmos_proto.accepts_interface) = "Content"];
+  repeated google.protobuf.Any messages             = 1 [(cosmos_proto.accepts_interface) = "sdk.Msg"];
  repeated cosmos.base.v1beta1.Coin initial_deposit = 2 [(gogoproto.nullable) = false];
  string                            proposer        = 3 [(cosmos_proto.scalar) = "cosmos.AddressString"];
+  // metadata is any arbitrary metadata attached to the proposal.
+  string metadata = 4;
}

For example, instead of broadcasting a v1beta1.MsgSubmitProposal with content a SoftwareUpgradeProposal, the proposer would submit a v1.MsgSubmitProposal with a /cosmos.upgrade.v1beta1.MsgSoftwareUpgrade message. When the proposal passes, the sdk.Msg will be executed by the Msg service router (instead of going through the gov proposal handlers).

The sdk.Msgs in the proposal are executed on behalf of the gov module account. This means that each of the sdk.Msg inside the proposal must have their GetSigners() method return exactly one address, which is the gov module account's address.

A metadata field has also been added to MsgSubmitProposal and MsgVote, for users to provide optional justification for their action.

From a client perspective, the new gov v1 is purely additive. All v1beta1 Protobuf defintions, queries and Msgs still work. Morever, users can also submit v1beta1 legacy proposals using the v1 Msg service, by including a MsgExecLegacyContent inside the v1.MsgSubmitProposal. It is recommended to switch to gov v1 during v0.46, as the gov v1beta1 backwards-compatibility might be removed in a future version.

... (truncated)

Changelog

Sourced from github.com/cosmos/cosmos-sdk's changelog.

Changelog

[Unreleased]

Features

• (cli) #12028 Add the tendermint key-migrate to perform Tendermint v0.35 DB key migration.
• (query) #12253 Add GenericFilteredPaginate to the query package to improve UX.
• (telemetry) #12405 Add query calls metric to telemetry.
• (sdk.Coins) #12627 Make a Denoms method on sdk.Coins.
• (upgrade) #12603 feat: Move AppModule.BeginBlock and AppModule.EndBlock to extension interfaces

Improvements

• #12702 Linting and tidiness, fixed two minor security warnings.

... (truncated)

Commits

• a114313 chore: v0.46.0 Final Release changelog (#12731)
• a69a77b chore: remove cosmossdk.io/api module from v0.46.x (#12719)
• f11cf53 fix: incorrect versions of imported protos in Makefile (#12701)
• 24be8ea refactor: remove cosmos/keyring (backport #12576) (#12707)
• 8042c66 docs: add cosmwasm to the sidebar and modules section (#12703) (#12704)
• 2df7ced feat: add message index event attribute to authz message execution (backport ...
• e28ac18 chore(store): upgrade iavl to v0.19.0 (backport #12626) (#12653)
• 19d6f39 fix: add cosmos_proto implements (#12639) (#12664)
• b823b17 docs: improve docs (backport #12647) (#12650)
• b1d5768 chore: Bump to Tendermint v0.34.20 (#12649)
• 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)