Evolución del consenso de Sui: de Tusk a Mysticeti

Sui ha reemplazado su núcleo de consenso dos veces. La red nunca ha necesitado un hard fork.

Este artículo es parte de una serie sobre Sui:

• Descubriendo Sui: Una Blockchain Con Múltiples Innovaciones
• Bajo el Capó de Sui: Validadores, Consenso y Staking
• Sui: El Modelo de Objetos, o Repensando las Blockchains a Través de los Datos
• Gobernanza de Sui: Actualizar Sin Romper
• El Consenso de Sui Explicado: Cómo Narwhal y Mysticeti Finalizan en 0,5 Segundos

La razón se reduce a una elección arquitectónica. Narwhal, la capa responsable de diseminar transacciones entre validadores y organizarlas en un DAG, se mantuvo estable en los tres protocolos. Por encima de él, el mecanismo responsable de ordenar las transacciones podía ser reemplazado. Tusk, luego Bullshark, luego Mysticeti, cada uno se conectó a la misma base. Donde otras blockchains habrían necesitado reconstruir desde cero, Sui solo reemplazó una capa.

Un punto terminológico que vale la pena aclarar desde el principio. Sui maneja dos tipos de transacciones de forma diferente, y esa distinción no tiene nada que ver con qué protocolo de consenso está en ejecución. Los objetos propiedad de una sola parte —una transferencia simple, por ejemplo— evitan el consenso por completo mediante Byzantine Consistent Broadcast, que es más rápido. Solo los objetos compartidos requieren consenso para su ordenamiento. Este mecanismo ha estado en vigor desde el lanzamiento de Sui y opera independientemente de qué protocolo de consenso esté activo. No debe confundirse con la evolución del propio protocolo de consenso, que es el tema de este artículo.

Tusk: El Punto de Partida Asíncrono

Tusk fue diseñado para una red donde no se puede asumir nada sobre los tiempos de entrega de mensajes. Sin límites de tiempo, sin suposiciones de sincronía. Ese es el escenario más adverso —y también el más realista para una red global donde las condiciones varían ampliamente de un validador al siguiente.

Su idea central: una vez construido el DAG de Narwhal, se alcanza el consenso sin ninguna comunicación adicional. Cada validador aplica el mismo algoritmo determinista a su vista local del DAG y llega al mismo orden que todos los demás validadores. Sin rondas de votación, sin coordinación explícita. El orden se lee de la propia estructura de referencia, identificando puntos de anclaje que actúan como marcadores de confirmación.

Los benchmarks del artículo original, medidos en 20 validadores, sitúan el rendimiento en alrededor de 160.000 transacciones por segundo con una latencia de aproximadamente 3 segundos. En ese momento, eso estaba por delante de lo que los sistemas clásicos podían lograr.

Quedaron dos problemas. Primero, la latencia: 3 segundos es manejable para muchos casos de uso, pero un impedimento para el trading o los juegos en tiempo real. Segundo, la equidad. En un entorno puramente asíncrono, los validadores mejor conectados veían sus transacciones incluidas con más frecuencia que otros —un desequilibrio estructural que favorecía a los nodos más rápidos.

Tusk vivió principalmente en la investigación y en la red de prueba. Para cuando se lanzó la mainnet de Sui en 2023, Bullshark ya estaba al mando.

Bullshark: Sincronía Parcial

El salto conceptual de Bullshark descansa en una única suposición: la mayor parte del tiempo, la red se comporta con normalidad. En lugar de prepararse siempre para lo peor, el protocolo aprovecha los períodos en que los mensajes llegan con demoras razonables. Este es el modelo parcialmente síncrono: se asumen límites de tiempo en condiciones normales; la robustez asíncrona entra en acción cuando la red se degrada.

De esa suposición se deriva el camino rápido genuino de Bullshark —no debe confundirse con la distinción de objetos propios/compartidos mencionada anteriormente. Durante los períodos síncronos, el protocolo puede confirmar más rápido, sin esperar tantas rondas como en el modo degradado. Es un atajo de latencia condicionado a la salud de la red.

Bullshark también abordó el problema de equidad que Tusk dejó sin resolver, a través de los weak links (enlaces débiles). Estos enlaces permiten que un validador temporalmente lento sea incluido en el consenso final incluso si los validadores más rápidos aún no lo han referenciado. Ningún validador honesto queda excluido por una conexión deficiente. El protocolo también refinó la selección de puntos de anclaje y la limpieza de memoria, lo que le permitió sostener la carga durante períodos prolongados.

El costo: mayor complejidad. Los enlaces débiles y la adaptación de red introducen casos límite y sobrecarga computacional. El artículo reporta 125.000 TPS con 2 segundos de latencia en 50 participantes —menor que Tusk en papel, pero la comparación es engañosa: Tusk fue medido en 20 validadores, y el rendimiento cae mecánicamente a medida que crece la red. Las dos cifras no son directamente comparables. La latencia, mientras tanto, se mantuvo en el rango de un segundo —todavía demasiado lenta para las aplicaciones más exigentes.

Para Sui, la transición tuvo un valor principal: demostrar que la red podía cambiar su consenso sin interrupciones. Una señal de confianza significativa para los desarrolladores que construyen sobre ella.

