@Dusk_Foundation
No início, assumi que as rodadas de consenso do Dusk eram, em sua maior parte, uma questão de esperar pelo número suficiente de votos. Mas quanto mais eu olhava para a estrutura de iteração, o que ficou comigo foi como uma tentativa fracassada não simplesmente desaparece. Se a validação ou a ratificação falharem, o protocolo passa para outra iteração, com um novo gerador e comitês selecionados por meio de uma sorteio determinístico. Isso cria uma dependência pequena, mas interessante: uma tentativa posterior é parcialmente moldada pelo que aconteceu nas anteriores. O whitepaper também limita uma rodada a 50 iterações, o que sugere que a falha não é tratada como um caso excepcional que pode ser ignorado. Ela precisa caber dentro de um processo limitado. Acho isso mais interessante do que a descrição usual de “finalidade rápida”. Aqui, o consenso parece envolver administrar a coordenação malsucedida tanto quanto a coordenação bem-sucedida. Talvez isso seja inevitável quando a participação na rede não é perfeitamente confiável. O que nos deixa uma pergunta mais silenciosa: como um sistema de consenso deve equilibrar persistência com o custo de tentar concordar repetidamente? #dusk $DUSK @Dusk $DUSK