Open bejavu opened 4 years ago
Agree something needs to be done as the software contains unencrypted info. This method seems a suitable solution but it must be easy to set up throught the UI.
This sounds like a good idea! It dose scare me currently how the password for the keystore on the hot machine is stored in plane text and that wallet currently holds all the rewards and access to the stake the validator has gained/staked. If my SSH key gets comprised or Azure gets hacked (unlikely!) It will be bye bye to everything...
Why is that needed? Why not just keep your tokens on Ledger and delegate them to the validator address?
FIP5 sets up the idea of a manager account which is in effect a delegator account. However, it looks like each node has 1 manager account, which is more overhead than using the existing delegator method, of 1 cold account delegating to many hot nodes. Using the existing method, plus 1 manager account for voting etc would be useful.
I suggest we use contracts as validator addresses rather than wallets. Might take some parity coding because I don't think parity can do that in its current state. Anyway this would allow us to set our payout wallet and lots of other things using contracts. This would entirely eliminate the need for passwords and wallets on a validator host machine and be infinitely more flexible than using a plain wallet (could do things such as selling shares, running multiple nodes paying out to a single wallet, splitting payments, better handling of delegation etc).
Also I want to add that I don't mean one single contract for everyone, I mean one contract per node so we can use our own custom contracts if we wish.
FIP5: Validators Key Splitting
Motivation:
In the current state, the validator key has an inherent security weakness since it is on a hot machine. To reduce the risk, the key should:
Suggestion:
We suggest to split the validator key into two keys. One that validates the blocks and stays on the hot validator machine and a second key which manages the validator, can vote in the governance process and have access to the stake and rewards. We will call them the validation key and the manager key. In this way, the validation key sits on the hot validator machine and can only sign on blocks. While the manager key sits in whatever wallet the validator chooses, possibly in a cold storage or can even be a smart contract, like a multi-sig.
Technical spec:
createValidator(address validationAddress)
.createValidator
method will create a contract with two attributes:validationAddress
: set to be thevalidationAddress
param.managerAddress
: set to bemsg.sender
.createValidator
method will register this contract to the consensus contract.validationAddress
in this contract can be changed only by a call from themanagerAddress
.managerAddress
cannot be changed since if themanagerAddress
is compromised it doesn't matter anyway, and if the validator thinks it is compromised, he just needs to create a new contract with new addresses and transfer the delegations to it.validationAddress
and its validator contract, which means that thevalidationAddress
should be unique between the validator contracts.delegate(address validator)
method with the validator contract address as the parameter.