#dusk $DUSK @Dusk

Eu estava analisando o consenso do Dusk e uma coisa que eu não esperava foi o quanto a camada de rede importa quando você está tentando tornar os blocos finais bem rápido.

Um bloco pode ser perfeitamente válido, mas se alguns provedores receberem isso tarde, todo o processo de consenso pode perder tempo.

É aí que o Kadcast chamou minha atenção. O Dusk o usa para propagação de mensagens, enquanto a Attestation Succinct lida com proposta, validação e ratificação. Então a propagação de blocos não é apenas “enviar para todo mundo”; ela precisa atravessar a rede rápido o suficiente para que comitês trabalhem com as mesmas informações.

Também notei que o Dusk exige que os provedores mantenham os nós sincronizados, com o Kadcast usando a porta UDP 9000. Até o guia oficial de solução de problemas diz para os operadores verificarem a conectividade entre pares e a altura do bloco quando o progresso da cadeia trava.

E a participação direta mínima é de 1.000 DUSK, o que significa que rodar a infraestrutura do consenso não é apenas sobre manter tokens — o nó precisa ficar online e sincronizado.

Para mim, essa é a parte interessante do Dusk: a finalização rápida não é apenas uma fórmula de consenso. A propagação pela rede faz parte do limite de velocidade também.

O que acontece quando o Dusk escala para muito mais provedores distribuídos geograficamente?

A propagação pode se tornar o verdadeiro gargalo?

Limite de Propagação?
Yes, Soon
Maybe Later
No, Never
11 hora(s) restante(s)