@Dusk Muitas pessoas dizem que as redes P2P só precisam de nós suficientes para naturalmente ficarem mais rápidas, mas eu nunca confiei muito nessa frase. Só até ler os “Core Components” de $DUSK é que notei que o Kadcast não usa gossip aleatório, e sim uma overlay estruturada (structured overlay). O objetivo é reduzir o consumo de largura de banda e tornar a latência mais previsível. Essa escolha me fez mudar de julgamento: a eficiência da rede não depende apenas da quantidade de nós, mas também de como a mensagem passa por relações de conexão que conseguem chegar ao alvo.
Para quem opera nós, isso não é um conceito abstrato. Quando as rotas têm mais estrutura, os nós passam a depender ainda mais da descoberta de vizinhos e da qualidade da conectividade da rede. E, quando o ambiente operacional bloqueia os canais UDP ou o endereço do Kadcast, em teoria uma latência previsível não se transforma automaticamente em desempenho de rede realmente utilizável. O que o operador pode observar é apenas que as mensagens não chegam ou que blocos ficam atrasados, enquanto ele precisa decidir por si mesmo se é um problema de versão, de estratégia de rede ou de configuração.
Cenários de pressão são bem concretos. Quando aumentam as atividades do mercado, a aplicação quer que as transações sejam confirmadas mais rápido, mas algum nó crítico fica bloqueado por um firewall. Este sistema não é tão simples quanto “quanto mais nós, mais seguro”. A acessibilidade dos nós também pode determinar se as mensagens conseguem se propagar conforme o desenho. E, no final, o custo de troubleshooting cai sobre quem está executando os nós. Então, quando eu olho para o desempenho de rede do DUSK, não considero apenas o tempo de bloco ou a quantidade de nós; eu também quero verificar as relações de vizinhança do Kadcast, as portas de comunicação e se nós atrasados têm sinais de monitoramento intuitivos para referência. @Dusk escolheu uma propagação estruturada, mas o quanto ela consegue realmente entregar essa previsibilidade para os operadores é a parte que #dusk precisa provar na rede.
Para quem opera nós, isso não é um conceito abstrato. Quando as rotas têm mais estrutura, os nós passam a depender ainda mais da descoberta de vizinhos e da qualidade da conectividade da rede. E, quando o ambiente operacional bloqueia os canais UDP ou o endereço do Kadcast, em teoria uma latência previsível não se transforma automaticamente em desempenho de rede realmente utilizável. O que o operador pode observar é apenas que as mensagens não chegam ou que blocos ficam atrasados, enquanto ele precisa decidir por si mesmo se é um problema de versão, de estratégia de rede ou de configuração.
Cenários de pressão são bem concretos. Quando aumentam as atividades do mercado, a aplicação quer que as transações sejam confirmadas mais rápido, mas algum nó crítico fica bloqueado por um firewall. Este sistema não é tão simples quanto “quanto mais nós, mais seguro”. A acessibilidade dos nós também pode determinar se as mensagens conseguem se propagar conforme o desenho. E, no final, o custo de troubleshooting cai sobre quem está executando os nós. Então, quando eu olho para o desempenho de rede do DUSK, não considero apenas o tempo de bloco ou a quantidade de nós; eu também quero verificar as relações de vizinhança do Kadcast, as portas de comunicação e se nós atrasados têm sinais de monitoramento intuitivos para referência. @Dusk escolheu uma propagação estruturada, mas o quanto ela consegue realmente entregar essa previsibilidade para os operadores é a parte que #dusk precisa provar na rede.
