Dump state and restart

[ebuchman]

We need a way to dump state to a neutral format that can be included in a genesis.json so we can do upgrades where we throw away history

[ethanfrey]

Yup, I think there was some attempt in tooling for merkleeyes for a generic restart tooling. Or should this be basecoin-specific stuff?

[cwgoes]

Is "upgrades where we throw away history" a desired capability at launch? What's an example of an upgrade that would require this - a serialization format upgrade where the store needs to be rewritten?

[cwgoes]

Relevant - #758 - if we implement a simple "dump store state to JSON", should solve both.

[ethanfrey]

Sure. Usecase was constant breaking testnets where we kept throwing away history. It would have been nice to easily transfer the balances on an upgrade.

Maybe this is unnecessary now. But if people ask some way to do this, it would be nice to give some path. JSON dump is nice...

[ebuchman]

Yes if there are changes in execution logic but you have a latest state you want to preserve, ideally we can dump this to json, and use it in the genesi json of a new chain

[cwgoes]

If our goal is to allow restarting from a new genesis.json, retaining state, one way to do this would be to have modules specify a WriteGenesis function - the reverse of InitGenesis, reading the store and writing all module state to JSON, such that InitGenesis . WriteGenesis = id.

Besides the utility in easily making large changes (serialization format) and restarting the chain while retaining state, this is also a convenient debugging/analysis tool in general: JSON from gaiacli export MODULE could easily be piped into data analysis software.

It does, however, require that all modules can enumerate over all state (e.g. accounts).

Example implementation of a WriteGenesis function: 6526652

[cwgoes]

Additionally, applications using the SDK, including gaia, can implement an dump command which calls WriteGenesis for all modules used by the application.

[cwgoes]

Example export-stake command added in 00d1b15 - works, but the architecture to pass a keeper to a CLI command is a bit clumsy.