Mysticeti: La 3ra generación de DAG-BFT con latencias sub-segundo

Narwhal separó la difusión de datos del ordenamiento: los validadores construyen un DAG de bloques y un protocolo de consenso decide un orden total sobre ese grafo. [2] Bullshark llevó esa idea a sincronía parcial con un commit determinista sobre anclas del DAG. [3] Ambos diseños obtienen alto throughput, pero pagan un precio en latencia porque cada vértice del grafo se certifica antes de poder ser referenciado.

Mysticeti, presentado por Babel y coautores en NDSS 2025, parte de una pregunta concreta: ¿puede un consenso basado en DAG alcanzar la latencia mínima de un protocolo BFT en sincronía parcial sin renunciar a la eficiencia de recursos del DAG? [1] Su respuesta es Mysticeti-C, un protocolo que elimina la certificación explícita de bloques y confirma en 3 retardos de mensaje en el caso estable, más una extensión, Mysticeti-FPC, con un camino rápido para transferir activos. [1]

Llamarlo "tercera generación" es una convención de esta serie, no del paper: la primera generación son los protocolos con líder y cadena lineal como HotStuff, la segunda los DAG certificados como Narwhal y Bullshark, y la tercera los DAG sin certificar.

Qué cuesta certificar cada bloque

En Narwhal, un validador difunde su bloque, los demás lo validan y devuelven una firma, y el autor agrega $2f + 1$ firmas en un certificado de disponibilidad. Solo los certificados entran al DAG como vértices referenciables. [2] Esa disciplina garantiza dos cosas valiosas: que los datos estén disponibles en suficientes réplicas correctas y que un autor no pueda tener dos vértices certificados distintos en la misma ronda.

El costo es temporal. Antes de que un bloque cuente para el consenso hay una ida y vuelta adicional de firmas, y el ordenamiento de Bullshark se apoya en rondas formadas por esos vértices ya certificados. [3] En protocolos con líder como HotStuff, la evidencia también es explícita: el líder recolecta votos firmados y los agrega en un certificado de quórum (QC) por cada fase. [4]

Mysticeti cuestiona que esa certificación individual sea necesaria. Si la estructura del DAG ya registra quién vio qué, los votos pueden leerse del grafo en lugar de recolectarse como mensajes aparte. [1] La consecuencia es que el DAG deja de tener la garantía de "un vértice por autor y ronda": un validador bizantino puede equivocar y publicar dos bloques distintos para la misma ronda. El protocolo tiene que absorber esa posibilidad en su regla de decisión, no en la capa de difusión.

Bloques, votos y certificados implícitos

En Mysticeti-C el tiempo avanza en rondas. En cada ronda, cada validador honesto produce un único bloque firmado que contiene transacciones y referencias a bloques de rondas anteriores, incluyendo al menos $2f + 1$ bloques de la ronda previa. [1] Algunas parejas (validador, ronda) se designan como slots de líder, y el protocolo admite varios slots de líder por ronda, de modo que más de un bloque por ronda puede convertirse en punto de commit. [1]

Sobre esa estructura el paper define dos patrones que se reconocen localmente, sin mensajes adicionales: [1]

1. Voto. Un bloque de la ronda $r+1$ vota por un bloque $B$ de un slot de la ronda $r$ cuando $B$ aparece en su historia causal. Si el slot tiene varios bloques por equivocación, el voto cuenta para el primero que se encuentra al recorrer la historia de forma determinista, de modo que un bloque honesto vota a lo sumo por uno.
2. Certificado. Un bloque de la ronda $r+2$ certifica a $B$ cuando su historia causal contiene $2f + 1$ votos por $B$.

Por intersección de quórums, dos conjuntos de $2f + 1$ votos comparten al menos una réplica correcta, y esa réplica no vota por dos bloques del mismo slot. Por eso, aunque el DAG no impida la equivocación, a lo sumo un bloque por slot puede quedar certificado. [1] La firma que hace no repudiable el voto es la firma ordinaria del bloque que lo contiene; no hay una firma de voto separada.

