He estado ejecutando una posición pequeña en $DUSK durante unas semanas, principalmente observando. Nada dramático; ayer aumenté un poco más después de notar algo en la documentación del protocolo que no había visto que nadie estuviera comentando.

Se trata de lo que ocurre cuando el consenso simplemente... deja de funcionar. No por un ataque. No por un bug. Simplemente porque los validadores se quedan en silencio.

Dusk tiene algo llamado Emergency Mode, y mi primera lectura fue que existía para producir bloques de emergencia. No es exactamente así.

El punto real es preservar la vivacidad (liveness) cuando la participación del stake se vuelve poco fiable.

Esto es lo que llamó mi atención: Dusk no se congela si los validadores siguen fallando. En cambio, deja abiertas las iteraciones anteriores de consenso mientras al mismo tiempo comienzan otras nuevas. Los provisioners restantes obtienen más intentos para llegar a un acuerdo, en lugar de chocar contra un muro definitivo.

La regla de prioridad también importa. Si varias iteraciones se completan con éxito a la vez, el protocolo siempre favorece la iteración de menor número. Así se resuelve el problema de bloques en competencia sin necesidad de intervención manual.

Y si incluso eso falla, entra en juego la Emergency Block Request.

Una vez que las EBR que representan la mayoría del stake se acumulan, la cadena produce un bloque vacío: ¡sin transacciones, solo continuidad y una semilla fresca para la siguiente ronda!

Esa elección de diseño me dice que @Dusk no está construyendo para condiciones ideales.

Está construyendo para el momento en que esas condiciones se rompen.

Lo que genuinamente aún no sé es cómo se sostiene esta vía de recuperación si la participación sigue degradada durante múltiples rondas consecutivas. Esa es la prueba de esfuerzo que me gustaría ver documentada.

#Dusk #EmergencyMode #DuskEVM
¿Qué es lo más importante del diseño del Emergency Mode de Dusk?