A chave que um provedor de Dusk executando não precisa necessariamente possuir a participação
Comprometer um servidor de provisionador não precisa dar ao atacante autoridade de retirada sobre o DUSK por trás dele.
O staking no Dusk separa duas funções. A Chave de Consenso é a credencial online usada pelo nó para votar e assinar blocos. A Chave do Proprietário controla o destroncamento (unstaking) e a retirada da participação. Se nenhum proprietário for especificado, a chave de consenso se torna o proprietário por padrão. Mas o Dusk também oferece suporte ao staking com rusk-wallet --owner <OWNER_ADDRESS> para separá-las.
Isso muda o limite de segurança de um provisionador.
O nó precisa de consensus.keys para participar do consenso; ele não precisa da carteira do proprietário ao lado. A orientação atual da Dusk para operadores recomenda explicitamente manter a carteira do proprietário e o material de recuperação fora do nó.
Assim, o operador pode tratar a Chave de Consenso como uma credencial operacional “quente” sem, automaticamente, conceder a esse ambiente “quente” a capacidade de sair com o capital.
A separação não é proteção absoluta. Uma Chave de Consenso roubada ainda pode assinar mensagens de consenso conflitantes ou de outra forma inválidas, e as penalidades rígidas do Dusk podem queimar a participação por esse comportamento.
A decisão prática, portanto, acontece antes do staking: usar a configuração padrão combina autoridade de consenso e autoridade de controle do capital; especificar um proprietário separado restringe o que um host de validador comprometido pode fazer diretamente.
@Dusk $DUSK #dusk
Comprometer um servidor de provisionador não precisa dar ao atacante autoridade de retirada sobre o DUSK por trás dele.
O staking no Dusk separa duas funções. A Chave de Consenso é a credencial online usada pelo nó para votar e assinar blocos. A Chave do Proprietário controla o destroncamento (unstaking) e a retirada da participação. Se nenhum proprietário for especificado, a chave de consenso se torna o proprietário por padrão. Mas o Dusk também oferece suporte ao staking com rusk-wallet --owner <OWNER_ADDRESS> para separá-las.
Isso muda o limite de segurança de um provisionador.
O nó precisa de consensus.keys para participar do consenso; ele não precisa da carteira do proprietário ao lado. A orientação atual da Dusk para operadores recomenda explicitamente manter a carteira do proprietário e o material de recuperação fora do nó.
Assim, o operador pode tratar a Chave de Consenso como uma credencial operacional “quente” sem, automaticamente, conceder a esse ambiente “quente” a capacidade de sair com o capital.
A separação não é proteção absoluta. Uma Chave de Consenso roubada ainda pode assinar mensagens de consenso conflitantes ou de outra forma inválidas, e as penalidades rígidas do Dusk podem queimar a participação por esse comportamento.
A decisão prática, portanto, acontece antes do staking: usar a configuração padrão combina autoridade de consenso e autoridade de controle do capital; especificar um proprietário separado restringe o que um host de validador comprometido pode fazer diretamente.
@Dusk $DUSK #dusk
