#dusk $DUSK @Dusk

No había pensado mucho en la capa de red hasta que noté que Dusk no mueve bloques y votos de la manera en que lo hacen la mayoría de las cadenas. En lugar de inundar cada mensaje a cada par, utiliza algo llamado Kadcast, construido sobre un enrutamiento estructurado al estilo Kademlia.

Por sí solo, eso suena como un detalle de backend en el que nadie fuera del equipo central piensa. Pero empieza a importar más cuando lo pones junto a cómo funciona realmente la Atestación Sucinta. El consenso basado en comités depende de un grupo pequeño de provisioners que intercambian votos con la suficiente rapidez para finalizar un bloque en cuestión de segundos. Si la capa de red subyacente es lenta o desperdicia ancho de banda reenviando el mismo mensaje a todos, esa ventana de votación se vuelve más difícil de alcanzar a medida que el conjunto de validadores crece o se dispersa geográficamente.

Kadcast enruta mensajes por rutas deterministas basadas en la distancia dentro de la red, en lugar de usar inundación aleatoria, y el resultado documentado es un consumo de ancho de banda por mensaje de manera significativamente menor. Para una cadena que se apoya en comités intercambiando votos cada ronda, esa no es una ganancia meramente estética: es algo más cercano a un requisito previo para que las garantías de finalización realmente se sostengan a gran escala, no solo en un pequeño testnet.

Lo que no tengo claro es cómo se desempeña en condiciones más difíciles: un conjunto de validadores distribuido entre continentes, una calidad de conexión desigual o un comportamiento genuinamente adversario en la capa de red, más que una simple ineficiencia. Los protocolos de enrutamiento estructurado conllevan sus propios compromisos cuando los nodos se comportan mal o se desconectan de forma impredecible. Si la eficiencia de Kadcast se mantiene una vez que la red sea más grande y caótica de lo que es hoy, parece algo que solo realmente sabremos cuando las pruebas de escala real lo pongan a prueba.