A maioria das blockchains enfrenta a saída em massa de nós offline; só existem dois caminhos: ou continuar forçando para produzir blocos conforme o plano original, e, se não der para reunir os validadores escolhidos, simplesmente travar e esperar pela próxima rodada; ou parar completamente, aguardando intervenção manual. O Dusk fica entre essas duas opções, e foi projetado especificamente com a terceira resposta.

A Seção 3.6 do whitepaper é bem detalhada: se a maioria dos Provisioners estiver offline ou isolada, e várias iterações consecutivas não conseguirem eleger pessoas para produzir blocos nem montar um comitê de votação que atinja o quórum, chegando ao limite de falha (atualmente definido como 16 ocorrências), o protocolo entra em modo de emergência.

Nesse modo, o mecanismo original de timeout é desativado; as iterações continuam até que, de fato, um bloco candidato seja produzido e que, nas duas etapas—verificação e aprovação—se reúnam as quantidades mínimas legais (quórum). Além disso, permite que várias iterações ocorram em paralelo ao mesmo tempo, aumentando a probabilidade de gerar um bloco válido em situações extremas.

Se nem esse conjunto de mecanismos conseguir aguentar, o protocolo ainda deixa uma última salvaguarda—um pedido conjunto, iniciado pelos Provisioners que detêm a maior parte das participações (stake). Esse pedido gera um “bloco de emergência” que não contém nenhuma transação, trazendo apenas novas sementes, para que a cadeia consiga avançar um pouco, evitando um travamento infinito.

Minha avaliação é que esse design, em essência, troca “risco de fork” por “sobrevivência da rede”: ao permitir que múltiplas iterações em paralelo rodem simultaneamente, a probabilidade de fork realmente aumenta. Mas esse custo é compensado pelas regras de fallback subsequentes, que limpam o “campo de batalha”, garantindo que a rede não morra totalmente em casos extremos.

Para instituições, esse modo de lidar com cenários de borda talvez seja ainda mais valioso para incluir na due diligence do que a liquidação em segundos do dia a dia—no estado normal, a maioria das blockchains em nível institucional já consegue entregar. A verdadeira diferença aparece quando o sistema falha: o que é fornecido é “degrada, mas continua operando” ou “trava direto”.

#dusk $DUSK @Dusk
Vocês acham que, ao avaliar a confiabilidade de uma blockchain, o desenho de contingência para situações extremas deve ter qual peso?