O nó foi invadido; o mais chato, em geral, não é a parada em si, mas aquela chave usada para votar todos os dias—que talvez também permita retirar o valor do staking. Eu sempre categorizei isso como “falha do servidor”, até encontrar o guia de node wallet da Dusk. Foi na seção “Owner vs Consensus Keys” que mudei de ideia.
A Dusk permite colocar dois tipos de permissões no mesmo endereço. A consensus key é responsável por votar e assinar blocos, enquanto a owner key é quem controla a remoção do staking e os saques; se você não configurar um owner separado, a consensus key também acumula essas funções. A documentação sugere que, para separar o risco do nó do “caminho de saída” dos fundos, você configure um endereço owner por conta própria.
Eu antes achava que adicionar mais uma chave só aumentaria as etapas de operação e manutenção. Agora vejo que, na prática, isso admite: o nó precisa ficar online por muito tempo, mas o controle dos ativos não precisa ficar o tempo todo ao lado daquela máquina.
O cenário, ao fim e ao cabo, não é tão complicado: há vazamento de permissões do servidor, mas a owner key não está no servidor. Assim, o atacante pode atrapalhar o nó, porém não consegue retirar diretamente o staking. Se as duas permissões ficarem sempre acopladas, um incidente que começaria como problema de operação e manutenção vira um problema de fundos. Claro, a guarda e a transição do owner exigem mais uma camada de trabalho.
Por isso, eu encaro essa configuração como uma forma de fatiar o risco, e não como uma garantia de segurança. @Dusk Quer ajudar operadores comuns de nós a não caírem em armadilhas; o ideal é explicar de modo mais direto o que cada abordagem—“mesmo endereço” versus “endereços separados”—implica em termos de consequências. $DUSK O ecossistema de nós só fica realmente maduro quando não se avalia apenas quantos nós existem, mas também se os operadores entendem qual chave consegue mover dinheiro. #dusk