🇪🇸Stader meets DVT

Una aproximación experimental para el uso de DVT y SSV en validadores de Stader

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 a un cluster (propio o público) de SSV.

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.

Paso 0 - Qué tener en cuenta

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 que hemos realizado en la testnet de Stader para verifica el comportamiento del operador Por cuestiones de seguridad, nosotros recomendamos deshabilitarlo completamente.

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)

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.

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!

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.

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.

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. Usando el ejecutable Wagyu del launchpad de Ethereum https://github.com/stake-house/wagyu-key-gen/releases

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.

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 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 keystores en keyshares rápidamente!

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.

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

Paso 6 - Cargando los keyshares en SSV

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.

Siguiendo la siguiente guía puedes cargar normalmente los keyshares en SSV: https://docs.ssv.network/validator-user-guides/validator-management/distributing-a-validator

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:

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

La address a indicar en caso de que estés en el socializing pool de Stader la puedes encontrar aquí: https://www.staderlabs.com/docs-v1/Ethereum/smart-contracts

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.

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!

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.

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.

Última actualización