Há alguns dias, me peguei pensando em uma parte do desempenho de blockchain que raramente é discutida: o que acontece quando a rede já não pode mais assumir que tudo está funcionando normalmente?
A maioria dos projetos é fácil de admirar quando os validadores estão online, as mensagens estão em movimento e os blocos estão sendo produzidos exatamente como esperado. A pergunta mais difícil é o que acontece quando uma grande parte da rede de repente desaparece.
Eu costumava achar que isso era apenas uma questão de esperar o sistema se recuperar. Mas, depois de olhar com mais atenção para a Dusk, percebi que a parte mais interessante é como o protocolo é projetado para responder quando a operação normal começa a falhar.
O projeto de consenso da Dusk leva em conta a participação degradada. Se um número significativo de Provisioners ficar offline ou ficar isolado, o protocolo não simplesmente assume que o conjunto esperado de validadores continuará operando normalmente. Quando iterações repetidas de consenso falham em alcançar o resultado necessário, o protocolo tem mecanismos que permitem ajustar seu comportamento e continuar lidando com as condições variáveis da rede.
Essa distinção importa mais do que pode parecer.
Uma blockchain pode ter um desempenho extremamente bom em condições ideais. O teste real é saber se ela consegue tomar decisões sensatas quando a participação diminui, a comunicação se torna não confiável, ou o conjunto esperado de validadores não consegue ser formado.
Mas há outra pergunta que eu acho tão importante quanto: com que frequência esses mecanismos de recuperação são testados em condições realistas?
Um protocolo pode ter uma estratégia de falha bem desenhada no papel, mas a confiança real vem da implementação, de testes e de observar como a rede se comporta quando algo realmente dá errado.
É por isso que eu acho que a resiliência de blockchain não deve ser medida apenas por TPS ou tempos de bloco. O teste mais profundo é muito mais simples:
Quando as coisas quebram, o protocolo sabe como responder?
@Dusk #dusk $DUSK
$TUT $UAI
A maioria dos projetos é fácil de admirar quando os validadores estão online, as mensagens estão em movimento e os blocos estão sendo produzidos exatamente como esperado. A pergunta mais difícil é o que acontece quando uma grande parte da rede de repente desaparece.
Eu costumava achar que isso era apenas uma questão de esperar o sistema se recuperar. Mas, depois de olhar com mais atenção para a Dusk, percebi que a parte mais interessante é como o protocolo é projetado para responder quando a operação normal começa a falhar.
O projeto de consenso da Dusk leva em conta a participação degradada. Se um número significativo de Provisioners ficar offline ou ficar isolado, o protocolo não simplesmente assume que o conjunto esperado de validadores continuará operando normalmente. Quando iterações repetidas de consenso falham em alcançar o resultado necessário, o protocolo tem mecanismos que permitem ajustar seu comportamento e continuar lidando com as condições variáveis da rede.
Essa distinção importa mais do que pode parecer.
Uma blockchain pode ter um desempenho extremamente bom em condições ideais. O teste real é saber se ela consegue tomar decisões sensatas quando a participação diminui, a comunicação se torna não confiável, ou o conjunto esperado de validadores não consegue ser formado.
Mas há outra pergunta que eu acho tão importante quanto: com que frequência esses mecanismos de recuperação são testados em condições realistas?
Um protocolo pode ter uma estratégia de falha bem desenhada no papel, mas a confiança real vem da implementação, de testes e de observar como a rede se comporta quando algo realmente dá errado.
É por isso que eu acho que a resiliência de blockchain não deve ser medida apenas por TPS ou tempos de bloco. O teste mais profundo é muito mais simples:
Quando as coisas quebram, o protocolo sabe como responder?
@Dusk #dusk $DUSK
$TUT $UAI
