We have the opportunity to work with SSV.network and to build on their product to offer DAppNode runners a way to leverage their hardware to validate eth2 with external deposits.
The way SSV works - it breaks the validator key in
n pieces. That means if Alice has a validator key but no means to validate and doesn’t want to trust one single person to validate with it, it can go to SSV.network, split the key in 4 pieces and give it to 4 diferent actors.
If 3 out of 4 agree on signing a message - a correct attestation, for example, the attestation goes through and the validator can receive the rewards.
As you see, none of the 4 can single-handedly do anything malicious with the validator, as they only have a piece of the signing key. They would have to get together (3 out of 4 again) to sign malicious actions.
In the most naive implementation, DAppNode users can offer themselves as SSV Operators so they can validate for other people and get rewarded thanks to the SSV.network.
This opens up the door for someone spinning up lots of DAppNodes in the hope to be randomly assigned a minimum of 3 parts of the same key, and then be able to:
- Slash the validator
- Ask for a ransom to the owner of the Deposit
Asking for a ransom would just trigger an immediate exit from the owner of the Deposit, leaving the attacker with nothing; and just slashing also does not give the attacker any economic benefit. Hence we put the probability of this attack as very low and unfeasible.
Nevertheless, it opens the door to a large-scale attack to the Ethereum network as a whole, where you silently try to control as many validators as possible and then cause maximum havoc thanks to correlation penalties.
Right now, SSV offers known infra providers who will be part of the network (Blox Staking, Lido, Stakefish, Staked, Stakewise…). We could force 2 known validators (they have their reputation at risk) and 2 DAppNode validators.
This way DAppNode validators can participate in the SSV.network in a secure manner!
More information about the SSV.network model and how our token can interact with the platform need to be on the table.
We could require a NODE deposit to DAppNode participants - this would increase the amount of non-circulating NODE, and use it if the DAppNode misbehaves?
What are your thoughts, in general but also specifically about:
- possible token models
- should we spend the Association’s resources pursuing this?