Voltei à documentação do Dusk na noite passada, e a seção sobre o modo de emergência me fez olhar para o consenso de um jeito um pouco diferente.
No começo, pensei que um mecanismo de emergência fosse apenas uma reserva para quando os validadores ficassem offline. Mas os detalhes são mais interessantes.
O Dusk usa comitês de validação e ratificação, com provisionadores selecionados aleatoriamente votando sobre se um bloco proposto é válido e se esse resultado deve ser aceito. Um quórum exige limiares diferentes dependendo do voto, incluindo uma supermaioria de 2/3 para votos de Válido.
O que acontece quando a rede não consegue atingir esse quórum?
Após 16 iterações fracassadas, de acordo com a documentação, o protocolo entra em modo de emergência. Em vez de expirar e desistir, as iterações podem permanecer abertas até que um candidato receba suporte suficiente. Múltiplas iterações podem rodar ao mesmo tempo, o que aumenta a chance de produzir um bloco, mas também cria a possibilidade de forks.
Achei interessante esse compromisso.
Se múltiplos blocos candidatos alcançam consenso, o protocolo resolve o fork escolhendo o candidato da menor iteração. Estou curioso sobre como isso se comporta sob congestão prolongada da rede ou isolamento parcial, especialmente quando partes diferentes da rede veem mensagens em momentos distintos.
A alternativa final é ainda mais incomum. Se a última iteração falhar, provisionadores que detêm a maioria do stake total podem solicitar um bloco de emergência. Esse bloco não contém transações e permite que a rede avance para a próxima rodada.
Isso levanta questões para mim sobre governança e descentralização.
Exigir maioria de stake para um bloco de emergência cria um mecanismo de segurança útil, ou poderia se tornar um ponto de influência durante uma falha séria da rede?
E quão robusto é o sistema quando a comunicação é fortemente interrompida, mas diferentes comitês continuam operando?
Ainda estou investigando os casos-limite, mas estas são as partes do design de consenso que acho mais valiosas para entender.
@Dusk $DUSK #dusk
#dusk $DUSK @Dusk
No começo, pensei que um mecanismo de emergência fosse apenas uma reserva para quando os validadores ficassem offline. Mas os detalhes são mais interessantes.
O Dusk usa comitês de validação e ratificação, com provisionadores selecionados aleatoriamente votando sobre se um bloco proposto é válido e se esse resultado deve ser aceito. Um quórum exige limiares diferentes dependendo do voto, incluindo uma supermaioria de 2/3 para votos de Válido.
O que acontece quando a rede não consegue atingir esse quórum?
Após 16 iterações fracassadas, de acordo com a documentação, o protocolo entra em modo de emergência. Em vez de expirar e desistir, as iterações podem permanecer abertas até que um candidato receba suporte suficiente. Múltiplas iterações podem rodar ao mesmo tempo, o que aumenta a chance de produzir um bloco, mas também cria a possibilidade de forks.
Achei interessante esse compromisso.
Se múltiplos blocos candidatos alcançam consenso, o protocolo resolve o fork escolhendo o candidato da menor iteração. Estou curioso sobre como isso se comporta sob congestão prolongada da rede ou isolamento parcial, especialmente quando partes diferentes da rede veem mensagens em momentos distintos.
A alternativa final é ainda mais incomum. Se a última iteração falhar, provisionadores que detêm a maioria do stake total podem solicitar um bloco de emergência. Esse bloco não contém transações e permite que a rede avance para a próxima rodada.
Isso levanta questões para mim sobre governança e descentralização.
Exigir maioria de stake para um bloco de emergência cria um mecanismo de segurança útil, ou poderia se tornar um ponto de influência durante uma falha séria da rede?
E quão robusto é o sistema quando a comunicação é fortemente interrompida, mas diferentes comitês continuam operando?
Ainda estou investigando os casos-limite, mas estas são as partes do design de consenso que acho mais valiosas para entender.
@Dusk $DUSK #dusk
#dusk $DUSK @Dusk
