Hard Fork Upgrades
The have to wait throughout the entire voting period is one of the major drawbacks of the standard upgrade approach via governance. It is inappropriate for automated updates that include security vulnerability patches or other crucial components due to this time.
To create a Hard Fork technique is to use governance as a quicker substitute. By automatically implementing the modifications from an upgrade plan, it is possible to execute them at a specific block height without having to first prepare a governance proposal.
The following is the high-level plan for organizing an upgrade:
- A private branch with breaking changes has the vulnerability patched.
- A new patch release (for example
v1.0.0tov1.0.1) that executes an upgrade to the following breaking version (for examplev2.0.0) at a predetermined block height must be created. - Validators update their nodes to the latest patch release (for example
v1.0.1). It's critical that enough validators update to the patch release to account for at least 2/3 of the total validator voting power in order to effectively complete the hard fork. - The new major release (for example
v2.0.0) that includes the vulnerability fix is published one hour prior to the upgrade time (equivalent to the upgrade block height).
WARNING: Because validators require a buffer period of time to download the release binaries and update their cosmovisor settings, the release must be generated with a 1-hour anticipation.