FIP 005: Validators Key Splitting

[bejavu]

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:

• Never leave the machine by importing it to another wallet to use in the voting DApp or to delegate, withdraw and transfer tokens.
• Not have access to the validator stake or rewards.
• Be able to be replaced and managed by another (possibly cold wallet) key.

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:

• The consensus contract will have a new method called createValidator(address validationAddress).
• The createValidator method will create a contract with two attributes:
  • validationAddress: set to be the validationAddress param.
  • managerAddress: set to be msg.sender.
• The createValidator method will register this contract to the consensus contract.
• The validationAddress in this contract can be changed only by a call from the managerAddress.
• The managerAddress cannot be changed since if the managerAddress 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.
• The consensus contract will have a map between the validationAddress and its validator contract, which means that the validationAddress should be unique between the validator contracts.
• The empty payable method of the consensus contract will be removed.
• In order to delegate, one needs to send FUSE tokens to the consensus while invoking the delegate(address validator) method with the validator contract address as the parameter.
• The consensus contract will save the delegation mapped to the validator contract, only if it a registered contract.
• Block rewards will go to the delegators, all of them minus the fee.
• The fee will go to the manager address of the validator.
• The validator can choose to self delegate using the manager address or any other address that he have in order to get rewards.

[fileflume]

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.

[Andrew-Pohl]

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...

[shaimo]

Why is that needed? Why not just keep your tokens on Ledger and delegate them to the validator address?

[fileflume]

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.

[CrackerHax]

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.