Asumí que hacer staking en una cadena PoS significaba que una sola clave controlaba todo: metes DUSK, obtienes recompensas, y la misma clave lo gestiona de principio a fin.
La documentación oficial del operador de Dusk lo divide en dos.
La clave de consenso es la clave que usa un nodo para firmar y votar en el consenso. Tiene que residir en un nodo conectado a internet y participar mientras el validador opera. La clave de propietario es diferente: es la clave que puede deshacer el staking o retirar fondos, y la documentación indica que no necesita tocar el nodo en absoluto.
El beneficio de seguridad no es simplemente que existan dos claves. Es que la autoridad para participar en el consenso y la autoridad para retirar fondos no tienen que estar en el mismo lugar. Si la clave de consenso se ve comprometida porque el servidor en el que está alojada sufre una brecha, un atacante puede interferir con la participación en el consenso, pero aun así no puede desestacar ni retirar el stake. Esa autoridad nunca estuvo en la máquina que, en primer lugar, está expuesta a internet. En consecuencia, la pregunta real de seguridad no es solo cuánto está staked. Es dónde se encuentra realmente la autoridad para retirarlo en relación con la máquina que está expuesta a los atacantes.
Pero hay una trampa que la documentación no oculta: esta separación no es lo predeterminado. Si haces staking sin especificar un owner separado, la clave de consenso automáticamente pasa a ser también la clave de propietario: una clave, un límite, de vuelta al modelo que yo asumí originalmente. La configuración más segura es una elección que el operador tiene que hacer de forma activa, no algo que el protocolo les impone.
"Un límite de seguridad que hay que aceptar es una garantía distinta a la que se incorpora en el camino predeterminado, incluso cuando ambos están técnicamente disponibles".
Lo que realmente me gustaría saber: cuántos provisioners activos se ejecutan con una clave de propietario separada frente al valor predeterminado, porque eso me diría si el límite más fuerte se está adoptando de verdad, en lugar de que solo esté disponible.
#dusk $DUSK @Dusk
La documentación oficial del operador de Dusk lo divide en dos.
La clave de consenso es la clave que usa un nodo para firmar y votar en el consenso. Tiene que residir en un nodo conectado a internet y participar mientras el validador opera. La clave de propietario es diferente: es la clave que puede deshacer el staking o retirar fondos, y la documentación indica que no necesita tocar el nodo en absoluto.
El beneficio de seguridad no es simplemente que existan dos claves. Es que la autoridad para participar en el consenso y la autoridad para retirar fondos no tienen que estar en el mismo lugar. Si la clave de consenso se ve comprometida porque el servidor en el que está alojada sufre una brecha, un atacante puede interferir con la participación en el consenso, pero aun así no puede desestacar ni retirar el stake. Esa autoridad nunca estuvo en la máquina que, en primer lugar, está expuesta a internet. En consecuencia, la pregunta real de seguridad no es solo cuánto está staked. Es dónde se encuentra realmente la autoridad para retirarlo en relación con la máquina que está expuesta a los atacantes.
Pero hay una trampa que la documentación no oculta: esta separación no es lo predeterminado. Si haces staking sin especificar un owner separado, la clave de consenso automáticamente pasa a ser también la clave de propietario: una clave, un límite, de vuelta al modelo que yo asumí originalmente. La configuración más segura es una elección que el operador tiene que hacer de forma activa, no algo que el protocolo les impone.
"Un límite de seguridad que hay que aceptar es una garantía distinta a la que se incorpora en el camino predeterminado, incluso cuando ambos están técnicamente disponibles".
Lo que realmente me gustaría saber: cuántos provisioners activos se ejecutan con una clave de propietario separada frente al valor predeterminado, porque eso me diría si el límite más fuerte se está adoptando de verdad, en lugar de que solo esté disponible.
#dusk $DUSK @Dusk
