Releases: osmosis-labs/cosmos-sdk
v0.45.0x-osmo-v7.7
What's Changed
- chore(deps): bump github.com/otiai10/copy from 1.6.0 to 1.7.0 by @dependabot in #88
- chore(deps): bump google.golang.org/protobuf from 1.27.1 to 1.28.0 by @dependabot in #150
- chore: delete proto-docker.yml by @alexanderbez in #164
- chore: fix + update mergify config by @alexanderbez in #165
- chore(deps): bump actions/checkout from 2 to 3 by @dependabot in #128
- chore(deps): bump github.com/spf13/cobra from 1.2.1 to 1.4.0 by @dependabot in #138
- chore(deps): bump actions/setup-go from 2.1.4 to 3 by @dependabot in #125
- chore(deps): bump github.com/prometheus/common from 0.29.0 to 0.33.0 by @dependabot in #166
- fix: Update mergify bot config by @ValarDragon in #157
- chore: update TM dep + go.mod cleanup (backport #175) by @mergify in #180
- fix: proofs query to help debug app hash (backport #176) by @mergify in #177
Full Changelog: v0.45.0x-osmo-v7.6...v0.45.0x-osmo-v7.7
v0.45.0x-osmo-v7.6
v0.45.0x-osmo-v7.5
What's Changed
- add after validator slash hook by @antstalepresh in #136
- backport feat: Modify grpc gateway to be concurrent (cosmos#11234) from cos… by @p0mvn in #137
- extra logs during commit by @p0mvn in #146
- fix logs related to store keys and commit hash by @p0mvn in #151
- refactor: snapshot and pruning functionality by @p0mvn in #140
- feat: implement querying for commit hash and proofs by @p0mvn in #156
- fix: commit info data race by @p0mvn in #155
Full Changelog: v0.45.0x-osmo-v7.3...v0.45.0x-osmo-v7.5
v0.45.0x-osmo-v7.3
v0.45.0x-osmo-v7.1
-
fix bug related to old height export in IAVL: fix bug related to old height export
-
IAVL release: v0.17.3-osmo-v4
v0.45.0x-osmo-v7.2
The main focus of this release is stability improvements with the IAVL patch of v0.44.3x-osmo-v5.1. The big points are:
- Fixes the "version X was already saved to a different hash" and "insufficient funds" bugs nodes were sometimes seeing after crashes.
- Reduce the RAM overhead during the initial IAVL migration. Node operators should still have 32GB of RAM for all of their mainnet nodes.
- Improving the log messages during migrations
The bugs people were seeing for nodes being saved to a different hash, etc. happen after restoring the node post-crash during commit (the crash could be caused by something else). The bug on restart stems from the long-standing issue that SDK commits are actually not-atomic. This manifested in a failure to flush the latest height when an error during commit occurs, causing the state invalidities on restart. We mitigated the non-atomicity problem by flushing the metadata about the stores that successfully committed a new height. As a result, on restart, the SDK now knows which stores/modules are already on the newly committed height.
This [v0.45.0x-osmo-v7.2] release is used on v7.x in Osmosis. It has identical fast-storage changes to the v0.44.3x-osmo-v5.2 (used in v6.x).
v0.44.3x-osmo-v5.2
The main focus of this release is stability improvements with the IAVL patch of v0.44.3x-osmo-v5.1. The big points are:
- Fixes the "version X was already saved to a different hash" and "insufficient funds" bugs nodes were sometimes seeing after crashes.
- Reduce the RAM overhead during the initial IAVL migration. Node operators should still have 32GB of RAM for all of their mainnet nodes.
- Improving the log messages during migrations
The bugs people were seeing for nodes being saved to a different hash, etc. happen after restoring the node post-crash during commit (the crash could be caused by something else). The bug on restart stems from the long-standing issue that SDK commits are actually not-atomic. This manifested in a failure to flush the latest height when an error during commit occurs, causing the state invalidities on restart. We mitigated the non-atomicity problem by flushing the metadata about the stores that successfully committed a new height. As a result, on restart, the SDK now knows which stores/modules are already on the newly committed height.
v0.45.0x-osmo-v7-fast.1
This is a pre-release for upgrading v0.45.0x-osmo-v7 with fast storage
v0.44.3x-osmo-v5.1 - Fast storage (IAVL upgrade)
Background
Historically IAVL has had a very slow performance during state machine execution, and for responding to queries to live state. This release speeds up these routines by an order of magnitude, alleviating large amounts of pressure from all users of the IAVL database.
Details
This release introduces an auxiliary fast storage system to IAVL, which represents a copy of the latest state much more amenable to efficient querying and iteration.
Prior to this release, all data gets & iterations suffered two significant performance drawdowns:
- Every get/iteration is forced to walk the tree structure
- Every node (including leaves) is stored on disk, with its key being a SHA256 hash of something. Leaves were
Hash(logical key)
, internal nodes were indexed by their Merkle tree inner node hash as well. This breaks data locality and makes every get that should be in RAM / CPU caches instead be a random leveldb file open.
The fast storage nodes are instead indexed by the logical key on the disk. This allows us to preserve data locality for the latest state, significantly improving iterations and queries. (Depending on the particular benchmark, between 5-30x improvements) This implementation introduces a negligible overhead for writes.
Downgrade-re-upgrade protection
We introduced a downgrade and re-upgrade protection where we guard for potential downgrades of iavl and the subsequent enablement of the fast storage again. This is done so by storing the metadata about the current version of the storage and the latest live state stored.
v0.44.3x-osmo-v5-fast.4.1
This is a pre-release to test fast iavl.
Changes since the last pre-release:
- Fixed log for upgrading to fast iavl