🇬🇧Stader meets DVT

An experimental approach to the use of DVT and SSV for Stader validators

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).

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.

Step 0 - What to keep in mind

Before starting, you should know that once validators are removed from the Stader's operator, no more validators can be added under that same operator unless the existing ones are loaded again. This information must be taken into account if you want to scale further under the same operator in Stader. If this is not the case, or you will register new operators to continue running validators from Stader's protocol, this guide may help you.

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!

Step 1 - Locate the keystore and secret of the validators deployed on your Stader Node

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:

$ docker ps -a

The path of the keystores and secrets is as follows:

$ ~/.stader/data/validators/lodestar/validators
$ ~/.stader/data/validators/lodestar/secrets

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.

Step 2 - Regenerate the keystore keys (optional, if you want to migrate several validators)

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:

  1. 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…

Step 3 - KeyShares Generation

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.

Step 4 - Extraction of validators

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:

$ docker restart stader_validator
$ docker logs stader_validator –follow

Now you can confirm that it is no longer loading the validators in the logs:

Step 5 - Confirm the shutdown of validators on the network

Confirm that the validators have been turned off, checking that they are losing attestations.

Step 6 - Uploading keyshares to SSV

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

Step 7 - Configure the fee-recipient

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:

https://docs.ssv.network/validator-user-guides/validator-management/setting-fee-recipient-address#connect-your-web3-wallet-to-webapp

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.

Step 8 – Check that your validators sign attestations

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!

Last updated