He estado mirando con más detenimiento cómo @Dusk maneja el consenso, y un detalle que me resulta fácil pasar por alto es que el proceso no se trata como una sola decisión.

Primero se prepara y propone un bloque. Luego, los participantes que votan lo evalúan antes de que la red acepte el estado resultante.

me importa esa separación porque producir un bloque candidato y aceptar ese bloque no es lo mismo. Si una propuesta es incorrecta, la etapa de votación proporciona un punto distinto donde los participantes pueden rechazarla en lugar de tratar la producción de bloques en sí misma como aceptación.

me gusta ese diseño desde una perspectiva de sistemas. Hace que la lógica sea más fácil de separar: primero proponer, luego llegar a un acuerdo.

pero hay otro aspecto que sigo pensando. Las etapas más explícitas también significan más coordinación entre los componentes. Si esas etapas dependen unas de otras, una estructura adicional puede introducir lugares adicionales donde la coordinación necesita funcionar correctamente.

mi postura es que la pregunta interesante no es si el diseño parece sofisticado. Es si esa separación realmente mejora la resiliencia sin crear complejidad innecesaria.

¿el consenso por etapas hace a Dusk más robusto ante propuestas malas? ¿O la coordinación añadida crea una nueva compensación?
#dusk $DUSK