O NÓ DE BACKUP PODE SE TORNAR A FALHA.
Um aviso na documentação do provisioner do @Dusk me fez repensar o que “redundância” significa para um validador.
O Dusk avisa explicitamente os operadores para não executarem a mesma chave de consenso em vários nós ativos.
No começo, isso soa estranho.
Para uma infraestrutura normal, manter duas máquinas prontas para fazer o mesmo trabalho é exatamente o que reduz o tempo de indisponibilidade.
Mas uma chave de consenso é diferente.
Se dois nós ativos usarem a mesma identidade e acabarem assinando propostas ou votos conflitantes, a própria redundância pode se transformar em equivocation.
E o Dusk trata isso de um jeito bem diferente de simplesmente ficar offline.
Isso me trouxe uma distinção que eu não tinha pensado com clareza antes:
redundância de infraestrutura ≠ redundância de consenso.
Um provisioner quer um nó de backup pronto o suficiente para assumir rapidamente.
Mas não tão ativo que as duas máquinas possam falar pela mesma identidade de consenso ao mesmo tempo.
Isso torna o design de failover muito mais interessante do que apenas “rodar outro servidor”.
Existe uma linha tênue entre:
um nó falha → o backup assume
e
os dois nós acreditarem brevemente que são o signatário ativo.
No segundo caso, o sistema de segurança pode acabar se tornando a fonte do risco.
A documentação do Dusk classifica comportamentos conflitantes de consenso como o tipo de falha que pode levar a uma penalidade severa, incluindo queimar parte do stake.
Então, a métrica operacional pela qual eu me importaria não é apenas a disponibilidade do provisioner.
Eu gostaria de saber o quão confiável um operador consegue fazer o failover entre máquinas sem nunca criar uma chave de consenso ativo-ativo.
Essa é uma definição bem diferente de alta disponibilidade.
O backup mais seguro pode ser aquele que está completamente pronto para assinar —
mas que nunca assina até que o primeiro nó esteja definitivamente fora.
#dusk $DUSK @Dusk
$BTW
$HEMI
Um aviso na documentação do provisioner do @Dusk me fez repensar o que “redundância” significa para um validador.
O Dusk avisa explicitamente os operadores para não executarem a mesma chave de consenso em vários nós ativos.
No começo, isso soa estranho.
Para uma infraestrutura normal, manter duas máquinas prontas para fazer o mesmo trabalho é exatamente o que reduz o tempo de indisponibilidade.
Mas uma chave de consenso é diferente.
Se dois nós ativos usarem a mesma identidade e acabarem assinando propostas ou votos conflitantes, a própria redundância pode se transformar em equivocation.
E o Dusk trata isso de um jeito bem diferente de simplesmente ficar offline.
Isso me trouxe uma distinção que eu não tinha pensado com clareza antes:
redundância de infraestrutura ≠ redundância de consenso.
Um provisioner quer um nó de backup pronto o suficiente para assumir rapidamente.
Mas não tão ativo que as duas máquinas possam falar pela mesma identidade de consenso ao mesmo tempo.
Isso torna o design de failover muito mais interessante do que apenas “rodar outro servidor”.
Existe uma linha tênue entre:
um nó falha → o backup assume
e
os dois nós acreditarem brevemente que são o signatário ativo.
No segundo caso, o sistema de segurança pode acabar se tornando a fonte do risco.
A documentação do Dusk classifica comportamentos conflitantes de consenso como o tipo de falha que pode levar a uma penalidade severa, incluindo queimar parte do stake.
Então, a métrica operacional pela qual eu me importaria não é apenas a disponibilidade do provisioner.
Eu gostaria de saber o quão confiável um operador consegue fazer o failover entre máquinas sem nunca criar uma chave de consenso ativo-ativo.
Essa é uma definição bem diferente de alta disponibilidade.
O backup mais seguro pode ser aquele que está completamente pronto para assinar —
mas que nunca assina até que o primeiro nó esteja definitivamente fora.
#dusk $DUSK @Dusk
$BTW
$HEMI