Thank you to Taiga for providing the impetus and co-writing this article with us! We appreciate the chance to collaborate with SSV-Community members.
Disclaimer: You only need some hardware initially to set it up!
There’s recently been a significant amount of conversation around Distributed validator technology (DVT) and Rocketpool. DVT is a technology primitive used to improve the decentralization and robustness of ETH validators by splitting their operation between multiple nodes. And Rocketpool, a leading staking pool, focused on easy node setup and decentralization of validator nodes.
I’m passionate about decentralization and, thus, have followed both Rocketpool and SSV for a long time.
- Rocketpool Non-trusting Operators (NOs) are providers and consumers in the SSV protocol, e.g., also being SSV NOs, splitting their minipool duties among other Rocketpool-based SSV NOs.
- Rocketpool NOs are only consumers of the SSV network protocol by splitting their minipool across existing SSV network NOs.
- (insert other LEGO-based options)
The main question has always been, “How can these two work together?”. Realistically, there are likely “endless” ways SSV could integrate with Rocketpool:
Questions are often raised about Sybil resistance. This post doesn’t aim to address those concerns or “what’s right for Rocketpool.”
As SSV approaches mainnet, I thought it’d be an interesting experiment to see what’s possible today with no deep integration from either side. The really cool thing about Rocketpool is that it’s infrastructure agnostic — the protocol will look at your on-chain performance and pay you accordingly. Similarly ssv.network is an open and permissionless protocol that can be used as validator infrastructure for any staking application.
To see what that looks like, I’ll go through the process:
These generalized infra solutions means we could split our minipool’s validator keys and let ssv.network do the rest. Similar to the DeFi Legos used to create the bustling DeFi ecosystem we see today DVT and staking services are building blocks that can create tons of value when used together.
First of all, we need to create a minipool. We won’t go over that, because the Rocketpool docs already do a great job.
Once the minipool is up and running, it means that the smartnode (Rocketpool’s amazing utility) has imported the minipool keys into the validator client.
- Extract keystore
- Disable the validator on Rocketpool’s VC
- Register validator on SSV (split keystore)
Now we’ll go through this process:
1. Extract keystore
The first thing to know is how keys are stored and loaded. This depends on the CL/VC combination you are running; in my case, I’m doing Nethermind/Lighthouse.
Lighthouse has a very useful YAML file that describes validators and whether to load their keys or not, called validator_definition.yaml , its path is $HOME/.rocketpool/data/validators/lighthouse/validators/validator_definition.yaml .
Note that these files are owned by root (likely a safety measure from Rocketpool), so you’ll need that. The folder structure is such as:
├── lighthouse (or another client) │ ├── secrets │ │ └── 0x909a56fbb8576d38e402b663d5b5bf02e6070dd7aedb4901453d2542a3035bda99cd64a3e39ca89018ec371366f7abb2 │ └── validators │ ├── 0x909a56fbb8576d38e402b663d5b5bf02e6070dd7aedb4901453d2542a3035bda99cd64a3e39ca89018ec371366f7abb2 │ │ └── voting-keystore.json │ ├── api-token.txt │ ├── slashing_protection.sqlite │ ├── validator_definitions.yml │ └── validator_key_cache.json
Copy the contents of voting-keystore.json to your machine. The passphrase used to encrypt this keystore is randomly generated by smartnode and is stored within the secrets/ path under the folder with the validator address. You will need it later to split your key.
2. Disable validator on Rocketpool’s VC
Going back to the aforementioned file from earlier.
$ cat validator_definitions.yml - enabled: enable voting_public_key: "0x909a56fbb8576d38e402b663d5b5bf02e6070dd7aedb4901453d2542a3035bda99cd64a3e39ca89018ec371366f7abb2" description: "" type: local_keystore voting_keystore_path: /validators/lighthouse/validators/0x909a56fbb8576d38e402b663d5b5bf02e6070dd7aedb4901453d2542a3035bda99cd64a3e39ca89018ec371366f7abb2/voting-keystore.json voting_keystore_password_path: /validators/lighthouse/secrets/0x909a56fbb8576d38e402b663d5b5bf02e6070dd7aedb4901453d2542a3035bda99cd64a3e39ca89018ec371366f7abb2ya
We can set enabled to false to signal Lighthouse not load our minipool’s validator keys, and then restart such as rocketpool service stop && rocketpool service start . You can validate whether they have been loaded by checking rocketpool service logs
Note that if you are using another client, you’ll have to delete the keys (and restart) to stop the client from loading them on start-up. Obviously, back these up!
Remember to never run the same set of keys in two places at the same time. This also applies when registering your validator on SSV network.
3. Register validator on SSV
(leave at least 1 epoch between disabling your validator on Rocketpool’s VC and registering it on SSV)
Head to the SSV network app, and start the process to split a validator’s keys. You’ll be presented with two options:
For the highest level of safety and security I advocate doing any key-splitting completely offline. However, for the purpose of this post, I’ll do it online. Here, you can upload the keystore.json and keystore password from step 1:
Operator Selection
We can choose who to split the key across by looking at their yearly fee (charged in $SSV), performance, geographic location, etc.
You should now be all set:
We can now verify that everything is running as expected. Minipool on beaconcha.in:
As well as the SSV explorer:
We could now safely shut down the hardware used to spin up the minipool. That’s it! Your RPL validator is now being operated by multiple non-trusting nodes on the ssv.network with no hardware further required.
The Future of Staking is Modular
As ETH staking moves into the mainstream one of the goals for those building the ecosystem is to simplify the process and remove as many barriers as possible. When looking at DeFi it seems staking is following suit, a separation of concerns if you will. Projects focusing on core infrastructure like smart contracts and node operation, while others can build ontop of this infrastructure e.g. adding a token layer like LSTs or re-staking. As we can see from the above, projects can work together to optimize the staking process and support each other through the many different configurations that are possible with the correct building blocks.
I would like to thank the SSV team for their inputs in the blog post.
Some socials:
My twitter for the occasional technical tweet or blog.
Originally published at https://zktaiga.medium.com on July 25, 2023.
