DKG
En un validador de Ethereum tradicional, se utiliza una única clave privada para firmar mensajes, validar bloques y proponer nuevos. Habitualmente, dicha clave se almacena en un solo dispositivo. Si ese dispositivo falla o se ve comprometido, el validador corre el riesgo de sufrir inactividad o penalizaciones. DVT resuelve este problema eliminando la noción de que un solo dispositivo custodia toda la clave. En su lugar, la clave se genera desde el principio de manera distribuida mediante un proceso denominado generación distribuida de claves (DKG).
Durante el DKG, varias partes colaboran para generar conjuntamente una clave privada sin que ninguna llegue a conocer el secreto completo. Cada participante conserva una fracción de la clave privada del validador. Este proceso emplea primitivas criptográficas avanzadas para garantizar que la clave pública final sea exactamente la clave pública BLS (Boneh–Lynn–Shacham) empleada en la capa de consenso de Ethereum. Las fracciones de clave generadas se vinculan matemáticamente y después pueden combinarse para generar firmas válidas en nombre del validador.
La fragmentación de claves mediante DKG es una característica de seguridad fundamental de DVT. Como ningún participante controla la clave completa, la configuración del validador es intrínsecamente resistente ante compromisos. Incluso si un nodo es hackeado o queda fuera de línea, el resto del grupo puede seguir operando mientras se disponga del umbral requerido de fracciones de clave para firmar.
Una vez distribuidas las fracciones de clave, el clúster de validadores debe efectuar sus tareas de firma, proponer bloques y emitir atestaciones sin reconstruir jamás la clave privada completa. Es aquí donde las firmas BLS por umbral y la computación multipartita adquieren relevancia.
El esquema de firma BLS, adoptado en la capa de consenso de Ethereum, admite firmas por umbral. En un entorno DVT, debe colaborar un número predefinido de participantes para generar una firma. Por ejemplo, en un clúster de cinco nodos, pueden requerirse al menos tres para producir una firma válida. Este umbral se establece en la fase de generación de claves y determina el nivel de tolerancia a fallos del validador.
El proceso de firma se realiza mediante computación multipartita segura. Cada participante firma un mensaje con su fracción de clave y estas firmas parciales se agregan para obtener una firma BLS completa que se envía a la beacon chain de Ethereum. En ningún momento se reconstruye ni se expone la clave privada completa durante este proceso.
La MPC garantiza que el validador opere con seguridad incluso cuando hay participantes poco fiables o no confiables. Proporciona garantías criptográficas que permiten a un grupo de nodos independientes comportarse, desde la perspectiva de la red, como un único validador. Esta abstracción permite que DVT sea compatible con Ethereum sin necesidad de modificar el protocolo ni las reglas de consenso.
Un clúster DVT está formado por varios nodos que operan como parte de un cliente validador distribuido. Estos nodos deben comunicarse continuamente para mantenerse sincronizados, coordinar tareas y compartir información como propuestas de bloques, atestaciones y firmas parciales. Para ello, la mayoría de sistemas DVT emplean una capa de comunicación entre pares basada en el protocolo gossip.
En una red gossip, los nodos transmiten mensajes a un subconjunto de sus pares, quienes a su vez difunden la información. Este modelo descentralizado reduce el riesgo de cuellos de botella en la comunicación y evita que ningún nodo se convierta en un punto único de fallo. Los protocolos gossip son resistentes a fallos de nodos y a particiones de red, lo que los convierte en una opción idónea para la coordinación de validadores.
El cliente validador distribuido —por ejemplo, Charon de Obol o el software de nodos de SSV.Network— implementa la lógica para coordinar firmas, recuperar errores y hacer seguimiento de la participación. Están diseñados para ser compatibles con las principales pilas de validadores de Ethereum, como Prysm, Lighthouse, Teku y Nimbus. Esto implica que cada nodo de un clúster DVT puede emplear clientes de consenso estándar de Ethereum mientras ejecuta en paralelo la lógica DVT.
La compatibilidad con clientes es clave para la adopción. Los operadores no necesitan modificar toda su infraestructura para dar soporte a DVT, sino que pueden mantener su software habitual y beneficiarse de una mayor tolerancia a fallos y reparto de responsabilidades. Esta arquitectura plug-and-play favorece la integración de DVT en operaciones de staking existentes, sin añadir complejidad operativa innecesaria.
Aunque DVT incrementa la descentralización y la tolerancia a fallos, introduce a su vez ciertos compromisos. Uno de los más relevantes es la latencia. En un validador tradicional, la firma es instantánea en una máquina local. En un entorno DVT, la firma debe coordinarse entre varios nodos, cada uno de los cuales aporta una firma parcial antes del resultado final. Esto supone un mayor tráfico de comunicaciones y puede causar retrasos si la red está saturada o algunos participantes son lentos en responder.
Para mitigar este aspecto, los sistemas DVT establecen un quórum, es decir, el mínimo de nodos requeridos para producir una firma. El tamaño del quórum busca un equilibrio entre seguridad y disponibilidad: un quórum más pequeño incrementa la rapidez y la resiliencia ante nodos lentos, pero reduce el margen de fallos tolerable. Un quórum mayor aumenta la tolerancia a fallos, pero puede ralentizar la firma y hacerla más sensible a retrasos.
Por ejemplo, en un clúster DVT de 5 de 7, cinco nodos deben estar en línea y responder para que se genere una firma. Este diseño permite tolerar hasta dos nodos inactivos o no disponibles. Si fallan tres o más, el validador no puede firmar y se expone a penalizaciones por inactividad. Estos parámetros deben definirse cuidadosamente en función del riesgo asumido y de la distribución geográfica de los nodos.
Todo el funcionamiento de DVT parte del supuesto de mayoría honesta. El protocolo presupone que un número suficiente de nodos cumplirá las normas y actuará en beneficio de la red. Si demasiados nodos se ven comprometidos o conspiraran de forma maliciosa, podrían generar firmas inválidas o impedir deliberadamente la participación del validador. Aunque estos casos resultan improbables en clústeres bien diseñados, deben contemplarse en los modelos de amenazas y la planificación operativa.
En la práctica, los clústeres DVT suelen estar formados por operadores independientes o colectivos de staking con incentivos compartidos. Esto reduce las posibilidades de colusión y fortalece la seguridad del sistema. A medida que evoluciona la tecnología, surgirán nuevos mecanismos de coordinación, modelos de confianza y sistemas de reputación que reforzarán aún más las garantías de la validación distribuida.