Ontem à noite, voltei às @Dusk documentações técnicas, especificamente às seções sobre comunicação peer-to-peer e o protocolo Kadcast. No começo eu estava só dando uma olhada, mas quanto mais eu lia, mais o projeto começava a se encaixar de um jeito diferente das redes usuais baseadas em boatos.
O Kadcast roda sobre um DHT estilo Kademlia e usa distância XOR para estruturar como as mensagens se movem. Em vez de inundar tudo para vizinhos aleatórios, os nós encaminham para um conjunto cuidadosamente escolhido de peers em distâncias crescentes. Isso deve cortar bastante o tráfego redundante e deixar a latência mais previsível. A documentação também fala sobre como isso naturalmente dificulta apontar a origem da mensagem, o que parece relevante para uma cadeia com foco em privacidade.
O que ainda estou ponderando é a parte de tolerância a falhas. Quando nós caem ou se recusam a encaminhar, o protocolo deveria encontrar caminhos alternativos atualizando tabelas de roteamento. Eu consigo ver como isso funciona em teoria, mas fiquei me perguntando como ele se comporta sob churn sustentado ou ataques de drop direcionados de mensagens. O artigo menciona resiliência e caminhos alternativos, mas eu não consegui encontrar números concretos nem simulações detalhadas sobre os piores cenários.
No lado de governança e descentralização, esse tipo de overlay estruturado parece assumir uma distribuição razoavelmente saudável de nós honestos. Se uma grande parcela da rede acabar concentrada ou coordenada, a vantagem de eficiência vira um passivo? Não tenho certeza se a documentação fecha essa lacuna.
Curioso para saber como outras pessoas que já rodaram nós ou se aprofundaram no código veem as compensações no mundo real. O benefício de privacidade por ofuscação da origem se mantém quando você começa a olhar para análise de tráfego, ou ele ajuda principalmente contra observadores casuais?
@Dusk_Foundation #dusk $DUSK
O Kadcast roda sobre um DHT estilo Kademlia e usa distância XOR para estruturar como as mensagens se movem. Em vez de inundar tudo para vizinhos aleatórios, os nós encaminham para um conjunto cuidadosamente escolhido de peers em distâncias crescentes. Isso deve cortar bastante o tráfego redundante e deixar a latência mais previsível. A documentação também fala sobre como isso naturalmente dificulta apontar a origem da mensagem, o que parece relevante para uma cadeia com foco em privacidade.
O que ainda estou ponderando é a parte de tolerância a falhas. Quando nós caem ou se recusam a encaminhar, o protocolo deveria encontrar caminhos alternativos atualizando tabelas de roteamento. Eu consigo ver como isso funciona em teoria, mas fiquei me perguntando como ele se comporta sob churn sustentado ou ataques de drop direcionados de mensagens. O artigo menciona resiliência e caminhos alternativos, mas eu não consegui encontrar números concretos nem simulações detalhadas sobre os piores cenários.
No lado de governança e descentralização, esse tipo de overlay estruturado parece assumir uma distribuição razoavelmente saudável de nós honestos. Se uma grande parcela da rede acabar concentrada ou coordenada, a vantagem de eficiência vira um passivo? Não tenho certeza se a documentação fecha essa lacuna.
Curioso para saber como outras pessoas que já rodaram nós ou se aprofundaram no código veem as compensações no mundo real. O benefício de privacidade por ofuscação da origem se mantém quando você começa a olhar para análise de tráfego, ou ele ajuda principalmente contra observadores casuais?
@Dusk_Foundation #dusk $DUSK