Trustless validator blackmailing with the blockchain

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.

1 Like

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.

I think this part of the specification changed(changes…) a lot. The last version of the specification (https://github.com/ethereum/eth2.0-specs/blob/d0e3300e2726fbca95ff0b7647574a3efca0270d/specs/phase0/beacon-chain.md#proposer-slashings) gives ⅛ of the reward to the block proposer and ⅞ to the whistleblower, and that’s what I used in my calculations. I’m not sure it’s included in phase 0 though.

In phase 0 there is no separate whistleblower, so the entire slashing reward goes to the proposer.

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?

You could consider hardware wallets analogous, we seem to have enough options out there for them.

This is why only hardware wallets make sense.

Another way to protect against blackmailing is to have a finite (short) validity time for a fraud proof, so there is no time to blackmail

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.