Casper: Bugs in validators can lead to catastrophic losses of money.
kladkogex opened this issue · comments
https://github.com/ethereum/research/blob/master/papers/casper-basics/casper_basics.pdf
The requirement that all money deposited by validators is destroyed if two PREPARES are published is wrong and needs to be modified.
Indeed, in case of an unintentional software bug not even in the node software, but in the underlying
operating system, such as Linux, a large proportion of validators (a deposit-weighted majority in the language of the paper) may lose their deposit in case of an automated OS upgrade, which can lead to multi-billion $ losses.
It will also create a multi-billion dollar incentive to hack the underlying operating system.
Agree that this is a pretty big issue.
The current strategy/research direction here is to only completely slash validators only when the safety faults attributed to them actually contributed to consensus safety failure.
This is relatively simple to do in the finality gadget. When there are two conflicting finalized blocks, then any validators who committed to both of the finalized blocks will be slashed.
Validators who were Byzantine but didn't vote on the conflicting blocks don't need to be penalized much. Validators who equivocate but do not cause consensus safety failure also don't need to be penalized much.
But yeah, it's definitely an issue, and we're definitely working on it :)
Vlad - understood.
One thing you could think about is to limit the penalty to of the funds involved in the blocks involved.
I was talking to some people at the devcon3 conference, and my understanding is that
it is not yet clear how much many will be there, or what the exact economics for validators will it be.
An alternative is to have every node potentially working as a validator, and change the set of validators, say every 1000 blocks. Essentially you publish a random number every day, and then every node does a hash of its public key to match the hash, the nodes that match the hash close enough become validators for the current epoch. Once can also have a continuosly updating set of validators where the set is changing slowly. As an example, a node can do a hash of its public key and then compare it to the hashes of the last 1000 blocks, If there is a close match for one of the hashes, the node is a validator.
A positive thing about changing validator sets is that if validators change, say, every day, then an attacker has one day to bribe and compromise validators.