Eu testei alguns nós na rede de testes para o @Dusk . Minha maior impressão após fazer captura de pacotes é: muitos times de operação na rede principal ainda usam métricas da era passada como “linha vermelha da CPU + nível de memória”, mas não percebem nada sobre acúmulo de sinalização entre nós, mensagens duplicadas ou tremor na tabela de roteamento. O broadcast por inundação do início do Bitcoin é um exemplo negativo pronto: após uma transação chegar a um nó, ela é enviada indiscriminadamente a todos os vizinhos. Com 8 a 16 conexões pares em paralelo, a largura de banda da camada de rede é amplificada em escala multiplicativa. Nas estatísticas dos primeiros testnets do Bitcoin, a redundância de cópias do broadcast de uma única transação frequentemente ultrapassava o triplo do número de conexões. E, quando a concorrência aumenta, as interrupções da placa de rede atingem o limite antes mesmo da sincronização de blocos.

O Kadcast não segue esse caminho antigo. Ele empacota diretamente a lógica de distância XOR do Kademlia na camada de disseminação: os nós primeiro calculam a distância entre o alvo e o seu ID local, colocam os vizinhos em diferentes k-buckets conforme o comprimento do prefixo e, na sincronização, fazem multicast em múltiplos saltos de forma hierárquica, seguindo uma rota em forma de árvore. Eu medi nos testes de carga: o pico instantâneo de largura de banda fica uma faixa abaixo do da inundação, e até sondagens externas acham difícil inferir o IP de origem por causa do encaminhamento em múltiplos saltos. Do ponto de vista de projeto, isso tem embasamento: em simulações no nível de artigo, o Kadcast reduz a redundância do broadcast do nível linear do Gossip para o nível logarítmico — reduz um fator de ordem de grandeza.

Mas a minha dúvida justamente está aqui. A eficiência fica totalmente apoiada na saúde da tabela de roteamento, ou seja, terceiriza a tolerância a falhas de um sistema distribuído para suposições sobre a topologia. Se um cabo submarino for rompido, ou se um atacante contamin ar k-buckets específicos com identidades Sybil baratas, os nós passam a acionar frequentemente reparos de rota e alternar para caminhos alternativos. A latência de endereçamento não cresce de forma linear; ela é amplificada em forma de jitter: quando cada bucket de prefixo alto é perdido, o número de saltos das buscas pode degradar do nível logarítmico para uma tentativa exaustiva por exploração. Nos meus testes de carga, vi uma cena ainda menos intuitiva: ao injetar o mesmo volume de 2000 transações, o número de interrupções de NIC nos nós com inundação é quatro vezes o dos nós do Kadcast; porém, depois que a taxa de perda passa de 3%, o tempo de sincronização de blocos do Kadcast acaba ficando maior. Esse custo consegue “comer” o ganho de banda de antes.

A rede pública não é um laboratório: retransmissões TCP, perfuração de NAT e QoS dos provedores também amplificam a fragilidade de uma topologia lógica. Ao avaliar esse tipo de rede de camada inferior, o mais temido não é a CPU disparar, mas sim a degradação silenciosa da tabela de roteamento: o throughput aparente fica normal, mas as tentativas de sinalização e os consertos de buckets já atravessaram o plano de controle. #dusk $DUSK $BTC