v0.39.0 Launchpad
Cosmos SDK v0.39.0 Release Notes
This is the inaugural release of the Cosmos SDK 0.39 «Launchpad» release series.
See the CHANGELOG.md file or the Cosmos SDK 0.39.0 milestone on our issue tracker for details.
Changes to IAVL and store pruning
The pruning features introduced in the `0.38` release series are buggy and might lead to data loss,
even after upgrading to `v0.39.0`. When upgrading from `0.38` it is important to follow the instructions
below, to prevent data loss and database corruption.
Note: there are are several breaking changes with regard to IAVL, stores, and pruning settings that affect command line clients, server configuration, and Golang API.
Migrate an application from 0.38.5 to 0.39.0
The IAVL's `v0.13.0` release introduced a pruning functionality that turned out to be buggy and flawed.
IAVL's new `v0.14.0` release now commits and flushes every state to disk as it did in pre-`v0.13.0` release.
The SDK's multi-store will track and ensure the proper heights are pruned. The operator can now set the pruning
options by passing a `pruning` configuration via command line option or `app.toml`. The `pruning` flag supports the following
options: `default`, `everything`, `nothing`, `custom` - see docs for further details. If the operator chooses `custom`, they
may want to provide either of the granular pruning values:
• `pruning-keep-recent`
• `pruning-keep-every`
• `pruning-interval`
The former two options dictate how many recent versions are kept on disk and the offset of what versions are kept after that
respectively, and the latter defines the height interval in which versions are deleted in a batch. Note: there are are some
client application breaking changes with regard to IAVL, stores, and pruning settings. An example patch follows:
``` From 5884171ba73c3054e98564c39adc9cbbab8d4646 Mon Sep 17 00:00:00 2001 From: Alessio Treglia <[email protected]> Date: Tue, 14 Jul 2020 14:54:19 +0100 Subject: [PATCH 2/4] use new pruning options
--- cmd/cnd/main.go | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/cmd/cnd/main.go b/cmd/cnd/main.go index b0c86f4a..4a3a8518 100644 --- a/cmd/cnd/main.go +++ b/cmd/cnd/main.go @@ -23,7 +23,6 @@ import ( comgenutilcli "github.com/commercionetwork/commercionetwork/x/genutil/client/cli" "github.com/cosmos/cosmos-sdk/baseapp" "github.com/cosmos/cosmos-sdk/server" - "github.com/cosmos/cosmos-sdk/store" genutilcli "github.com/cosmos/cosmos-sdk/x/genutil/client/cli" "github.com/cosmos/cosmos-sdk/x/staking" ) @@ -87,9 +86,14 @@ func main() { } func newApp(logger log.Logger, db dbm.DB, traceStore io.Writer) abci.Application { + pruningOpts, err := server.GetPruningOptionsFromFlags() + if err != nil { + panic(err) + } + return app.NewCommercioNetworkApp( logger, db, traceStore, true, invCheckPeriod, - baseapp.SetPruning(store.NewPruningOptionsFromString(viper.GetString("pruning"))), + baseapp.SetPruning(pruningOpts), baseapp.SetMinGasPrices(viper.GetString(server.FlagMinGasPrices)), baseapp.SetHaltHeight(uint64(viper.GetInt(server.FlagHaltHeight))), ) ```
Migrate a node from 0.38.5 to 0.39.0
Note: do not modify pruning settings with any release prior to `v0.39.0` as that may cause data corruption .
The following instructions assume that **pruning settings have not been modified since the node started using 0.38.x. Note: the default pruning setting `syncable` used `KeepEvery:100`.
Chain Hard Fork (also know as The Tested Upgrade Path)
This strategy entails performing a hard fork of your chain.
It takes time, coordination and a few technical steps that the validators of the network must follow. Note: a software upgrade guide for `gaia`, the application that powers the Cosmos Hub, is available too . It contains detailed instructions on how to upgrade network nodes that apply to the vast majority of Cosmos SDK applications.
In preparation of the upgrade, you need to export the current state. This operation should be be performed on one node:
• Stop the node and export the current state, e.g.: `appd export --for-zero-height > export_genesis.json`.
• Manually replace the chain id and genesis time fields in `export_genesis.json` with the values that the network had agreed upon.
Follow these steps to perform the upgrade:
• Make a backup copy of the old `genesis.json` file in your server application's config directory (e.g. `$HOME/.appd/config/genesis.json`) and replace it with `export_genesis.json`. Note: do rename `export_genesis.json` to `genesis.json`.
• Replace the old binary with the new one and restart the service using the new binary.
Alternative strategies
Alternatively, you can follow one of the following strategies:
• Replace the application server's binary and perform a full sync of the node from scratch.
• If your node had started with using `KeepEvery:1` (e.g. pruning settings `nothing` or `everything`), upgrading to `v0.39.0` should be simple and safe.
• Do halt block processing with `--halt-height` after committing a height divisible by `KeepEvery` - e.g. at block 147600 with `KeepEvery:100`. The node must never have processed a height beyond that at any time in its past . Upgrading to `v0.39.0` is then safe.
• Set the `KeepEvery` setting to the same as the previous `KeepEvery` setting (both `<=v0.38.5` and `v0.39.0` default to `KeepEvery:100`). Upgrade to `v0.39.0` is then safe as long as you wait one `KeepEvery` interval plus one `KeepRecent` interval plus one pruning `Interval` before changing pruning settings or deleting the last `<=v0.38.5` height (so wait 210 heights with the default configuration).
• Otherwise, make sure the last version persisted with `<=v0.38.5` is never deleted after upgrading to `v0.39.0`, as doing so may cause data loss and data corruption.
Regression in the signature verification when multiple transactions in the same block are sent from the same account
When multiple transactions in the same block are sent (and correctly signed) by the same account, chances are that some of them could be rejected and the error `unauthorized: signature verification failed` would be returned due to the account's sequence ( nonce ) getting stuck and not being incremented by the ante handler. This behaviour was a regression introduced in the `v0.38` release series, it did not occur in the `v0.37` release series and is now fixed in this release.
Changes to ABCI Query's "app/simulate" path
The `app/simulate` query path is used to simulate the execution transactions in order to obtain an estimate
of the gas consumption that would be required to actually execute them. The response used to return only
the amount of gas, it now returns the result of the transaction as well.
bank.send event comes with sender information
The `bank.send` event used to carry only the recipient and amount. It was assumed that the sender of the funds was `message.sender`.
This is often not true when a module call the bank keeper directly. This may be due to staking distribution, or via a cosmwasm contract that released funds (where I discovered the issue).
`bank.send` now contains the entire triple `(sender, recipient, amount)`.
trace option is no longer ignored
The `--trace` option is reintroduced. It comes in very handy for debugging as it causes the full stack trace to be included in the ABCI error logs.
appcli keys parse command didn't honor client application's bech32 prefixes
The `key parse` command ignored the application-specific address bech32
prefixes and used to return `cosmos*1`-prefixed addresses regardless
of the client application's configuration.