Narwhal: cuando el mempool se vuelve DAG

Narwhal suele aparecer en la conversación como si fuera “el consenso rápido de Sui”. Esa frase es cómoda, pero borra la idea central: Narwhal no es el consenso; Narwhal es un mempool DAG de alta disponibilidad. El consenso viene después, ordenando certificados o referencias a datos que ya fueron difundidos. [1] [2]

Esa separación cambia el mapa mental. En HotStuff clásico, el líder carga mucho peso: propone bloques y el sistema difunde/vota sobre esa propuesta. [4] En diseños DAG-BFT, una parte importante del trabajo ocurre antes del orden total. Los validadores crean batches, los certifican como disponibles y construyen un grafo causal. Luego HotStuff, Tusk o Bullshark pueden ordenar referencias sin arrastrar todo el payload por el camino crítico. [1] [3]

Si HotStuff multipipeline es una cinta transportadora de evidencia, Narwhal es una bodega distribuida que asegura que las cajas están disponibles antes de decidir el orden de despacho.

Figura 1

Narwhal como DAG mempool

Fuentes:[1]

📖 Cómo leer esta figura (Detalle explicativo)

Las columnas representan rondas y cada nodo un certificado de batch creado por un validador. Las aristas hacia la ronda anterior declaran padres y construyen causalidad; un certificado significa que un quórum confirmó disponibilidad del batch. El consenso posterior ordena certificados ligeros, no vuelve a difundir todo el payload.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en pestaña nueva

Separar difusión y orden

La gran intuición de Narwhal es que las blockchains de alto throughput no solo sufren por consenso. Sufren porque difundir transacciones, asegurar disponibilidad y ordenar todo en un mismo camino produce cuellos de botella. Si cada propuesta de consenso tiene que cargar datos pesados, el líder y la red se vuelven el cuello de botella. [1]

Narwhal divide el problema:

1. Mempool DAG: los validadores agrupan transacciones en batches, las difunden y obtienen certificados de disponibilidad.
2. Causalidad: cada certificado referencia padres de rondas anteriores, formando un DAG.
3. Ordenamiento: el consenso ordena certificados, no necesariamente todo el payload.
4. Ejecución: al ordenar certificados, las transacciones ya deberían estar disponibles para recuperación.

Esta separación explica por qué los resultados de throughput de Narwhal-HotStuff pueden ser tan distintos de HotStuff solo. No estás midiendo únicamente “mejor consenso”; estás cambiando la arquitectura de difusión. Es como comparar un restaurante donde el chef también reparte delivery contra uno con cocina, despacho y rutas separadas. [1] [4]

Narwhal-HotStuff, Tusk y Bullshark

Narwhal puede componerse con HotStuff. En ese caso, HotStuff ordena certificados producidos por el DAG mempool. Eso mejora throughput porque el consenso no carga toda la difusión. Pero si la red pierde liveness o hay view-changes costosos, HotStuff aún puede sufrir latencia. [1] [4]

Tusk aparece como una respuesta asíncrona: trabaja sobre el DAG con overhead adicional bajo, buscando mantener buen rendimiento incluso cuando el camino parcialmente síncrono se atasca. Bullshark continúa esta familia con un enfoque más práctico y fast path sobre DAG. [1] [3]

La lectura sana es no ponerlos en una escalera simplona:

• HotStuff resuelve consenso BFT líder-based con QCs y responsiveness;
• Narwhal resuelve difusión y disponibilidad de datos como mempool DAG;
• Tusk/Bullshark resuelven ordenamiento sobre DAG bajo otros supuestos y rutas.

Cuando alguien dice “Narwhal supera a HotStuff”, pregunta: ¿en consenso puro, en difusión, en latencia, en throughput, bajo fallos, con cuántos workers, en WAN o LAN? Sin esas preguntas, las cifras son fuegos artificiales.

Profundización conceptual

Modelo mental: consenso ordena recibos, no cajas

Narwhal convierte batches de transacciones en certificados de disponibilidad. Un certificado es como un recibo fuerte: suficientes validadores confirman que el dato existe y puede recuperarse. El consenso ya no necesita cargar cada caja; ordena recibos. [1]

Ese modelo mental ayuda a entender por qué el DAG importa. Los enlaces a padres no son decoración. Codifican causalidad y ayudan a que el sistema sepa qué certificados estaban disponibles antes de otros. La estructura del DAG da un sustrato común para que el protocolo de ordenamiento no empiece desde una nube de mensajes sueltos. [1]

La consecuencia editorial para TrautsLab es clara: Narwhal no debe explicarse solo con un diagrama de consenso. Debe tener un diagrama de datos. Es una pieza de arquitectura de mempool, no solo una fase más de HotStuff.

