La clave que un provisionador de Dusk no tiene que poseer la participación
Comprometer un servidor de provisioner no tiene que otorgar a un atacante autoridad de retiro sobre el DUSK detrás de él.
El staking de Dusk separa dos roles. La Clave de Consenso es el credencial en línea que usa el nodo para votar y firmar bloques. La Clave de Propietario controla el des-staking y el retiro de la participación. Si no se especifica ningún propietario, la clave de consenso se convierte en el propietario de forma predeterminada. Pero Dusk también admite el staking rusk-wallet --owner <OWNER_ADDRESS> para separarlas.
Eso cambia el límite de seguridad de un provisionador.
El nodo necesita consensus.keys para participar en el consenso; no necesita que la billetera del propietario esté a su lado. La guía de operación actual de Dusk recomienda explícitamente mantener la billetera del propietario y el material de recuperación fuera del nodo.
Así, un operador puede tratar la Clave de Consenso como un credencial operacional “en caliente” sin otorgar automáticamente a ese entorno caliente la capacidad de salir con el capital.
La separación no es una protección absoluta. Una Clave de Consenso robada aún puede firmar mensajes de consenso contradictorios o, de otro modo, inválidos, y las sanciones estrictas de Dusk pueden quemar la participación por ese comportamiento.
Por lo tanto, la decisión práctica ocurre antes del staking: usar la configuración predeterminada combina la autoridad de consenso y la autoridad de control del capital; especificar un propietario separado reduce lo que un host de validador comprometido puede hacer directamente.
@Dusk $DUSK #dusk
Comprometer un servidor de provisioner no tiene que otorgar a un atacante autoridad de retiro sobre el DUSK detrás de él.
El staking de Dusk separa dos roles. La Clave de Consenso es el credencial en línea que usa el nodo para votar y firmar bloques. La Clave de Propietario controla el des-staking y el retiro de la participación. Si no se especifica ningún propietario, la clave de consenso se convierte en el propietario de forma predeterminada. Pero Dusk también admite el staking rusk-wallet --owner <OWNER_ADDRESS> para separarlas.
Eso cambia el límite de seguridad de un provisionador.
El nodo necesita consensus.keys para participar en el consenso; no necesita que la billetera del propietario esté a su lado. La guía de operación actual de Dusk recomienda explícitamente mantener la billetera del propietario y el material de recuperación fuera del nodo.
Así, un operador puede tratar la Clave de Consenso como un credencial operacional “en caliente” sin otorgar automáticamente a ese entorno caliente la capacidad de salir con el capital.
La separación no es una protección absoluta. Una Clave de Consenso robada aún puede firmar mensajes de consenso contradictorios o, de otro modo, inválidos, y las sanciones estrictas de Dusk pueden quemar la participación por ese comportamiento.
Por lo tanto, la decisión práctica ocurre antes del staking: usar la configuración predeterminada combina la autoridad de consenso y la autoridad de control del capital; especificar un propietario separado reduce lo que un host de validador comprometido puede hacer directamente.
@Dusk $DUSK #dusk
