#dusk $DUSK
A frase "modo de emergência" continuava aparecendo no whitepaper da Dusk e eu ia passando por ela. Quando eu de fato li a seção, o mecanismo é mais específico do que o nome sugere.
Consenso normal da Dusk: cada rodada vai até um máximo de 50 iterações. Em cada etapa, Proposta, Validação, Ratificação, há um tempo limite (timeout). Se nenhum quórum se formar antes do timeout, a etapa avança e eventualmente uma nova iteração começa. Sequencial, limitado, previsível.
O modo de emergência é diferente. Ele é acionado após 16 iterações consecutivas falhas — em que falha significa que não houve quórum, tipicamente porque validadores estão offline ou isolados. Quando é acionado: os timeouts das etapas são desativados. Novas iterações são iniciadas, mas cada iteração em andamento permanece ativa em vez de ser encerrada. Múltiplas iterações abertas ficam rodando em paralelo. Isso aumenta a chance de produzir um bloco. Também aumenta a chance de forks.
Forks no modo de emergência são resolvidos escolhendo o bloco do menor número de iteração. Se a rede ainda não conseguir formar um bloco, o último recurso é um bloco de emergência: um bloco vazio, sem transações, assinado pela Dusk, a entidade, usando sua chave pública global. Provedores (provisioners) que detêm a maioria do stake solicitam isso.
Então por que a rede não simplesmente roda o modo de emergência sempre que quiser ficar mais rápida.
O modo normal troca um pouco de velocidade por uma finalização mais limpa. Iterações abertas em concorrência aumentam a vivacidade sob estresse, mas introduzem complexidade que o fallback do bloco vazio é uma intervenção centralizada — a cadeia continua avançando, mas é a entidade Dusk quem a está movendo.
Eu realmente acho que o bloco de emergência é a questão de design mais interessante — porque isso significa que a garantia de vivacidade depende, no fim das contas, da disponibilidade e da disposição da entidade Dusk em assinar. A segurança do protocolo e a descentralização puxam em direções ligeiramente diferentes.
O que eu não vi explicado é o que acontece com transações que estavam em andamento quando um bloco de emergência substitui um bloco normal — se elas são reincluídas na próxima rodada ou se são descartadas. @Dusk
$DUSK #dusk
A frase "modo de emergência" continuava aparecendo no whitepaper da Dusk e eu ia passando por ela. Quando eu de fato li a seção, o mecanismo é mais específico do que o nome sugere.
Consenso normal da Dusk: cada rodada vai até um máximo de 50 iterações. Em cada etapa, Proposta, Validação, Ratificação, há um tempo limite (timeout). Se nenhum quórum se formar antes do timeout, a etapa avança e eventualmente uma nova iteração começa. Sequencial, limitado, previsível.
O modo de emergência é diferente. Ele é acionado após 16 iterações consecutivas falhas — em que falha significa que não houve quórum, tipicamente porque validadores estão offline ou isolados. Quando é acionado: os timeouts das etapas são desativados. Novas iterações são iniciadas, mas cada iteração em andamento permanece ativa em vez de ser encerrada. Múltiplas iterações abertas ficam rodando em paralelo. Isso aumenta a chance de produzir um bloco. Também aumenta a chance de forks.
Forks no modo de emergência são resolvidos escolhendo o bloco do menor número de iteração. Se a rede ainda não conseguir formar um bloco, o último recurso é um bloco de emergência: um bloco vazio, sem transações, assinado pela Dusk, a entidade, usando sua chave pública global. Provedores (provisioners) que detêm a maioria do stake solicitam isso.
Então por que a rede não simplesmente roda o modo de emergência sempre que quiser ficar mais rápida.
O modo normal troca um pouco de velocidade por uma finalização mais limpa. Iterações abertas em concorrência aumentam a vivacidade sob estresse, mas introduzem complexidade que o fallback do bloco vazio é uma intervenção centralizada — a cadeia continua avançando, mas é a entidade Dusk quem a está movendo.
Eu realmente acho que o bloco de emergência é a questão de design mais interessante — porque isso significa que a garantia de vivacidade depende, no fim das contas, da disponibilidade e da disposição da entidade Dusk em assinar. A segurança do protocolo e a descentralização puxam em direções ligeiramente diferentes.
O que eu não vi explicado é o que acontece com transações que estavam em andamento quando um bloco de emergência substitui um bloco normal — se elas são reincluídas na próxima rodada ou se são descartadas. @Dusk
$DUSK #dusk
