LA MÁQUINA QUE FIRMA PARA UN PROVISIONADOR DE ATARDECER NO TIENE QUE POSEER LA GARANTÍA.
He estado pensando en una clave de validador como si representara una sola cosa:
control.
Pero @Dusk divide ese control en dos funciones muy diferentes.
La Clave de Consenso es la que usa el nodo para participar en el consenso: votar y firmar bloques.
La Clave del Propietario es la que puede desestacar y retirar el capital que respalda a ese provisionador.
Dusk permite que ambos roles usen la misma clave por defecto.
Pero su documentación para operadores recomienda separarlas.
Esa distinción es más interesante para mí de lo que suena a primera vista:
la autoridad de consenso ≠ la autoridad de propiedad.
Un provisionador tiene que mantener su clave de consenso disponible en una máquina en línea que está participando constantemente en la red.
Ese es exactamente el tipo de entorno en el que menos querría dar una autoridad innecesaria sobre la garantía en sí.
Si se compromete el nodo o la clave de consenso, separar la Clave del Propietario significa que el atacante no obtiene automáticamente la capacidad de desestacar y retirar los fondos.
Así que el diseño está haciendo algo sutil.
No solo está protegiendo una clave.
Está limitando el radio de impacto de la clave que tiene que seguir en funcionamiento.
Pero hay un intercambio.
Al trasladar la autoridad de propiedad fuera del nodo, la Clave del Propietario ahora debe protegerse en algún otro lugar mientras sigue siendo recuperable cuando el operador realmente necesite desestacar o retirar.
Más separación puede reducir un tipo de riesgo mientras aumenta la responsabilidad operativa en otro lugar.
Esa es la parte que evaluaría.
No solo si un provisionador de Dusk es difícil de comprometer.
Yo preguntaría:
Si la máquina de consenso se compromete mañana, ¿cuánta autoridad hereda realmente el atacante?
Para infraestructuras que tienen que mantenerse en línea 24/7, tal vez el modelo de seguridad más sólido no es darle a la máquina más protección.
Es darle a la máquina menos poder desde el principio.
#dusk $DUSK @Dusk
$BOME $ETH
He estado pensando en una clave de validador como si representara una sola cosa:
control.
Pero @Dusk divide ese control en dos funciones muy diferentes.
La Clave de Consenso es la que usa el nodo para participar en el consenso: votar y firmar bloques.
La Clave del Propietario es la que puede desestacar y retirar el capital que respalda a ese provisionador.
Dusk permite que ambos roles usen la misma clave por defecto.
Pero su documentación para operadores recomienda separarlas.
Esa distinción es más interesante para mí de lo que suena a primera vista:
la autoridad de consenso ≠ la autoridad de propiedad.
Un provisionador tiene que mantener su clave de consenso disponible en una máquina en línea que está participando constantemente en la red.
Ese es exactamente el tipo de entorno en el que menos querría dar una autoridad innecesaria sobre la garantía en sí.
Si se compromete el nodo o la clave de consenso, separar la Clave del Propietario significa que el atacante no obtiene automáticamente la capacidad de desestacar y retirar los fondos.
Así que el diseño está haciendo algo sutil.
No solo está protegiendo una clave.
Está limitando el radio de impacto de la clave que tiene que seguir en funcionamiento.
Pero hay un intercambio.
Al trasladar la autoridad de propiedad fuera del nodo, la Clave del Propietario ahora debe protegerse en algún otro lugar mientras sigue siendo recuperable cuando el operador realmente necesite desestacar o retirar.
Más separación puede reducir un tipo de riesgo mientras aumenta la responsabilidad operativa en otro lugar.
Esa es la parte que evaluaría.
No solo si un provisionador de Dusk es difícil de comprometer.
Yo preguntaría:
Si la máquina de consenso se compromete mañana, ¿cuánta autoridad hereda realmente el atacante?
Para infraestructuras que tienen que mantenerse en línea 24/7, tal vez el modelo de seguridad más sólido no es darle a la máquina más protección.
Es darle a la máquina menos poder desde el principio.
#dusk $DUSK @Dusk
$BOME $ETH