A v0 iteration of the ValidatorDAO

A v0 iteration of the ValidatorDAO

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.

Building a v0 of a ValidatorDAO with SSV.network

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:

  1. Slash the validator
  2. 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.

How to minimize this risk?

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!

Token Economics

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?
2 Likes

Doing a quick reading of the SSV.Network, I see they have an audit done on their vesting, dex, and token contracts. Is there any word on an audit for the contract that Operators will have to use when Registering? Additionally, I am assuming Dappnode will have a package for the SSV client needed to join the network, correct? I like this and support it. Watching some of their youtube videos, I like pooling providers, reducing the chances of malicious actions from one provider.

1 Like

How does this compare with the work that Rocketpool is doing?

Is it easier to help port RocketPool to the DappNode environment?

Is SSV simpler to operate than RocketPool, with less swapping of tokens required?

From what I understand from the document section of SSV.network, operators provide resources. They do not have to provide any collateral, such as the 16 ETH needed to be an operator on rocketpool. The operators are placed in groups to reduce malicious activity, and the validator key is divided into shares. Operators are paid in the SSV native token from the validators. The network is still in testnet, but I see some good potential. One drawback would be validators will need 32 eth, unlike rocketpool’s 0.01 eth to participate. This may limit the number of participants and the chances of an operator being chosen.

“Blox Staking” YouTube channel has some videos better explaining the process for both operators and validators.

edited
in the future staking services can use ssv to stake thus adding more participants

Adding the discussion in Discord to the posts here, seems that there’s a generally positive reaction to this, so we’re testing and we’re going to have a package ready soon!

It would be really helpful if some people would like to test the SSV.Network package. Apart from the SSV package, the Prater and Goerli packages will be necessary. No prater validator deposit will be necessary as it will be received through the SSV package.

Any volunteers hit me up directly on Discord or mention it here and I’ll reach out to you!

I would like to participate

I too would like to participate: while I like what staking is already available, and with RPL coming online soon, having more on-ramps to staking that also enhance the network diversity are always needed