Updates Part II: protocol updates

[lrettig]

Requirements

• Protect network integrity and security. Don't allow the network to fail, or security assumptions to be violated, after an update.
• Minimize trust assumptions required to have confidence that an update is non-malicious
• Don't take agency away from node operators or make minority forks unreasonably burdensome
• Minimize node downtime around an update
• Give clarity and transparency into which nodes are running which version of the protocol
• Subject to these constraints, make it as fast and easy as possible to update the protocol, and minimize implementation complexity

Design

• Node operator downloads and manually installs a node update that contains a protocol update, or the node software auto-downloads it (see Updates Part I: node auto-update #32). The update contains a hardcoded layer number t for activation of protocol changes. As laid out in Updates Part I: node auto-update #32, the node adds a "protocol version signature" to its blocks and/or ATXs to indicate a.) that it's received the update and b.) commits to triggering the protocol update at layer t.
• In addition to the protocol update trigger layer, t, an update includes a cutoff layer height s < t, by which sufficient support must be indicated or else the update won’t be carried out. There should be sufficient time between s and t to achieve finality (so that, by the time the update trigger layer t arrives, all honest nodes are in consensus about the state of voting on the update).
• After downloading and activating a client update, count the number of clients that have upgraded/“voted for” the change for one epoch (by spacetime committed/block weight). If the support level is not high enough by layer s, do not trigger the protocol upgrade.
• If a node detects that an update has been approved but the node software has not been upgraded, it will begin printing a countdown and warnings of an impending shutdown with instructions. Some number of layers before the update is due to trigger, the node will panic and exit and print instructions again. The node operator may choose to run the node with a --ignore-updates flag that will explicitly continue running the old protocol, they may restart with the --auto-updates flag enabled, or they may manually download and install an update. The printed message should contain a link to a document with a more complete explanation of how and why it works this way.
• The next release after a “triggered” upgrade can remove the vote counting logic and hardcode the protocol update as of layer t—this is equivalent to a checkpoint. A subsequent upgrade is likely to use the same logic to trigger a subsequent update at a later layer.

Tasks

• Finalize node software and protocol version signature format. Consider the differences among node implementation version, P2P protocol version, and core Spacemesh protocol version. See Updates Part I: node auto-update #32.
• Develop node logic that counts update/version “signature” votes and triggers a protocol update, or not, on this basis
• Finalize update params (minimum spacetime/block weight "voting" threshold, minimum time to trigger update)
• Finalize copy, order, and timing of new warning messages, and update longer doc explaining this
• Add tests for voting mechanism
• Discuss what to do in case of a failed update