Muitas blockchains propagam transações via Gossip: quando um nó recebe uma mensagem, ele a reencaminha aleatoriamente para os nós ao redor. É um método simples, mas à medida que a escala de nós cresce, também aumentam os dados duplicados, o consumo de largura de banda e a latência de propagação.
Depois de analisar a documentação de rede do @Dusk , descobri que o Kadcast usado pela Dusk não realiza uma difusão totalmente aleatória; ele organiza a propagação de mensagens entre nós por meio de uma rede de cobertura estruturada. Seu objetivo não é fazer com que cada nó notifique cegamente todos os vizinhos, e sim, controlar a largura de banda e, ao mesmo tempo, permitir que blocos e mensagens de consenso cheguem à rede em tempos mais previsíveis.
Isso é como entregas urbanas. O Gossip aleatório é mais parecido com cada depósito que, ao ver um pacote, notifica todos os outros depósitos ao redor; já o Kadcast tenta desenhar previamente rotas de retransmissão para reduzir a quantidade de vezes em que o mesmo pacote é transportado repetidamente. Para consensos que precisam de Proposal, Validation e Ratification rapidamente, quanto mais estável for a latência de propagação, menos provável é que os nós percam suas responsabilidades por mensagens que chegam tarde.
Mas uma rede estruturada também tem custos. Quando surgem problemas nas portas do nó, NAT, firewall e nas configurações de conexão com vizinhos, o processo ainda pode estar em execução, mas pode não conseguir participar corretamente da propagação. Os nós da Dusk exigem que o Kadcast use 9000/UDP; falhas dessas conexões UDP também não são necessariamente tão fáceis de detectar quanto serviços comuns de páginas web.
Por isso, não vou olhar apenas o tempo médio de produção de blocos; também vou acompanhar a quantidade de Peers dos nós, a latência na cauda da propagação de mensagens, a taxa de mensagens de consenso que ficam sem assinatura e a distribuição de nós entre regiões. O que a performance da rede realmente teme não é ser um pouco mais lenta em média, e sim que poucas mensagens, ocasionalmente, fiquem lentas o suficiente para perder a janela do consenso. #dusk $DUSK
Depois de analisar a documentação de rede do @Dusk , descobri que o Kadcast usado pela Dusk não realiza uma difusão totalmente aleatória; ele organiza a propagação de mensagens entre nós por meio de uma rede de cobertura estruturada. Seu objetivo não é fazer com que cada nó notifique cegamente todos os vizinhos, e sim, controlar a largura de banda e, ao mesmo tempo, permitir que blocos e mensagens de consenso cheguem à rede em tempos mais previsíveis.
Isso é como entregas urbanas. O Gossip aleatório é mais parecido com cada depósito que, ao ver um pacote, notifica todos os outros depósitos ao redor; já o Kadcast tenta desenhar previamente rotas de retransmissão para reduzir a quantidade de vezes em que o mesmo pacote é transportado repetidamente. Para consensos que precisam de Proposal, Validation e Ratification rapidamente, quanto mais estável for a latência de propagação, menos provável é que os nós percam suas responsabilidades por mensagens que chegam tarde.
Mas uma rede estruturada também tem custos. Quando surgem problemas nas portas do nó, NAT, firewall e nas configurações de conexão com vizinhos, o processo ainda pode estar em execução, mas pode não conseguir participar corretamente da propagação. Os nós da Dusk exigem que o Kadcast use 9000/UDP; falhas dessas conexões UDP também não são necessariamente tão fáceis de detectar quanto serviços comuns de páginas web.
Por isso, não vou olhar apenas o tempo médio de produção de blocos; também vou acompanhar a quantidade de Peers dos nós, a latência na cauda da propagação de mensagens, a taxa de mensagens de consenso que ficam sem assinatura e a distribuição de nós entre regiões. O que a performance da rede realmente teme não é ser um pouco mais lenta em média, e sim que poucas mensagens, ocasionalmente, fiquem lentas o suficiente para perder a janela do consenso. #dusk $DUSK