Eu reli novamente o whitepaper da Dusk na noite passada, com foco nas seções de modo de emergência, fallback e finalidade em rolagem. Os detalhes eram mais sutis do que eu esperava inicialmente.

O modo de emergência é ativado após 16 iterações falhas. Em seguida, os timeouts de etapa são desativados, e as iterações em aberto continuam até que um bloco candidato atinja quórum tanto na validação quanto na ratificação. Várias iterações podem ser executadas ao mesmo tempo, o que melhora a chance de produzir um bloco, mas também aumenta a possibilidade de forks. Se vários candidatos alcançarem consenso, a menor iteração é selecionada. Na última iteração, os provisioners podem solicitar um bloco de emergência, mas isso exige que os provisioners que o solicitam detenham a maioria do stake total da rede.

As regras de fallback também chamaram minha atenção: um bloco da iteração J > 0 pode potencialmente ser substituído por um bloco de iteração menor que, mais tarde, alcance consenso, enquanto a iteração 0 não pode ser substituída dessa forma.

Depois, a finalidade em rolagem adiciona outra camada. Se n iterações anteriores falharem na atestação, um bloco é aceito e precisa de 2×n blocos consecutivos atestados ou confirmados para se tornar confirmado. O exemplo do artigo usa a iteração 5, com n=2, o que significa que são necessários mais 4 blocos.

Ainda estou pensando: este desenho cria algum risco significativo de centralização em torno da recuperação de emergência ponderada por stake?

@Dusk #dusk $DUSK