@Dusk_Foundation
16 iteraciones fallidas consecutivas son suficientes para que Dusk deje de comportarse de forma normal.
Leí ese número varias veces antes de que se asentara.
En condiciones normales, los pasos de consenso se ejecutan con un tiempo de espera. Si un paso no produce un resultado a tiempo, no devuelve nada y la ronda vuelve a intentarlo.
Prueba. Tiempo de espera. Vuelve a intentar.
Asumí que esa ruta de fallo se quedaba en su sitio, sin importar lo mal que se pusieran las cosas.
No es así.
Después de 16 fallos consecutivos, Dusk desactiva esos tiempos de espera. Los pasos ya no pueden devolver NoCandidate o NoQuorum. Las iteraciones siguen ejecutándose hasta que un candidato alcance efectivamente el quórum para la validación y la ratificación.
Eso crea un segundo modo de fallo que no había separado antes.
El fallo normal está acotado por el reloj. El modo de emergencia elimina ese límite.
Y eso introduce otro problema: pueden ejecutarse varias iteraciones sin un final definido al mismo tiempo, creando la posibilidad de que candidatos en competencia alcancen el quórum en la misma ronda.
Dusk ya tiene una regla para ese caso: gana el candidato que alcanza el quórum en la iteración más baja.
Lo que aún no sé es cómo se ve realmente lo de 16 fallos consecutivos en una red en funcionamiento.
¿Qué tipo de condición sostenida de la red te lleva a eso y con qué frecuencia se aplicaría realmente la regla de resolución del fork en lugar de quedarse como un camino teórico?
$DUSK become más interesante para mí si esta ruta de emergencia demuestra ser fiable cuando la red realmente la necesita.
#dusk
16 iteraciones fallidas consecutivas son suficientes para que Dusk deje de comportarse de forma normal.
Leí ese número varias veces antes de que se asentara.
En condiciones normales, los pasos de consenso se ejecutan con un tiempo de espera. Si un paso no produce un resultado a tiempo, no devuelve nada y la ronda vuelve a intentarlo.
Prueba. Tiempo de espera. Vuelve a intentar.
Asumí que esa ruta de fallo se quedaba en su sitio, sin importar lo mal que se pusieran las cosas.
No es así.
Después de 16 fallos consecutivos, Dusk desactiva esos tiempos de espera. Los pasos ya no pueden devolver NoCandidate o NoQuorum. Las iteraciones siguen ejecutándose hasta que un candidato alcance efectivamente el quórum para la validación y la ratificación.
Eso crea un segundo modo de fallo que no había separado antes.
El fallo normal está acotado por el reloj. El modo de emergencia elimina ese límite.
Y eso introduce otro problema: pueden ejecutarse varias iteraciones sin un final definido al mismo tiempo, creando la posibilidad de que candidatos en competencia alcancen el quórum en la misma ronda.
Dusk ya tiene una regla para ese caso: gana el candidato que alcanza el quórum en la iteración más baja.
Lo que aún no sé es cómo se ve realmente lo de 16 fallos consecutivos en una red en funcionamiento.
¿Qué tipo de condición sostenida de la red te lleva a eso y con qué frecuencia se aplicaría realmente la regla de resolución del fork en lugar de quedarse como un camino teórico?
$DUSK become más interesante para mí si esta ruta de emergencia demuestra ser fiable cuando la red realmente la necesita.
#dusk