Sério, no começo quando eu rodava os nós do Dusk, eu nem dava muita importância à camada de rede. A consenso funcionava, os blocos saíam e os rewards caíam na conta—quem teria tempo pra ficar de olho nos pacotes UDP na porta, indo e voltando? Até que um dia o pessoal do datacenter me reportou que o tráfego de saída do nó estava mais alto do que o previsto. Fui checar e descobri que não era RPC sendo varrida, era Gossip: depois que a escala aumentava, começava a “falar besteira”. Uma mensagem num grupo, o pessoal grita, cada um repassa mais uma vez—efeito de N ao quadrado; quem já mexeu com P2P entende.
O plano caiu um pouco—mas o BTC ainda está acumulando energia!
Quando a documentação do Dusk colocou o Kadcast em destaque, eu na verdade fui olhar com um espírito bem exigente. A ideia de “rede de cobertura estruturada” é, no fim, traçar um mapa para as mensagens e então entregar sem ficar girando aleatoriamente. Aquela queda de banda de 25% a 50% que a equipe oficial mencionou: eu fiz um teste grosseiro por duas semanas com nós que eu mesmo rodo—desligando a opção de otimização do Kadcast (na testnet existe essa opção). Comparando com o estado ligado, o tráfego de saída realmente dá pra reduzir perto de 40%. Mas aqui é bom deixar claro: isso é um número só da camada de rede. Não dá pra igualar isso a “cortar custos do nó em 40%”. O dinheiro da máquina, da storage, das despesas de hardware do Prover—tudo continua lá, sem desconto.
O que de fato me fez achar que essa questão vale ser destacada são alguns detalhes de configuração de portas. No guia do nó, 9000/udp é obrigatório, enquanto 8080/tcp vira opcional—esse sinal é direto demais. Mostra que no arcabouço do Dusk, o Kadcast não é um enfeite: é a linha vital da comunicação. A proposta precisa passar, os votos de validação precisam voar, o estágio de aprovação precisa consolidar tudo—se qualquer etapa travar por causa de congestionamento na rede, a experiência de consenso desanda. O bloco até pode sair rápido, mas se a mensagem não passa, é zero.
Quem já rodou nós na rede do padrão ETH também já teve esse tipo de sensação: quando você chega a alguns milhares de nós na testnet, a latência de sincronização começa a oscilar. O Dusk separa a eficiência de propagação como uma camada de otimização—o caminho faz sentido. Mas o que importa no longo prazo é ver se, depois que o tamanho da rede dobra e dobra de novo, aquele “mapa” do Kadcast ainda consegue manter baixa repetição e uma latência estável. Isso não tem a ver com TPS, nem com limiar de segurança—é trabalho da própria camada de comunicação.
@Dusk $DUSK #dusk
O plano caiu um pouco—mas o BTC ainda está acumulando energia!
Quando a documentação do Dusk colocou o Kadcast em destaque, eu na verdade fui olhar com um espírito bem exigente. A ideia de “rede de cobertura estruturada” é, no fim, traçar um mapa para as mensagens e então entregar sem ficar girando aleatoriamente. Aquela queda de banda de 25% a 50% que a equipe oficial mencionou: eu fiz um teste grosseiro por duas semanas com nós que eu mesmo rodo—desligando a opção de otimização do Kadcast (na testnet existe essa opção). Comparando com o estado ligado, o tráfego de saída realmente dá pra reduzir perto de 40%. Mas aqui é bom deixar claro: isso é um número só da camada de rede. Não dá pra igualar isso a “cortar custos do nó em 40%”. O dinheiro da máquina, da storage, das despesas de hardware do Prover—tudo continua lá, sem desconto.
O que de fato me fez achar que essa questão vale ser destacada são alguns detalhes de configuração de portas. No guia do nó, 9000/udp é obrigatório, enquanto 8080/tcp vira opcional—esse sinal é direto demais. Mostra que no arcabouço do Dusk, o Kadcast não é um enfeite: é a linha vital da comunicação. A proposta precisa passar, os votos de validação precisam voar, o estágio de aprovação precisa consolidar tudo—se qualquer etapa travar por causa de congestionamento na rede, a experiência de consenso desanda. O bloco até pode sair rápido, mas se a mensagem não passa, é zero.
Quem já rodou nós na rede do padrão ETH também já teve esse tipo de sensação: quando você chega a alguns milhares de nós na testnet, a latência de sincronização começa a oscilar. O Dusk separa a eficiência de propagação como uma camada de otimização—o caminho faz sentido. Mas o que importa no longo prazo é ver se, depois que o tamanho da rede dobra e dobra de novo, aquele “mapa” do Kadcast ainda consegue manter baixa repetição e uma latência estável. Isso não tem a ver com TPS, nem com limiar de segurança—é trabalho da própria camada de comunicação.
@Dusk $DUSK #dusk