Pasé una velada comparando la documentación de Dusk con cómo se comporta realmente su consenso, y el detalle que se me quedó grabado no es la capa de privacidad: es que Dusk @Dusk $DUSK #dusk splitea la generación de bloques de la ratificación de bloques en dos comités separados en lugar de que un único conjunto de validadores haga ambos trabajos. La mayoría de las cadenas tratan el consenso como un único rol que se pone dos sombreros. Aquí el generador está optimizado para el rendimiento, el ratificador para la seguridad de la finalidad, y esos dos objetivos no están alineados automáticamente. Lo que no pude encontrar una respuesta clara, ni en la documentación ni en la actividad de la red de pruebas, es qué sucede cuando los dos comités realmente discrepan: no un validador que se desconecta, sino una división real de criterio entre la generación y la ratificación. La arquitectura tiene claramente una ruta de resolución incorporada, ya que la cadena no se ha detenido en condiciones normales, pero "aún no se ha detenido" y "se resuelve limpiamente ante una discrepancia adversaria" son afirmaciones distintas. Casi ningún uso actual somete a prueba esa ruta, porque la mayor parte de la actividad todavía es ligera y cooperativa. Es una elección de diseño que ahora mismo es invisible y solo se vuelve legible cuando alguien la prueba bajo presión. Me pregunto cómo se ve eso en la práctica.