We propose to modify the HCU process for deploying small fixes (mainly security fixes) which provides 2 benefits:
Network upgrade can be performed with 0 downtime
Requires less coordination with node operators (node operators can roll out new version update at the time that suits them, within agreed time period)
Solution
We will create new build with new functionality behind a feature flag, using HCU version beacon. This feature flag can be toggled by the existing HCU Tx. This way the new version can be rolled-out with no change in node SW behaviour and the behaviour changes only after the nodes on the new version receive the version beacon event.
If a node operator does not upgrade to new version before the new version beacon is set via Tx, their node will stop as is the case with the existing HCU process.
After the node SW is switched to new version and feature flag is enabled via the version beacon Tx, the feature flag an be removed from the code.
### Tasks
- [ ] Expose the version beacon semver from FVM to Cadence runtime
- [ ] After the new process is tested, write ops guide on how to use the new mechanism for future releases
Why
We propose to modify the HCU process for deploying small fixes (mainly security fixes) which provides 2 benefits:
Solution
We will create new build with new functionality behind a feature flag, using HCU version beacon. This feature flag can be toggled by the existing HCU Tx. This way the new version can be rolled-out with no change in node SW behaviour and the behaviour changes only after the nodes on the new version receive the version beacon event. If a node operator does not upgrade to new version before the new version beacon is set via Tx, their node will stop as is the case with the existing HCU process.
After the node SW is switched to new version and feature flag is enabled via the version beacon Tx, the feature flag an be removed from the code.