#dusk $DUSK @Dusk

Eu estava analisando o mecanismo de Fallback do Dusk e uma coisa me chamou atenção: o número de iteração realmente importa muito quando ocorre um fork.

Como o consenso do Dusk é assíncrono, mensagens podem chegar atrasadas ou ser perdidas durante a congestão. Assim, diferentes partes da rede podem ver blocos diferentes, e às vezes mais de um candidato pode obter quórum na mesma rodada.

A regra básica é que a iteração menor tem prioridade. Se um bloco da iteração 1 for aceito, mas um bloco da iteração 0 depois obtiver quórum, o bloco da iteração menor pode substituí-lo. O nó reverte para o estado antes do bloco antigo e reorganiza a cadeia.

Isso torna a iteração 0 interessante. A iteração 0 é a primeira tentativa, seguida pelas iterações 1, 2 e assim por diante. Como não existe iteração -1, um bloco da iteração 0 não pode ser substituído diretamente por Fallback através de uma iteração menor.

Mas eu não chamaria isso de finalidade completa. Um bloco da iteração 0 ainda pode ser afetado se um ancestral for revertido. A finalidade real vem por meio da Rolling Finality.

Então, do meu ponto de vista, o Fallback é mais do que apenas limpeza de fork. O número de iteração dá à rede uma forma determinística de escolher entre blocos concorrentes, com a iteração 0 no fundo dessa ordem de prioridade.