Invariante: no ordenar lo que no está disponible

El invariante fundamental es que el consenso no debería comprometer referencias a datos que luego no se puedan recuperar. Si el orden total apunta a payloads ausentes, los nodos pueden acordar una secuencia que no pueden ejecutar. Eso es elegante como paper y fatal como sistema.

Narwhal protege ese punto haciendo que los certificados dependan de disponibilidad. Una vez que el consenso ordena certificados, los datos asociados ya deberían estar diseminados con suficiente redundancia. Esto no elimina todos los problemas de almacenamiento, garbage collection o recuperación, pero cambia el cuello de botella. [1]

También protege contra líderes lentos. Si el líder de consenso no es el único encargado de difundir datos, su falla no paraliza la entrada de batches. El sistema puede seguir construyendo DAG mientras el ordenamiento decide qué certificados van primero.

Escenario adversarial: consenso rápido con datos que nadie tiene

Imagina un líder que propone referencias a transacciones grandes que solo él conoce. El consenso podría votar sobre hashes, pero cuando llega la ejecución, los nodos no tienen el payload. El resultado es una cadena “finalizada” que no se puede ejecutar sin pedirle ayuda al sospechoso de siempre: el líder.

Narwhal evita esa dependencia moviendo disponibilidad antes del orden. Para que un batch sea certificado, debe haber suficiente evidencia de difusión. Un líder posterior no puede simplemente ordenar un fantasma. Puede ordenar referencias a certificados que ya pasaron por el mempool DAG.

El adversario cambia entonces de forma. Ya no basta con mirar equivocación de líderes; hay que mirar disponibilidad, retención de datos, workers, firmas de certificados y enlaces del DAG. La superficie de análisis crece, pero el throughput deja de estar preso de una propuesta monolítica.

Cómo leer el paper

Lee Narwhal and Tusk en dos pasadas. La primera, sin fórmulas: identifica qué parte es mempool y qué parte es consenso. La segunda, con lápiz: sigue cómo se forma un certificado, qué significa una ronda, cómo se conectan padres y qué ordena finalmente el protocolo.

Luego mira la evaluación con cuidado. Los números fuertes de throughput suelen venir de separar difusión y orden, y de escalar workers. Eso es legítimo, pero no es equivalente a decir “el core de consenso mágicamente se volvió 100x mejor”. Es una arquitectura distinta.

El artículo de xufeisofly sirve como puente de lectura porque enfatiza que Narwhal no es consenso. Toma esa frase como señal de tráfico: si en tu explicación Narwhal aparece como un reemplazo directo de HotStuff, probablemente estás mezclando capas. [2]

La pregunta de implementación que queda abierta es garbage collection. Un DAG mempool de alto throughput no puede guardar todo para siempre. Debe saber cuándo un certificado ya fue ordenado, cuándo sus datos siguen siendo necesarios para rezagados y cuándo puede limpiar sin romper disponibilidad. Ese detalle conecta Narwhal con el post anterior de sync: si un nodo llega tarde y el DAG ya limpió demasiado, necesita otra ruta de recuperación. Por eso los papers de DAG-BFT se leen mejor junto a ingeniería de almacenamiento, snapshots y workers, no como “solo consenso con grafos bonitos”.

Referencias

Bibliografía académica

Formato IEEENumerado para ingeniería, sistemas y protocolos.

1. [1]

   G. Danezis, L. Kokoris-Kogias, A. Sonnino, and A. Spiegelman, "Narwhal and Tusk: A DAG-Based Mempool and Efficient BFT Consensus," arXiv:2105.11827, 2021.

   PaperID: NARWHAL-TUSK-2021🔗 Abrir fuente

   Fuente primaria para DAG mempool, disponibilidad y composición con HotStuff/Tusk.

2. [2]

   xufeisofly, "Narwhal and Tusk，Sui 共识协议的设计逻辑 P1," Saliva Group, 2025.

   Engineering noteID: NARWHAL-XUFEI-2025🔗 Abrir fuente

   Referencia secundaria útil para enfatizar la separación entre mempool y consenso.

3. [3]

   A. Spiegelman, N. Giridharan, A. Sonnino, and L. Kokoris-Kogias, "Bullshark: DAG BFT Protocols Made Practical," arXiv:2201.05677, 2022.

   PaperID: BULLSHARK-2022🔗 Abrir fuente

   Continuación práctica de la línea DAG-BFT.

4. [4]

   M. Yin, D. Malkhi, M. K. Reiter, G. G. Gueta, and I. Abraham, "HotStuff: BFT Consensus in the Lens of Blockchain," arXiv:1803.05069, 2018.

   PaperID: HOTSTUFF-2019🔗 Abrir fuente

   Base comparativa para Narwhal-HotStuff.