Voltei à documentação e passei mais tempo do que eu esperava em duas áreas: a tolerância a falhas do Kadcast e as regras de finalização do protocolo.
No começo, o uso do Kadcast da DHT do Kademlia pareceu relativamente simples. Os nós podem atualizar suas tabelas de roteamento quando pares desaparecem, enquanto múltiplos pares em cada bucket fornecem caminhos alternativos quando um nó falha. Mas me veio a dúvida: quão rapidamente a rede consegue se adaptar quando nós estão constantemente entrando, saindo ou se tornando não confiáveis? E a participação altamente desigual poderia criar partes mais fracas na estrutura de roteamento?
O modelo de estado de consenso foi ainda mais interessante.
Um bloco de @Dusk pode avançar por aceito, atestado, confirmado e, por fim, final. O que me ajudou a entender foi a distinção entre um bloco atestado e um aceito. Se iterações anteriores falharam, um bloco bem-sucedido pode ser aceito, mas ainda permanecer substituível. Quanto mais iterações fracassadas houver, mais tempo a confirmação pode levar.
Por exemplo, com duas iterações anteriores falhas, as regras exigem quatro blocos consecutivos atestados ou confirmados antes que um bloco aceito se torne confirmado.
Isso levanta questões para mim sobre segurança e descentralização. Esse mecanismo oferece proteção suficiente contra instabilidade temporária da rede sem tornar a finalização desnecessariamente lenta? Como o protocolo se comporta quando falhas estão correlacionadas entre muitos nós, em vez de serem isoladas?
Também me pergunto como a dinâmica das tabelas de roteamento e a finalização do consenso interagem durante períodos de disrupção séria da rede.
Meu entendimento ainda está evoluindo, então eu gostaria de ouvir como outras pessoas interpretam esses trade-offs.
Quais cenários de falha você acha que o Kadcast lida particularmente bem? E onde as premissas dele poderiam ser testadas?
$DUSK #dusk
#dusk $DUSK @Dusk
No começo, o uso do Kadcast da DHT do Kademlia pareceu relativamente simples. Os nós podem atualizar suas tabelas de roteamento quando pares desaparecem, enquanto múltiplos pares em cada bucket fornecem caminhos alternativos quando um nó falha. Mas me veio a dúvida: quão rapidamente a rede consegue se adaptar quando nós estão constantemente entrando, saindo ou se tornando não confiáveis? E a participação altamente desigual poderia criar partes mais fracas na estrutura de roteamento?
O modelo de estado de consenso foi ainda mais interessante.
Um bloco de @Dusk pode avançar por aceito, atestado, confirmado e, por fim, final. O que me ajudou a entender foi a distinção entre um bloco atestado e um aceito. Se iterações anteriores falharam, um bloco bem-sucedido pode ser aceito, mas ainda permanecer substituível. Quanto mais iterações fracassadas houver, mais tempo a confirmação pode levar.
Por exemplo, com duas iterações anteriores falhas, as regras exigem quatro blocos consecutivos atestados ou confirmados antes que um bloco aceito se torne confirmado.
Isso levanta questões para mim sobre segurança e descentralização. Esse mecanismo oferece proteção suficiente contra instabilidade temporária da rede sem tornar a finalização desnecessariamente lenta? Como o protocolo se comporta quando falhas estão correlacionadas entre muitos nós, em vez de serem isoladas?
Também me pergunto como a dinâmica das tabelas de roteamento e a finalização do consenso interagem durante períodos de disrupção séria da rede.
Meu entendimento ainda está evoluindo, então eu gostaria de ouvir como outras pessoas interpretam esses trade-offs.
Quais cenários de falha você acha que o Kadcast lida particularmente bem? E onde as premissas dele poderiam ser testadas?
$DUSK #dusk
#dusk $DUSK @Dusk
