Todo el mundo habla del modo de emergencia de Dusk como si fuera solo una red de seguridad cuando se atasca la producción de bloques. Pero lo que realmente captó mi atención es algo más pequeño que eso: cuando un paso se agota el tiempo, Dusk no se detiene y espera. Simplemente inicia una nueva iteración, mientras la anterior sigue ejecutándose, todavía permitida para llegar al quórum. Dos intentos vivos al mismo tiempo, y eso no es casualidad.

Eso es algo extraño de aceptar, si lo piensas. La mayoría de los sistemas de consenso tratan la espera como el movimiento seguro y el desacuerdo como el que da miedo. Dusk básicamente lo invierte durante las emergencias. Dice: una ruta bloqueada es peor que un fork temporal, siempre que haya una regla limpia para limpiar ese fork después; gana la iteración más baja, listo.

Pero lo que me inquieta es esto. Esa regla solo funciona si cada provisionador puede, en realidad, ponerse de acuerdo sobre qué iteración llegó al quórum primero, sin discutirlo. Y el momento en que estás en modo de emergencia es exactamente el momento en el que es más difícil saberlo: validadores que faltan, conexiones irregulares, mensajes demorados.

Así que no creo que la pregunta interesante sea si Dusk tolera el caos. Claramente lo hace, a propósito. La pregunta real es si la salida de ese caos se mantiene limpia cuando la red ya está sufriendo, o si simplemente suele hacerlo.

#dusk @Dusk $DUSK