Stader meets DVT
Una aproximación experimental para el uso de DVT y SSV en validadores de Stader
Última actualización
Una aproximación experimental para el uso de DVT y SSV en validadores de Stader
Última actualización
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.
Toda la información contenida en este artículo es experimental y requiere de un conocimiento profundo sobre los sistemas implicados
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.
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:
Mantener el VC funcional
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!
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:
La ruta de los keystores y secrets es la siguiente:
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.
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:
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…
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.
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:
Ahora puedes confirmar que ya no está cargando los validadores en los logs:
Confirma que los validadores se han apagado, comprobando que están perdiendo attestations.
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
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í: 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.
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!
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_validatorRegistro 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_validatorRegistro 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.
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.
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.
Es importante dejar que los validadores pierdan 3 o 4 attestations antes de cargarlos de nuevo en SSV, para evitar slashings por doble sign.
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.
