cosmos-sdk/x/upgrade/spec
technicallyty e3a0148bf6
x/upgrade: protocol version tracking (#8897)
* -added consensus version tracking to x/upgrade

* -added interface to module manager -added e2e test for migrations using consensus version store in x/upgrade -cleaned up x/upgrade Keeper -handler in apply upgrade now handles errors and setting consensus versions -cleaned up migration map keys -removed init chainer method -simapp now implements GetConsensusVersions to assist with testing

* protocol version p1

* add protocol version to baseapp

* rebase against master

* add test

* added test case

* cleanup

* docs and change to bigendian

* changelog

* cleanup keeper

* swap appVersion and version

* cleanup

* change interface id

* update keeper field name to versionSetter

* reorder keys and docs

* -move interface into exported folder

* typo

* typo2

* docs on keeper fields

* docs for upgrade NewKeeper

* cleanup

* NewKeeper docs

Co-authored-by: technicallyty <48813565+tytech3@users.noreply.github.com>
Co-authored-by: Alessio Treglia <alessio@tendermint.com>
2021-04-02 07:11:58 -07:00
..
01_concepts.md x/upgrade: added consensus version tracking (part of ADR-041) (#8743) 2021-03-19 22:01:29 +00:00
02_state.md x/upgrade: protocol version tracking (#8897) 2021-04-02 07:11:58 -07:00
03_events.md Docs: hide frontmatter, bugfixes (#5413) 2019-12-17 08:44:44 -03:00
README.md x/upgrade: remove support for time based upgrades (#8849) 2021-03-14 01:03:01 +00:00

README.md

upgrade

Abstract

x/upgrade is an implementation of a Cosmos SDK module that facilitates smoothly upgrading a live Cosmos chain to a new (breaking) software version. It accomplishes this by providing a BeginBlocker hook that prevents the blockchain state machine from proceeding once a pre-defined upgrade block height has been reached.

The module does not prescribe anything regarding how governance decides to do an upgrade, but just the mechanism for coordinating the upgrade safely. Without software support for upgrades, upgrading a live chain is risky because all of the validators need to pause their state machines at exactly the same point in the process. If this is not done correctly, there can be state inconsistencies which are hard to recover from.

  1. Concepts
  2. State
  3. Events