Pessoal, a maioria das blockchains assume que o consenso continua avançando. $DUSK Na verdade, ela tem um plano para quando isso não acontece.
No seu consenso SA, cada bloco carrega uma seed derivada da assinatura do gerador de bloco anterior. Isso muda constantemente a aleatoriedade, tornando difícil prever com antecedência os futuros geradores e comitês de blocos.
Mas a parte mais interessante é o que acontece quando as coisas dão errado.
Se provisionadores suficientes ficarem offline e 16 iterações consecutivas falharem, o Dusk entra em modo de emergência. Em vez de simplesmente desistir, a rede continua tentando até que um bloco candidato atinja quórum.
Várias iterações ainda podem permanecer abertas ao mesmo tempo, aumentando a chance de uma delas ter sucesso. A troca? Mais tentativas simultâneas também podem criar forks, que o Dusk resolve selecionando o candidato da menor iteração.
E se a rede chegar à iteração final sem progresso, provisionadores que detêm a maioria do stake podem solicitar um bloco de emergência. Esse bloco não contém transações, mas dá à rede uma nova seed para ela avançar para a próxima rodada.
Eu particularmente acho isso mais interessante do que a habitual alegação de “consenso rápido”. Isso mostra o que o protocolo faz quando a rede se comporta mal — não apenas quando tudo funciona perfeitamente.
Mas eu continuo pensando: ter um caminho de emergência elaborado torna o Dusk mais resiliente, ou a complexidade adicionada introduz novos casos extremos?
Você preferiria usar uma blockchain com um mecanismo detalhado de recuperação de falhas, ou uma com um design de consenso mais simples?
#dusk $DUSK @Dusk
No seu consenso SA, cada bloco carrega uma seed derivada da assinatura do gerador de bloco anterior. Isso muda constantemente a aleatoriedade, tornando difícil prever com antecedência os futuros geradores e comitês de blocos.
Mas a parte mais interessante é o que acontece quando as coisas dão errado.
Se provisionadores suficientes ficarem offline e 16 iterações consecutivas falharem, o Dusk entra em modo de emergência. Em vez de simplesmente desistir, a rede continua tentando até que um bloco candidato atinja quórum.
Várias iterações ainda podem permanecer abertas ao mesmo tempo, aumentando a chance de uma delas ter sucesso. A troca? Mais tentativas simultâneas também podem criar forks, que o Dusk resolve selecionando o candidato da menor iteração.
E se a rede chegar à iteração final sem progresso, provisionadores que detêm a maioria do stake podem solicitar um bloco de emergência. Esse bloco não contém transações, mas dá à rede uma nova seed para ela avançar para a próxima rodada.
Eu particularmente acho isso mais interessante do que a habitual alegação de “consenso rápido”. Isso mostra o que o protocolo faz quando a rede se comporta mal — não apenas quando tudo funciona perfeitamente.
Mas eu continuo pensando: ter um caminho de emergência elaborado torna o Dusk mais resiliente, ou a complexidade adicionada introduz novos casos extremos?
Você preferiria usar uma blockchain com um mecanismo detalhado de recuperação de falhas, ou uma com um design de consenso mais simples?
#dusk $DUSK @Dusk