Stader meets DVT
An experimental approach to the use of DVT and SSV for Stader validators
Last updated
An experimental approach to the use of DVT and SSV for Stader validators
Last updated
Version last updated: 29.04.2024
At Ethernodes.io we use DVT technology to ensure the best possible uptime for all the validators we manage. That is why, regardless of whether we manage volume through vanilla validators or through Liquid Staking protocols, we try to base all operations on the use of our DVT clusters.
In the following article, we explain our experience in the form of a guide on how to migrate validators operated in Stader to an SSV cluster (own or public).
All information contained in this article is experimental and requires in-depth knowledge of the systems involved.
Any error in the process can mean the partial or total loss of the validator's funds, as well as slashings due to double signature or by Stader due to malpractice.
Ethernodes.io is not responsible for a poor final result in the execution of the process or its accuracy, nor for possible future risks that arise from the use of SSV to operate Stader's validators.
Even if keystores and secrets are removed from the node, it is possible to continue creating validators from the Stader node as long as the operator wallet file remains on the machine.
You have two options:
Keep the VC functional
Disable the VC completely
If you choose to keep the VC functional, when you create new keys (with the normal Stader process) the same client will begin to perform their tasks once the entire process is completed.
If, on the other hand, you choose to disable it completely, even if you generate new validators from the same operator, you will either have to enable the VC to perform tasks or migrate it to DVT following the process we explain here.
In this link you can see the tests we have carried out on the Stader testnet to verify the behavior of the operator For security reasons, we recommend disabling it completely.
Certain precautions must be taken before starting, such as enabling doppleganger protection to avoid possible fatal errors with the validators (double sign).
Make sure that you have all the necessary elements to carry out the process before starting it, and that you have mastered the different aspects of the process independently.
Si algún punto del proceso te genera alguna duda o reserva, NO inicies el proceso. ¡Puedes preguntarnos y te resolveremos cualquier duda que tengas!
If any point in the process raises any doubts or reservations, DO NOT start the process. You can ask us. We will do our best to answer any questions you might have!
Stader runs several internal modules, one of them is the validation client. In the example we use the lodestar validation client (VC). Replace it with the one you are using.
With the following command you will be able to see the validation client in use in the stader_validator line:
The path of the keystores and secrets is as follows:
Remember to modify this route with the VC that is in use on your Stader node.
It is advisable to safely save a copy of these files (keystores and secrets), in case you want to run the validators again in the future from the Stader operator itself.
You may have noticed that each keystore has a different password assigned. If you want to migrate several validators to SSV using its bulk process, you must execute the Step 2, described below.
If you have several validators that you want to transfer to SSV, it is recommended that you regenerate the keystore files and assign them a single password. This way the sharding process will be much less tedious. The keys are regenerated using the operator mnemonic that you obtained when you installed the Stader node.
You can use two methods to generate Keystores:
Using the Wagyu executable from the Ethereum launchpad https://github.com/stake-house/wagyu-key-gen/releases
Confirm that the pubkeys of the keystore you just generated match the pubkeys of the validators that are running in Stader. The deposit_data file is not necessary.
Now you have the keystores under the same password…
Follow the SSV's steps guide at https://docs.ssv.network/developers/get-started to generate the keyshares. The latest version of the executable allows bulk operations, specifying a directory with keystore files instead of a single keystore file. This is how you quickly convert keystores into keyshares!
Remember that we generated the keystores again in Step 2 since the SSV executable cannot perform the bulk keyshare generation task if the keystores have different passwords.
It is time to remove Stader keystores and secrets. Remove all folders and files located in the path in Step 1 from your validation client. Once you do this, you can run:
Now you can confirm that it is no longer loading the validators in the logs:
Confirm that the validators have been turned off, checking that they are losing attestations.
If your operators are private, you must modify their owner, indicating the operating wallet of the Stader node. This way you can include new validators from that address in your private cluster.
Following this guide you can normally upload keyshares to SSV: https://docs.ssv.network/validator-user-guides/validator-management/distributing-a-validator
If you are in Stader's socializing pool, you must configure the fee-recipient of your validators. To modify the fee-recipient of your validators in SSV, you can use this guide:
The address to indicate in case you are in the Stader socializing pool can be found here: https://www.staderlabs.com/docs-v1/Ethereum/smart-contracts
If you have your validators configured to be part of the socializing pool, not configuring the fee-recipient may result in penalties from the Stader protocol.
All you have to do is check that your validators sign attestations again. Once the process is complete, your Stader validators will be running on SSV under a DVT infrastructure!
In coordination with the Stader and SSV teams, we have carried out the following tests on the Stader testnet, to check the behavior of an operator when incorporating new validators, having some already migrated to the SSV infrastructure:
Test 1:
Registering 10 validators normally, using the Stader's client
Deleting folders containing secrets and path validators
.stader/data/validators/lighthouse/[secrets,validators]Validation client shutdown
docker stop stader_validatorRegistration of three new validators
Result: the three validators are generated without any problem. The keys are not repeated or the old ones are imported. The validation client restarts automatically, without any action on our part
Test 2:
Registering 10 validators normally, using the Stader's client
Deleting folders containing secrets and path validators
.stader/data/validators/lighthouse/[secrets,validators]Validation client shutdown and unable to start again:
docker stop stader_validatorRegistration of three new validators.
Result: the three validators are generated without any problem. The keys are not repeated or the old ones are imported. The validation client has been kept powered off, without initializing.
The results of the tests indicate that it is possible to continue generating new validators regardless of the state of the Stader validation client. This makes it possible to act on the Stader operator to add new validators even if some or all of the validators controlled by the operator have been migrated to the SSV service.
This is because the creation of validators has its logic in the wallet linked to the operator, being independent of the validator client. As long as the wallet file is kept synchronized (not deleted or used on multiple machines), the generating should work.
Tests carried out on testnet do not guarantee the same future behavior on mainnet. The version changes that Stader or SSV may make to their clients and operation may have a direct impact on the results observed in the tests carried out.
It is important that you regenerate the keys of the old validators to use the SSV's bulk process. Therefore, you must use the nonces that were used from Stader to carry it out. If you have 1 validator, its nonce is 0. If you have 2 validators, its nonce will be 0 and 1. And so on, depending on the number of validators.
There is a limitation of 80 validators per keyshare file. Therefore, if you have more than 80 validators to migrate to SSV, you must do it in batches of 80, generating a keyshare file for each block. Also, you should not have any files other than keystores in the target folder.
It is important to let the validators lose 3 or 4 attestations before loading them again into SSV, to avoid double sign slashings.
Remember that this is an experimental process. This exact process has been executed successfully by Ethernodes.io with +200 validators. However, we do not recommend doing it without in-depth knowledge of the different systems involved.
