Skip to content

@robert-zaremba robert-zaremba released this Sep 1, 2021

v0.44 is a security release which contains a consensus breaking change.
It doesn't bring any new feature and it's a logical continuation of v0.43.

Consequences:

  • v0.43 is discontinued;
  • all chains should upgrade to v0.44. Update from v0.43 doesn't require any migration. Chains can upgrade directly from v0.42, in that case v0.43 migrations must be executed when upgrading to v0.44;
  • all previously planned features for v0.44 are going to land in v0.45, with the same release schedule.

Please see Cosmos SDK v0.43.0 Release Notes.

Updates

For a comprehensive list of all breaking changes and improvements since the v0.42 "Stargate" release series, please see the CHANGELOG.

Client Breaking Changes

  • Removed broadcast & encode legacy REST endpoints. Both requests should use the new gRPC-Gateway REST endpoints. Please see the REST Endpoints Migration guide to migrate to the new REST endpoints.
Assets 2

@amaurym amaurym released this Aug 10, 2021

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.
  • 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.

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.
  • cosmos.upgrade.v1beta1.Plan#upgraded_client_state is deprecated as IBC logic has been moved to the IBC repo. If this field is set, the node will error.

The SDK team is planning to document Protobuf change process using an ADR. It will be a guideline for all chain developers, follow #9477 for more info.

Assets 2

@robert-zaremba robert-zaremba released this Aug 6, 2021

This is the first tracked release of Cosmovisor. It contains the original behavior of scanning app stdin and stdout.
Since the original design, this release contains one important feature: state backup. Since v0.1, by default, cosmovisor will make a state backup (<app_directory>/data directory). Backup will be skipped if UNSAFE_SKIP_BACKUP=true is set.

Updates to this release will be pushed to release/cosmovisor/v0.1.x branch.

Please see the CHANGELOG for more details.

Assets 2
Pre-release

@robert-zaremba robert-zaremba released this Aug 5, 2021

This is a fourth Release Candidate for v0.43. If no issue will be reported this will be the final release.

This release contains two major bug fixes:

  • This release includes an important x/capabiliy module bug fix which prohibited IBC to create new channels (issue #9800).
    The fix introduces an API-breaking change by removing the x/capability/keeper/Keeper.InitializeAndSeal method and replaces it with Seal(). It also requires app developers to update their app module manager by adding x/capability module to BeginBlockers before any other module's BeginBlocker.
  • #9793 Fixed ECDSA/secp256r1 transaction malleability.

One client-breaking change has also been introduced to fix an emitted event:

  • #9785 Fix missing coin denomination in logs when emitting the create_validator event.

It also includes a couple of minor fixes and improvements:

  • #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>').
  • Multiple CLI UX improvements. Notably, we changed <app> tx distribution withdraw-all-rewards CLI by forcing the broadcast mode if a chunk size is greater than 0. This will ensure that the transactions do not fail even if the user uses invalid broadcast modes for this command (sync and async). This was requested by the community and we consider it as fixing the withdraw-all-rewards behavior.

Please see the CHANGELOG for more details.

Assets 2

This release includes an important x/capabiliy module bug fix for 0.42.7 and 0.42.8 which prohibits IBC to create new channels (issuse #9800).
The fix changes the x/capability/keeper/Keeper.InitializeAndSeal method behavior and requires to update an app module manager by adding x/capability module to Begin Blockers.

We also fixed <app> init --recovery mode where the mnemonic was not handled correctly.

We also changed <app> tx distribution withdraw-all-rewards CLI by forcing the broadcast mode if a chunk size is greater than 0. This will ensure that the transactions do not fail even if the user uses invalid broadcast modes for this command (sync and async). This was requested by the community and we consider it as fixing the withdraw-all-rewards behavior.

See the Cosmos SDK v0.42.9 milestone on our issue tracker for the exhaustive list of all changes.

Assets 2

@robert-zaremba robert-zaremba released this Jul 30, 2021

This release includes various minor bug fixes and improvements, including:

  • 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>'),
  • support other signing algorithms than secp256k1 with --ledger in with the CLI keys add command,
  • add missing documentation for CLI flag --output json/text to all tx cli commands.

See the Cosmos SDK v0.42.8 milestone on our issue tracker for the exhaustive list of all changes.

Assets 2
Pre-release

@robert-zaremba robert-zaremba released this Jul 19, 2021

This is a third Release Candidate for v0.43. If no issue will be reported this will be the final release.

This release contains one bug fix:

  • (server) #9704 Start GRPCWebServer in goroutine, avoid blocking other services from starting.
Assets 2
Pre-release

@robert-zaremba robert-zaremba released this Jul 14, 2021

Cosmos SDK v0.43.0-RC1 Release Notes

This is a second Release Candidate for v0.43. If no issue will be reported this will be the final release.

There are 3 changes since v0.43.0-rc0:

  • FIX #9159: (bank) Added migration to prune balances with zero coins (backport #9664).
  • #9593 Error on tx multisign command if chain-id is blank. This is a common cause of signature verification failures when combining signatures and the error message doesn't provide any clues to this common cause.
  • #9621 Rollback #9371 and log warning if there's an empty value for min-gas-price in app.toml. During QA testing we found that this change will break nodes which will forget to set the min-gas-price. This is an issue for chains running with cosmovisor - the node will not be able to start without a manual intervention. So we decided to make a warning. In the next release (v0.44) this will be an error (w will bring back #9371).

Read Release Notes and v0.43.0-rc0 notes for all updates related to v0.43.0 release.

Assets 2

@robert-zaremba robert-zaremba released this Jul 9, 2021

Cosmos SDK v0.42.7 "Stargate" Release Notes

This is minor release porting few bug fixes and backward compatible improvements. See the Cosmos SDK v0.42.7 milestone for more details.

Improvements

  • (baseapp) #9578 Return Baseapp's trace value for logging error stack traces.
  • (cli) #9593 Check if chain-id is blank before verifying signatures in multisign and error.

Bug Fixes

  • (x/ibc) #9640 Fix IBC Transfer Ack Success event as it was initially emitting opposite value.
  • #9645 Use correct Prometheus format for metric labels.
  • #9299 Fix [appd] keys parse cosmos1... freezing.
  • (keyring) #9563 fix keyring kwallet backend when using with an empty wallet.
Assets 2
Pre-release
Pre-release

@ryanchristo ryanchristo released this Jun 25, 2021

Cosmos SDK v0.43.0-RC0 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.
  • 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.

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. Whan 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.
  • cosmos.upgrade.v1beta1.Plan#upgraded_client_state is deprecated as IBC logic has been moved to the IBC repo. If this field is set, the node will error.

The SDK team is planning to document Protobuf change process using an ADR. It will be a guideline for all chain developers, follow #9477 for more info.

Assets 2