build(deps): bump github.com/cosmos/cosmos-sdk from 0.43.0-rc3 to 0.43.0

[dependabot]

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

Release notes

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

Cosmos SDK v0.43.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.43 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.42 "Stargate" release series, please see the CHANGELOG.

Two new modules: x/authz and x/feegrant

The v0.43 release focused on simplifying keys and fee management for SDK users, by introducing the two following modules:

• x/feegrant allows one account, the "granter" to grant another account, the "grantee" an allowance to spend the granter's account balance for fees within certain well-defined limits. It solves the problem of signing accounts needing to possess a sufficient balance in order to pay fees.
  • See ADR-029 introducing the module.
  • Read the documentation.
  • Check out its Protobuf definitions.
• x/authz provides functionality for granting arbitrary privileges from one account (the "granter") to another account (the "grantee"). These privileges, called Authorizations in the code, can for example allow grantees to execute Msgs on behalf of the granter.
  • See ADR-030 introducing the module.
  • Read the documentation.
  • Check out its Protobuf definitions.

These two modules have a slightly different folder structure compared to previously existing modules. For example, all Protobuf-generated files are generated in the module root folder instead of the types/ folder, and the module itself is defined inside a module sub-package. Moving forward, we believe this folder structure is clearer and sets a better example for module developers. To learn more about building modules following this structure, please read our building modules documentation.

ADR-028 Addresses

In the SDK versions v0.42 and earlier, addresses were all 20-bytes long, generated by truncating the first 20 bytes of the SHA-256 hash of some given bytes (e.g. the public key for normal accounts, or the module name for module accounts). Unfortunately, this significantly decreases the security of Cosmos SDK due to address space collisions.

ADR-028 introduces a new specification for deriving addresses for all kinds of addressable accounts. Following is a quick summary:

• secp256k1 public keys still have 20-byte addresses to keep backwards-compatibility,
• new public key types (e.g. ed25519) and module accounts will have 32-byte address to increase collision resistance,
• new algorithms have also been specified for composed accounts (like multisigs) or derived accounts (like module sub-accounts).

Link to ADR-028.

ADR-041 In-place store migrations

Chain upgrades were historically done with the Cosmos SDK by creating an upgrade proposal, halting the chain at the given height, exporting state to a JSON file, making the necessary JSON file changes, and creating a new chain with the modified JSON file as genesis. This procedure is tedious, and could take up to several hours.

Cosmos SDK v0.43 introduces a new way of handling upgrades. When an upgrade happens, instead of starting a new chain, the new binary will read the existing database, and perform in-place modifications of the store. We expect this method to significantly reduce the migration time.

For more information:

• see the upgrading modules documentation to learn how to modify your module to be able to support in-place store migrations,
• check out how to set up an upgrade handler that perform in-place store migrations in your app.go,
• read ADR-041 introducing this feature.

Protobuf Client-Side Breaking Changes

In this release, we deprecated a couple of fields in our Protobuf definitions. When using these fields, some changes in behavior might occur whether you're hitting an v0.42 or a v0.43 node.

• cosmos.gov.v1beta1.Vote#option is deprecated in favor of cosmos.gov.v1beta1.Vote#options (with an "s") to support x/gov split votes. There are no breaking changes in Msgs, as a new MsgWeightedVote has been added to support split votes. However, when querying, the deprecated option field is populated only when the underlying vote has one VoteOption with weight 1. For other split votes, the option field will be equal to OptionEmpty.
• cosmos.upgrade.v1beta1.Plan#time is deprecated, because the SDK stops supporting time-based upgrades in favor or height-based upgrades. If an upgrade Plan is created with a non-empty time, the node will error.

... (truncated)

Changelog

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

Changelog

[Unreleased]

Features

• #9860 Emit transaction fee in ante handler fee decorator. The event type is tx and the attribute is fee.
• #9776 Add flag staking-bond-denom to specify the staking bond denomination value when initializing a new chain.
• #9533 Added a new gRPC method, DenomOwners, in x/bank to query for all account holders of a specific denomination.
• (bank) #9618 Update bank.Metadata: add URI and URIHash attributes.
• #9750 Emit events for tx signature and sequence, so clients can now query txs by signature (tx.signature='<base64_sig>') or by address and sequence combo (tx.acc_seq='<addr>/<seq>').
• #9837 --generate-only flag will accept the keyname now.

API Breaking Changes

... (truncated)

Commits

• 3f8596c chore: v0.43.0 Changelog and Release Notes (#9886)
• 118d57b chore: add missing changelog entry from #9859 (backport #9867) (#9871)
• 1afd470 refactor: update default pruning strategy (#9859) (#9863)
• See full diff 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)