Tenho olhado com mais atenção para como @Dusk lida com o consenso, e um detalhe que acho fácil de ignorar é que o processo não é tratado como uma única decisão.

Um bloco do tipo “A” é primeiro preparado e proposto. Em seguida, os participantes da votação o avaliam, antes que a rede concorde com o estado resultante.

Essa separação importa para mim porque produzir um bloco candidato e aceitar esse bloco não são a mesma coisa. Se uma proposta estiver errada, a etapa de votação fornece um ponto distinto em que os participantes podem rejeitá-la, em vez de tratar a produção do bloco em si como aceitação.

Gosto desse desenho do ponto de vista de sistemas. Ele facilita separar a lógica: propõe primeiro, chega a um acordo depois.

mas há outro lado sobre o qual fico pensando. Etapas mais explícitas também significam mais coordenação entre os componentes. Se essas etapas dependem uma da outra, uma estrutura adicional pode introduzir lugares adicionais onde a coordenação precisa funcionar corretamente.

Minha visão é que a questão interessante não é se o desenho parece sofisticado. É se essa separação realmente melhora a resiliência sem criar complexidade desnecessária.

O consenso por etapas torna a Dusk mais robusta a propostas ruins? Ou a coordenação adicional cria um novo tipo de compromisso?
#dusk $DUSK