El nodo fue comprometido; lo más problemático muchas veces no es que se detenga, sino esa llave con la que se vota cada día, que además podría permitir retirar el staking. Yo antes siempre lo atribuía a que el servidor no estaba bien gestionado, hasta que encontré la guía de la wallet del nodo de Dusk. En la sección de "Owner vs Consensus Keys" me hizo cambiar de opinión.
Dusk permite poner dos tipos de permisos en una misma dirección. La consensus key se encarga de votar y firmar bloques, mientras que la owner key es la que gestiona la eliminación del staking y los retiros; si no se configura un owner por separado, la consensus key también actúa como owner. En la documentación se recomienda que, si quieres separar el riesgo del nodo de la salida de fondos, configures una dirección owner aparte.
Antes pensaba que tener una llave más solo incrementa los pasos operativos. Ahora veo que en realidad está reconociendo esto: el nodo debe estar en línea durante mucho tiempo, pero no hace falta mantener el control de los activos todo el tiempo junto a esa máquina.
El escenario, dicho sin rodeos, no es complicado: se filtra el permiso del servidor, pero la owner key no está en el servidor. El atacante puede interferir con el nodo, pero no puede retirar directamente el staking. Si ambos tipos de permisos se mantienen unidos todo el tiempo, el incidente pasa de ser un problema operativo a ser un problema de fondos. Claro, la custodia y la transferencia de la owner también añaden una capa extra de trabajo.
Por eso considero este diseño como una forma de dividir el riesgo, no como una garantía de seguridad. @Dusk quiere que los operadores de nodos comunes tropiecen con menos obstáculos; para ello, conviene decir de forma más directa qué consecuencias trae "la misma dirección" frente a "dirección separada". $DUSK , la verdadera madurez del ecosistema de nodos no solo se mide por cuántos nodos hay, sino también por si los operadores tienen claro qué llave puede mover el dinero. #dusk