Hablemos del rendimiento de blockchain, y en un grupo de diez personas, nueve tendrán como primera reacción pensar en TPS. El otro quizá mire la latencia. Pero el proyecto Dusk, si te tomas el tiempo de sacar su whitepaper y revisarlo con cuidado, descubrirás que hay algo que merece más atención que la velocidad de las transacciones: cómo “se comunican” los nodos entre sí.
El pastel de todos modos: ¡BTC cayó, pero no mucho!
Lo que digo no es porque el TPS no sea importante, sino porque “calcular rápido” y “transmitir rápido” son cosas totalmente distintas. Si la capa de ejecución es muy potente y el diseño del consenso es aún más fino, pero los mensajes se atascan en la red de nodos—las propuestas no llegan a los validadores y los resultados de verificación no regresan al comité de ratification—entonces todo el flujo de tres fases se queda esperando. Si el bloque llega con retraso por unos segundos, en el mejor de los casos la experiencia se resiente; y en el peor, distintos nodos ven distintos bloques candidatos, y la tasa de stale block se dispara.
Dusk eligió el camino de Kadcast. No es el modo de difusión “Gossip” de reenviar a todo el mundo, sino una red de cobertura estructurada construida sobre Kademlia DHT: la distancia XOR entre IDs de nodos determina el enrutamiento, y los mensajes se despliegan capa por capa como si fuera un árbol. ¿Suena académico, verdad? Pero la lógica central se resume en una sola frase: cada mensaje solo recorre el camino que le corresponde; no toma rutas “de casualidad”.
El whitepaper cita estudios que dicen que Kadcast, frente a Gossip, puede ahorrar entre 25% y 50% de ancho de banda. Por ejemplo, si antes se consumían 100 unidades de ancho de banda, ahora sería aproximadamente entre 50 y 75—pero esos números no se pueden traducir directamente como “a la mitad el costo de los nodos”. La configuración de las máquinas no cambia, el cómputo de pruebas no cambia, la carga de almacenamiento no cambia; lo único que cambia es el costo de transmisión en la capa de red. Pero hablando claro, para quienes ejecutan nodos: ¿qué significa que la mitad de ancho de banda? Significa que, con las mismas condiciones de ancho de banda, se pueden conectar más nodos; o que, con el mismo tamaño de red, es menos probable que las tarifas de ancho de banda se conviertan en el cuello de botella.
Hay un detalle que lo explica muy bien. En la documentación de nodos, el 9000/udp está marcado como el puerto indispensable para Kadcast. El Provisioner tiene que participar en el consenso, por lo que debe ser accesible ese canal. En cambio, 8080/tcp es opcional: solo se abre si necesitas usar la interfaz de consulta. En otras palabras, Kadcast no es un adorno del diagrama de arquitectura: directamente pone el límite de si el nodo puede o no participar en el consenso.
Quien conoce la difusión punto a punto de BTC sabe que cómo atraviesa un mensaje la red de nodos nunca es un asunto menor. @Dusk $DUSK #dusk
El pastel de todos modos: ¡BTC cayó, pero no mucho!
Lo que digo no es porque el TPS no sea importante, sino porque “calcular rápido” y “transmitir rápido” son cosas totalmente distintas. Si la capa de ejecución es muy potente y el diseño del consenso es aún más fino, pero los mensajes se atascan en la red de nodos—las propuestas no llegan a los validadores y los resultados de verificación no regresan al comité de ratification—entonces todo el flujo de tres fases se queda esperando. Si el bloque llega con retraso por unos segundos, en el mejor de los casos la experiencia se resiente; y en el peor, distintos nodos ven distintos bloques candidatos, y la tasa de stale block se dispara.
Dusk eligió el camino de Kadcast. No es el modo de difusión “Gossip” de reenviar a todo el mundo, sino una red de cobertura estructurada construida sobre Kademlia DHT: la distancia XOR entre IDs de nodos determina el enrutamiento, y los mensajes se despliegan capa por capa como si fuera un árbol. ¿Suena académico, verdad? Pero la lógica central se resume en una sola frase: cada mensaje solo recorre el camino que le corresponde; no toma rutas “de casualidad”.
El whitepaper cita estudios que dicen que Kadcast, frente a Gossip, puede ahorrar entre 25% y 50% de ancho de banda. Por ejemplo, si antes se consumían 100 unidades de ancho de banda, ahora sería aproximadamente entre 50 y 75—pero esos números no se pueden traducir directamente como “a la mitad el costo de los nodos”. La configuración de las máquinas no cambia, el cómputo de pruebas no cambia, la carga de almacenamiento no cambia; lo único que cambia es el costo de transmisión en la capa de red. Pero hablando claro, para quienes ejecutan nodos: ¿qué significa que la mitad de ancho de banda? Significa que, con las mismas condiciones de ancho de banda, se pueden conectar más nodos; o que, con el mismo tamaño de red, es menos probable que las tarifas de ancho de banda se conviertan en el cuello de botella.
Hay un detalle que lo explica muy bien. En la documentación de nodos, el 9000/udp está marcado como el puerto indispensable para Kadcast. El Provisioner tiene que participar en el consenso, por lo que debe ser accesible ese canal. En cambio, 8080/tcp es opcional: solo se abre si necesitas usar la interfaz de consulta. En otras palabras, Kadcast no es un adorno del diagrama de arquitectura: directamente pone el límite de si el nodo puede o no participar en el consenso.
Quien conoce la difusión punto a punto de BTC sabe que cómo atraviesa un mensaje la red de nodos nunca es un asunto menor. @Dusk $DUSK #dusk