Hoy estuve investigando la delegación (staking) en el nodo de Dusk y me encontré con un problema: si la delegación proviene de un mismo sistema de billeteras, ¿por qué la documentación oficial recomienda separar la Owner Key y la Consensus Key? Después de leer la guía de billeteras del nodo, entendí que es algo más parecido a separar los permisos de “estar de turno” de los permisos de “llevarse el dinero”.
Pienso en la Consensus Key como el pase de trabajo de turno nocturno de una empresa. El nodo la usa para participar en el consenso, hacer votaciones y firmar mensajes de bloques; debe colocarse en una ubicación donde el servidor en línea pueda utilizarla. La Owner Key, en cambio, es como la llave principal del cofre de seguridad de la tesorería: se encarga de retirar (desbloquear/undelegar) y de extraer fondos. La configuración predeterminada oficial busca lo más fácil: si no se especifica explícitamente la dirección del propietario, la Consensus Key se convierte automáticamente en la Owner Key. Pero esto también significa que, si la máquina en línea es comprometida, el atacante que obtenga la clave correspondiente podría ver comprometidos también los permisos de retirar y extraer.
Otro enfoque recomendado por la propia documentación es delegar el staking a una dirección de propietario distinta, de modo que el nodo conserve solo el archivo de la clave de consenso, mientras que los permisos de los fondos se guardan por separado.
Este tipo de analogía tiene un límite: separar las dos claves no significa que, si el servidor es comprometido, automáticamente “ya está todo bien”. La Consensus Key todavía puede firmar mensajes de consenso; si se abusa de ella, o si la misma clave de consenso se ejecuta simultáneamente en dos nodos activos, podrían generarse mensajes conflictivos y provocar un hard penalty. En otras palabras: la separación protege principalmente los permisos de retiro y des-staking, pero el riesgo del consenso aún debe mitigarse mediante una operación correcta.
La intuición de los usuarios de BTC sobre “no atar los activos a una máquina en línea por mucho tiempo” no es desconocida; al llegar al escenario de staking en ETH, también es muy fácil entender por qué se separa la gestión de las responsabilidades de firma y los permisos de retiro. Dusk incluye esta división en la guía del nodo, y me hace prestar más atención a dónde se guardan las claves, en lugar de solo mirar si el nodo puede ejecutarse.
Para los delegadores (stakers) comunes de @Dusk , me gustaría que la billetera o las herramientas del nodo indiquen directamente si la Owner Key y la Consensus Key corresponden a la misma dirección, y que avisen qué clave, exactamente, necesita conservarse en el servidor. $DUSK necesita que más personas participen en el consenso a largo plazo; la experiencia de seguridad no puede consistir solo en “reducir un elemento de configuración”. Si en el futuro de verdad monto un nodo, dejaría las frases mnemónicas en un entorno sin conexión, guardaría la Owner Key por separado y recién después consideraría la tasa de estar en línea y las recompensas. Es mucho más tranquilo que meter todos los permisos en un solo servidor.
#dusk
Pienso en la Consensus Key como el pase de trabajo de turno nocturno de una empresa. El nodo la usa para participar en el consenso, hacer votaciones y firmar mensajes de bloques; debe colocarse en una ubicación donde el servidor en línea pueda utilizarla. La Owner Key, en cambio, es como la llave principal del cofre de seguridad de la tesorería: se encarga de retirar (desbloquear/undelegar) y de extraer fondos. La configuración predeterminada oficial busca lo más fácil: si no se especifica explícitamente la dirección del propietario, la Consensus Key se convierte automáticamente en la Owner Key. Pero esto también significa que, si la máquina en línea es comprometida, el atacante que obtenga la clave correspondiente podría ver comprometidos también los permisos de retirar y extraer.
Otro enfoque recomendado por la propia documentación es delegar el staking a una dirección de propietario distinta, de modo que el nodo conserve solo el archivo de la clave de consenso, mientras que los permisos de los fondos se guardan por separado.
Este tipo de analogía tiene un límite: separar las dos claves no significa que, si el servidor es comprometido, automáticamente “ya está todo bien”. La Consensus Key todavía puede firmar mensajes de consenso; si se abusa de ella, o si la misma clave de consenso se ejecuta simultáneamente en dos nodos activos, podrían generarse mensajes conflictivos y provocar un hard penalty. En otras palabras: la separación protege principalmente los permisos de retiro y des-staking, pero el riesgo del consenso aún debe mitigarse mediante una operación correcta.
La intuición de los usuarios de BTC sobre “no atar los activos a una máquina en línea por mucho tiempo” no es desconocida; al llegar al escenario de staking en ETH, también es muy fácil entender por qué se separa la gestión de las responsabilidades de firma y los permisos de retiro. Dusk incluye esta división en la guía del nodo, y me hace prestar más atención a dónde se guardan las claves, en lugar de solo mirar si el nodo puede ejecutarse.
Para los delegadores (stakers) comunes de @Dusk , me gustaría que la billetera o las herramientas del nodo indiquen directamente si la Owner Key y la Consensus Key corresponden a la misma dirección, y que avisen qué clave, exactamente, necesita conservarse en el servidor. $DUSK necesita que más personas participen en el consenso a largo plazo; la experiencia de seguridad no puede consistir solo en “reducir un elemento de configuración”. Si en el futuro de verdad monto un nodo, dejaría las frases mnemónicas en un entorno sin conexión, guardaría la Owner Key por separado y recién después consideraría la tasa de estar en línea y las recompensas. Es mucho más tranquilo que meter todos los permisos en un solo servidor.
#dusk