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