A sala de servidores ficou sem internet por dez minutos e, com a mesma chave, eu assinei duas vezes resultados conflitantes. Dá para punir com a mesma gravidade? Se a resposta for “queimar moedas”, eu na verdade não ouso rodar o nó.
Eu reavaliei novamente as regras de delegação (staking) atuais do @Dusk . O Dusk divide as sanções de consenso em soft e hard, mas a linha real de separação não é se o dono do nó tem ou não intenção maliciosa por palavras; é o que fica como evidência na cadeia.
A penalidade soft é para ações falhas em que a participação não deu certo, por exemplo, quando não é capaz de produzir blocos-candidatos válidos. O protocolo pode pausar a qualificação do nó e mover parte do active stake para locked stake. As quantias ainda pertencem ao delegador, mas temporariamente perdem a capacidade de participar do consenso e de ganhar recompensas.
A penalidade hard é para comportamentos comprovadamente inválidos, incluindo votos inválidos e assinaturas duplicadas de propostas ou votos em conflitos. Além de pausar a qualificação, o protocolo também pode destruir diretamente parte do stake, porque a assinatura já constitui evidência de quebra do consenso.
O protocolo não vai decidir por conta própria se foi um ataque ou um “escorregão” operacional. O aviso oficial é especialmente claro: não é permitido que a mesma <consensus key> funcione ao mesmo tempo em duas máquinas-nó ativas. Durante a migração, se o nó antigo ainda não tiver sido desligado e o novo nó já começar a assinar, um acidente operacional também pode gerar mensagens de conflito e sofrer punição hard.
Portanto, o risco do staking não pode ser avaliado apenas pelo APY. A penalidade soft afeta o staking efetivo e a receita de parar o trabalho; a penalidade hard pode atingir o principal. Vou acompanhar o fault count, o locked stake, a duração da pausa e as assinaturas em conflito. O staking $DUSK não é como um depósito: é uma garantia de um sistema de produção que precisa ficar online continuamente, com uma chave única.
#dusk $DUSK
Eu reavaliei novamente as regras de delegação (staking) atuais do @Dusk . O Dusk divide as sanções de consenso em soft e hard, mas a linha real de separação não é se o dono do nó tem ou não intenção maliciosa por palavras; é o que fica como evidência na cadeia.
A penalidade soft é para ações falhas em que a participação não deu certo, por exemplo, quando não é capaz de produzir blocos-candidatos válidos. O protocolo pode pausar a qualificação do nó e mover parte do active stake para locked stake. As quantias ainda pertencem ao delegador, mas temporariamente perdem a capacidade de participar do consenso e de ganhar recompensas.
A penalidade hard é para comportamentos comprovadamente inválidos, incluindo votos inválidos e assinaturas duplicadas de propostas ou votos em conflitos. Além de pausar a qualificação, o protocolo também pode destruir diretamente parte do stake, porque a assinatura já constitui evidência de quebra do consenso.
O protocolo não vai decidir por conta própria se foi um ataque ou um “escorregão” operacional. O aviso oficial é especialmente claro: não é permitido que a mesma <consensus key> funcione ao mesmo tempo em duas máquinas-nó ativas. Durante a migração, se o nó antigo ainda não tiver sido desligado e o novo nó já começar a assinar, um acidente operacional também pode gerar mensagens de conflito e sofrer punição hard.
Portanto, o risco do staking não pode ser avaliado apenas pelo APY. A penalidade soft afeta o staking efetivo e a receita de parar o trabalho; a penalidade hard pode atingir o principal. Vou acompanhar o fault count, o locked stake, a duração da pausa e as assinaturas em conflito. O staking $DUSK não é como um depósito: é uma garantia de um sistema de produção que precisa ficar online continuamente, com uma chave única.
#dusk $DUSK
