My contribution is much simpler and possibly (as noted) more relevant after the Plan stage as it refers to the mechanics. Thought I'd just flag it early.
Issue:
Directly using a private key online (if not using a hardware wallet or equivalent) increases the risk that it becomes compromised. If nodes are compromised then this presents some risk to the network. The less frequently a node operator has to directly use their private key, the less risk they hold of that key and its associated staked XDC being lost.
Suggestion:
Perhaps node operators could nominate a secondary address/privatekey that would be used to vote from (instead of having to use/expose a masternode private key every time a vote is taken)
Perhaps it could be done by logging in to the masternode dApp to nominate a secondary private key/address and the voting mechanism would then look to that secondary address for the vote of that node operator.
Votes could then be done from that address/privatekey and, if neccessary, the node operator could even log in to the masternode dApp and re-nominate a different address for future votes if they thought the regular-use private key was compromised. Or even better, they could just nominate an address controlled by a hardware wallet to increase security during the voting process from the get-go).
As I mentioned, just flagging the issue early for consideration when determining the mechanics of how whatever the determined process is gets actioned.
Great discussion here.
My contribution is much simpler and possibly (as noted) more relevant after the Plan stage as it refers to the mechanics. Thought I'd just flag it early.
Issue:
Directly using a private key online (if not using a hardware wallet or equivalent) increases the risk that it becomes compromised. If nodes are compromised then this presents some risk to the network. The less frequently a node operator has to directly use their private key, the less risk they hold of that key and its associated staked XDC being lost.
Suggestion:
Perhaps node operators could nominate a secondary address/privatekey that would be used to vote from (instead of having to use/expose a masternode private key every time a vote is taken)
Perhaps it could be done by logging in to the masternode dApp to nominate a secondary private key/address and the voting mechanism would then look to that secondary address for the vote of that node operator.
Votes could then be done from that address/privatekey and, if neccessary, the node operator could even log in to the masternode dApp and re-nominate a different address for future votes if they thought the regular-use private key was compromised. Or even better, they could just nominate an address controlled by a hardware wallet to increase security during the voting process from the get-go).
As I mentioned, just flagging the issue early for consideration when determining the mechanics of how whatever the determined process is gets actioned.
Great suggestions. I completely agree.