Sigo volviendo a la idea de que Dusk no trata el consenso como una única gran decisión.

El proceso se divide en etapas. Un bloque se prepara y se propone; luego, los participantes de la votación lo evalúan antes de que la red alcance un acuerdo sobre el estado resultante.

Esa separación es fácil de pasar por alto porque el resultado final es simplemente
“el bloque fue aceptado”.

Pero, mecánicamente, crea una distinción útil entre producir un estado candidato y lograr que la red esté de acuerdo con él. Si la propuesta es incorrecta, la etapa de votación tiene una oportunidad separada para rechazarla, en lugar de tratar la producción del bloque en sí misma como aceptación.
Me gusta esa estructura.

El intercambio es la coordinación. Cada etapa adicional tiene que comunicarse correctamente con la siguiente, y un sistema se vuelve más difícil de razonar cuando hay más piezas móviles que dependen unas de otras.

Entonces, ¿dividir el consenso en etapas explícitas hace que Dusk sea más resistente a propuestas malas, o la coordinación adicional simplemente crea otra superficie de falla?

#dusk @Dusk $DUSK
🛡️ More resilient
50%
⚙️ Adds failure points
0%
⚖️ Both
50%
🤔 Too early to tell
0%
2 Votos • Votación cerrada