Mysticeti: Eliminando la Certificación Explícita

Mysticeti no extiende Bullshark —cambia la lógica subyacente. Tanto Tusk como Bullshark dependen de un DAG certificado: cada bloque debe ser firmado por un quórum de validadores antes de considerarse disponible. Esa certificación es costosa —en firmas a producir y verificar, y en viajes de ida y vuelta en la red. Era el cuello de botella compartido por las dos generaciones anteriores.

Mysticeti elimina ese paso por completo. Opera sobre un DAG no certificado: los validadores firman y difunden sus bloques, y eso es todo. El acuerdo ya no se vota; se infiere. Cuando un validador referencia el bloque de otro en su propia salida, ese acto de referenciar constituye aprobación implícita. El consenso se deriva del comportamiento de referenciación, sin mensajes de votación dedicados en absoluto.

Los resultados se muestran en dos dimensiones. En latencia, Mysticeti confirma en tres rondas de mensajes —el mínimo teórico, a la par con BFT práctico. En recursos, eliminar miles de firmas por ronda reduce significativamente la carga de CPU: aproximadamente un 40% menos en producción (de ~48% a ~29% en los validadores desplegados). El protocolo también ejecuta múltiples líderes en paralelo cada ronda, lo que reduce las latencias medianas y de cola, y absorbe la no disponibilidad del líder sin detenerse.

Una variante, Mysticeti-FPC, añade un camino de confirmación rápida para transferencias de activos. Su característica distintiva es tejer esas transacciones directamente en el DAG en lugar de manejarlas por separado, lo que ahorra firmas y mensajes. Aquí es donde vive el genuino camino de confirmación rápida integrado en la estructura —no en Bullshark.

Los números, medidos en un entorno controlado: 300.000 TPS con 10 nodos y 400.000 TPS con 50 nodos antes de que la latencia cruce un segundo. Bajo carga sostenida, las confirmaciones llegan alrededor de 0,5 segundos a 200.000 TPS. En las mismas pruebas, otros protocolos líderes alcanzan un pico inferior a 150.000 TPS con latencias que comienzan alrededor de 2 segundos.

Luego está la ampliamente citada "reducción del 80% en latencia frente a Bullshark" (de ~1,9 s a ~400 ms). La cifra es precisa, pero es una comparación en el mejor caso: enfrenta a Bullshark en condiciones degradadas contra Mysticeti en condiciones óptimas. Bajo una carga típica de objetos compartidos, la ganancia es más modesta, aunque ninguna medición pública determina una cifra exacta. También vale la pena tener en cuenta: los números de 200.000–400.000 TPS provienen de benchmarks controlados. En la mainnet, bajo condiciones reales, el rendimiento observado es mucho menor.

Lo Que Muestra la Trayectoria

Alineando las tres generaciones, la progresión es clara —siempre que los números se lean en contexto.

El rendimiento va de ~160.000 TPS (Tusk, 20 validadores) a 125.000 TPS (Bullshark, 50 participantes) y luego a 300.000–400.000 TPS según la configuración (Mysticeti). Los recuentos de nodos difieren, por lo que estos valores no se comparan punto por punto: dan un orden de magnitud, no una clasificación estricta. La latencia, por otro lado, cae inequívocamente: de 3 segundos a aproximadamente 0,5 segundos, pasando por ~2 segundos para Bullshark. En el lado de la comunicación, la progresión va de cero sobrecarga una vez construido el DAG (pero con certificación costosa en sentido ascendente) a la certificación implícita que elimina la mayor parte del tráfico de votación.

El verdadero punto de inflexión no está entre Tusk y Bullshark —ambos pertenecen a la misma familia: DAG certificado, certificación explícita, optimizaciones incrementales. La ruptura está entre Bullshark y Mysticeti, con el abandono de la certificación. Tusk y Bullshark optimizaron un paso; Mysticeti lo eliminó.

Una cosa que vale la pena enfatizar: en los tres protocolos, Narwhal apenas cambió. Toda la innovación se concentró en la capa de ordenamiento, sin desestabilizar la diseminación de datos. Es esa separación de responsabilidades la que hizo posibles estos reemplazos sin interrupción del servicio —el tipo de elección arquitectónica que no da frutos de inmediato, pero acaba cambiándolo todo.

Mysticeti probablemente no sea la última palabra. El enfoque de Sui es precisamente reemplazar un componente cuando surge uno mejor, sin tocar el resto. Si llega una cuarta generación, lo más probable es que se conecte al mismo Narwhal.

Fuentes

• Tusk — Danezis, Kokoris-Kogias, Sonnino, Spiegelman. Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus (2021). arXiv · PDF
• Bullshark — Spiegelman, Giridharan, Sonnino, Kokoris-Kogias. Bullshark: DAG BFT Protocols Made Practical (2022). arXiv · PDF
• Mysticeti — Babel, Chursin, Danezis, Kichidis, Kokoris-Kogias, Koshy, Sonnino, Tian. Mysticeti: Reaching the Limits of Latency with Uncertified DAGs (2023, NDSS 2025). arXiv · PDF

La Evolución del Consenso de Sui: De Tusk a Mysticeti fue publicado originalmente en Coinmonks en Medium, donde las personas continúan la conversación destacando y respondiendo a esta historia.