Quando se fala em desempenho de blockchain, nove em cada dez pessoas pensam primeiro em TPS. Os outros talvez olhem para a latência. Mas, no projeto Dusk, se você pegar o whitepaper e ler com atenção, vai perceber algo que vale mais a pena observar do que a velocidade das transações: como os nós “conversam” entre si.
A parte do “bolo” está ok, né? O BTC caiu, mas não foi tanto!
Estou dizendo isso não porque o TPS não seja importante, mas porque “computar rápido” e “transmitir rápido” são coisas completamente diferentes. Mesmo que sua camada de execução seja fortíssima e o design de consenso seja bem elaborado, se as mensagens travarem na rede entre os nós — propostas não chegam aos validadores, resultados de validação não retornam ao comitê de ratificação — todo o fluxo em três etapas fica esperando. Um bloco atrasar alguns segundos: no pior caso, diferentes nós verão blocos candidatos diferentes e a taxa de stale blocks só vai subir.
O Dusk escolheu o caminho do Kadcast. Ele não usa o modo de broadcast do Gossip, em que “transmite para todo mundo”, mas sim uma rede de cobertura estruturada construída sobre um Kademlia DHT: a distância XOR entre IDs de nós determina o roteamento, e as mensagens se desdobram em camadas, como uma árvore. Parece acadêmico, certo? Mas a lógica central é, na prática, uma frase: cada mensagem percorre apenas o caminho que precisa, sem fazer trajetos inúteis.
O whitepaper cita pesquisas que indicam que o Kadcast economiza de 25% a 50% de largura de banda em comparação ao Gossip. Por exemplo: antes eram 100 unidades de largura de banda; agora seriam cerca de 50 a 75. Mas esses números não podem ser traduzidos diretamente como “custo dos nós pela metade”. A configuração das máquinas não muda, o cálculo de provas não muda, a sobrecarga de armazenamento não muda — muda apenas o custo de transmissão na camada de rede. Dito isso: para quem roda nós, o que significa ter metade da largura de banda? Significa conseguir integrar mais nós com as mesmas condições de largura de banda, ou então — com o mesmo tamanho de rede — não ser tão facilmente estrangulado por taxas de banda.
Tem um detalhe que deixa isso bem claro. Na documentação do nó, 9000/udp é marcado como a porta necessária para o Kadcast. O Provisioner precisa participar do consenso e, para isso, deve conseguir acessar esse canal. Já 8080/tcp é opcional: só precisa estar aberto quando você precisa usar a interface de consulta. Em outras palavras, o Kadcast não é um “enfeite” no diagrama de arquitetura — ele literalmente determina o patamar de entrada para um nó participar do consenso.
Quem conhece o broadcast ponto a ponto do BTC sabe que não é trivial como uma mensagem atravessa a rede de nós. @Dusk $DUSK #dusk
A parte do “bolo” está ok, né? O BTC caiu, mas não foi tanto!
Estou dizendo isso não porque o TPS não seja importante, mas porque “computar rápido” e “transmitir rápido” são coisas completamente diferentes. Mesmo que sua camada de execução seja fortíssima e o design de consenso seja bem elaborado, se as mensagens travarem na rede entre os nós — propostas não chegam aos validadores, resultados de validação não retornam ao comitê de ratificação — todo o fluxo em três etapas fica esperando. Um bloco atrasar alguns segundos: no pior caso, diferentes nós verão blocos candidatos diferentes e a taxa de stale blocks só vai subir.
O Dusk escolheu o caminho do Kadcast. Ele não usa o modo de broadcast do Gossip, em que “transmite para todo mundo”, mas sim uma rede de cobertura estruturada construída sobre um Kademlia DHT: a distância XOR entre IDs de nós determina o roteamento, e as mensagens se desdobram em camadas, como uma árvore. Parece acadêmico, certo? Mas a lógica central é, na prática, uma frase: cada mensagem percorre apenas o caminho que precisa, sem fazer trajetos inúteis.
O whitepaper cita pesquisas que indicam que o Kadcast economiza de 25% a 50% de largura de banda em comparação ao Gossip. Por exemplo: antes eram 100 unidades de largura de banda; agora seriam cerca de 50 a 75. Mas esses números não podem ser traduzidos diretamente como “custo dos nós pela metade”. A configuração das máquinas não muda, o cálculo de provas não muda, a sobrecarga de armazenamento não muda — muda apenas o custo de transmissão na camada de rede. Dito isso: para quem roda nós, o que significa ter metade da largura de banda? Significa conseguir integrar mais nós com as mesmas condições de largura de banda, ou então — com o mesmo tamanho de rede — não ser tão facilmente estrangulado por taxas de banda.
Tem um detalhe que deixa isso bem claro. Na documentação do nó, 9000/udp é marcado como a porta necessária para o Kadcast. O Provisioner precisa participar do consenso e, para isso, deve conseguir acessar esse canal. Já 8080/tcp é opcional: só precisa estar aberto quando você precisa usar a interface de consulta. Em outras palavras, o Kadcast não é um “enfeite” no diagrama de arquitetura — ele literalmente determina o patamar de entrada para um nó participar do consenso.
Quem conhece o broadcast ponto a ponto do BTC sabe que não é trivial como uma mensagem atravessa a rede de nós. @Dusk $DUSK #dusk