|
| 1 | +# Cosmos SDK v0.39.0 Release Notes |
| 2 | + |
| 3 | +This is the inaugural release of the **Cosmos SDK 0.39 «Launchpad»** release series. |
| 4 | + |
| 5 | +See the [Cosmos SDK 0.39.0 milestone](https://github.com/cosmos/cosmos-sdk/milestone/27?closed=1) on our issue tracker for details. |
| 6 | + |
| 7 | +## Changes to IAVL and store pruning |
| 8 | + |
| 9 | +The pruning features introduced in the `0.38` release series are buggy and might lead to data loss, |
| 10 | +even after upgrading to `v0.39.0`. When upgrading from `0.38` it is important to follow the instructions |
| 11 | +below, to prevent data loss and database corruption. |
| 12 | + |
| 13 | +**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.** |
| 14 | + |
| 15 | +### Migrate an application from 0.38.5 to 0.39.0 |
| 16 | + |
| 17 | +The IAVL's `v0.13.0` release introduced a pruning functionality that turned out to be buggy and flawed. |
| 18 | +IAVL's new `v0.14.0` release now commits and flushes every state to disk as it did in pre-`v0.13.0` release. |
| 19 | +The SDK's multi-store will track and ensure the proper heights are pruned. The operator can now set the pruning |
| 20 | +options by passing a `pruning` configuration via command line option or `app.toml`. The `pruning` flag supports the following |
| 21 | +options: `default`, `everything`, `nothing`, `custom` - see docs for further details. If the operator chooses `custom`, they |
| 22 | +may want to provide either of the granular pruning values: |
| 23 | +- `pruning-keep-recent` |
| 24 | +- `pruning-keep-every` |
| 25 | +- `pruning-interval` |
| 26 | + |
| 27 | +The former two options dictate how many recent versions are kept on disk and the offset of what versions are kept after that |
| 28 | +respectively, and the latter defines the height interval in which versions are deleted in a batch. **Note: there are are some |
| 29 | +client application breaking changes with regard to IAVL, stores, and pruning settings.** An example patch follows: |
| 30 | + |
| 31 | +```patch |
| 32 | +From 5884171ba73c3054e98564c39adc9cbbab8d4646 Mon Sep 17 00:00:00 2001 |
| 33 | +From: Alessio Treglia < [email protected]> |
| 34 | +Date: Tue, 14 Jul 2020 14:54:19 +0100 |
| 35 | +Subject: [PATCH 2/4] use new pruning options |
| 36 | + |
| 37 | +--- |
| 38 | + cmd/cnd/main.go | 8 ++++++-- |
| 39 | + 1 file changed, 6 insertions(+), 2 deletions(-) |
| 40 | + |
| 41 | +diff --git a/cmd/cnd/main.go b/cmd/cnd/main.go |
| 42 | +index b0c86f4a..4a3a8518 100644 |
| 43 | +--- a/cmd/cnd/main.go |
| 44 | ++++ b/cmd/cnd/main.go |
| 45 | +@@ -23,7 +23,6 @@ import ( |
| 46 | + comgenutilcli "github.com/commercionetwork/commercionetwork/x/genutil/client/cli" |
| 47 | + "github.com/cosmos/cosmos-sdk/baseapp" |
| 48 | + "github.com/cosmos/cosmos-sdk/server" |
| 49 | +- "github.com/cosmos/cosmos-sdk/store" |
| 50 | + genutilcli "github.com/cosmos/cosmos-sdk/x/genutil/client/cli" |
| 51 | + "github.com/cosmos/cosmos-sdk/x/staking" |
| 52 | + ) |
| 53 | +@@ -87,9 +86,14 @@ func main() { |
| 54 | + } |
| 55 | + |
| 56 | + func newApp(logger log.Logger, db dbm.DB, traceStore io.Writer) abci.Application { |
| 57 | ++ pruningOpts, err := server.GetPruningOptionsFromFlags() |
| 58 | ++ if err != nil { |
| 59 | ++ panic(err) |
| 60 | ++ } |
| 61 | ++ |
| 62 | + return app.NewCommercioNetworkApp( |
| 63 | + logger, db, traceStore, true, invCheckPeriod, |
| 64 | +- baseapp.SetPruning(store.NewPruningOptionsFromString(viper.GetString("pruning"))), |
| 65 | ++ baseapp.SetPruning(pruningOpts), |
| 66 | + baseapp.SetMinGasPrices(viper.GetString(server.FlagMinGasPrices)), |
| 67 | + baseapp.SetHaltHeight(uint64(viper.GetInt(server.FlagHaltHeight))), |
| 68 | + ) |
| 69 | +``` |
| 70 | + |
| 71 | +### Migrate a node from 0.38.5 to 0.39.0 |
| 72 | + |
| 73 | +Note: **do not modify pruning settings with any release prior to `v0.39.0` as that may cause data corruption**. |
| 74 | + |
| 75 | +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`. |
| 76 | + |
| 77 | +#### Chain Hard Fork (also know as The Tested Upgrade Path) |
| 78 | + |
| 79 | +This strategy entails performing a hard fork of your chain. |
| 80 | +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](https://hub.cosmos.network/master/gaia-tutorials/upgrade-node.html). It contains detailed instructions on how to upgrade network nodes that apply to the vast majority of Cosmos SDK applications. |
| 81 | + |
| 82 | +In preparation of the upgrade, you need to export the current state. This operation should be be performed on one node: |
| 83 | + |
| 84 | + * Stop the node and export the current state, e.g.: `appd export --for-zero-height > export_genesis.json`. |
| 85 | + * Manually replace the chain id and genesis time fields in `export_genesis.json` with the values that the network had agreed upon. |
| 86 | + |
| 87 | +Follow these steps to perform the upgrade: |
| 88 | + |
| 89 | +* 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`. |
| 90 | +* Replace the old binary with the new one and restart the service using the new binary. |
| 91 | + |
| 92 | +#### Alternative strategies |
| 93 | + |
| 94 | +Alternatively, you can follow *one of* the following strategies: |
| 95 | + |
| 96 | +* Replace the application server's binary and perform a full sync of the node from scratch. |
| 97 | + |
| 98 | +* 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. |
| 99 | + |
| 100 | +* 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. |
| 101 | + |
| 102 | +* 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). |
| 103 | + |
| 104 | +* 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. |
| 105 | + |
| 106 | +## Regression in the signature verification when multiple transactions in the same block are sent from the same account |
| 107 | + |
| 108 | +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](https://github.com/cosmos/cosmos-sdk/issues/6287) introduced in the `v0.38` release series, it did not occur in the `v0.37` release series and is now fixed in this release. |
| 109 | + |
| 110 | +## Changes to ABCI Query's "app/simulate" path |
| 111 | + |
| 112 | +The `app/simulate` query path is used to simulate the execution transactions in order to obtain an estimate |
| 113 | +of the gas consumption that would be required to actually execute them. The response used to return only |
| 114 | +the amount of gas, it now returns the result of the transaction as well. |
| 115 | + |
| 116 | +## bank.send event comes with sender information |
| 117 | + |
| 118 | +The `bank.send` event used to carry only the recipient and amount. It was assumed that the sender of the funds was `message.sender`. |
| 119 | +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). |
| 120 | + |
| 121 | +`bank.send` now contains the entire triple `(sender, recipient, amount)`. |
| 122 | + |
| 123 | +## trace option is no longer ignored |
| 124 | + |
| 125 | +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. |
| 126 | + |
| 127 | +## appcli keys parse command didn't honor client application's bech32 prefixes |
| 128 | + |
| 129 | +The `key parse` command ignored the application-specific address bech32 |
| 130 | +prefixes and used to return `cosmos*1`-prefixed addresses regardless |
| 131 | +of the client application's configuration. |
0 commit comments