In fact, the prudent validator can’t know for sure.
But the design of Casper slashing (the individual being punished more if many fail at same time) anyway works in favor of those who avoid doing what everybody else does. It incentivizes decentralization in a very generic way, including e.g. trying to not use the same software and distribution channels everybody else is relying upon.
As a result of this multi-dimensional decentralization (the term diversity seems to fit), it should become much harder for an attacker to get in control of a large chunk of the network.
This could also mean that for non-techies it’s safer to ask a friend to run a validator node for them instead of using some one-click solution which requires no understanding of the system and which many others may be using too.
I think that’s better for network resilience, thus am skeptical about attempts which try to make running a validator node very easy.
We will see how it plays out.
It is worth pointing out that slashing rewards go to the block proposer that includes the slashing information, not the entity that broadcasts the slashing details. This makes this a relatively difficult attack to pull off for a large number of validators.
Very much so. As @dankrad says above, having an HSM with built-in slashing protection is something that is not simple to do, and beyond the abilities of most. Any pure software solution is vulnerable to an attacker gaining the private key.
As to if you trust the HSM provider, that’s a different matter. As no-one has built one yet it’s hard to decide if they’re trustworthy or not.
It’s like hardware wallets – hopefully there will be providers who will make a good effort and show to the community that they’re building things with good faith (open source, commissioning audits, etc.).
We can probably add extra layers of security over time:
Since only very limited communication from the HSM to the outside is necessary – you can probably add a device to the connection that checks that only the required signatures and nothing else comes out of the HSM. Then, even if the HSM manufacturer is compromised, you would still be protected
As we have made all the efforts to be able to run a validator in a secure multi-party computation, it is also possible to use several HSMs by different manufacturers, and you would only be exposed if 2/3 of them are compromised
I don’t expect these will happen next year, but if Ethereum becomes massively successful and the capital requirements go up to 100k$ or more, we will probably see some of this.
So most will adopt a standard setup? How does that help decentralization? How many different setups will there be? What will incentivize creating “one more“ security solution? How will a user ascertain that this one more is materially different?
It may be possible to get very close to that level to security using SGX and similar solutions. While exploits have been found, I think they can be mitigated as long as the hardware is under your control. I would be very happy if someone would implement this as a first-order solution.
For the sake of completeness, the hardware (or sgx) wallet must also check that it doesn’t sign an attestation or a block that breaks a slashing condition, so the hacker cannot generate them to reveal them later. I guess it means as well that the slashing conditions cannot be changed easily.
Changing the key isn’t really possible, as they still have to be responsible for their past equivocations. Otherwise, it would be like a get-out-of-jail-free card.
(Adding a new key, without removing the potential for penalties from the old one, is possible (but not implemented) but that would only help you if you lose the key, not if it’s stolen).