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
Software upgrade is the process of upgrading the node software version in the middle of the execution of the blockchain. In Cosmos SDK chains, this is achieved via a software upgrade governance proposal: one submits a proposal suggesting that the chain upgrades to a given version at a given height. If the proposal has passed, then upon this given height, the chain will halt. Only after the supermajority of validators have restarted with the given version, the chain will resume execution.
The upgrade can be breaking in the sense that the new DB schema is not compatible with the old one, e.g., a module is added/removed, DB schema has changed, etc.. In this case, the developer needs to write a migration function defining how the state under the old schema can be applied to the new schema. The migration function is versatile in the sense that one can manipulate state at wish.
As an example, Osmosis defines such callback function for all software upgrades, and this one tops up OSMO tokens to a number of accounts given here. Agoric has something similar here.
Tasks
This issue defines the task on adding software upgrade support to Babylon. We take Osmosis as the reference implementation. This includes a set of steps:
SebastianElvis
changed the title
gov: software upgrade governance proposal support
feat(gov): software upgrade governance proposal support
Jul 10, 2024
Overview
Software upgrade is the process of upgrading the node software version in the middle of the execution of the blockchain. In Cosmos SDK chains, this is achieved via a software upgrade governance proposal: one submits a proposal suggesting that the chain upgrades to a given version at a given height. If the proposal has passed, then upon this given height, the chain will halt. Only after the supermajority of validators have restarted with the given version, the chain will resume execution.
The upgrade can be breaking in the sense that the new DB schema is not compatible with the old one, e.g., a module is added/removed, DB schema has changed, etc.. In this case, the developer needs to write a migration function defining how the state under the old schema can be applied to the new schema. The migration function is versatile in the sense that one can manipulate state at wish.
As an example, Osmosis defines such callback function for all software upgrades, and this one tops up OSMO tokens to a number of accounts given here. Agoric has something similar here.
Tasks
This issue defines the task on adding software upgrade support to Babylon. We take Osmosis as the reference implementation. This includes a set of steps:
PreBlocker
for upgrade module #707The text was updated successfully, but these errors were encountered: