Genesis port script for 0.36

[fedekunze]

Summary

Write genesis port script for v0.34.0 release.

Ref 0.34 script: #4023

Add TODO script changes below:
cc: @alexanderbez @rigelrozanski @alessio @cwgoes @jackzampolin @sabau

• Supply: x/supply genesis and add FeeCollector account from keeper, delete gov addresses for burning and deposits
• flatten gov genesis state deposits and votes (See changes here)

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[alexanderbez]

The only changes are going to be anything that happens in the supply module PR and possibly somethings that happened in the parameter store/governance PR.

[aaronc]

As some of you know, Regen Network has been planning to do a test of our live upgrade module #4233 in our current testnet. If possible, I would like to do this as an upgrade to 0.36 and have been waiting for 0.36 to get released before coordinating the upgrade. If it's at all possible to write this genesis port script in such a way that it could rewrite the state for a live chain, I think that would be a great test of the upgrade functionality, and could potentially pave the way for doing a live upgrade of Cosmos Hub the next time around.

@sabau I see that you are working on these scripts and we chatted briefly about this in Berlin. How feasible do you think it would be for us to do this? Basically we would create an upgrade handler in a new binary which when the new binary starts up would call the necessary port scripts and rewrite state either partially or entirely if needed.

[alexanderbez]

@aaronc it would be fanastic if we could combine efforts here.

Indeed the original intent of this PR was to have the ability to support exported state migrations from one version to the next. The process is intended to be:

• Manually (or automatically via halt-height config ) halt the node
• Upgrade the binary
• Export state & run this migration command (v0.34 => v0.36)
• Restart binary with new genesis

That being said, maybe we can take the work you've done in #4233 and update the upgrade plan handler to live upgrade state reducing the error surface and the manual burden on node operators.

To accomplish that, and I'm just spitballing here, we could iterate over each module that needs upgrading, then for each module, iterate over each record that needs to migrate, then for each record remove it from state and reinsert the migrated record back into state.

What do you think?

/cc @rigelrozanski @ebuchman @jaekwon

[aaronc]

To accomplish that, and I'm just spitballing here, we could iterate over each module that needs upgrading, then for each module, iterate over each record that needs to migrate, then for each record remove it from state and reinsert the migrated record back into state.

What do you think?

That's exactly what I'm thinking. Seems like the groundwork for it exists in #4471 with legacy types moved to a separate package.

[alexanderbez]

Yes @aaronc, the current #4471 PR will have to be amended slightly, but it is doable. I don't want to block work on that PR, so if possible I'd like to see a follow up PR that instead of exporting new Genesis state, takes a keeper and does the migration. Should be very simple. Do you think you can do this?

[aaronc]

Yes @aaronc, the current #4471 PR will have to be amended slightly, but it is doable. I don't want to block work on that PR, so if possible I'd like to see a follow up PR that instead of exporting new Genesis state, takes a keeper and does the migration. Should be very simple. Do you think you can do this?

@alexanderbez I'll take a look on Monday when I'm back on. Should be doable. Looks like there are a few other genesis scripts for 0.36 that I'll have to take a look at too.