In the light of Ethereum being in danger of network split because validators failed to upgrade the software, I suggest we consider adding command line arguments --auto-update-source and --auto-update-fingerprint to the node that would make the node automatically download and restart the new release from the source (e.g. a github repo) if it is signed with the specified pgp key. WDYT?
1 Like
I know that some validators have their own processes to verify and upgrade their nodes, which means they do not want something like auto-upgrade. That said, I believe this may be helpful for other validators. @janewang could you talk to validators and collect some more data on this?
4 Likes
Sure, happy to ask the validators. My understanding of the geth issue is that Ethereum network has multiple different clients: https://www.ethernodes.org/, and the geth client bug caused the network split. Unlike them, we have one client at the moment, and the network upgrades when 80% of the clients switch to the new version. So it is less likely we may be caught in this type of network split.
1 Like
Is it possible to introduce slashing for validators that have not been updated for a long time?
Optional auto-update argument is totally fine for me!
2 Likes
I have a mixed feeling about this one.
On one side validators need to act independently.
Auto-update could be a double edge sword - if mechanism is hijacked - it could be used to bring down all validator nodes at the same time by introducing a breaking upgrade to the node.
I think we should still leave responsibility of upgrade on node operators while at the same time enabling autokick for outdated nodes which do not upgrade for a given period of time.
3 Likes
We already have measures in place to limit this type of situation. In the event of a protocol upgrade validators will be kicked if they do not upgrade within two epochs. Any other upgrade not resulting in a protocol update would mean that they are still in a known good state.
I like the idea of this as an optional flag. However, this would need to include a build process as it is not recommended to use NEARUp on MainNet.
Finally, some professional validators have auditing and security measures in place that would not make this type of forced upgrade agreeable.
3 Likes
IMO this should at best be optional. The situation with Ethereum is very different:
A) There are thousands of Ethereum miner operators (dilution of responsibility)
B) Geth frequently issues updates, and most are in NEARspeak code YELLOW or GREEN. The code RED updates are few and far between. Operators can become desensitized to it.
C) This latest update was launched without fanfare, as standard Geth updates are launched, with only one difference. They announced there would be a security upgrade coming up on the 24th regarding an undisclosed vulnerability (and potentially undiscovered by any other than the Geth team, though this is the naive assumption). Node operators that are more conservative waited to see whether the new version had any issues before upgrading (benefit of doubt assumption, they were on top of it but cautious). Before anyone could blink, the vulnerability got exploited. This situation would be a code RED on NEAR, or at least YELLOW.
In summary, the situation is very different. The only other chain we’ve encountered with auto upgrading was Harmony, but I noticed the more professional operators didn’t use the auto upgrade feature (Harmony has this “anyone can be a validator” mentality)
3 Likes
We (LunaNova) would not be in favour of such a mechanism as it starts to introduce more centralization. In our opinion, ensuring the node is running the latest software is one of the key things validators are being paid to do through their validation fees. In order for the network to be truly decentralized it is critical that validators go through the process of verifying and implementing software updates independently.
We would be open to introducing slashing for validators that do not update within a specified time frame if it is felt that the auto-kick within 2 epochs for protocol upgrades is not sufficient to motivate validators to keep up with software update notifications.
1 Like