Tres retardos de mensaje: por qué es la cifra relevante

El nombre del artículo habla de saltos de red; la unidad precisa es el retardo de mensaje. En el caso estable, el líder difunde su bloque en la ronda $r$ (primer retardo), los validadores lo referencian en sus bloques de $r+1$ (segundo) y los bloques de $r+2$ acumulan esos votos como certificados (tercero). Al recibir $2f + 1$ certificados de la ronda $r+2$, una réplica puede confirmar el slot. [1]

Los autores presentan Mysticeti-C como el primer consenso bizantino basado en DAG que alcanza la cota inferior de latencia de 3 rondas de mensajes para el commit. [1] La mejora no viene de mensajes más rápidos sino de quitar pasos: no hay una ida y vuelta de certificación antes de que un bloque cuente, ni mensajes de voto separados del flujo normal de bloques.

Conviene separar este resultado de dos lecturas erróneas. La primera es pensar que el commit es incondicional en 3 retardos: lo es en el caso estable, con líderes correctos y red sincrónica; con líderes lentos o caídos interviene la regla indirecta. La segunda es leer "3 saltos" como una latencia en milisegundos: la latencia real depende de la geografía del comité y de la carga, y las cifras publicadas son mediciones de un experimento concreto.

La regla de decisión de Mysticeti-C

Cada slot de líder termina en uno de tres estados: confirmado (commit), saltado (skip) o pendiente. La regla directa intenta decidir el slot con la evidencia de las rondas inmediatas: [1]

• Commit directo. Si la réplica observa $2f + 1$ bloques de la ronda $r+2$ que certifican a $B$, confirma el slot con $B$.
• Skip directo. Si observa $2f + 1$ bloques de la ronda $r+1$ que no votan por ningún bloque del slot, ningún bloque del slot puede reunir $2f + 1$ votos y el slot se salta sin esperar.
• Pendiente. Si no se cumple ninguna de las dos condiciones, la regla directa no decide.

El skip directo explica buena parte del comportamiento ante fallas por caída: si el líder de un slot no publica nada, los bloques de la ronda siguiente no votan por él y las réplicas lo saltan sin un timeout de cambio de vista al estilo de los protocolos con líder único. [1]

Para los slots pendientes actúa la regla indirecta. La réplica busca un ancla: el primer slot de una ronda $r' \ge r+3$ que esté confirmado o pendiente, ignorando los saltados. Si el ancla está pendiente, el slot original sigue pendiente. Si el ancla está confirmada, la réplica revisa la historia causal del bloque ancla: si contiene un certificado para $B$, confirma $B$; si no, salta el slot. [1]

Finalmente, la réplica procesa los slots en orden y se detiene en el primero que siga pendiente. La secuencia de bloques líder confirmados define el orden, y la historia causal de cada uno se linealiza de forma determinista para producir el orden total de transacciones. [1] Es la misma idea que Bullshark aplica a sus anclas, donde el commit de un ancla arrastra las anclas anteriores alcanzables en el DAG. [3]

Por qué la regla indirecta es segura

La pregunta de safety es si dos réplicas honestas pueden decidir distinto sobre el mismo slot: una confirmarlo de forma directa y otra saltarlo de forma indirecta. El argumento del paper descansa en que un commit directo exige $2f + 1$ certificados en la ronda $r+2$. [1]

Cualquier bloque de una ronda $r' \ge r+3$ referencia $2f + 1$ bloques de la ronda anterior, y por eso su historia causal alcanza al menos uno de esos certificados. Si una réplica confirmó $B$ directamente, toda ancla posterior contiene un certificado para $B$ y la regla indirecta también lo confirma. [1] Del mismo modo, si existe un skip directo, ningún bloque del slot reunió $2f + 1$ votos, así que ninguna ancla puede contener un certificado para él.

