#dusk $DUSK @Dusk

Estaba mirando el consenso de Dusk y una cosa que no esperaba era cuánto importa la capa de red cuando intentas que los bloques se finalicen realmente rápido.

Un bloque puede ser perfectamente válido, pero si algunos provisionadores lo reciben tarde, todo el proceso de consenso puede perder tiempo.

Ahí fue donde Kadcast llamó mi atención. Dusk lo usa para la propagación de mensajes, mientras que Succinct Attestation se encarga de la propuesta, la validación y la ratificación. Así que la propagación del bloque no es solo “enviarlo a todos”; tiene que moverse por la red lo suficientemente rápido como para que los comités trabajen con la misma información.

También noté que Dusk exige a los provisionadores mantener los nodos sincronizados, y que Kadcast utiliza el puerto UDP 9000. Incluso la guía oficial de solución de problemas le dice a los operadores que verifiquen la conectividad entre pares y la altura del bloque cuando se estanca el progreso de la cadena.

Y la inversión directa mínima es de 1.000 DUSK, lo que significa que ejecutar infraestructura de consenso no es solo cuestión de tener tokens: el nodo tiene que permanecer en línea y sincronizado.

Para mí, esta es la parte interesante de Dusk: la finalización rápida no es solo una fórmula de consenso. La propagación de red también forma parte del límite de velocidad.

¿Qué pasa cuando Dusk escala a provisionadores mucho más distribuidos geográficamente?

¿La propagación podría convertirse en el verdadero cuello de botella?

Límite de propagación?
Yes, Soon
Maybe Later
No, Never
11 hora(s) restante(s)