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?
4 Likes
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
- A node downloads an update.
- Runs the update in parallel to itself
- 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).
- 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.
15 Likes