# Stader meets DVT
*Versión actualizada el 29.04.2024*
En Ethernodes.io utilizamos tecnología DVT para asegurar el mejor uptime posible para todos los validadores que gestionamos. Es por ello que, con independencia de si gestionamos volumen mediante validadores *vanilla* o a través de protocolos de *Liquid Staking*, intentamos basar todas las operaciones en el uso de nuestros *clusters*.
En el siguiente artículo, explicamos nuestra experiencia en forma de guía sobre cómo migrar validadores operados en [Stader ](https://www.staderlabs.com/eth/)a un *cluster* (propio o público) de [SSV](https://ssv.network/).
{% hint style="info" %}
:warning:**Toda la información contenida en este artículo es experimental y requiere de un conocimiento profundo sobre los sistemas implicados**:warning:
Cualquier error en el proceso puede significar la pérdida parcial o total de fondos del validador, así como *slashings* por doble firma o por parte de Stader por mala práctica.
Ethernodes.io no se responsabiliza de un mal resultado final en la ejecución del proceso ni en la exactitud del mismo, así como tampoco de posibles riesgos futuros que se den por el uso de SSV para operar validadores de Stader.
{% endhint %}
## Paso 0 - Qué tener en cuenta
{% hint style="info" %}
Aunque se retiren los *keystore* y los *secrets* del nodo, es posible continuar creando validadores desde el nodo de Stader siempre y cuando el archivo de la wallet del operador continúe en la máquina.
Tienes dos opciones:
1. Mantener el VC funcional
2. Deshabilitarlo completamente
Si optas por mantener el VC funcional, cuando crees nuevas *keys* (con el proceso normal de Stader) el mismo cliente comenzará a realizar las tareas de los mismos una vez se complete todo el proceso.
Si por el contrario optas por deshabilitarlo completamente, aunque generes nuevos validadores desde el mismo operador, tendrás o bien que habilitar el VC para que realicen tareas o migrarlo a DVT siguiendo el proceso que explicamos aquí.
[En este enlace puedes ver las pruebas](#tests-realizados) que hemos realizado en la testnet de Stader para verifica el comportamiento del operador\
\
Por cuestiones de seguridad, nosotros recomendamos deshabilitarlo completamente.
{% endhint %}
{% hint style="info" %}
Hay que **tomar ciertas precauciones antes de comenzar**, como por ejemplo habilitar la protección *doppleganger* para evitar posibles errores fatales con el validador (doble sign)
{% endhint %}
{% hint style="info" %}
Asegúrate de que tienes todos los elementos necesarios para realizar el proceso antes de iniciarlo, y que tienes dominados los diferentes aspectos del proceso de forma independiente.
{% endhint %}
{% hint style="info" %}
Si algún punto del proceso te genera alguna duda o reserva, NO inicies el proceso. ¡Puedes [preguntarnos ](https://twitter.com/AlphaGrowth_xyz)y te resolveremos cualquier duda que tengas!
{% endhint %}
## Paso 1 - Localizar los keystore y secret (password) de los Validadores deployados en tu Nodo Stader
Stader ejecuta varios módulos internos, uno de ellos es el cliente de validación. En el ejemplo utilizamos el cliente de validación (VC) *lodestar.* Substituir por el que estés utilizando.
Con el siguiente comando podrás ver el cliente de validación en uso en la línea de stader\_validator:
```
$ docker ps -a
```
La ruta de los *keystores* y *secrets* es la siguiente:
```
$ ~/.stader/data/validators/lodestar/validators
```
```
$ ~/.stader/data/validators/lodestar/secrets
```
Recuerda modificar esta ruta con el VC que esté en uso en tu nodo Stader.
{% hint style="info" %}
Es recomendable guardar una copia de forma segura de estos archivos (keystores y secrets), por si en un futuro quieres volver a ejecutar los validadores desde el propio operador Stader.
{% endhint %}
Habrás notado que cada *keystore* tiene una contraseña distinta asignada. En el caso de querer migrar varios validadores a SSV utilizando su proceso bulk, deberás ejecutar el Paso 2, descrito a continuación.
## Paso 2 - Regenerar las claves de las keystores (opcional, si quieres migrar varios validadores)
Si tienes varios validadores que deseas transferir a SSV, es recomendable que regeneres los archivos *keystore* y les asignes un único *password.* De este modo el proceso del *sharding* será mucho menos tedioso. Las claves se regeneran utilizando el *mnemonic* del operador que obtuviste cuando instalaste el nodo Stader.
Puedes utilizar dos métodos para generar las Keystores:
1. Mediante esta guía\
2. Usando el ejecutable Wagyu del launchpad de Ethereum\
:warning: Es importante que regeneres las claves de los validadores antiguos. Por tanto, debes utilizar los *nonce* que se utilizaron desde Stader para llevarlo a cabo. Si tienes 1 validador, su *nonce* es 0. Si tienes 2 validadores sus *nonce* serán 0 y 1 . Y así sucesivamente en función del número de validadores.
{% hint style="info" %}
Confirma que las *pubkeys* de los *keystore* que acabas de generar coinciden con las *pubkeys* de los validadores que están ejecutándose en Stader. El archivo *deposit\_data* no es necesario.
{% endhint %}
Ahora ya tienes los *keystore* bajo el mismo *password*…
## Paso 3 - Generación de KeyShares
Sigue los pasos de SSV que encontrarás en [https://docs.ssv.network/developers/get-started ](https://docs.ssv.network/developers/get-started)para generar los *keyshares*. La última versión del ejecutable **permite operaciones en *****bulk,*** especificando un directorio con *keystore files* en lugar de un archivo *keystore* suelto. ¡Así conviertes los k*eystores* en *keyshares* rápidamente!
{% hint style="info" %}
Recuerda que hemos generado las *keystores* de nuevo en el Paso 2 ya que el ejecutable de SSV no puede realizar la tarea de generación de *keyshares* en *bulk* si los *keystores* tienen diferentes contraseñas.
{% endhint %}
\
:warning: Existe una limitación de 80 validadores por archivo *keyshare.* Por lo tanto, si tienes más de 80 validadores a migrar a SSV, deberás hacerlo por *batches* de 80, generando un archivo *keyshare* por cada bloque. Además, no debes tener ningún otro archivo que no sean *keystores* en la carpeta target.
## Paso 4 - Extracción de validadores
Es el momento de retirar los *keystores* y *secrets* de Stader. Retira de tu cliente de validación todas las carpetas y archivos ubicados en la ruta del [Paso 1](#paso-1-localizar-los-keystore-y-secret-password-de-los-validadores-deployados-en-tu-nodo-stader). Una vez hagas esto, puedes ejecutar:
```
$ docker restart stader_validator
```
```
$ docker logs stader_validator –follow
```
Ahora puedes confirmar que ya no está cargando los validadores en los logs:
## Paso 5 - Confirmar el apagado de los validadores en la red
Confirma que los validadores se han apagado, comprobando que están perdiendo *attestations*.
:warning:Es importante dejar que los validadores pierdan 3 o 4 *attestations* antes de cargarlos de nuevo en SSV, para evitar *slashings* por *doble sign*.
## Paso 6 - Cargando los keyshares en SSV
{% hint style="info" %}
Si tus operadores son privados, debes modificar *owner* de los mismos, indicando la *wallet* operadora del nodo de Stader. De este modo podrás incluir nuevos validadores desde esa *address* en tu cluster privado.
{% endhint %}
Siguiendo la siguiente guía puedes cargar normalmente los keyshares en SSV:
## Paso 7 - Configurar el fee-recipient
En el caso de que estés en el *socializing pool* de Stader, debes configurar el *fee-recipient* de tus validadores.
Para modificar el fee-recipient de tus validadores en SSV, puedes utilizar esta guía:
La address a indicar en caso de que estés en el *socializing pool* de Stader la puedes encontrar aquí:
{% hint style="info" %}
En el caso de tener tus validadores configurados para formar parte del *socializing pool*, no configurar el fee-recipient puede suponer penalizaciones por parte del protocolo de Stader.
{% endhint %}
## Paso 8 - Comprueba que tus validadores firmar attestations
Sólo te queda comprobar que tus validadores vuelven a firmar *attestations*. Una vez finalizado el proceso, ¡Tus validadores de Stader estarán funcionando en SSV bajo una infraestructura DVT!
{% hint style="info" %}
:warning: Recuerda que se trata de un proceso experimental. Desde Ethernodes.io se ha ejecutado el mismo con éxito con +200 validadores. No obstante, no recomendamos realizarlo sin un conocimiento profundo de los diferentes sistemas implicados.:warning:
{% endhint %}
## Tests realizados
En coordinación con los equipos de Stader y SSV, hemos realizado los siguientes tests en la testnet de Stader, para comprobar el comportamiento de un operador al incorporar nuevos validadores, teniendo algunos ya migrados a la infraestructura de SSV:
> **Test 1:**
>
> * Registro de 10 validadores con normalidad, utilizando el cliente de Stader
> * Eliminación de carpetas que contienen los secrets y los validadores del path `.stader/data/validators/lighthouse/[secrets,validators]`
> * Apagado del cliente de validación: `docker stop stader_validator`
> * Registro de tres validadores nuevos.
>
> **Resultado**: los tres validadores se generan sin ningún tipo de problema. No se repiten las *keys* o se importan las antiguas. El cliente de validación se reinicia automáticamente, sin realizar ninguna acción por nuestra parte
>
> \
> **Test 2:**
>
> * Registro de 10 validadores con normalidad, utilizando el cliente de Stader
> * Eliminación de carpetas que contienen los secrets y los validadores del path `.stader/data/validators/lighthouse/[secrets,validators]`
> * Apagado del cliente de validación e imposibilitado que se inicie de nuevo: `docker stop stader_validator`
> * Registro de tres validadores nuevos.
>
> **Resultado**: los tres validadores se generan sin ningún tipo de problema. No se repiten las *keys* o se importan las antiguas. El cliente de validación se ha mantenido apagado, sin inicializarse.
El resultado de los tests indica que es posible continuar generando nuevos validadores con independencia del estado del cliente de validación de Stader. Esto hace posible actuar sobre el operador de Stader para añadir nuevos validadores aunque se hayan migrado alguno o todos los validadores controlados por el operador al servicio de SSV.
Esto es debido a que la creación de validadores tiene su lógica en la wallet vinculada al operador, siendo independiente al cliente de validador. Mientras se mantenga el archivo de la wallet sincronizado (no eliminado ni utilizado en diversos equipos), la generación debe funcionar.
{% hint style="info" %}
Los tests realizados en testnet no garantizan un comportamiento igual futuro en mainnet. Los cambios de versión que puedan realizar Stader o SSV en sus clientes y funcionamiento pueden tener una afectación directa al resultado observado en los tests realizados.
{% endhint %}
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.alphanodes.io/publicaciones/stader-meets-dvt.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.