Eu estava rastreando como Dusk move blocos pela rede, esperando a história tradicional de “fofoca” em forma de inundação. Em vez disso, encontrei algo mais estreito e deliberado.
O Kadcast não inunda. Ele roteia. Usando a estrutura de distância XOR da Kademlia, cada nó encaminha dados por caminhos determinísticos até buckets específicos de pares, e não para todos. Essa é a história de eficiência em que a maioria das pessoas para.
Mas o roteamento estruturado tem uma fraqueza óbvia: se um nó no caminho ficar offline, a mensagem simplesmente “morre” ali? Foi aí que eu desacelerei. O Kadcast não depende de um único caminho por bucket — ele usa um parâmetro de redundância, β, que seleciona múltiplos delegados por bucket para receber e reenviar o mesmo chunk. Se um deles falhar, os outros ainda o carregam.
E então vem o RaptorQ, incorporado como correção de erros de reenvio: os dados são codificados para que um receptor reconstrua o original a partir de fragmentos parciais, sem precisar que cada pacote chegue íntegro.
Assim, a resiliência não é realmente sobre nós “ficarem ativos”. É sobre o protocolo presumir que eles não vão, e construir redundância na própria estrutura do caminho, em vez de depender de inundação cega.
Fica a me perguntar como o β é ajustado à medida que os conjuntos de validadores crescem: mais redundância custa largura de banda; menos redundância custa confiabilidade. Onde exatamente o Dusk traça essa linha em escala?
#dusk $DUSK @Dusk
O Kadcast não inunda. Ele roteia. Usando a estrutura de distância XOR da Kademlia, cada nó encaminha dados por caminhos determinísticos até buckets específicos de pares, e não para todos. Essa é a história de eficiência em que a maioria das pessoas para.
Mas o roteamento estruturado tem uma fraqueza óbvia: se um nó no caminho ficar offline, a mensagem simplesmente “morre” ali? Foi aí que eu desacelerei. O Kadcast não depende de um único caminho por bucket — ele usa um parâmetro de redundância, β, que seleciona múltiplos delegados por bucket para receber e reenviar o mesmo chunk. Se um deles falhar, os outros ainda o carregam.
E então vem o RaptorQ, incorporado como correção de erros de reenvio: os dados são codificados para que um receptor reconstrua o original a partir de fragmentos parciais, sem precisar que cada pacote chegue íntegro.
Assim, a resiliência não é realmente sobre nós “ficarem ativos”. É sobre o protocolo presumir que eles não vão, e construir redundância na própria estrutura do caminho, em vez de depender de inundação cega.
Fica a me perguntar como o β é ajustado à medida que os conjuntos de validadores crescem: mais redundância custa largura de banda; menos redundância custa confiabilidade. Onde exatamente o Dusk traça essa linha em escala?
#dusk $DUSK @Dusk