El precio de esta seguridad es que un slot pendiente bloquea el avance del orden hasta que se decide. La liveness depende de que, después de la estabilización de la red, haya líderes correctos cuyos slots se confirmen; los validadores esperan un tiempo acotado por los bloques de líder antes de avanzar de ronda, lo que mantiene el compromiso habitual de la sincronía parcial: safety siempre, progreso después de GST. [1]

Mysticeti-FPC: el camino rápido para objetos con dueño

Algunas transacciones no necesitan orden total. Una transferencia que solo toca objetos de un único dueño, como monedas de una cuenta, únicamente debe evitar que ese dueño gaste dos veces el mismo objeto. Para esos casos basta con que un quórum de validadores acepte la transacción, sin decidir su posición respecto de transacciones ajenas. Mysticeti-FPC ofrece ese camino rápido para transferir activos. [1]

Lo distintivo es dónde viven los votos. Los caminos rápidos previos recogen firmas por transacción y construyen certificados aparte; Mysticeti-FPC teje las transacciones del camino rápido dentro del DAG, de modo que los bloques que ya circulan transportan los votos y el número de firmas y mensajes se reduce. [1] Un validador vota por una transacción al incluirla en la historia de sus bloques, y la evidencia de $2f + 1$ votos se lee del grafo como en Mysticeti-C. Las transacciones sobre objetos compartidos, en cambio, siguen necesitando el orden total del consenso.

El camino rápido no elimina el riesgo de equivocación del dueño. Si este firma dos transacciones que gastan el mismo objeto, los validadores correctos votan por a lo sumo una, y puede ocurrir que ninguna reúna quórum. Ese caso no rompe la safety, pero deja el objeto sin progreso por la vía rápida, y el cierre de época exige un tratamiento específico porque las transacciones rápidas no pasan por el orden total. [1]

Ese tratamiento separa dos momentos. La ejecución por camino rápido ocurre cuando un validador ve bloques de $2f + 1$ validadores que incluyen un voto por la transacción: ya puede ejecutarla y seguir operando sobre el mismo objeto. La finalidad por camino rápido es lo que garantiza que el efecto persista más allá del cierre de época y de una reconfiguración de validadores. Entre ambos momentos hay una ventana real: si los bloques del validador que ejecutó no llegan al DAG antes de que termine la época, ningún otro validador ve evidencia suficiente y ese validador revierte la ejecución al cambiar de época. [1]

Para quien integra pagos, la consecuencia es concreta: un resultado del camino rápido que solo se ha ejecutado todavía puede revertirse, y la señal para acreditar es la finalidad, no la ejecución. La equivocación del dueño tampoco bloquea el objeto para siempre: dentro de una época puede quedar sin progreso, y en una época posterior el dueño honesto puede volver a usarlo. [1]

Del paper a Sui: qué miden los autores

El paper reporta su evaluación experimental y la integración en la blockchain Sui. Según sus mediciones, Mysticeti-C alcanza una latencia de commit de 0.5 s en una red de área amplia manteniendo un throughput de más de 200k transacciones por segundo, y su integración como protocolo de consenso de Sui redujo la latencia en más de 4 veces respecto del protocolo anterior. [1]

Esas cifras son mediciones de los autores sobre su configuración experimental y su despliegue, no una garantía universal. Lo que sí es estructural es la diferencia de pasos: eliminar la certificación por bloque y los mensajes de voto aparte reduce la latencia en el caso estable, y el skip directo hace que la degradación ante caídas de líderes sea más gradual que la de diseños que dependen de timeouts. [1]

Para el lector que viene de HotStuff, la lección es que la evidencia de quórum no tiene por qué ser un objeto criptográfico separado. En HotStuff el QC es un mensaje agregado que el líder construye. [4] En Mysticeti el certificado es un patrón del grafo que cada réplica reconoce localmente.

Siguiente lectura

Para comparar con el DAG certificado sobre el que Mysticeti construye su crítica, vuelve a Narwhal: mempool DAG y HotStuff. Para el contexto más amplio de los protocolos de frontera, sigue con HotStuff-2, DAG-BFT y Twins.