La semana pasada, mi nodo en una configuración de retransmisión (relay) en un testnet en Karachi se quedó con lag cada vez que intenté simular mucho tráfico de mensajes. Supuse que el problema era simplemente que mi ancho de banda era débil, un problema típico de mi ISP local con el que ya me había topado antes.

Luego leí cómo maneja Dusk la comunicación de igual a igual y me di cuenta de que mi suposición iba al revés. El lag no era por el ancho de banda “en bruto”, sino por lo ineficiente que resulta la difusión estilo flooding cuando cada nodo repite los mensajes a todos sus vecinos sin importar la distancia.

Dusk usa Kadcast en su lugar, construido sobre la estructura de distancia XOR de Kademlia. Los nodos reenvían los mensajes solo a pares seleccionados a distancias crecientes, creando un efecto en cascada en lugar de repetir a ciegas. Esto reduce significativamente las transmisiones redundantes frente a protocolos de gossip como los que usa Ethereum. Además, de forma natural dificulta identificar de dónde se originó un mensaje, ya que pasa por varios saltos antes de llegar a la red más amplia, lo cual encaja con el enfoque de privacidad de Dusk para transacciones financieras.

Lo que el whitepaper no explica con claridad es cuál es el número exacto de latencia en el mundo real bajo condiciones de red adversas, como qué ocurre específicamente durante la congestión regional en lugares con infraestructura inestable. Es un vacío que no puedo llenar con confianza.

La prueba real para DUSK es si Kadcast mantiene su ventaja de eficiencia cuando el número de nodos escala hasta los miles bajo estrés real de la red, y no solo en condiciones controladas de testnet.

¿Alguien aquí ha ejecutado realmente un nodo de Dusk el tiempo suficiente como para notar diferencias de velocidad de propagación de primera mano?
#dusk $DUSK @Dusk