Cuando los nodos se sienten realmente incómodos, por lo general no es que el bloque de repente crezca, sino que la red empieza a volverse “desobediente”.
Esta vez, al observar la capa de propagación de <t-2/> #dusk , me atrae un detalle: no interpreta la eficiencia de la red simplemente como “a más ancho de banda, mejor”, sino que intenta actuar directamente sobre el hecho de cómo viajan los mensajes.
@Dusk utiliza un mecanismo de propagación direccional basado en la distancia entre nodos en Kadcast. El nodo no recibe un mensaje y luego lo difunde sin pensar a todos los vecinos; en su lugar, elige el siguiente salto según las relaciones de enrutamiento, para que el mensaje continúe transmitiéndose por una ruta más definida. Parece menos “sexy” que otras ideas, pero en realidad es muy importante para una blockchain pública.
Porque el mayor problema de Gossip no es “ser lento”, sino la repetición.
Una misma transacción vuelve en un bucle desde nodos distintos: la red aún tiene que seguir reenviando, validando y almacenando en caché. Cuando aumenta la cantidad de nodos, la redundancia de mensajes termina consumiendo tanto el ancho de banda como la CPU. Lo que Kadcast intenta resolver, en esencia, es reducir esa propagación inútil, haciendo que los recursos de la red se empleen en mensajes que realmente necesitan llegar.
Pero yo no voy a asentir simplemente al ver la frase “reducir el consumo de ancho de banda”.
El mayor riesgo de este tipo de diseño es precisamente la red del mundo real. Si los nodos se desconectan de forma repentina, la latencia se dispara o los vecinos del enrutamiento dejan de estar disponibles, la supuesta ruta más corta podría convertirse instantáneamente en un camino cortado. Para garantizar que el mensaje finalmente llegue, el sistema debe preparar rutas alternativas y mecanismos de reencaminamiento. Cuanto más complejo sea el mecanismo de respaldo, más evidente se vuelve la tensión entre eficiencia de propagación y costo de mantenimiento.
Además, los nodos de una blockchain pública no son servidores fijos de laboratorio.
Al contrario, creo que ese es precisamente el punto que vale la pena seguir observando en la capa de propagación de $DUSK .
Si Kadcast logra mantener la estabilidad incluso en escenarios sucios como la entrada y salida masiva de nodos, la latencia entre regiones y la partición de la red, entonces no solo resuelve “ahorrar ancho de banda”, sino que hace que sea más fácil para los nodos comunes participar en la red.
Pero si, ante cualquier fallo de enrutamiento, se repliega con frecuencia, entonces toda esa eficiencia teórica de antes no tendrá mucho significado.
Al final, la blockchain pública no la gana la curva más bonita del whitepaper, sino si a las tres de la madrugada, cuando la red tiene problemas, los nodos aún pueden encontrarse el camino por sí mismos. ¿Ustedes creen que una modificación así en la capa de propagación suma para la descentralización a largo plazo de la blockchain pública, o empuja la complejidad del sistema hacia arriba?
Esta vez, al observar la capa de propagación de <t-2/> #dusk , me atrae un detalle: no interpreta la eficiencia de la red simplemente como “a más ancho de banda, mejor”, sino que intenta actuar directamente sobre el hecho de cómo viajan los mensajes.
@Dusk utiliza un mecanismo de propagación direccional basado en la distancia entre nodos en Kadcast. El nodo no recibe un mensaje y luego lo difunde sin pensar a todos los vecinos; en su lugar, elige el siguiente salto según las relaciones de enrutamiento, para que el mensaje continúe transmitiéndose por una ruta más definida. Parece menos “sexy” que otras ideas, pero en realidad es muy importante para una blockchain pública.
Porque el mayor problema de Gossip no es “ser lento”, sino la repetición.
Una misma transacción vuelve en un bucle desde nodos distintos: la red aún tiene que seguir reenviando, validando y almacenando en caché. Cuando aumenta la cantidad de nodos, la redundancia de mensajes termina consumiendo tanto el ancho de banda como la CPU. Lo que Kadcast intenta resolver, en esencia, es reducir esa propagación inútil, haciendo que los recursos de la red se empleen en mensajes que realmente necesitan llegar.
Pero yo no voy a asentir simplemente al ver la frase “reducir el consumo de ancho de banda”.
El mayor riesgo de este tipo de diseño es precisamente la red del mundo real. Si los nodos se desconectan de forma repentina, la latencia se dispara o los vecinos del enrutamiento dejan de estar disponibles, la supuesta ruta más corta podría convertirse instantáneamente en un camino cortado. Para garantizar que el mensaje finalmente llegue, el sistema debe preparar rutas alternativas y mecanismos de reencaminamiento. Cuanto más complejo sea el mecanismo de respaldo, más evidente se vuelve la tensión entre eficiencia de propagación y costo de mantenimiento.
Además, los nodos de una blockchain pública no son servidores fijos de laboratorio.
Al contrario, creo que ese es precisamente el punto que vale la pena seguir observando en la capa de propagación de $DUSK .
Si Kadcast logra mantener la estabilidad incluso en escenarios sucios como la entrada y salida masiva de nodos, la latencia entre regiones y la partición de la red, entonces no solo resuelve “ahorrar ancho de banda”, sino que hace que sea más fácil para los nodos comunes participar en la red.
Pero si, ante cualquier fallo de enrutamiento, se repliega con frecuencia, entonces toda esa eficiencia teórica de antes no tendrá mucho significado.
Al final, la blockchain pública no la gana la curva más bonita del whitepaper, sino si a las tres de la madrugada, cuando la red tiene problemas, los nodos aún pueden encontrarse el camino por sí mismos. ¿Ustedes creen que una modificación así en la capa de propagación suma para la descentralización a largo plazo de la blockchain pública, o empuja la complejidad del sistema hacia arriba?