Os nós do Running Boreas RC1 mudaram a forma como penso sobre infraestrutura de rede.
Não por causa dos tempos de bloco ou recompensas de staking. Mas porque comecei a usar tcpdump no tráfego de sincronização por hábito e notei algo que a maioria das pessoas nunca olha. @Dusk nodes não usam a pilha gossipsub do Geth para propagação de blocos. Eles usam Kadcast.
Esse detalhe importa mais do que a maioria das métricas de manchete.
Um protocolo de gossip funciona fazendo com que cada nó envie blocos para N pares aleatórios, que então enviam para seus próprios pares. A propagação exponencial parece eficiente até você perceber que o mesmo bloco chega ao mesmo nó cinco vezes por cinco caminhos diferentes. A largura de banda é consumida por duplicatas, não por dados úteis.
O Kadcast resolve isso de forma diferente. Os nós se organizam em k-buckets usando a distância XOR do Kademlia. O produtor do bloco envia apenas para os k nós mais próximos. Cada salto segue a tabela de roteamento, avançando sem fazer broadcast para a rede inteira. Cada nó recebe cada mensagem uma única vez. Pacotes redundantes caem para perto de zero.
Para a arquitetura do Dusk, isso não é uma otimização menor. As provas Phoenix PLONK, compromissos Zedger e as provas confidenciais Hedger para variáveis são todos cargas úteis consideráveis. O Sequencer do DuskEVM que faz batches voltando ao DuskDS para verificação de SBA passam por essa mesma rede. Sob gossip, 50 nós encaminhando mutuamente requisições de verificação saturariam a banda doméstica. O Kadcast reduz os bytes totais por propagação de bloco em aproximadamente uma ordem de magnitude nesse nível.
Eu executei dois nós de testnet local simultaneamente. Um usando Kadcast e outro simulando o encaminhamento de gossip. Mesma altura de bloco; comparei capturas do tcpdump diretamente. O tráfego de entrada no nó do Kadcast foi 38% do da simulação de gossip. As rodadas de assinatura SBA entre produtor, validador e aprovador também passaram pelo Kadcast, e a variação (jitter) da produção de blocos caiu de forma perceptível.
A maioria dos operadores de nós observa os tempos de bloco. A camada de propagação por baixo é que determina se esses tempos de bloco permanecem estáveis sob carga.
#dusk $DUSK #Binance
Não por causa dos tempos de bloco ou recompensas de staking. Mas porque comecei a usar tcpdump no tráfego de sincronização por hábito e notei algo que a maioria das pessoas nunca olha. @Dusk nodes não usam a pilha gossipsub do Geth para propagação de blocos. Eles usam Kadcast.
Esse detalhe importa mais do que a maioria das métricas de manchete.
Um protocolo de gossip funciona fazendo com que cada nó envie blocos para N pares aleatórios, que então enviam para seus próprios pares. A propagação exponencial parece eficiente até você perceber que o mesmo bloco chega ao mesmo nó cinco vezes por cinco caminhos diferentes. A largura de banda é consumida por duplicatas, não por dados úteis.
O Kadcast resolve isso de forma diferente. Os nós se organizam em k-buckets usando a distância XOR do Kademlia. O produtor do bloco envia apenas para os k nós mais próximos. Cada salto segue a tabela de roteamento, avançando sem fazer broadcast para a rede inteira. Cada nó recebe cada mensagem uma única vez. Pacotes redundantes caem para perto de zero.
Para a arquitetura do Dusk, isso não é uma otimização menor. As provas Phoenix PLONK, compromissos Zedger e as provas confidenciais Hedger para variáveis são todos cargas úteis consideráveis. O Sequencer do DuskEVM que faz batches voltando ao DuskDS para verificação de SBA passam por essa mesma rede. Sob gossip, 50 nós encaminhando mutuamente requisições de verificação saturariam a banda doméstica. O Kadcast reduz os bytes totais por propagação de bloco em aproximadamente uma ordem de magnitude nesse nível.
Eu executei dois nós de testnet local simultaneamente. Um usando Kadcast e outro simulando o encaminhamento de gossip. Mesma altura de bloco; comparei capturas do tcpdump diretamente. O tráfego de entrada no nó do Kadcast foi 38% do da simulação de gossip. As rodadas de assinatura SBA entre produtor, validador e aprovador também passaram pelo Kadcast, e a variação (jitter) da produção de blocos caiu de forma perceptível.
A maioria dos operadores de nós observa os tempos de bloco. A camada de propagação por baixo é que determina se esses tempos de bloco permanecem estáveis sob carga.
#dusk $DUSK #Binance