@Dusk
Em um primeiro momento, assumi que o processo de votação do Dusk era, em sua maior parte, sobre atingir um quórum antes de um tempo limite (timeout). Mas quanto mais eu olhava, mais me chamava atenção o tratamento de um quórum ausente. Se a etapa de validação não conseguir reunir votos suficientes no tempo, ela não apenas declara o bloco como inválido. Ela produz um resultado NoQuorum, que então é levado para a ratificação. O próximo comitê passa a votar sobre esse desfecho, em vez de reiniciar todo o processo imediatamente. Isso cria uma pequena diferença entre “o bloco falhou” e “a rede não conseguiu decidir”. São situações bem diferentes, especialmente quando os provisionadores podem ficar offline ou quando as mensagens são atrasadas. O protocolo mantém essa incerteza visível por mais um passo antes de decidir se a iteração deve falhar. Acho isso mais interessante do que o próprio timeout. Isso sugere que o silêncio é tratado como informação, mas não necessariamente como rejeição.
Então talvez a pergunta mais silenciosa seja: quanta incerteza um sistema de consenso deve preservar antes que, por fim, transformar a ausência de concordância em falha?
@Dusk #dusk $DUSK