mirror of
https://github.com/0glabs/0g-chain.git
synced 2024-11-14 03:55:19 +00:00
4a8b5696cb
* initial sketch * add module migrations * add migrations for all accout types * test account migration * add tendermint migration and migrate cmd * remove need for errors pkg dependency * add bech32 decoding fork * add suggested params and cmd to write them * add basic upgrade instructions * fix tests * address some migration todos * tidy contrib folder * finalize params values * align cdp init genesis with other modules * add tendermint and distribution test add custom distribution migration to patch bug * add staking migration test * add slashing, evidence tests, refactor auth tests * add full migration test * remove go-amino dependency from go.mod also tidy up unused indirect dependencies * address remaining TODOs * remove commented out code from legacy types * add spot/liquidation markets ids to kava-3 params * Apply suggestions from code review Co-authored-by: Alexander Bezobchuk <alexanderbez@users.noreply.github.com> Co-authored-by: Federico Kunze <31522760+fedekunze@users.noreply.github.com> * address code review suggestions * add validate genesis to migrate test * refactor add params func * remove commented out code from old types * fix add params * add deputy address * add tests using exported kava-2 state * incorporate new cdp params from master * update params from review Co-authored-by: Kevin Davis <karzak@users.noreply.github.com> * add deputy account * add committee permissions for new params Co-authored-by: Alexander Bezobchuk <alexanderbez@users.noreply.github.com> Co-authored-by: Federico Kunze <31522760+fedekunze@users.noreply.github.com> Co-authored-by: Kevin Davis <karzak@users.noreply.github.com>
41 lines
2.0 KiB
Go
41 lines
2.0 KiB
Go
/*
|
|
Migrate handles translating the state of the blockchain between software versions.
|
|
|
|
For example, as modules are changed over time the structure of the data they store changes. The data structure must be
|
|
migrated to the new structure of the newer versions.
|
|
|
|
There are two types of migration:
|
|
- **genesis migration** a script converts an exported genesis file from the old software to a new genesis file for the new software
|
|
- **live upgrade** a handler in the upgrade module converts data in the database itself from the old version to the new
|
|
|
|
Genesis migration starts a whole new blockchain (with new chain-id) for the new software version.
|
|
Live upgrade keeps the blockchain (and chain-id) the same for the new software version.
|
|
|
|
We only support migrations between mainnet kava releases.
|
|
We only support migrations from the previous mainnet kava version to the current. We don't support migrating between two old versions, use the old software version for this.
|
|
We only support migrations from old to new versions, not the other way around.
|
|
|
|
Genesis Migration
|
|
The process is:
|
|
- unmarshal the current genesis file into the old `GenesisState` type that has been copied into a `legacy` folder (ideally using the old codec version)
|
|
- convert that `GenesisState` to the current `GenesisState` type
|
|
- marshal it to json (using current codec)
|
|
|
|
On each release we can delete the previous releases migration and old GenesisState type.
|
|
eg kava-3 migrates `auth.GenesisState` from kava-2 to `auth.GenesisState` from kava-3,
|
|
but for kava-4 we don't need to keep around kava-2's `auth.GenesisState` type.
|
|
|
|
This folder contains old types from several sdk modules because they needed custom migrations for kava-3.
|
|
The sdk version for kava-2 was a master commit 18de63.
|
|
|
|
Live Upgrade
|
|
The process is:
|
|
- submit upgrade proposal on old chain
|
|
- old chain halts
|
|
- people download new version and restart their validators
|
|
- on start the new upgrade handler runs
|
|
- use copypasted old keeper and types to read from db, convert to current types and write with current keeper
|
|
|
|
*/
|
|
package migrate
|