2

We have a prototype of substrate-based blockchain running with few nodes.

After some time running and testing we came up with new version of code-base, which consists of the same runtime, pallets and storage items but with some naming changes for both pallet crates and their storage.

So there are few questions I am interested in:

  1. Is it possible to migrate from old code base to new one (which are basically two different repositories with different structure but with similar components) without loosing blocks history and storage data?
  2. Would forkless upgrade via uploading new WASM binary work considering it was built from different code-base?

I already checked substrate documentation 1, 2 and didn't find similar problem. There is a storage migration article but the problem discovered there is not exactly what I am looking for. It is just about adding new field to pallet storage.

I know it's possible to transfer all storage between blockchains by dumping all the storage from one and then transfering into another via genesis file configuration. But it would also be nice to store blocks history with all executed transactions.

1 Answer 1

1

End of the day, you will need to do a storage migration with your OLD network to make it compatible with your new code. And depending on what you changed, it may not be easily doable.

You cannot just create a brand new client and expect your old blocks to exist, because your new client may not be compatible to import the old blocks.

Additionally, you cannot just change your pallets and expect the old genesis to work since the genesis is dependent on the specific storage items and structures from your original chain.

If you want to work with a whole new client and a whole new codebase, restarting your genesis makes the most sense to me. You can still migrate things like user accounts and balances over to your new chain, but you should assume that all previous history is lost.

If you want to keep the history, you need to start bringing your new changes incrementally into your old client, making sure that any client breaking changes are handled, for example using client_logic_1 from block 1 to N, and using client_logic_2 for block N and on.

2
  • Thanks. I just want to notice regarding pallet changes I've mentioned previously. Most of the changes are just updated storage names and struct fields in those storages. No other storage/struct changes were done (no new storages added and no new structs created to store in those storages). There are some changes regarding extrinsics logic, which in the end operates with same storage items. But I assume that is not an issue for migration.
    – Yevhen V
    Apr 1, 2022 at 9:46
  • No, it should not be an issue. You just need to write a migration which moves the appropriate data into the appropriate places in terms of storage names or storage structures. If you can define that migration, should be no issue.
    – Shawn Tabrizi
    Apr 1, 2022 at 13:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.