#dusk $DUSK @Dusk
Antes pensaba que el Modo de Emergencia de Dusk era simplemente un plan de respaldo cuando la red no podía producir un bloque.
Pero después de mirarlo con más profundidad, creo que hay una idea más interesante aquí: ¿cómo se mantiene un blockchain en movimiento cuando falla el consenso normal?
Dusk normalmente avanza a través de iteraciones en las que se proponen, validan y ratifican bloques. Pero si demasiados provisioners se desconectan, varias iteraciones pueden fallar una tras otra.
Después de 16 iteraciones consecutivas fallidas, Dusk puede entrar en Modo de Emergencia.
Lo que cambia aquí es bastante interesante. Los timeouts normales del tiempo de paso dejan de ser la principal limitación, y varias iteraciones abiertas pueden seguir intentando hasta que una alcance el quórum.
Por supuesto, eso crea otro problema. Tener varios candidatos también significa una mayor probabilidad de bloques en competencia.
Dusk lo maneja aceptando el bloque exitoso de la iteración con el número más bajo y cerrando el resto de las iteraciones abiertas.
Pero, ¿qué pasa si incluso la última iteración no puede llegar al quórum?
Ahí es donde entran las Solicitudes de Bloque de Emergencia.
Si una mayoría ponderada por participación de los provisioners solicita una, Dusk puede crear un bloque especial vacío, firmado por Dusk mismo, lo que permite que la cadena avance en lugar de quedarse atascada indefinidamente.
La parte que más me interesa es el equilibrio.
Dusk está agregando un respaldo centralizado controlado para proteger la continuidad de la red durante un escenario de falla extrema.
Así que tal vez la pregunta real no es si el Modo de Emergencia está lo suficientemente descentralizado.
Sino si mantener viva la red durante una situación en el peor de los casos vale esa pequeña concesión.
Ese equilibrio entre descentralización y continuidad es lo que hace que el diseño de consenso de Dusk sea interesante para mí.
Antes pensaba que el Modo de Emergencia de Dusk era simplemente un plan de respaldo cuando la red no podía producir un bloque.
Pero después de mirarlo con más profundidad, creo que hay una idea más interesante aquí: ¿cómo se mantiene un blockchain en movimiento cuando falla el consenso normal?
Dusk normalmente avanza a través de iteraciones en las que se proponen, validan y ratifican bloques. Pero si demasiados provisioners se desconectan, varias iteraciones pueden fallar una tras otra.
Después de 16 iteraciones consecutivas fallidas, Dusk puede entrar en Modo de Emergencia.
Lo que cambia aquí es bastante interesante. Los timeouts normales del tiempo de paso dejan de ser la principal limitación, y varias iteraciones abiertas pueden seguir intentando hasta que una alcance el quórum.
Por supuesto, eso crea otro problema. Tener varios candidatos también significa una mayor probabilidad de bloques en competencia.
Dusk lo maneja aceptando el bloque exitoso de la iteración con el número más bajo y cerrando el resto de las iteraciones abiertas.
Pero, ¿qué pasa si incluso la última iteración no puede llegar al quórum?
Ahí es donde entran las Solicitudes de Bloque de Emergencia.
Si una mayoría ponderada por participación de los provisioners solicita una, Dusk puede crear un bloque especial vacío, firmado por Dusk mismo, lo que permite que la cadena avance en lugar de quedarse atascada indefinidamente.
La parte que más me interesa es el equilibrio.
Dusk está agregando un respaldo centralizado controlado para proteger la continuidad de la red durante un escenario de falla extrema.
Así que tal vez la pregunta real no es si el Modo de Emergencia está lo suficientemente descentralizado.
Sino si mantener viva la red durante una situación en el peor de los casos vale esa pequeña concesión.
Ese equilibrio entre descentralización y continuidad es lo que hace que el diseño de consenso de Dusk sea interesante para mí.