Muchos, cuando mencionan "finalidad", piensan en “cuántos bloques hay que pasar para que ya no se pueda cambiar”, una idea de corte tajante. Después de ver el diseño de finality rolling de Dusk, me di cuenta de que esa idea es demasiado burda.

Divide el estado de los bloques en cuatro niveles: accepted, attested, confirmed y final. Se va escalando capa por capa, no es blanco o negro. Si un bloque de una ronda con pocas iteraciones no logra reunir suficientes “pruebas de fallos”, puede ser reemplazado por bloques de rondas posteriores. Sin embargo, a medida que se acumulan más bloques confirmados, la probabilidad de bifurcación cae de forma exponencial y, al final, queda bloqueado en un estado final irreversible. En esencia, este diseño cuantifica el “cuánto tiempo hace falta para poder estar tranquilos” como una curva, en lugar de un número fijo.

Lo que más me preocupa es cómo evita la especulación: por ejemplo, que alguien intencionalmente llegue a la ronda en la que va a proponer/apoyar, esperando recoger las recompensas por minar bloques en rondas posteriores. El protocolo diseña específicamente varias contramedidas: recompensas por voto, puntos adicionales, y la exclusión de la elegibilidad para proponer/minar en la ronda siguiente; además, impone un límite al número de iteraciones. En conjunto, va cerrando una a una las brechas a nivel de teoría de juegos, en vez de confiar simplemente en las penalizaciones.

Pero cuanto más me meto en los detalles, más dudas me surgen: el mecanismo se basa en que el tamaño del comité sea lo bastante grande y que la comunicación de red sea lo bastante rápida. Si algún día hay una partición de red o se alarga la latencia de propagación de mensajes, ¿no se vendría abajo primero la suposición de “acumulación rápida de bloques confirmados”? Si se puede o no lograr a la vez la finalización en segundos y la robustez bajo condiciones de red extremas, por ahora no he visto una respuesta que me deje completamente tranquilo.

@Dusk_Foundation #dusk $DUSK