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
{{ message }}
This repository was archived by the owner on Dec 26, 2023. It is now read-only.
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
The text was updated successfully, but these errors were encountered:
Requirements
Design
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 layert
.t
, an update includes a cutoff layer heights
<t
, by which sufficient support must be indicated or else the update won’t be carried out. There should be sufficient time betweens
andt
to achieve finality (so that, by the time the update trigger layert
arrives, all honest nodes are in consensus about the state of voting on the update).s
, do not trigger the protocol upgrade.--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.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
The text was updated successfully, but these errors were encountered: