I am long term RocketPool community member and a NO. Love the project and the values it stands for. Currently I am a full time contributor of SSV DAO and am exploring what could be the synergies between RocketPool and SSV.
In short, combining RocketPool + SSV allows for having more fault tolerant setup + earning additional rewards.
Possible synergies
I have thought of 3 ways how RocketPool <> ssv.network could complement each other.
RocketPool node operators can run SSV node NEXT to rpl stack. This will allow them to earn additional rewards from the SSV network and help decentralize eth staking further. Think this is quite exciting use case :), more rewards + decentralizing staking is always better!
RocketPool node operators can run their validator ON top of ssv node only for themselves and their squad. Basically running their validator clients in a distributed fashion to prevent down time and slashing.
Combining one and two. RocketPool node operators can run their validators in a distributed fashion using ssv’s DVT tech, basically the same as 1. but also using SSV node to decentralize their setup. The unique feature of DVT tech that ssv uses is that NOs could let other stakers stake with their SSV node. Basically, you decentralize your setup, but also let other stakers use your node in a permissionless way. The more stakers use your node the more additional funds you make.
What I propose here does not require changes to the RPL stack and it is purely additive. As a member of both communities I believe the best way for RocketPool is to stay neutral with regards to DVT solutions it can leverage, the more the merrier ;).
Also I think these project align ideologically as they both follow the open source ethos.
Interested in running RocketPool + SSV ?
I would like to gage the community interest in one or any of these use cases, to see if it makes sense to pursue them and which ones.
Also, if you are exited about some of these use cases and would like to get involved, let me know, would create a working group for this.
I will be happy help people apply for a grant from SSV DAO to work on what would be needed for this.
The main things that come to mind to make these use cases a reality and easy to use:
find a way to port reputation of NOs to SSV network (for other stakers to pick you as a NO in SSV, they need to trust you are doing a good job)
create resources for setting up nodes, so that it is easy to use
– this could include guides, documentation, scripts or whatever else is helpful
request features / changes from SSV dao if needed to make everything smoothly together
find out if there are any issues / blockers / with SSV that RPL community is not happy about and solve them.
There could be other actions things worth exploring, happy for any feedback.
Permissionless DVT (the 3rd suggestion) isn’t safe. In this setup, it would be the NOs that may suffer (RP should be fine).
Sybil Attack:
Let’s say we have 8 ETH minipools and only require 1 ETH per participant
On a given day evil-Val puts in 100 1 ETH shares. Some other non-evil folks put in 30 1 ETH shares.
Now the protocol randomly makes groups of 8 to start minipools
In many groups, I’ll have 6-9 shares
In these groups I have full control, and have essentially leveraged my ETH
I can hold the other people’s shares hostage (I won’t exit unless you pay me)
I can steal all MEV to my address while the whole pool gets penalized
I’m sure there’s other bad things, but the core is that without Sybil protection I can control the whole validator, which is decidedly not the idea.
The first suggestion sounds just fine. That said, I do have concerns about who the users and use cases are, and how they’re Sybil proof.
For the second suggestion, what’s the benefit over an HA solution like vouch+dirk? If I’m splitting with just myself, this introduces latencies for little benefit. If I’m splitting with friends (to save on capital costs?) I think this can make sense. Just need to remember there’s actual trust here.
In your Sybil attack case I believe it’s the NO’s responsibility (and liability) to select their trusted SSV operators, and not randomized, which I think this is SSV by design.
I have not studied vouch/dirk in detail but it seems like you need to maintain vouch, dirk and the multi-beacon nodes. And the redundancy you get is for a beacon node going offline, while having the extra upkeep + failure modes from the need to maintain vouch and dirk.
I think DVT solutions in general can give NOs the redundancy for the entire validator stack with minimal effort but of course with some extra, but minimal in my opinion, trust assumptions on the DVT operators.
@Valdorff In the case you describe it may be problematic. Let me clarify what I ment by case 2 and 3.
Case 2 & 3
As @unnawut says you as a minipool owner would choose 4 operators (or more). The idea is that one would be you and other three your friends you trust.
What you are describing here, is a quite different use case. What I am suggesting in this pilot is not to change current 8 eth minipools in any way, Nor try to lower bond for participants, but let your validator run in a cluster with other operators of your choosing. This is the case 2.
Case 3 is the same as two, with addition that you let other stakers use you as one of their operator to help them run their validator and earn some rewards
Also, these other parties you would run your validator with do not have the control of the validator, they can only attest, you can replace them on the fly with other operators or exit the validator completely.
Yes this is the point. The idea in case 2 is that you and your friends run your validators in clusters. It means your setup can go down completely and nothing happens. Also you are running ssv validator instead of regular validator that’s all.
No problem if the other folks are trustfully chosen
Just need to be extremely explicit as people want the other and it leads to misunderstanding. Eg, the question just above this comment is asking about validator exits which would be a non-issue in a trustful setup.
The Issue
I think it’s important to focus on the issue we trying to solve here with DVT (SSV).
The underlaying RPL protocol aims to encourage permissionless mini pool operators to run their own validators by marrying pooled ETH with their ETH for collateral.
The biggest issue I see (and would love the input from the RPL community) are super large mini pool operators which create pretty big centralization points.
It’s actually less about slashing and more about general protocol healthiness and single points of failure
They can be hacked
They can be malicious
They can be forced by regulators
They can be incompetent
All the above affects RPL and ethereum at large as RPL grows.
Where DVT Can Help
What if massive mini pool operators will be socially forced to use DVT with other operators of their choice?
They will make the same rewards
They will remove single points of failure
They will be more robust against hacking/ regulators/ incompetence
As well as letting smaller mini pool operators participate in larger operations, potentially make everyone better.
What It Takes?
It actually doesn’t take much in terms of technical work, it’s more about finding the path of least resistance and promoting education which, in-turn, will create social pressure on bigger mini pool operators to show they use DVT for the greater good.
How to Get Started?
The first step was actually done already by @markus which is show a viable path for a testnet integration.
Next steps:
Formalize a small scale testnet on prater which will test out all aspects of DVT mini pools
High risk mainnet testing - run a few mainnet mini pools fully insured so any potential losses will be covered (SSV can cover)
The super large operators need to trust the people they are splitting with, right? So… how do they select those people?
Scenario 1: The easiest path I can see is reciprocal setups. Ie, 4 super-large setups all use DVT for each other. This allows a great deal of vetting, since you only have to vet 3 people. It also means everyone has a huge interest in working well together. This doesn’t sound like what you’re talking about?
Scenario 2: Another path is to use highly trusted people. For example, WhaleVal might trust Alon as both as a person and an NO and thus decide to include them in his DVT squad. This… kinda works? As long as trust is well-placed, this is great - it will help against hacks/regulators/incompetence, as you say (I leave off malicious, because WhaleVal is not worried about himself… and if he’s malicious then he simply won’t opt into this). On the other hand, if trust is misplaced, then this is a hack. And if it’s partly misplaced then regulator exposure might not change much.
Scenario 3: Yet another path is to use a ton of moderately trusted people. Here WhaleVal, with his 500 minipools says “I have these 150 people I mostly trust from the discord server - I’m gonna give each of them a partial key for 10 minipools”. Vs Scenario 2, I’d expect more issues (lower bar, more groupings), but the cost of an issue is significantly lower.
I guess essentially the first question is something like, "How confident am I that P(at least 2 of the 3 people I choose to trust deserve it) > P(hack) + P(regulator enforcement) + P(own incompetence)? Off-hand, that feels truer for Scenario 1 than 2 or 3.
Yes, in the proposed scenario you still have the full validator credentials, thus you could perform exits the same way as if you are running a solo validator.
DVT does not necessarily mean that you do not have the full validator key, only that other operators in your cluster have a share of this key and can help you sign duties validator duties.
So in the proposed scenarios, the owner still maintains the full key, but shares some keyparts with other operators
Ok. The main owner having the full key is a big difference from what I’ve usually seen. This helps exits, and scenarios like MEV theft by the other parties. It doesn’t help with a threatened slash. It also significantly damages regulator resistance, right?
Depends what you mean here, but it has the same anislashing properties as if you use DKG( nobody has full key).
Still the signing happens with the partial key. You as a validator owner also have the full key, but it is in cold storage, you are not signing anything with it, so slashing risk is highly unlikely, same as if you did not have the full key. The cluster participants would have to collude to slash a validator.
Correct, if you have the full key, somebody can coerce you. It’s a tradeoff of having full key or not. Since you are already a validator owner, it does make sense to do it this way IMO.
To do it using DKG is and don’t have a validator owner is also a possibility, but think to start a pilot this is a better one.
Exactly, think this is most relevant for rocketpool NO at this stage and easiest to manage. No major issues / changes with exits / key management, just fault tolerant validator operation + additional income.
1, 2 and therefore 3 (combination of both) is already possible.
On Goerli, some of my my RocketPool validators are running on SSV, in a cluster with one or more of my own nodes (including a node ran by the RocketPool stack that the ssv node connects to).
It’s fairly simple: one just needs to grab the keys from the ~/.rocketpool directory and follow the SSV launchpad to split it and distribute it on selected ssv node operators (4 of them minimum, just pick one or more of your own ones).
Just don’t forget to rename or move the keys from the ~/.rocketpool directory.
As a validator, you and only you remain in control of your key and can get out of SSV anytime you want.
As a NO, anyone can select you as one of the NO cluster and you hold only a share of the key so cannot do much with it. Only the validator having selected you can, and he/she can change NO anytime (or even leave).
I am exploring that setup vs Obol and Vouch.
All of them are great and play nice with RocketPool validators.
Only vouch has a drawback as it cannot use the full power of Dirk’s distributed wallet (as RocketPool’s wallet is a hd wallet), although there are some experimental projects to split them into a Dirk distributed wallet.
