Hoje eu estava lendo o fluxo de consenso do Dusk e fiquei preso a um detalhe que é fácil de perder quando você só observa a arquitetura do título.
A parte interessante não é exatamente quem propõe um bloco.
O que importa é o que tem que acontecer antes que esse bloco se torne algo em que o restante da rede possa confiar para construir.
O Dusk usa certificados como parte do seu processo de consenso.
Isso parece bastante padrão até você pensar no que, de fato, um certificado representa.
Não é apenas mais um pedaço de metadados anexado a um bloco.
Ele é, efetivamente, uma evidência de que uma quantidade suficiente da rede concluiu um passo específico do protocolo.
Isso cria uma dependência interessante.
A produção de blocos pode ser rápida.
Validadores individuais podem responder rapidamente.
Mas a rede ainda precisa esperar pelo estado coletivo representado pelo certificado.
Então a questão de desempenho passa a ser um pouco diferente da discussão usual de TPS.
Não é apenas:
Com que rapidez um nó consegue processar algo...
É:
Com que rapidez participantes independentes suficientes conseguem produzir a evidência necessária para que todos os outros avancem?
Isso muda a forma como eu enxergo a latência do consenso.
Um motor de execução mais rápido é útil.
Processamento paralelo é útil.
Mas se a formação do certificado se tornar a parte mais lenta em condições reais de rede, então a velocidade teórica de tudo o que está por baixo disso importa menos do que eu esperava.
Este é um daqueles detalhes arquiteturais que não parece empolgante em uma página de benchmark.
Mas durante congestionamento ou desempenho desigual dos validadores eu suspeito que se torne muito mais importante.
Quanto mais eu leio o Dusk, mais eu acho que a história real de desempenho não é sobre um componente rápido.
É sobre qual componente a rede inteira é obrigada a esperar.
#dusk $DUSK @Dusk