Hoje, ao pesquisar o staking do nó Dusk, fiquei preso numa questão: como o staking vem de um mesmo sistema de carteiras, por que a equipe oficial ainda recomenda separar a Owner Key e a Consensus Key? Depois de ler o guia das carteiras do nó, entendi: é algo mais parecido com separar “permissões de plantão” de “permissões para tirar o dinheiro”.
Pensei na Consensus Key como o crachá de trabalho do turno noturno de uma empresa. O nó precisa dela para participar do consenso, fazer votos e assinar mensagens de blocos; por isso, ela deve ficar num local que o servidor online consiga usar. Já a Owner Key é como a chave-mestra do cofre do setor financeiro: ela é responsável por cancelar o staking (undelegate) e por sacar fundos. A configuração padrão oficial é a opção mais simples: quando você não especifica explicitamente os endereços do proprietário, a Consensus Key passa a ser automaticamente a Owner Key. Mas isso também significa que, se a máquina online for comprometida, um atacante que obtenha as chaves correspondentes pode acabar comprometendo também as permissões de cancelar o staking e sacar.
Outra prática recomendada pela equipe oficial é indicar um outro endereço de proprietário para o staking: assim, o nó mantém apenas o arquivo da chave de consenso, enquanto as permissões de movimentação de fundos ficam guardadas separadamente.
Essa analogia tem um limite: separar as duas chaves não significa que, caso o servidor seja invadido, ficará tudo resolvido. A Consensus Key ainda consegue assinar mensagens de consenso; se ela for abusada, ou se a mesma chave de consenso estiver rodando em duas instâncias ativas de nós ao mesmo tempo, pode gerar mensagens em conflito e acionar hard penalty. Ou seja, a separação protege principalmente as permissões de saque e de cancelamento do staking, mas o risco do consenso continua dependendo de uma operação correta.
A intuição de segurança de usuários de BTC — “não deixar ativos de longo prazo presos a máquinas online” — não é novidade. No cenário de staking da ETH, separar as responsabilidades de assinatura das permissões de saque também faz bastante sentido. O Dusk incorporou essa divisão no guia do nó, e isso me fez me preocupar mais com onde as chaves ficam guardadas, e não apenas se o nó consegue rodar.
Para os stakers comuns de @Dusk , espero que a carteira ou as ferramentas do nó indiquem diretamente se a Owner Key e a Consensus Key são do mesmo endereço e avisem qual chave o servidor realmente precisa salvar. Para $DUSK , que precisa contar com mais pessoas participando do consenso por muito tempo, a experiência de segurança não pode buscar apenas “ter menos um item para configurar”. Se no futuro eu realmente montar um nó, vou primeiro deixar as palavras-mnemônicas em um ambiente offline, guardar a Owner Key separadamente e só então considerar a taxa de tempo online e os incentivos; isso me dá mais tranquilidade do que colocar todas as permissões numa única máquina.
#dusk
Pensei na Consensus Key como o crachá de trabalho do turno noturno de uma empresa. O nó precisa dela para participar do consenso, fazer votos e assinar mensagens de blocos; por isso, ela deve ficar num local que o servidor online consiga usar. Já a Owner Key é como a chave-mestra do cofre do setor financeiro: ela é responsável por cancelar o staking (undelegate) e por sacar fundos. A configuração padrão oficial é a opção mais simples: quando você não especifica explicitamente os endereços do proprietário, a Consensus Key passa a ser automaticamente a Owner Key. Mas isso também significa que, se a máquina online for comprometida, um atacante que obtenha as chaves correspondentes pode acabar comprometendo também as permissões de cancelar o staking e sacar.
Outra prática recomendada pela equipe oficial é indicar um outro endereço de proprietário para o staking: assim, o nó mantém apenas o arquivo da chave de consenso, enquanto as permissões de movimentação de fundos ficam guardadas separadamente.
Essa analogia tem um limite: separar as duas chaves não significa que, caso o servidor seja invadido, ficará tudo resolvido. A Consensus Key ainda consegue assinar mensagens de consenso; se ela for abusada, ou se a mesma chave de consenso estiver rodando em duas instâncias ativas de nós ao mesmo tempo, pode gerar mensagens em conflito e acionar hard penalty. Ou seja, a separação protege principalmente as permissões de saque e de cancelamento do staking, mas o risco do consenso continua dependendo de uma operação correta.
A intuição de segurança de usuários de BTC — “não deixar ativos de longo prazo presos a máquinas online” — não é novidade. No cenário de staking da ETH, separar as responsabilidades de assinatura das permissões de saque também faz bastante sentido. O Dusk incorporou essa divisão no guia do nó, e isso me fez me preocupar mais com onde as chaves ficam guardadas, e não apenas se o nó consegue rodar.
Para os stakers comuns de @Dusk , espero que a carteira ou as ferramentas do nó indiquem diretamente se a Owner Key e a Consensus Key são do mesmo endereço e avisem qual chave o servidor realmente precisa salvar. Para $DUSK , que precisa contar com mais pessoas participando do consenso por muito tempo, a experiência de segurança não pode buscar apenas “ter menos um item para configurar”. Se no futuro eu realmente montar um nó, vou primeiro deixar as palavras-mnemônicas em um ambiente offline, guardar a Owner Key separadamente e só então considerar a taxa de tempo online e os incentivos; isso me dá mais tranquilidade do que colocar todas as permissões numa única máquina.
#dusk