Update Rollback Mechanism

The idea is to design the network to cache the previous network code state after a network wide update. If for some reason it were decided that the new upgrade is not favored, vault operators with a certain level of voting rights could choose to revert back to the previous state. If enough vaults (60%) queue the rollback, the network restores the previous state. Very rough idea but could act as a safety net in case of buggy updates or malicious code integration. Making this rollback mechanism read-only/protected could prevent an attacker from removing this safe guard. Thoughts?


Data chains makes this possible but how will the rollback be triggered?

1 Like

Rough (as I am working on another part right now) idea is that

  1. A node downloads an update.
  2. Runs the update in parallel to itself
  3. Ensure at least the new nodes age grows as it should (as it relocates etc.) and still earns safecoin (albeit at a smaller but measurable rate).
  4. When node is happy with update it cut’s over to it. (random time, possibly based on a % of age)

The nodes must all have the wire format formalised with a version number though. Each node should be able to communicate with current version and current-1 version. This is where having managed connections helps a lot as the connection can agree the version to use between two nodes.

Taking this further (well past launch) I would like to see the network self QA itself and not accept updates that degrade it and perhaps even provide security guarantees against backdoors as much as possible.