Tivemos um período de cortes de energia em Islamabad na semana passada em que a rede simplesmente continuou falhando de novo e de novo, e toda vez que voltava, o sistema de backup tinha que reiniciar do zero em vez de retomar de onde parou. Eu assumi que o modo de emergência da Dusk funcionava do mesmo jeito: travamentos na rede, ele só continua tentando com o mesmo tempo limite fixo até que algo funcione.
Não é isso que acontece. O modo de emergência só entra depois de 16 iterações consecutivas falhas, e, quando é ativado, toda a estrutura de timeouts é removida. As iterações não expiram mais; elas rodam indefinidamente até que um bloco candidato seja de fato proposto e chegue ao quórum tanto na validação quanto na ratificação. Votos de NoCandidate e NoQuorum também ficam desativados, então cada etapa precisa realmente ter sucesso antes de a próxima começar.
O que de fato redefiniu isso para mim é que várias dessas iterações abertas podem rodar ao mesmo tempo. Isso não é uma falha; é intencional. Ele aumenta as chances de que pelo menos uma produza um bloco válido. A contrapartida é um maior risco de fork, que é resolvido sempre escolhendo o candidato que chegou ao consenso no menor número de iteração.
Existe também um último recurso dentro do último recurso. Se até a iteração final travar, os provedores que detêm a maioria do stake total podem solicitar um bloco de emergência: um bloco especial vazio assinado pela Dusk, sem transações, apenas para manter a rodada em movimento.
O que o whitepaper não diz é com que frequência isso realmente foi acionado na infraestrutura real da Dusk até agora. Eu não tenho dados para sustentar uma alegação de frequência.
O teste real para a DUSK é quão raramente o modo de emergência precisa ser acionado depois que o mainnet rodar em escala real.
Alguém já testemunhou o modo de emergência sendo disparado na Dusk até agora?
@Dusk #dusk $DUSK
Não é isso que acontece. O modo de emergência só entra depois de 16 iterações consecutivas falhas, e, quando é ativado, toda a estrutura de timeouts é removida. As iterações não expiram mais; elas rodam indefinidamente até que um bloco candidato seja de fato proposto e chegue ao quórum tanto na validação quanto na ratificação. Votos de NoCandidate e NoQuorum também ficam desativados, então cada etapa precisa realmente ter sucesso antes de a próxima começar.
O que de fato redefiniu isso para mim é que várias dessas iterações abertas podem rodar ao mesmo tempo. Isso não é uma falha; é intencional. Ele aumenta as chances de que pelo menos uma produza um bloco válido. A contrapartida é um maior risco de fork, que é resolvido sempre escolhendo o candidato que chegou ao consenso no menor número de iteração.
Existe também um último recurso dentro do último recurso. Se até a iteração final travar, os provedores que detêm a maioria do stake total podem solicitar um bloco de emergência: um bloco especial vazio assinado pela Dusk, sem transações, apenas para manter a rodada em movimento.
O que o whitepaper não diz é com que frequência isso realmente foi acionado na infraestrutura real da Dusk até agora. Eu não tenho dados para sustentar uma alegação de frequência.
O teste real para a DUSK é quão raramente o modo de emergência precisa ser acionado depois que o mainnet rodar em escala real.
Alguém já testemunhou o modo de emergência sendo disparado na Dusk até agora?
@Dusk #dusk $DUSK
