You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For less user facing testnets that use versions of the app that we don't want to (yet!) provide guarantees for maintaining certain features, we often upgrade via a reset height hardfork. This typically involves copying over the balances from the first chain into a new genesis, along with optionally copying over any other state that we want, such as the validator set and delegations.
One easy and consistent way to do this is to initialize a new blank genesis, then arbitrarily read the bank module's balances and push them to the new genesis by creating a creating a new genesis account. After that is completed, then we must arbitrarily query the delegations, and add the amount of funds delegated to the user's balances from the first step.
This results in a hardforked genesis file that is flexible and ready for an arbitrary version upgrade without the need to worry about further version proprietary version upgrades. From this step, we can also add genesis validators as needed to start up the new hardforked chain.
We should create the above described logic in a sub command.
The text was updated successfully, but these errors were encountered:
For less user facing testnets that use versions of the app that we don't want to (yet!) provide guarantees for maintaining certain features, we often upgrade via a reset height hardfork. This typically involves copying over the balances from the first chain into a new genesis, along with optionally copying over any other state that we want, such as the validator set and delegations.
One easy and consistent way to do this is to initialize a new blank genesis, then arbitrarily read the bank module's balances and push them to the new genesis by creating a creating a new genesis account. After that is completed, then we must arbitrarily query the delegations, and add the amount of funds delegated to the user's balances from the first step.
This results in a hardforked genesis file that is flexible and ready for an arbitrary version upgrade without the need to worry about further version proprietary version upgrades. From this step, we can also add genesis validators as needed to start up the new hardforked chain.
We should create the above described logic in a sub command.
The text was updated successfully, but these errors were encountered: