Por fin el verano está llegando a su fin y las temperaturas también van bajando poco a poco. La semana pasada, mientras conducía con mi familia para ir a divertirnos, en la autopista apareció de repente un accidente delante. El sistema de navegación me indicó temporalmente una vía secundaria, pero los coches detrás no cambiaron y siguieron por la ruta original. Durante casi diez minutos, ambas rutas fueron paralelas; más tarde, cuando se despejó el accidente, el sistema recién entonces volvió a dirigir a todos de vuelta a la vía principal. Durante ese tiempo, nadie sabía cuál era "la ruta final" que realmente habría que seguir.
En el consenso de Dusk también hay un escenario parecido de "bifurcación" llamado fallback (retroceso). Debido a que la red es asíncrona, los mensajes pueden retrasarse o perderse. En una misma ronda, a veces se puede llegar a un consenso simultáneo sobre más de un bloque candidato; eso es una bifurcación. Las reglas de manejo son muy directas: se considera el bloque que haya alcanzado el consenso en la iteración (iteration) más baja. Los bloques de rondas más altas serán reemplazados por los de rondas más bajas; la cadena retrocede hasta el bloque que existía antes de la bifurcación y luego se conecta con la rama en la que se llegó a un consenso más temprano. La cadena que fue sustituida, y todos los bloques que venían después, también quedan invalidados.
Hay un detalle que se suele pasar por alto: los bloques que alcanzan consenso en la iteración 0 (iteration 0) son los únicos que no pueden ser "reemplazados", porque no existe una iteración más baja. Pero incluso ellos, si su propio "bloque padre" luego fue retrocedido, igual tendrán que retroceder con él: no es una seguridad absoluta, sino una forma relativamente más estable.
Este mecanismo resuelve cómo "dar salida" a una bifurcación temporal causada por retrasos en los mensajes de red, pero a cambio, durante un tiempo breve la cadena puede tener incertidumbre. Los bloques recién salidos, especialmente los de iteraciones más altas, en teoría tienen la posibilidad de ser reemplazados; hay que esperar a que los bloques posteriores los "suelden" para poder estar realmente tranquilos.
$DUSK
#dusk @Dusk
En el consenso de Dusk también hay un escenario parecido de "bifurcación" llamado fallback (retroceso). Debido a que la red es asíncrona, los mensajes pueden retrasarse o perderse. En una misma ronda, a veces se puede llegar a un consenso simultáneo sobre más de un bloque candidato; eso es una bifurcación. Las reglas de manejo son muy directas: se considera el bloque que haya alcanzado el consenso en la iteración (iteration) más baja. Los bloques de rondas más altas serán reemplazados por los de rondas más bajas; la cadena retrocede hasta el bloque que existía antes de la bifurcación y luego se conecta con la rama en la que se llegó a un consenso más temprano. La cadena que fue sustituida, y todos los bloques que venían después, también quedan invalidados.
Hay un detalle que se suele pasar por alto: los bloques que alcanzan consenso en la iteración 0 (iteration 0) son los únicos que no pueden ser "reemplazados", porque no existe una iteración más baja. Pero incluso ellos, si su propio "bloque padre" luego fue retrocedido, igual tendrán que retroceder con él: no es una seguridad absoluta, sino una forma relativamente más estable.
Este mecanismo resuelve cómo "dar salida" a una bifurcación temporal causada por retrasos en los mensajes de red, pero a cambio, durante un tiempo breve la cadena puede tener incertidumbre. Los bloques recién salidos, especialmente los de iteraciones más altas, en teoría tienen la posibilidad de ser reemplazados; hay que esperar a que los bloques posteriores los "suelden" para poder estar realmente tranquilos.
$DUSK
#dusk @Dusk