Estaba rastreando cómo Dusk mueve bloques a través de la red, esperando la historia habitual de chismes en forma de inundación. En cambio, encontré algo más estrecho y deliberado.
Kadcast no inunda. Encaminan. Usando la estructura de distancia XOR de Kademlia, cada nodo reenvía los datos a lo largo de rutas deterministas hacia buckets específicos de pares, no hacia todos. Esa es la historia de eficiencia en la que la mayoría se detiene.
Pero el enrutamiento estructurado tiene una debilidad obvia: si un nodo en la ruta se desconecta, ¿el mensaje se muere allí? Ahí fue donde me detuve. Kadcast no depende de una sola ruta por bucket: usa un parámetro de redundancia, β, que selecciona múltiples delegados por bucket para recibir y reenviar el mismo fragmento. Si pierdes uno, los demás todavía lo llevan.
Luego está RaptorQ, integrado como corrección de errores hacia adelante: los datos se codifican para que un receptor pueda reconstruir el original a partir de fragmentos parciales, sin necesidad de que llegue intacto cada paquete.
Así que la resiliencia no trata realmente de que los nodos «se mantengan en línea». Trata de que el protocolo asume que no estarán, y construye redundancia dentro de la estructura de la ruta en lugar de depender de una inundación ciega.
Me hace preguntarme cómo se ajusta β a medida que crecen los conjuntos de validadores: más redundancia cuesta ancho de banda, menos cuesta confiabilidad. ¿Dónde traza Dusk esa línea a escala?
#dusk $DUSK @Dusk
Kadcast no inunda. Encaminan. Usando la estructura de distancia XOR de Kademlia, cada nodo reenvía los datos a lo largo de rutas deterministas hacia buckets específicos de pares, no hacia todos. Esa es la historia de eficiencia en la que la mayoría se detiene.
Pero el enrutamiento estructurado tiene una debilidad obvia: si un nodo en la ruta se desconecta, ¿el mensaje se muere allí? Ahí fue donde me detuve. Kadcast no depende de una sola ruta por bucket: usa un parámetro de redundancia, β, que selecciona múltiples delegados por bucket para recibir y reenviar el mismo fragmento. Si pierdes uno, los demás todavía lo llevan.
Luego está RaptorQ, integrado como corrección de errores hacia adelante: los datos se codifican para que un receptor pueda reconstruir el original a partir de fragmentos parciales, sin necesidad de que llegue intacto cada paquete.
Así que la resiliencia no trata realmente de que los nodos «se mantengan en línea». Trata de que el protocolo asume que no estarán, y construye redundancia dentro de la estructura de la ruta en lugar de depender de una inundación ciega.
Me hace preguntarme cómo se ajusta β a medida que crecen los conjuntos de validadores: más redundancia cuesta ancho de banda, menos cuesta confiabilidad. ¿Dónde traza Dusk esa línea a escala?
#dusk $DUSK @Dusk