26 Jul 14:50

a114313

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.

As an app developer, some API changes from v1beta1 to v1 are to be expected in the x/gov Keeper, and are documented in the UPGRADING.md guide.

Baseapp PostHandlers

A transaction's lifecycle in the SDK goes through BaseApp's CheckTx and DeliverTx, and both of them run the AnteHandlers; then, DeliverTx also runs the sdk.Msgs execution (in BaseApp's runMsgs function).

In v0.46, we added "PostHandlers" to the SDK. PostHandlers are like AnteHandlers (they have the same signature), but they are run after runMsgs. One use case for PostHandlers is transaction tips (see below), but other use cases like unused gas refund can also be enabled by PostHandlers.

Please note that the PostHandlers run in the same store branch as runMsgs. This means that if the PostHandlers fail, then all the state from runMsgs will also be reverted. As a reminder, the AnteHandlers run in a separate store branch before runMsgs. This means that the v0.46 SDK currently creates 2 store branches when running transactions:

one for AnteHandlers,
one for runMsgs and PostHandlers.

Transaction Tips and `SIGN_MODE_DIRECT_AUX`

Transaction tips are a mechanism to pay for transaction fees using another denom than the native fee denom of the chain.

The transaction initiator signs a partial transaction (called AuxSignerData) without specifying fees, but uses a new Tip field. They send this AuxSignerData to a fee relayer who will choose the transaction fees and broadcast the final transaction, and the SDK provides a mechanism that will transfer the pre-defined Tip to the fee payer, to cover for fees. A market between tippers and feepayers could arise, based on exchange rates between the tip denom and the fee denom.

For this mechanism to work, the SDK introduces a new sign mode, SIGN_MODE_DIRECT_AUX, whereby the signer signs over the transaction body and their own signer info, but not over fees or other signers' info. This sign mode is not limited to transaction tips though, and can be used in any multi-signer transaction, where N-1 signers sign using SIGN_MODE_DIRECT_AUX, and only one signer, the fee payer, signs using SIGN_MODE_DIRECT, allowing for a better UX for the N-1 other signers.

The transaction tips decorator is NOT enabled by default on the SDK. If you want to include transaction tips on your chain, please enable setPosthandler in your app.go and include the tips decorator inside: see simapp/app.go for a template.

Assets 2

26 Jul 15:46

github-actions

cosmovisor/v1.2.0

fed3ce6

Cosmovisor v1.2.0

Release Notes

New Features

With the cosmovisor init command, all the necessary folders for using cosmovisor are automatically created. You do not need to manually symlink the chain binary anymore.

We've added a new configuration option: DAEMON_RESTART_DELAY (as env variable). When set, Cosmovisor will wait that delay between the node halt and backup. See the README file for more details.

Bug Fixes

Fix Cosmovisor binary usage for pre-upgrade. Cosmovisor was using the wrong binary when running a pre-upgrade command.

Changelog

For more details, please see the CHANGELOG.

Assets 9

18 Jul 11:21

amaury1093

v0.46.0-rc3

db2949e

v0.46.0-rc3 Pre-release

Pre-release

Features

(telemetry) #12405 Add query calls metric to telemetry.

Improvements

#12589 Allow zero gas in simulation mode.
#12453 Add NewInMemoryWithKeyring function which allows the creation of in memory keystore instances with a specified set of existing items.
#11390 LatestBlockResponse & BlockByHeightResponse types' Block filed has been deprecated and they now contains new field sdk_block with proposer_address as string

CLI Breaking Changes

(x/group) #12551 read the decision policy from disk in group CLI commands.

Bug Fixes

(testutil/sims) #12374 fix the non-determinstic behavior in simulations caused by GenSignedMockTx and check empty coins slice before it is used to create banktype.MsgSend.
#12448 Start telemetry independently from the API server.
#12509 Fix Register{Tx,Tendermint}Service not being called, resulting in some endpoints like the Simulate endpoint not working.

Assets 2

05 Jul 14:05

alexanderbez

v0.46.0-rc2

0d4fd41

v0.46.0-rc2 Pre-release

Pre-release

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.

Improvements

(deps) Downgrade to Tendermint v0.34.20-rc0.
#12089 Mark the TipDecorator as beta, don't include it in simapp by default.
#12153 Add a new NewSimulationManagerFromAppModules constructor, to simplify simulation wiring.

Bug Fixes

#12416 Prevent zero gas transactions in the DeductFeeDecorator AnteHandler decorator.
(x/mint) #12384 Ensure GoalBonded must be positive when performing x/mint parameter validation.
(x/auth) #12261 Deprecate pagination in GetTxsEventRequest/Response in favor of page and limit to align with tendermint SignClient.TxSearch
(vesting) #12190 Replace #12190 to use NewBaseAccountWithAddress in all vesting account message handlers.
(linting) #12135 Fix variable naming issues per enabled linters. Run gofumpt to ensure easy reviews of ongoing linting work.
(linting) #12132 Change sdk.Int to math.Int, run gofumpt -w -l ., and golangci-lint run ./... --fix
(cli) #12127 Fix the CLI not always taking into account --fee-payer and --fee-granter flags.
(migrations) #12028 Fix v0.45->v0.46 in-place store migrations.
(baseapp) #12089 Include antehandler and runMsgs events in SimulateTx.
(cli) #12095 Fix running a tx with --dry-run returns an error
(x/auth) #12108 Fix GetBlockWithTxs error when querying block with 0 tx
(genutil) #12140 Fix staking's genesis JSON migrate in the simd migrate v0.46 CLI command.
(types) #12154 Add baseAccountGetter to avoid invalid account error when create vesting account.
(x/crisis) #12208 Fix progress index of crisis invariant assertion logs.
(types) #12229 Increase sdk.Dec maxApproxRootIterations to 300

Assets 2

28 Jun 21:09

github-actions

v0.45.6

f2d9444

v0.45.6

Cosmos SDK v0.45.6 Release Notes

This release introduces a few bug fixes and improvements.
Notably, it fixes GetLastCompleteUpgrade in x/upgrade to properly return the latest upgrade.

See the Cosmos SDK v0.45.6 Changelog for the exhaustive list of all changes.

Full Commit History: v0.45.5...v0.45.6

Assets 2

09 Jun 21:01

github-actions

v0.45.5

a2761bd

v0.45.5

Cosmos SDK v0.45.5 Release Notes

This release introduces a few bug fixes and improvements. Notably, it removes
the redacted error message, fixes a few bugs in the types package, and
indexing of events for failed txs.

See the Cosmos SDK v0.45.5 Changelog
for the exhaustive list of all changes.

Full Commit History: v0.45.4...v0.45.5

Assets 2

23 May 18:38

amaury1093

v0.46.0-rc1

3a7eac6

v0.46.0-rc1 Pre-release

Pre-release

Cosmos SDK v0.46.0 Release Candidate 1 - 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.

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.

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.

`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;
}

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

As an app developer, some API changes from v1beta1 to v1 are to be expected in the x/gov Keeper, and are documented in the UPGRADING.md guide.

Baseapp PostHandlers

one for AnteHandlers,
one for runMsgs and PostHandlers.

Transaction Tips and `SIGN_MODE_DIRECT_AUX`

Transaction tips are a mechanism to pay for transaction fees using another denom than the native fee denom of the chain.

Assets 2

25 Apr 15:38

github-actions

v0.45.4

ad9e562

v0.45.4

Cosmos SDK v0.45.4 Release Notes

This release introduces a few bug fixes and improvements. Notably, it adds an
error check to the NewNode call in the server package, which would allow nodes
to sync correctly.

See the Cosmos SDK v0.45.4 Changelog for the exhaustive list of all changes.

Full Commit History: v0.45.3...v0.45.4

Assets 2

12 Apr 10:46

github-actions

v0.45.3

c2fd51b

v0.45.3

Cosmos SDK v0.45.3 Release Notes

This release introduces a Tendermint dependency update to v0.34.19 which
itself includes two bug fixes related to consensus. See the full changelog from
v0.34.17-v0.34.19 here.

In addition, it includes a change to ScheduleUpgrade to allow upgrades without
requiring a governance proposal process.

See the Cosmos SDK v0.45.3 Changelog for the exhaustive list of all changes.

Full Commit History: v0.45.2...v0.45.3

Assets 2

12 Apr 10:43

github-actions

v0.44.8

d004391

v0.44.8

Cosmos SDK v0.44.8 Release Notes

This release introduces only a Tendermint dependency update to v0.34.19 which
itself includes two bug fixes related to consensus. See the full changelog from
v0.34.17-v0.34.19 here.

See the Cosmos SDK v0.44.8 Changelog for the exhaustive list of all changes.

Full Changelog: v0.44.7...v0.44.8

Assets 2

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Cosmos SDK v0.46.0 Release Notes

New Module: `x/group`

`Msg`-based Gov Proposals

Baseapp PostHandlers

Transaction Tips and `SIGN_MODE_DIRECT_AUX`