Imo, this is exactly the type of validator we want to incentivize. Validators should be investing into their hardware and security setups.
And by doing this, they are causing a massive negative externality harm to the network in the form of resilience decrease. This procedure is to incentivize them to not do that.
If they do this, it is beneficial to the network, as it is helping make the network more resilient.
Yeah, that is exactly my intention. The harm that centralization poses is when validators fault. And so we should harm the contributors to centralization when they fault.
Redelegate whenever they feel that the risk profiles of their validators have changed. Delegators are expected to be active participants in the network.
If somoene hacks your setup, then sure, they’d try to make both your keys fault.
Only if the slash is correlated. Then all correlated validators get the same slash. The standard default is that the small validator gets a smaller slash.
Well they should figure out how. Cause if not, they’re just burdening the network with additional signatures while not contributing to security by increasing the resilience of the network.
They probably shouldn’t run their entire setup on single cloud providers. And there’s many different infrastructure setups. Using different HSMs, data centers, KMS service, cloud providers (there’s many), servers, tendermint implementations, even OSs. I believe @mdyring was even planning on using BSD originally!