Anoche volví a revisar el whitepaper de Dusk, centrándome en las secciones de modo de emergencia, fallback y finalización en progreso. Los detalles eran más matizados de lo que esperaba.

El modo de emergencia se activa después de 16 iteraciones fallidas. Luego se deshabilitan los timeouts de los pasos y las iteraciones abiertas continúan hasta que un bloque candidato alcanza quórum tanto en validación como en ratificación. Se pueden ejecutar varias iteraciones a la vez, lo que mejora la probabilidad de producir un bloque, pero también aumenta la posibilidad de bifurcaciones. Si varios candidatos alcanzan consenso, se selecciona la iteración más baja. En la última iteración, los provisioners pueden solicitar un bloque de emergencia, pero requiere que los provisioners que lo soliciten tengan la mayoría de la participación total de la red.

Las reglas de fallback también llamaron mi atención: un bloque de la iteración J > 0 potencialmente puede reemplazarse por un bloque de iteración inferior que luego alcance consenso, mientras que la iteración 0 no puede reemplazarse de esta manera.

Luego, la finalización en progreso añade otra capa. Si n iteraciones anteriores fallaron la atestación, se acepta un bloque y se necesita que existan 2×n bloques consecutivos atestados o confirmados para que se confirme. El ejemplo del documento usa la iteración 5, n=2, lo que significa que se requieren 4 bloques más.

Todavía me pregunto: ¿este diseño crea algún riesgo de centralización significativo en torno a la recuperación de emergencia ponderada por stake?

@Dusk #dusk $DUSK