Eu estava pensando sobre o consenso do @Dusk por meio de uma situação simples.

Imagine duas pessoas tomando rotas diferentes para o mesmo destino. Uma começa primeiro, mas fica atrasada. A outra começa mais tarde e chega primeiro.

Você decide automaticamente que a segunda rota foi a correta?

Foi isso que tornou o design de resolução de fork da Dusk interessante para mim.

A Attestação Succinta funciona por iterações. Se uma iteração falhar, o protocolo pode avançar. Mas se várias iterações, eventualmente, produzirem candidatos válidos, a Dusk dá prioridade à menor iteração.

Então, se a iteração 2 e a iteração 5 atingirem o quórum, a iteração 5 não “vence” simplesmente porque terminou depois, mas porque chegou ao quórum com sucesso.

O protocolo se importa com o momento em que o candidato apareceu no processo de consenso.

Isso fica especialmente interessante com a finalização em rolagem. $DUSK leva em conta candidatos de iterações inferiores que ainda não foram resolvidos, em vez de tratar cada iteração posterior bem-sucedida como imediatamente final.

Há também um incentivo sutil aqui. validadores têm motivos para ajudar a resolver iterações anteriores em vez de simplesmente esperar pela mais nova.

Eu gosto desse design porque ele trata o consenso menos como uma corrida e mais como uma sequência controlada de tentativas.

Para infraestrutura financeira, essa distinção pode importar.

Talvez a finalização determinística não seja apenas sobre chegar a um acordo rapidamente. É também sobre saber qual acordo merece prioridade.

#dusk $DUSK #DUSK