Tuvimos un período de cortes de energía en Islamabad la semana pasada, donde la red seguía fallando una y otra vez, y cada vez que volvía, el sistema de respaldo tenía que reiniciarse desde cero en lugar de retomar donde lo había dejado. Asumí que el modo de emergencia de Dusk funcionaba igual: se atasca la red y simplemente sigue reintentando el mismo tiempo de espera fijo hasta que algo funcione.
No es así. El modo de emergencia solo se activa después de 16 iteraciones consecutivas fallidas, y una vez que se activa, toda la estructura de tiempos de espera se elimina. Las iteraciones ya no expiran; se ejecutan indefinidamente hasta que un bloque candidato realmente se propone y llega al quórum tanto en la validación como en la ratificación. Los votos NoCandidate y NoQuorum también se deshabilitan, así que cada paso tiene que completarse correctamente antes de que comience el siguiente.
Lo que en realidad cambió mi perspectiva es que varias de estas iteraciones abiertas pueden ejecutarse a la vez. Eso no es una falla: es intencional. Aumenta las probabilidades de que al menos una produzca un bloque válido. El costo es más riesgo de bifurcación, que se resuelve eligiendo siempre el candidato que alcanzó el consenso en el menor número de iteración.
También hay un último recurso dentro del último recurso. Si incluso la iteración final se atasca, los provisionadores que controlan la mayoría de la participación total pueden solicitar un bloque de emergencia: un bloque vacío especial firmado por Dusk, sin transacciones, solo para mantener el ciclo en marcha.
Lo que el whitepaper no dice es con qué frecuencia esto se ha activado realmente en la infraestructura de Dusk hasta ahora. No tengo datos para respaldar una afirmación sobre la frecuencia.
La prueba real para DUSK es qué tan raramente tiene que activarse el modo de emergencia una vez que el mainnet funcione a escala real.
¿Alguien ha presenciado realmente que se active el modo de emergencia en Dusk?
@Dusk #dusk $DUSK
No es así. El modo de emergencia solo se activa después de 16 iteraciones consecutivas fallidas, y una vez que se activa, toda la estructura de tiempos de espera se elimina. Las iteraciones ya no expiran; se ejecutan indefinidamente hasta que un bloque candidato realmente se propone y llega al quórum tanto en la validación como en la ratificación. Los votos NoCandidate y NoQuorum también se deshabilitan, así que cada paso tiene que completarse correctamente antes de que comience el siguiente.
Lo que en realidad cambió mi perspectiva es que varias de estas iteraciones abiertas pueden ejecutarse a la vez. Eso no es una falla: es intencional. Aumenta las probabilidades de que al menos una produzca un bloque válido. El costo es más riesgo de bifurcación, que se resuelve eligiendo siempre el candidato que alcanzó el consenso en el menor número de iteración.
También hay un último recurso dentro del último recurso. Si incluso la iteración final se atasca, los provisionadores que controlan la mayoría de la participación total pueden solicitar un bloque de emergencia: un bloque vacío especial firmado por Dusk, sin transacciones, solo para mantener el ciclo en marcha.
Lo que el whitepaper no dice es con qué frecuencia esto se ha activado realmente en la infraestructura de Dusk hasta ahora. No tengo datos para respaldar una afirmación sobre la frecuencia.
La prueba real para DUSK es qué tan raramente tiene que activarse el modo de emergencia una vez que el mainnet funcione a escala real.
¿Alguien ha presenciado realmente que se active el modo de emergencia en Dusk?
@Dusk #dusk $DUSK
