About that:
Maybe my message has not been read in the private vo-committee channel on Discord, but I spent quite some time analyzing the SSV official documentation and here’s what I found (I personally did not use DKG until now, always KeySplitting method):
With SSV’s DKG, the validator key is created so nobody ever sees the full private key. It only exists as encrypted shares across the operators. When you need to swap operators, you run a reshare:
-
The private key stays the same, so the validator identity doesn’t change.
-
Each operator gets a new encrypted share of that same key, old shares are thrown away.
-
A quorum of current operators must cooperate so the secret never gets exposed.
So yes, DKG-generated keys can be re-shared on the SSV web app to swap out operators on the fly without exposing the validator key. It is one of the biggest advantages of DKG. If the validator used the older KeySplitting method (the validator had the full key first then split it with the operators) then he/she can still change operators by manually re-splitting or re-onboarding with DKG. But re-onboarding with DKG defeats the whole purpose of DKG. The whole point of DKG is that the private key never exists in one place. If you already had the full key once, migrating it into DKG later won’t give you the same trustless guarantee, the validator key has already been exposed. Better to start fresh with DKG from the beginning.
Let’s add to the DKG approach:
With DKG, the validator/cluster owner never has the signing private key. Exits and operator resharing require a quorum of operators (≥ threshold). Even if the cluster owner loses quorum for example, 2 out of 4 operators disappear in a 4-operator cluster, the validator is still safe. Thanks to the Pectra upgrade, you can now exit a validator and withdraw the stake directly from the withdrawal key. That means you’re never stuck, and this makes DKG an obvious choice.