Narwhal + Bullshark: consenso DAG de nueva generación

La vida después de Libra: cómo la tecnología de un proyecto muerto cambió el consenso para siempre

El 18 de junio de 2019, Facebook sacudió el mundo financiero con un anuncio que pocos esperaban: Facebook —una empresa de redes sociales, no un banco— iba a lanzar su propia moneda digital global. Se llamaría Libra, estaría respaldada por una cesta de divisas tradicionales, y su ambición declarada era dar acceso a servicios financieros a los 1.700 millones de personas en el mundo que no tenían cuenta bancaria. La reacción fue sísmica. En semanas, congresistas de Estados Unidos convocaron audiencias de emergencia. El ministro de Finanzas de Francia, Bruno Le Maire, declaró que Libra «no debe ocurrir». El Banco Central Europeo emitió advertencias. Reguladores de todo el planeta, acostumbrados a que las criptomonedas fueran un fenómeno marginal, se dieron cuenta de repente de que una empresa cuyas plataformas sumaban 2.700 millones de usuarios activos podía, literalmente, crear un sistema monetario paralelo de la noche a la mañana.

Lo que siguió fue una lenta asfixia regulatoria. PayPal abandonó el consorcio Libra en octubre de 2019. Visa, Mastercard y Stripe hicieron lo mismo días después. El proyecto se rebautizó como Diem en diciembre de 2020, en un intento de distanciarse de la marca Facebook —que también cambió su nombre a Meta—, pero el daño estaba hecho. En enero de 2022, el consorcio Diem vendió sus activos tecnológicos al banco Silvergate por unos 182 millones de dólares. El sueño de la moneda digital de Facebook había muerto.

Pero aquí es donde la historia se vuelve verdaderamente interesante. Porque si bien Libra/Diem fracasó como producto, el equipo de ingenieros que Meta había reunido para construirlo —más de trescientos investigadores y desarrolladores, muchos de ellos provenientes de las mejores universidades del mundo en criptografía y sistemas distribuidos— había producido algo extraordinario durante esos tres años de trabajo: una nueva generación de protocolos de consenso que resolvían problemas que llevaban décadas abiertos. Cuando Diem cerró, esos ingenieros no se fueron a casa. Se dispersaron por el ecosistema blockchain como semillas al viento, fundando nuevos proyectos y publicando la investigación que habían desarrollado internamente. Entre esas publicaciones, dos artículos científicos cambiarían la forma en que entendemos el consenso en redes descentralizadas: el primero describía un sistema llamado Narwhal, y el segundo un protocolo llamado Bullshark.

Para entender por qué estos dos protocolos importan, necesitamos dar un paso atrás y comprender el problema que resuelven. No es un problema nuevo. Es, de hecho, uno de los problemas más antiguos y más difíciles de la informática: ¿cómo logran miles de ordenadores, repartidos por todo el mundo, que no confían entre sí y que algunos de los cuales pueden ser maliciosos, ponerse de acuerdo sobre un estado común? Este problema tiene un nombre técnico —el problema del consenso bizantino— y una historia que se remonta a 1982, cuando tres investigadores llamados Leslie Lamport, Robert Shostak y Marshall Pease publicaron un artículo que lo formalizaba utilizando una metáfora militar: generales bizantinos que deben coordinar un ataque, sabiendo que algunos de ellos son traidores.

Lo que Narwhal y Bullshark aportan no es una solución al problema bizantino —eso ya existía—, sino una forma radicalmente más eficiente de resolverlo. Una forma que multiplica el rendimiento por cien sin sacrificar seguridad. Una forma que, como veremos, separa dos tareas que todos los protocolos anteriores habían mantenido unidas, y que al separarlas descubre que cada una puede optimizarse de manera independiente. Es como descubrir que el cuello de botella de una fábrica no estaba en la cadena de montaje, sino en que usaban el mismo camión para transportar materias primas y productos terminados: al asignar camiones distintos a cada tarea, la producción se dispara.

El cuello de botella del consenso tradicional: una sola pista de aterrizaje para todo un continente

Para comprender por qué Narwhal y Bullshark representan un salto cualitativo, necesitamos primero entender cómo funcionan los protocolos de consenso tradicionales y por qué tienen un límite de rendimiento intrínseco. La analogía más clara es la de un aeropuerto con una sola pista de aterrizaje.

Imagina el aeropuerto de una gran ciudad —digamos, un aeropuerto que gestiona millones de pasajeros al año— pero con una única pista. Solo un avión puede aterrizar o despegar a la vez. Cada operación sigue un protocolo rígido: el avión solicita permiso a la torre de control, la torre verifica que la pista está libre, autoriza el aterrizaje, el avión aterriza, libera la pista, y entonces —y solo entonces— el siguiente avión puede comenzar su aproximación. Si un avión tiene un problema técnico y tarda más de lo normal en liberar la pista, todos los demás esperan. Si la torre de control falla, todo se detiene. Si hay niebla y las operaciones se ralentizan, la cola crece exponencialmente.

Esto es, en esencia, lo que hacen protocolos como PBFT (Practical Byzantine Fault Tolerance), publicado en 1999 por Miguel Castro y Barbara Liskov. En PBFT, un nodo designado como «líder» —la torre de control— propone un bloque de transacciones. Ese bloque se envía a todos los demás nodos, que lo verifican y envían sus votos. El líder recopila los votos, confirma el bloque, y entonces —y solo entonces— se puede proponer el siguiente bloque. Es un proceso secuencial: bloque tras bloque, como avión tras avión en una sola pista.

PBFT fue revolucionario en su momento. Fue el primer protocolo que demostró que el consenso bizantino podía ser práctico, no solo teórico. Pero tenía dos problemas fundamentales. El primero era la complejidad de mensajes: en cada ronda, cada nodo necesitaba comunicarse con todos los demás, generando un número de mensajes proporcional a n² (donde n es el número de nodos). Con 4 nodos, eso son 16 mensajes. Con 100 nodos, 10.000. Con 1.000 nodos, un millón. La red se satúra rápidamente. El segundo problema era la dependencia del líder: si el líder era lento, malicioso o estaba desconectado, todo el sistema se detenía hasta que se eligiera un nuevo líder, un proceso llamado «cambio de vista» (view change) que en PBFT es costoso y complejo.

En 2019, un equipo de investigadores de la Universidad de Cornell —entre ellos Maofan Yin, Dahlia Malkhi y Michael K. Reiter— publicó HotStuff, un protocolo que resolvía el problema de la complejidad de mensajes. En lugar de que todos hablen con todos, HotStuff organiza la comunicación como un árbol: el líder recopila votos, los agrega en un certificado único, y distribuye ese certificado. La complejidad de mensajes baja de n² a n —lineal en vez de cuadrática—. Además, HotStuff simplifica el cambio de líder hasta hacerlo trivial: cada ronda tiene un líder nuevo, y el protocolo de cambio es idéntico al protocolo normal. Este diseño inspiró directamente la blockchain de Libra/Diem, y se convirtió en la base sobre la que se construirían los protocolos siguientes.

Otro enfoque importante fue Tendermint, propuesto por Ethan Buchman y Jae Kwon en 2014 y desarrollado a lo largo de los años siguientes. Tendermint tomó una decisión de diseño radical: sacrificar disponibilidad a cambio de consistencia. En Tendermint, si más de un tercio de los validadores están desconectados, la red se detiene por completo. No produce bloques, no procesa transacciones, se para. Puede sonar drástico, pero la ventaja es que los bloques, una vez confirmados, son definitivos inmediatamente: no hay posibilidad de reorganización, no hay «confirmaciones pendientes». En Bitcoin, se recomienda esperar seis bloques (unos sesenta minutos) para considerar una transacción segura. En Tendermint, un bloque confirmado es un bloque definitivo, punto. Esta propiedad —llamada finalidad instantánea— es crucial para aplicaciones financieras donde una transferencia bancaria no puede estar «probablemente confirmada».

Pero tanto HotStuff como Tendermint, a pesar de sus mejoras, comparten el mismo problema fundamental: son secuenciales. El líder propone un bloque, todos lo verifican, todos votan, el bloque se confirma, y solo entonces comienza el siguiente. Es la misma pista de aterrizaje, quizás con un sistema de control de tráfico más eficiente, quizás con aviones más rápidos, pero sigue siendo una única pista. Y la razón por la que es una única pista es que todos estos protocolos mezclan dos tareas en el mismo proceso: distribuir los datos (asegurarse de que todos los nodos tienen las transacciones) y ordenar los datos (decidir en qué secuencia se procesan). La genialidad de Narwhal y Bullshark está en separar estas dos tareas.

La gran idea: separar distribución de ordenación

Para entender por qué la separación de distribución y ordenación es tan poderosa, imaginemos un parlamento. No cualquier parlamento, sino uno grande, con cientos de diputados, que debe tramitar miles de propuestas legislativas cada año. En un parlamento real, la tramitación de una ley sigue dos fases claramente diferenciadas. Primero, la fase de distribución: los textos de las propuestas se imprimen, se reparten a todos los diputados, se registran en el boletín oficial, y se garantiza que cada diputado ha recibido su copia. Segundo, la fase de ordenación y votación: los diputados debaten, se establece un orden del día, se vota, y las leyes se aprueban o rechazan.

Ahora imagina un parlamento disfuncional donde ambas fases ocurren simultáneamente. El presidente del parlamento lee en voz alta el texto de una propuesta, espera a que todos los diputados confirmen que la han oído (distribución), y luego inmediatamente pasa a la votación (ordenación). Solo cuando esa propuesta está completamente votada, el presidente puede comenzar a leer la siguiente. Si el texto es largo, todos esperan. Si un diputado pide una aclaración, todos esperan. Si el presidente tiene que ausentarse un momento, todos esperan. Es un sistema que funciona, pero es desesperadamente lento.

Lo que Narwhal y Bullshark hacen es lo que haría cualquier gestor parlamentario sensato: separar las dos fases. Narwhal es el sistema de distribución de documentos del parlamento. Se encarga de que cada diputado reciba copia de todas las propuestas, de forma eficiente, en paralelo, sin esperar a que se vote ninguna. Bullshark es el sistema de votación. Toma las propuestas que Narwhal ya distribuyó —que todos los diputados ya tienen en sus manos— y las ordena y vota. Y aquí está la clave: como Bullshark sabe que la distribución ya está hecha, no necesita preocuparse por ella. Solo tiene que ordenar. Y como Narwhal sabe que la votación vendrá después, no necesita esperar a ninguna votación para seguir distribuyendo. Cada sistema opera a su propia velocidad, sin que uno frene al otro.

En términos más concretos: en los protocolos tradicionales, el líder propone un bloque que contiene las transacciones y todos los nodos deben, primero, descargar todas esas transacciones, y segundo, votar sobre su orden. Si el bloque es grande (muchas transacciones), la descarga tarda más, y la votación se retrasa. Si el bloque es pequeño (para que la descarga sea rápida), se procesan pocas transacciones. Es un dilema sin solución dentro del paradigma secuencial. Narwhal rompe ese dilema haciendo que la descarga de transacciones ocurra continuamente y en paralelo, independientemente del proceso de votación. Para cuando Bullshark necesita votar, las transacciones ya están distribuidas. El voto se reduce a un pequeño mensaje de metadatos —esencialmente, un «sí» o un «no» sobre un resumen de lo que ya todos tienen—, en lugar de un bloque entero de datos.

Qué es un DAG y por qué es la estructura perfecta para el consenso paralelo

Antes de sumergirnos en cómo funcionan Narwhal y Bullshark, necesitamos entender la estructura de datos que está en el corazón de ambos: el DAG, siglas de Directed Acyclic Graph, o grafo acíclico dirigido. No es necesario ser matemático para entenderlo; basta con visualizar una analogía cotidiana.

Piensa en un río con afluentes. El río principal fluye de la montaña al mar. A lo largo de su recorrido, recibe agua de arroyos y afluentes que se incorporan al caudal principal. Esos afluentes, a su vez, reciben agua de arroyos más pequeños. El agua siempre fluye en una dirección —de la montaña al mar— y nunca vuelve hacia atrás: no hay ciclos, no hay circuitos cerrados. Cada punto del río puede rastrear de dónde vino su agua siguiendo los afluentes hacia arriba, pero el flujo siempre avanza hacia adelante. Esto es un grafo acíclico dirigido: un conjunto de puntos (los puntos del río) conectados por flujos (las corrientes de agua) que tienen una dirección definida y que nunca forman ciclos.

Ahora apliquemos esta idea al consenso. Imagina que tienes cuatro validadores —llamemos a estos validadores Alfa, Beta, Gamma y Delta—. En un protocolo de consenso tradicional (la cadena lineal, la pista de aterrizaje única), solo uno de ellos puede proponer un bloque a la vez. En un DAG de consenso, todos proponen simultáneamente. Cada validador produce un vértice —un paquete de transacciones junto con algunos metadatos— y lo emite a la red. Pero cada vértice no flota en el vacío: incluye referencias (enlaces) a vértices anteriores de otros validadores. Es como si cada afluente del río llevara una etiqueta que dice «mi agua proviene de estos tres arroyos de más arriba».

Esas referencias crean la estructura del DAG. Cada vértice apunta a vértices anteriores, y esos vértices apuntan a otros aún más antiguos, formando una red de dependencias que se extiende hacia atrás en el tiempo pero nunca forma ciclos (un vértice solo puede referenciar vértices creados antes que él, no después). El resultado es una estructura mucho más rica que una cadena lineal: en lugar de una secuencia de bloques, tenemos un tejido de vértices entrelazados.

¿Por qué es esto mejor que una cadena? Volvamos a la analogía del transporte. Una cadena lineal de bloques es una carretera de un solo carril: solo pasa un vehículo a la vez. Un DAG es una autopista de múltiples carriles. Si tienes cuatro validadores, tienes cuatro carriles. Si tienes cien validadores, cien carriles. Cada carril avanza a su propia velocidad, y los carriles se «sincronizan» periódicamente mediante las referencias cruzadas. Si un validador es lento o se desconecta, los demás siguen produciendo vértices en sus propios carriles. El sistema no se detiene; simplemente pierde un carril. En una cadena lineal, si el líder falla, todo se detiene hasta que se elige uno nuevo. En un DAG, no existe ese punto único de fallo.

El DAG tiene otra propiedad crucial: codifica información causal. Cuando el vértice V de Alfa referencia al vértice W de Beta, eso significa que Alfa había visto el vértice de Beta antes de crear el suyo. Es un hecho cronológico irrefutable, registrado criptográficamente. Si seguimos todas las referencias desde un vértice reciente hacia atrás, podemos reconstruir parcialmente qué vio cada validador y en qué orden. Esta información causal es la que Bullshark explotará después para establecer un orden total sin necesidad de comunicación adicional. Es como si la estructura misma del río —qué afluentes se unen dónde— contuviera ya la información necesaria para determinar la historia completa del flujo de agua.

Para ponerle números concretos: en un protocolo de consenso clásico con n validadores, se produce un bloque por ronda. En un DAG con n validadores, se producen n vértices por ronda —uno por validador—. Si cada vértice contiene el mismo volumen de transacciones que un bloque clásico, el rendimiento bruto del DAG es n veces mayor. Con 50 validadores, eso significa potencialmente 50 veces más transacciones por segundo. En la práctica, el factor de mejora es algo menor por la sobrecarga de las referencias cruzadas y la coordinación, pero las mediciones reales muestran mejoras de entre 10 y 20 veces sobre protocolos lineales equivalentes. Es la diferencia entre tramitar expedientes uno a uno en ventanilla y tener cincuenta ventanillas abiertas simultáneamente.

Narwhal: el sistema de distribución de documentos del parlamento

Lotes, certificados y rondas: la mecánica básica

Narwhal es la capa de disponibilidad de datos (data availability). Su responsabilidad es garantizar que las transacciones que los usuarios envían a la red lleguen a todos los validadores de forma fiable, rápida y verificable. No decide el orden de las transacciones; solo se asegura de que estén disponibles. Es el servicio de mensajería del parlamento: no decide qué leyes se aprueban, pero garantiza que cada diputado tiene en su mesa copia de todas las propuestas.

El funcionamiento de Narwhal se organiza en rondas. Una ronda es como un ciclo de un semáforo: un período definido durante el cual cada validador realiza una serie de acciones específicas. En cada ronda, cada validador hace lo siguiente:

Primero, agrupa transacciones en lotes. Las transacciones que los usuarios envían a un validador no se procesan individualmente —eso sería como enviar un camión de reparto por cada paquete individual en lugar de cargar cientos de paquetes en un solo camión—. El validador acumula transacciones y las agrupa en lotes (batches). Cada lote se identifica por el hash de su contenido: una huella digital única que permite verificar que el lote no ha sido alterado.

Segundo, construye un vértice. El validador empaqueta los hashes de sus lotes —no los lotes completos, solo sus huellas digitales— junto con referencias a los vértices de otros validadores de la ronda anterior. Este paquete es el vértice del DAG. Es como un acta parlamentaria que dice: «Tengo estas propuestas nuevas [hashes de los lotes], y confirmo haber recibido las propuestas de estos colegas en la ronda anterior [referencias a vértices previos]».

Tercero, difunde el vértice y solicita firmas. El validador envía su vértice a todos los demás validadores. Cada validador que recibe el vértice verifica dos cosas: que efectivamente tiene disponibles los lotes correspondientes a los hashes mencionados, y que las referencias a vértices previos son legítimas. Si ambas verificaciones pasan, el validador firma el vértice, indicando «confirmo que este vértice es válido y que tengo los datos a los que se refiere».

Cuarto, obtiene un certificado. Cuando el validador original ha recopilado firmas de una mayoría cualificada de validadores —específicamente, de al menos 2f+1 validadores, donde f es el número máximo de validadores maliciosos que el sistema puede tolerar—, esas firmas se combinan en un certificado. El certificado es la prueba irrefutable de que una mayoría honesta del sistema ha verificado y confirmado la disponibilidad de esos datos. Es como un documento notarial firmado ante testigos: no solo afirma algo, sino que demuestra que un número suficiente de partes independientes lo han verificado.

Firmas BLS: el sello que cabe en un sobre

Un detalle técnico que merece atención es el tipo de firmas que Narwhal utiliza para construir sus certificados: las firmas BLS (por Boneh, Lynn y Shacham). Estas firmas tienen una propiedad extraordinaria que las hace ideales para este contexto: son agregables. Si cien validadores firman el mismo vértice, las cien firmas individuales pueden combinarse en una única firma agregada que ocupa exactamente el mismo espacio que una sola firma. Es como si cien personas firmaran un contrato, pero en lugar de necesitar cien páginas de firmas, todas se condensaran mágicamente en una sola firma que demuestra que las cien personas firmaron.

¿Por qué importa esto? Porque sin agregación, un certificado que requiere firmas de, digamos, 67 validadores contendría 67 firmas individuales. Si cada firma ocupa 48 bytes (el tamaño de una firma BLS sobre la curva BLS12-381), eso son 3.216 bytes solo en firmas. Con agregación, el certificado contiene una sola firma de 48 bytes más una lista que indica qué validadores firmaron. Y la verificación también es más rápida: en lugar de verificar 67 firmas por separado, se verifica una sola firma agregada. En un sistema que produce miles de certificados por segundo, esta compresión marca la diferencia entre un sistema viable y uno que se ahoga en su propia burocracia.

La garantía de disponibilidad: por qué los datos no pueden desaparecer

La propiedad más importante de Narwhal es su garantía de disponibilidad de datos. Cuando un vértice obtiene un certificado, eso significa que al menos 2f+1 validadores han confirmado que poseen los datos asociados. Si el sistema tolera un máximo de f validadores maliciosos (que podrían mentir o negarse a compartir datos), entonces entre los 2f+1 firmantes hay al menos f+1 validadores honestos que realmente tienen los datos y están dispuestos a compartirlos. Cualquier otro validador que necesite esos datos puede pedirlos a esos f+1 validadores honestos, y al menos uno de ellos responderá.

Pongamos números concretos. Imagina una red con 100 validadores y una tolerancia a fallos de f = 33 (el sistema puede funcionar correctamente incluso si 33 validadores son maliciosos o están desconectados). Un certificado requiere firmas de al menos 2(33)+1 = 67 validadores. De esos 67 firmantes, incluso en el peor caso en que los 33 validadores maliciosos hayan firmado (quizás sin tener realmente los datos), quedan al menos 67 − 33 = 34 validadores honestos que sí tienen los datos. Esos 34 validadores son suficientes para que cualquier nodo de la red pueda obtener los datos que necesita.

Esta garantía es lo que permite a Bullshark trabajar solo con metadatos. Cuando Bullshark ordena vértices que tienen certificado, sabe con certeza matemática que los datos asociados están disponibles en la red. No necesita verificarlo ni descargarlo él mismo; Narwhal ya lo hizo. Es como si el sistema de votación del parlamento no necesitara leer el texto completo de cada propuesta antes de votar, porque el sistema de distribución ya ha certificado que todos los diputados tienen su copia. La votación se reduce a decidir el orden, que es una operación mucho más ligera.

Bullshark: el sistema de votación del parlamento

Líderes, anclas y la interpretación del DAG

Si Narwhal es el servicio de mensajería que distribuye documentos, Bullshark es el presidente del parlamento que establece el orden del día y dirige la votación. Pero hay una diferencia fundamental entre Bullshark y un presidente parlamentario real: Bullshark no necesita enviar mensajes adicionales para hacer su trabajo. Toda la información que necesita ya está en la estructura del DAG que Narwhal construyó. Bullshark simplemente interpreta el DAG de una forma específica para extraer un orden total de los vértices.

¿Cómo funciona esto? La clave está en el concepto de ancla (anchor). En determinadas rondas —por ejemplo, las rondas pares—, un validador específico es designado como «líder». El vértice que ese líder produce en esa ronda es el ancla. Pensemos en la analogía parlamentaria: en cada sesión, un diputado es designado como ponente. La propuesta del ponente —el ancla— tiene un papel especial: sirve como punto de referencia alrededor del cual se organiza la votación de esa sesión.

Pero —y esto es crucial— el líder no tiene ningún poder especial sobre el contenido ni sobre el proceso. No puede censurar transacciones ni manipular el orden a su antojo. Lo único que hace es producir un vértice normal, como todos los demás. Su vértice simplemente se utiliza como punto de referencia para la interpretación del DAG. Si el líder es malicioso y no produce su vértice, Bullshark simplemente salta a la siguiente ronda de anclaje. No hay crisis, no hay bloqueo, no hay «cambio de vista» costoso. La ausencia del líder es un contratiempo menor, no una emergencia.

La regla de compromiso: cuándo un ancla es definitiva

Para que un ancla se «comprometa» —es decir, para que las transacciones que contiene se consideren definitivamente ordenadas—, Bullshark aplica una regla elegante basada en la estructura del DAG. La idea, simplificada, funciona así:

Consideremos un ancla A en la ronda r. Bullshark examina los vértices de la ronda r+2 (dos rondas después). Para cada vértice en la ronda r+2, Bullshark comprueba si tiene un «camino» hasta el ancla A a través de las referencias del DAG. Si una mayoría cualificada (2f+1) de los vértices de la ronda r+2 tienen camino hasta el ancla A, entonces el ancla se compromete. Si no hay mayoría suficiente, el ancla se descarta y Bullshark pasa a la siguiente.

La analogía parlamentaria ilumina la lógica. Imagina que el ponente presenta una propuesta (el ancla) en la sesión del lunes. Los diputados no votan inmediatamente. En lugar de eso, en la sesión del miércoles (dos rondas después), cada diputado presenta su propia propuesta, que contiene referencias a las propuestas que ha visto y procesado. Si la mayoría de las propuestas del miércoles incluyen, directa o indirectamente, una referencia a la propuesta del ponente del lunes, eso significa que la mayoría ha «visto» y «aceptado» esa propuesta. Se considera aprobada sin necesidad de una votación explícita. La estructura del DAG —las referencias entre vértices— es la votación.

Esta es la razón por la que Bullshark se describe como un protocolo de cero mensajes adicionales (zero-message overhead). No necesita una fase de votación separada. No necesita que los validadores envíen mensajes de «sí» o «no». Los mensajes que Narwhal ya intercambia para distribuir datos —los vértices con sus referencias— contienen implícitamente toda la información necesaria para que Bullshark determine el orden. Es como si la correspondencia interna del parlamento, que ya existe para otros fines, contuviera automáticamente los votos de cada diputado, sin necesidad de una votación formal separada.

Del ancla al orden total: cómo se ordena todo el DAG

Una vez que un ancla se compromete, Bullshark ordena no solo las transacciones del ancla, sino todas las transacciones del DAG que son alcanzables desde ese ancla. Es decir, Bullshark sigue las referencias del ancla hacia atrás, recopilando todos los vértices que el ancla referencia directa o indirectamente, y los ordena siguiendo un criterio determinista —por ejemplo, ordenando primero por ronda y luego por identificador de validador dentro de cada ronda—.

Imagina un rompecabezas. El ancla es la pieza central, y las referencias son las conexiones entre piezas. Cuando el ancla se compromete, Bullshark «tira del hilo» de las referencias y arrastra consigo todas las piezas conectadas, organizándolas en una secuencia lineal. Los vértices que ya fueron ordenados por un ancla anterior se saltan (no se procesan dos veces). El resultado es un orden total y determinista: cada validador honesto, aplicando las mismas reglas al mismo DAG, llega exactamente al mismo orden. No hay ambigüedad, no hay divergencia, no hay necesidad de coordinación adicional.

El camino rápido: la caja exprés del supermercado

Bullshark incluye una optimización llamada fast path («camino rápido») que reduce la latencia en condiciones favorables. En el modo normal, un ancla se compromete después de dos rondas (se propone en la ronda r y se evalúa en la ronda r+2). Pero si las condiciones de red son buenas y la gran mayoría de validadores están conectados y respondiendo rápidamente, el fast path permite comprometer un ancla después de solo una ronda.

La analogía perfecta es la caja exprés del supermercado. Normalmente, para pagar tus compras pasas por la caja estándar: esperas tu turno, el cajero escanea los productos, pagas, recibes el cambio. Es un proceso fiable pero no especialmente rápido. Ahora imagina que llevas solo dos productos. El supermercado tiene una caja exprés para compras pequeñas: menos espera, proceso más ágil, misma garantía de que tu pago queda registrado. El fast path de Bullshark funciona igual: cuando las condiciones son óptimas (baja latencia de red, alta participación de validadores), las transacciones se confirman más rápido. Cuando las condiciones se deterioran —validadores lentos, alta congestión, ataques—, el sistema vuelve automáticamente al «camino lento» estándar, que es más lento pero igualmente seguro. No hay compromiso en seguridad: ambos caminos ofrecen la misma garantía de finalidad. La única diferencia es la velocidad.

Los números son significativos. En condiciones normales, con el fast path activo, Bullshark puede lograr finalidad en menos de un segundo. Sin fast path, la finalidad típica es de dos a tres segundos. En comparación, Bitcoin necesita unos sesenta minutos para una confirmación razonablemente segura, y Ethereum unos doce minutos. Para aplicaciones que requieren confirmación rápida —pagos en punto de venta, transacciones financieras, interacciones en juegos—, la diferencia entre un segundo y sesenta minutos es la diferencia entre viable e inviable.

Tolerancia a fallos bizantinos: las matemáticas de la confianza

El problema de los generales bizantinos, explicado

El año es 1982. Leslie Lamport, Robert Shostak y Marshall Pease, tres investigadores de SRI International en California, publican un artículo titulado «The Byzantine Generals Problem» que se convertirá en uno de los textos más citados de la historia de la informática. El artículo plantea un escenario aparentemente simple: varios generales del ejército bizantino rodean una ciudad enemiga. Deben coordinar un ataque simultáneo. Si todos atacan a la vez, ganarán. Si solo algunos atacan y los demás no, los atacantes serán derrotados. El problema es que los generales se comunican únicamente mediante mensajeros, y algunos de los generales son traidores: enviarán mensajes contradictorios para sabotear la coordinación. «Atacaremos al amanecer», le dicen al general del norte. «Retirada inmediata», le dicen al general del sur.

La pregunta clave es: ¿cuántos generales leales necesitas para garantizar que todos llegarán a la misma decisión, a pesar de los traidores? La respuesta, demostrada matemáticamente por Lamport, Shostak y Pease, es que necesitas al menos 3f + 1 generales en total, donde f es el número de traidores. Dicho de otro modo: los traidores deben ser menos de un tercio del total.

¿Por qué exactamente un tercio? La intuición es la siguiente. Imagina que tienes tres generales: Ana, Bruno y Carlos. Ana es leal, Bruno es leal, y Carlos es traidor. Carlos le dice a Ana: «Bruno dice que ataquemos». Y le dice a Bruno: «Ana dice que nos retiremos». Ana y Bruno no pueden distinguir si Carlos está mintiendo o si el otro general cambió de opinión. Con solo tres generales y uno traidor (f = 1, total = 3 = 3×1), no hay forma de alcanzar consenso fiable. Necesitas al menos 3(1) + 1 = 4 generales. Con cuatro generales y un traidor, los tres leales siempre pueden detectar la inconsistencia del traidor porque pueden comparar versiones entre sí y la mayoría honesta (tres de cuatro) prevalecerá.

Los números que sostienen el sistema: n, f y el quorum

En Narwhal y Bullshark, la tolerancia a fallos bizantinos se expresa mediante tres parámetros fundamentales:

n es el número total de validadores. f es el número máximo de validadores que pueden ser maliciosos (bizantinos) sin comprometer la seguridad del sistema. La relación entre ambos es n ≥ 3f + 1. Es decir, para tolerar f validadores maliciosos, necesitas al menos 3f + 1 validadores en total. Si tienes 100 validadores, puedes tolerar hasta 33 maliciosos. Si tienes 31 validadores, puedes tolerar hasta 10. Si tienes 4 validadores, puedes tolerar 1.

El tercer parámetro clave es el quorum, que es el número mínimo de validadores que deben estar de acuerdo para que una decisión sea válida. En estos protocolos, el quorum es 2f + 1. ¿Por qué 2f + 1 y no simplemente la mitad más uno? Porque necesitamos garantizar que dos quorums cualesquiera siempre se solapan en al menos un validador honesto.

Veamos los números con un ejemplo concreto. Red de 100 validadores, f = 33. El quorum es 2(33) + 1 = 67. Ahora imagina dos decisiones que alcanzan quorum: la primera recopila 67 votos, la segunda también recopila 67 votos. ¿Cuántos validadores votaron en ambas? Como solo hay 100 validadores en total, y 67 + 67 = 134, necesariamente hay al menos 134 − 100 = 34 validadores que votaron en ambas decisiones. De esos 34, incluso en el peor caso en que los 33 validadores maliciosos hayan votado en ambas (quizás de forma contradictoria), queda al menos 1 validador honesto que votó en ambas. Ese validador honesto es el «testigo» que conecta las dos decisiones y garantiza la consistencia. Siempre hay solapamiento honesto entre cualquier par de quorums. Esta propiedad es la piedra angular matemática de todo el sistema de seguridad.

Traslademos estos números a escenarios reales. Una red pequeña con 10 validadores tolera hasta 3 maliciosos (necesita quorum de 7). Es apropiada para un consorcio empresarial donde los participantes se conocen pero no confían completamente entre sí. Una red mediana de 100 validadores tolera hasta 33 maliciosos (quorum de 67). Es el rango típico de una blockchain pública de alto rendimiento. Una red grande de 1.000 validadores tolera hasta 333 maliciosos (quorum de 667). Ofrece una descentralización masiva a costa de mayor latencia en la comunicación.

Detección de equivocación: cuando un validador miente

Uno de los ataques más peligrosos que un validador bizantino puede intentar es la equivocación (equivocation): producir dos vértices diferentes para la misma ronda y enviar uno a un grupo de validadores y otro a un grupo distinto. Es el equivalente al traidor que dice «atacaremos» a unos generales y «nos retiraremos» a otros. En el contexto de una blockchain, esto podría permitir un doble gasto: el validador incluye una transacción que envía fondos a Alicia en un vértice y la misma transacción enviando fondos a Bruno en otro.

Narwhal detecta la equivocación de forma natural gracias al proceso de certificación. Cuando un validador envía su vértice a los demás para obtener firmas, cada validador que firma solo firma un vértice por validador por ronda. Si un validador intenta enviar dos vértices distintos para la misma ronda, algunos validadores firmarán uno y otros firmarán otro. Pero como cada validador firma a lo sumo uno, el equivocador no puede obtener un quorum (2f+1 firmas) para ambos vértices simultáneamente. Es matemáticamente imposible: con n = 3f+1 validadores y cada uno firmando como máximo un vértice, las 2f+1 firmas que necesita para un certificado consumen más de dos tercios del total, dejando menos de un tercio para un segundo certificado, que es insuficiente.

La analogía es un notario que certifica documentos. Si un estafador lleva dos versiones contradictorias de un contrato a distintos notarios, los notarios podrían no darse cuenta. Pero si el protocolo exige que el mismo notario certifique ambas versiones, y el notario se niega a certificar dos documentos contradictorios del mismo autor, la estafa se frustra automáticamente. En Narwhal, cada validador es un notario que solo certifica un vértice por autor por ronda.

Además, si un validador detecta dos vértices distintos del mismo validador para la misma ronda, puede difundir ambos como prueba de equivocación. Esta prueba es irrefutable: dos vértices firmados por el mismo validador para la misma ronda son evidencia criptográfica de comportamiento malicioso. En sistemas con penalización económica (slashing), esta prueba puede desencadenar la confiscación del depósito de garantía del equivocador, desincentivando el ataque no solo técnicamente sino también económicamente.

Comités dinámicos y quorums ponderados por participación

Hasta ahora hemos supuesto que todos los validadores son iguales: cada uno tiene un voto, y el quorum se calcula simplemente contando cabezas. Pero en las redes blockchain reales, no todos los validadores son iguales. Algunos han depositado más garantías económicas (stake) que otros, lo que les da más «peso» en el sistema. Además, la composición del comité de validadores cambia con el tiempo: nuevos validadores se unen, otros se retiran, los depósitos de garantía aumentan o disminuyen.

Pensemos en una analogía del mundo empresarial. En una junta de accionistas, el voto no se cuenta por personas sino por acciones. Un accionista que posee el 10% de la empresa tiene diez veces más peso que uno con el 1%. Las decisiones requieren una mayoría cualificada del capital, no de las personas. De forma similar, en un sistema de consenso ponderado por stake, el quorum no se mide en número de validadores sino en porcentaje del stake total. Si el quorum requiere dos tercios del stake, y un validador posee el 15% del stake total, su firma vale más que la de uno con el 0,5%.

Narwhal y Bullshark soportan esta ponderación de forma natural. En lugar de contar «¿han firmado al menos 2f+1 validadores?», el protocolo calcula «¿los validadores que han firmado representan al menos dos tercios del stake total?». La lógica matemática es idéntica —la intersección de dos quorums siempre contiene stake honesto suficiente—, pero la implementación refleja la realidad económica de la red.

Los comités dinámicos añaden otra dimensión. En redes de larga duración, no se puede asumir que el mismo conjunto de validadores operará indefinidamente. Cada cierto período —llamado época—, la composición del comité se actualiza: se incorporan nuevos validadores, se retiran los que quieran salir, y se recalculan los pesos según los depósitos actualizados. La transición entre épocas debe ser cuidadosa: durante el cambio, el DAG de Narwhal debe «cerrarse» limpiamente bajo las reglas del comité saliente y «abrirse» bajo las reglas del comité entrante, sin que se pierdan transacciones ni se creen inconsistencias.

Es como el relevo en una carrera de postas: el corredor saliente debe pasar el testigo al entrante dentro de una zona marcada, sin que ningún tramo de la pista quede sin cubrir. Si el relevo se hace mal, se pierde tiempo (o se descalifican). Las transiciones de época en los protocolos DAG son un área de investigación activa, y las implementaciones más maduras —como las de Sui y Aptos— han desarrollado mecanismos sofisticados para que el cambio de comité sea transparente para los usuarios de la red.

Comparación de protocolos: qué gana qué y a qué coste

Para situar a Narwhal + Bullshark en contexto, es útil comparar los principales protocolos de consenso BFT en varias dimensiones. La siguiente tabla sintetiza las características más relevantes:

Característica	PBFT (1999)	Tendermint (2014)	HotStuff (2019)	Narwhal + Bullshark (2022)
Complejidad de mensajes por ronda	n²	n²	n (lineal)	n (lineal, en la capa de ordenación)
Separación datos/ordenación	No	No	No	Sí (Narwhal = datos, Bullshark = orden)
Rendimiento típico (tx/s)	1.000 – 5.000	1.000 – 10.000	5.000 – 20.000	100.000 – 160.000
Latencia de finalidad	1 – 5 s	1 – 7 s	1 – 3 s	0,5 – 3 s
Tolerancia a fallos	f < n/3	f < n/3	f < n/3	f < n/3
Dependencia del líder	Alta (view change costoso)	Alta (requiere timeouts)	Media (rotación suave)	Baja (el líder solo afecta a la latencia)
Finalidad	Instantánea	Instantánea	Instantánea	Instantánea
Camino rápido (fast path)	No	No	No nativo	Sí (compromiso en 1 ronda)
Escalabilidad de validadores	Hasta ~20	Hasta ~200	Hasta ~500	Hasta ~500+ (probado en redes reales)
Despliegues destacados	Hyperledger Fabric (v0.6)	Cosmos, Terra	Diem/Libra (original)	Sui, Aptos (Quorum Store)

Los números de la tabla cuentan una historia clara. PBFT fue el pionero, pero su complejidad cuadrática limita su uso a redes muy pequeñas. Tendermint mejoró la usabilidad y popularizó el consenso BFT en la práctica, pero sigue siendo secuencial. HotStuff dio el salto a complejidad lineal y rotación de líder fluida, pero mantenía el acoplamiento entre distribución y ordenación. Narwhal + Bullshark completan la evolución separando ambas capas, y el resultado es un salto de rendimiento de uno a dos órdenes de magnitud.

Pero los números no cuentan toda la historia. Cada protocolo tiene ventajas en contextos específicos. Tendermint, por ejemplo, es más sencillo de implementar y depurar, lo que lo hace ideal para proyectos que priorizan la fiabilidad sobre el rendimiento máximo. HotStuff ofrece un buen equilibrio entre rendimiento y simplicidad. La elección del protocolo depende siempre del caso de uso concreto, como veremos en la sección de escenarios reales.

Una dimensión adicional que merece mención es la relación entre estos protocolos y otros enfoques basados en DAG. En 2021, un equipo liderado por Idit Keidar publicó DAG-Rider, un protocolo que demostró formalmente que era posible construir consenso BFT con orden total sobre un DAG sin ningún mensaje adicional. DAG-Rider fue, en cierto sentido, la prueba de concepto teórica; Bullshark es su evolución práctica, optimizada para redes reales con condiciones de red variables y la posibilidad de un camino rápido.

Cinco escenarios del mundo real: dónde Narwhal + Bullshark marcan la diferencia

Escenario 1: una bolsa de valores descentralizada con millones de operaciones por segundo

Imagina una plataforma de intercambio financiero descentralizada —una bolsa de valores que no depende de una empresa central, sino de una red de validadores distribuidos por el mundo—. Esta bolsa necesita procesar órdenes de compra y venta, emparejarlas, ejecutarlas y confirmarlas, todo en milisegundos. La Bolsa de Nueva York (NYSE) procesa miles de millones de mensajes al día; Nasdaq, cantidades similares. Para que una bolsa descentralizada sea competitiva, necesita un rendimiento del mismo orden de magnitud.

Con un protocolo secuencial como Tendermint, esta bolsa alcanzaría quizás 10.000 operaciones por segundo en condiciones óptimas. Con Narwhal + Bullshark, esa misma red de validadores podría procesar 100.000 operaciones o más. La separación de Narwhal (que distribuye las órdenes a todos los validadores en paralelo) y Bullshark (que establece el orden de ejecución) permite que el cuello de botella no esté en el consenso sino en la lógica de emparejamiento de órdenes, que es donde debería estar. Además, la finalidad instantánea de Bullshark significa que una orden ejecutada es una orden definitiva: no hay posibilidad de que se revierta después, una garantía esencial cuando hay dinero real en juego.

Escenario 2: una moneda digital de banco central con finalidad rápida

Varios bancos centrales del mundo están explorando la creación de monedas digitales (CBDC, por sus siglas en inglés). El Banco Central Europeo tiene su proyecto de euro digital; China ya ha pilotado su yuan digital; Brasil trabaja en el Drex. Todas estas iniciativas comparten un requisito inegociable: finalidad absoluta e instantánea. Cuando transfiero diez euros a alguien, esa transferencia debe ser final en segundos, no en minutos ni en horas. Y no puede existir la posibilidad de que se revierta después. Los ciudadanos no aceptarían un sistema de pagos donde una compra en el supermercado pueda quedar «pendiente de confirmación» durante diez minutos.

Narwhal + Bullshark son especialmente adecuados para este escenario. La finalidad típica de menos de un segundo (con fast path) o dos a tres segundos (sin fast path) es comparable a los sistemas de pago con tarjeta actuales. La tolerancia a fallos bizantinos garantiza que el sistema funciona correctamente incluso si algunos nodos de la infraestructura son comprometidos. Y la capacidad de procesamiento de más de 100.000 transacciones por segundo supera con creces las necesidades de la mayoría de economías nacionales (el sistema de pagos con tarjeta de toda la Unión Europea, por ejemplo, procesa unos 70.000 millones de transacciones al año, lo que equivale a un promedio de unos 2.200 por segundo).

Escenario 3: una cadena de suministro global con participantes en cinco continentes

Consideremos una red de cadena de suministro que conecta fabricantes en China, transportistas en Singapur, puertos en Róterdam, distribuidores en Alemania y minoristas en España. Cada participante registra eventos en la cadena: «lote 47829 fabricado», «contenedor cargado en buque», «inspección aduanera superada», «mercancía entregada en almacén». La red tiene validadores repartidos por todo el planeta, con latencias de red que varían desde los 20 milisegundos entre nodos en la misma región hasta los 300 milisegundos entre Asia y Europa.

En este escenario, la capacidad de Narwhal de distribuir datos continuamente y en paralelo es especialmente valiosa. Mientras un validador en Singapur espera los datos de un validador en Róterdam (latencia alta), puede seguir procesando datos de validadores cercanos (latencia baja). La estructura del DAG acomoda naturalmente estas asimetrías de latencia: un validador no necesita esperar a que todos los demás respondan antes de producir su siguiente vértice; basta con que haya recibido vértices de un quorum (2f+1). Los validadores lentos no bloquean a los rápidos; simplemente aparecen más tarde en el DAG, y sus datos se incorporan en rondas posteriores.

Escenario 4: una plataforma de juegos que necesita confirmaciones en menos de un segundo

Los videojuegos multijugador con economías basadas en tokens (lo que la industria llama «GameFi») tienen un requisito extremo de latencia. Cuando un jugador compra un objeto virtual, desbloquea un logro o intercambia un activo con otro jugador, la confirmación debe ser instantánea. Un jugador no va a esperar dos segundos para saber si su espada legendaria se ha transferido correctamente; y desde luego no va a esperar sesenta minutos.

El fast path de Bullshark, con su confirmación inferior al segundo, sitúa la latencia del consenso por debajo del umbral perceptible para la mayoría de interacciones de juego. Combinado con el alto rendimiento de Narwhal, que permite procesar decenas de miles de microtransacciones por segundo, la arquitectura DAG se convierte en una base viable para economías de juego a gran escala. La blockchain Sui, que utiliza Narwhal y una variante de Bullshark, ha sido adoptada por varios estudios de juegos precisamente por estas características.

Escenario 5: una red social descentralizada resistente a la censura

Imagina una red social donde cada publicación, cada comentario, cada «me gusta» se registra en una red descentralizada. No hay una empresa que pueda borrar contenido arbitrariamente ni censurar a un usuario porque un gobierno se lo pida. Suena utópico, pero proyectos como Bluesky, Lens Protocol y Farcaster están trabajando activamente en variantes de esta idea.

El desafío técnico es enorme: una red social popular genera millones de interacciones por día. Solo Twitter (ahora X) procesa unos 500 millones de tweets diarios, más miles de millones de «me gusta», retweets y visualizaciones. Una red social descentralizada necesita un sistema de consenso capaz de absorber ese volumen sin que la experiencia del usuario se degrade.

La arquitectura de Narwhal + Bullshark ofrece la capacidad necesaria. Pero hay una sutileza adicional: en una red social, no todas las operaciones necesitan el mismo nivel de garantía. Publicar un contenido requiere registro inmutable (nadie debe poder falsificar una publicación a nombre de otro). Pero un «me gusta» puede tolerar latencia algo mayor. La separación entre Narwhal y Bullshark permite optimizar: Narwhal garantiza que el contenido está disponible inmediatamente (la publicación es visible al instante), mientras que Bullshark establece el orden definitivo en segundo plano. El usuario percibe inmediatez; la garantía criptográfica llega milisegundos después.

Despliegues reales: de la teoría al código en producción

Sui: la blockchain que nació de las cenizas de Diem

Cuando Meta disolvió el proyecto Diem en enero de 2022, varios de los ingenieros principales fundaron una nueva empresa llamada Mysten Labs. Su producto estrella, la blockchain Sui, lanzada en su red principal en mayo de 2023, implementa directamente Narwhal como capa de disponibilidad de datos y una variante optimizada de Bullshark como capa de ordenación. Sui no es un proyecto académico ni un prototipo: es una red en producción que procesa millones de transacciones diarias.

La arquitectura de Sui añade una innovación adicional: para transacciones que involucran objetos sin conflicto (es decir, transacciones que no intentan modificar los mismos datos simultáneamente), Sui las procesa sin pasar siquiera por el consenso del DAG. Utiliza un mecanismo más ligero basado en certificación directa, logrando finalidad en unos 400 milisegundos. Solo las transacciones que sí involucran objetos compartidos pasan por el flujo completo de Narwhal + Bullshark. Esta optimización, inspirada en una observación empírica (la mayoría de las transacciones en una blockchain típica no tienen conflictos entre sí), multiplica aún más el rendimiento efectivo de la red.

Los resultados son impresionantes. En pruebas de rendimiento (benchmarks), la red Sui ha demostrado capacidad para procesar más de 297.000 transacciones por segundo con una latencia de finalidad inferior a un segundo. En operación normal en la red principal, con transacciones reales de usuarios reales, el rendimiento sostenido supera las 10.000 transacciones por segundo con picos significativamente mayores. Para ponerlo en perspectiva, la red Visa procesa un promedio de unas 1.700 transacciones por segundo, con picos de hasta 65.000 en días de alta demanda.

Aptos y Quorum Store: otra rama del árbol de Diem

Aptos, otra blockchain nacida del equipo de Diem, tomó un camino ligeramente distinto. En lugar de implementar Narwhal y Bullshark como protocolos separados, Aptos desarrolló lo que llama Quorum Store: una capa de disponibilidad de datos inspirada en los principios de Narwhal pero integrada más estrechamente con su protocolo de consenso, una variante de HotStuff llamada DiemBFT (y luego AptosBFT). La idea central es la misma —separar la diseminación de datos de la ordenación—, pero la implementación difiere en los detalles.

El resultado es igualmente notable. Aptos ha demostrado rendimientos superiores a 160.000 transacciones por segundo en pruebas internas, y en su red principal procesa miles de transacciones por segundo de forma sostenida. La competencia entre Sui y Aptos —ambas nacidas del mismo proyecto, implementando variantes de la misma tecnología— ha acelerado el desarrollo y la optimización de los protocolos DAG de forma significativa. Es la versión blockchain de la rivalidad entre Boeing y Airbus: la competencia beneficia a todo el ecosistema.

Más allá de Bullshark: la frontera de la investigación

Narwhal + Bullshark no son el final de la historia; son el comienzo de un nuevo capítulo. La investigación en consenso basado en DAG está más activa que nunca, y varios avances recientes merecen mención.

El primero es la mejora de la latencia en el peor caso. Bullshark, en su versión estándar, necesita dos rondas para comprometer un ancla. Protocolos más recientes como Shoal y Mysticeti exploran formas de reducir esa latencia a una sola ronda incluso sin las condiciones óptimas que requiere el fast path. Sui, de hecho, ha adoptado Mysticeti como su protocolo de consenso principal, logrando mejoras adicionales de latencia respecto a su implementación original de Bullshark.

El segundo área de investigación activa es la resistencia a la censura. Un líder malicioso en Bullshark no puede alterar el orden de las transacciones que ya están en el DAG, pero podría negarse a incluir ciertas transacciones en sus propios vértices. La estructura del DAG mitiga este riesgo —si un líder censura una transacción, otro validador puede incluirla en su propio vértice—, pero se están desarrollando mecanismos más formales para garantizar la inclusión de todas las transacciones válidas en un plazo acotado.

El tercero es la interoperabilidad entre cadenas. A medida que proliferan las blockchains basadas en DAG, surge la necesidad de que se comuniquen entre sí. La garantía de disponibilidad de datos de Narwhal podría extenderse entre cadenas: si un dato tiene certificado en una cadena, ¿puede otra cadena confiar en ese certificado sin repetir la verificación? La respuesta parece ser que sí, y los primeros protocolos de puentes entre cadenas basados en estas ideas están comenzando a aparecer.

Las matemáticas de la seguridad: por qué funciona

Seguridad (safety): nunca se confirman dos historias contradictorias

La propiedad de seguridad de Bullshark establece que si un validador honesto confirma un ancla y las transacciones asociadas, ningún otro validador honesto confirmará jamás un orden diferente para esas mismas transacciones. Es decir, no puede haber «forks» —bifurcaciones donde parte de la red cree una cosa y otra parte cree otra distinta—.

La garantía matemática se basa en la propiedad de intersección de quorums que explicamos antes. Si un ancla A fue comprometida (confirmada), eso significa que al menos 2f+1 validadores «votaron» por ella (tienen camino hasta ella en la ronda de evaluación). Si otra ancla A' en la misma posición intentara comprometerse, también necesitaría 2f+1 votos. Pero como los dos quorums se solapan en al menos un validador honesto, y un validador honesto no puede votar por dos anclas contradictorias en la misma posición, la contradicción es imposible.

Para visualizarlo, piensa en una elección con voto único. Si se necesitan dos tercios de los votos para ganar, es matemáticamente imposible que dos candidatos obtengan cada uno dos tercios de los votos, porque eso requeriría más del 100% del total. Del mismo modo, dos anclas contradictorias no pueden obtener ambas quorum, porque eso requeriría más votos honestos de los que existen.

Vivacidad (liveness): el sistema sigue avanzando pase lo que pase

La propiedad de vivacidad garantiza que el sistema no se «atasca»: las transacciones que los usuarios envían eventualmente se procesan, incluso si algunos validadores fallan o son maliciosos. La clave está en la rotación de líderes: si el líder actual es malicioso y no produce su ancla (o produce un ancla que no obtiene suficientes votos), Bullshark simplemente avanza a la siguiente ronda de anclaje con un líder diferente. Como la selección de líderes rota entre todos los validadores, y al menos dos tercios son honestos, eventualmente le tocará el turno a un líder honesto que producirá un ancla válida y el sistema avanzará.

Además, el DAG de Narwhal sigue creciendo independientemente de si Bullshark está comprometiendo anclas o no. Los validadores siguen produciendo vértices, distribuyendo datos y obteniendo certificados. Si Bullshark no compromete un ancla en la ronda r, las transacciones acumuladas no se pierden; simplemente se incluirán en el orden cuando se comprometa el siguiente ancla. Es como un río que sigue fluyendo incluso cuando la esclusa está cerrada: el agua se acumula, y cuando la esclusa se abre, todo fluye de golpe.

Esta separación entre la vivacidad de los datos (Narwhal) y la vivacidad del orden (Bullshark) es una de las ventajas más importantes de la arquitectura. En los protocolos monolíticos, un fallo en el consenso también detiene la distribución de datos. En Narwhal + Bullshark, la distribución de datos nunca se detiene; solo el ordenamiento puede ralentizarse temporalmente. Y cuando el ordenamiento se reanuda, tiene todos los datos listos para procesar. Es la diferencia entre una fábrica donde un fallo en la línea de empaquetado detiene también la producción, y una donde la producción continúa y los productos se van acumulando en el almacén, listos para ser empaquetados en cuanto la línea se reactive.

Rendimiento en números: lo que dicen las mediciones

La teoría es convincente, pero ¿qué dicen los datos empíricos? Los artículos originales de Narwhal y Bullshark incluyen mediciones detalladas realizadas en entornos controlados, y las implementaciones reales en Sui y Aptos proporcionan datos adicionales de producción.

En las mediciones del artículo original de Narwhal (Danezis et al., 2022), un despliegue con 50 validadores distribuidos por varios continentes alcanzó un rendimiento de 130.000 transacciones por segundo con una latencia de 2 a 3 segundos hasta la finalidad. Cuando el número de validadores se redujo a 10, el rendimiento subió a más de 300.000 transacciones por segundo con latencia inferior a 2 segundos. Estas cifras incluían la propagación de datos real a través de la red, no solo el consenso sobre metadatos.

Las mediciones de Bullshark (Spiegelman et al., 2022) mostraron que la adición de la capa de ordenación añadía una sobrecarga negligible al rendimiento de Narwhal. La latencia adicional del ordenamiento era del orden de milisegundos —insignificante comparada con la latencia de la red—. Esto confirma que la estrategia de separación funciona: el cuello de botella está en la distribución de datos (Narwhal), no en el ordenamiento (Bullshark), y como Narwhal está optimizado específicamente para la distribución, el rendimiento global es excelente.

Comparemos estas cifras con otros protocolos medidos en condiciones similares. PBFT, en implementaciones reales, raramente supera las 5.000 transacciones por segundo con 20 validadores. HotStuff alcanza entre 5.000 y 20.000 con 50 validadores. Tendermint, en la red de Cosmos, procesa de forma sostenida unos 4.000 a 10.000 transacciones por segundo. La mejora de Narwhal + Bullshark es de un orden de magnitud o más: no es un ajuste incremental, sino un salto cualitativo.

Para poner estos números en contexto humano: 130.000 transacciones por segundo equivalen a procesar todas las operaciones con tarjeta de crédito de la Unión Europea en hora punta. Equivalen a que cada persona en España (47 millones de habitantes) realice una transacción cada seis minutos, continuamente, las veinticuatro horas del día. Equivalen a procesar en un solo segundo el mismo número de transacciones que Bitcoin procesa en cinco horas. La brecha entre los protocolos clásicos y los basados en DAG no es incremental; es exponencial.

Los matices: lo que Narwhal + Bullshark no resuelven

Sería deshonesto presentar Narwhal + Bullshark como una solución perfecta sin mencionar sus limitaciones y compromisos. Toda tecnología tiene contextos donde brilla y contextos donde otras alternativas son más apropiadas.

La primera limitación es la complejidad de implementación. Un protocolo que separa dos capas (datos y orden), utiliza un DAG con certificados, implementa firmas BLS agregables, gestiona comités dinámicos y soporta un fast path adaptativo es significativamente más complejo de implementar y depurar que un protocolo monolítico como Tendermint. La superficie de error es mayor, y los bugs pueden ser sutiles y difíciles de detectar. Las implementaciones de producción de Sui y Aptos representan años de trabajo de equipos de ingeniería grandes y experimentados.

La segunda limitación es el consumo de ancho de banda. Narwhal distribuye datos continuamente a todos los validadores, lo que consume más ancho de banda que un protocolo donde solo el líder envía datos. En redes con ancho de banda limitado o costoso, esta sobrecarga puede ser significativa. En la práctica, las redes blockchain de alto rendimiento suelen requerir validadores con conexiones de al menos un gigabit por segundo, lo que excluye a participantes con infraestructura modesta.

La tercera limitación es que, como todos los protocolos BFT, Narwhal + Bullshark asumen que menos de un tercio de los validadores son maliciosos. Si un atacante controla un tercio o más del stake de la red, puede romper la seguridad del sistema. Este límite es teóricamente óptimo (está demostrado que no se puede hacer consenso BFT con un tercio o más de nodos maliciosos), pero significa que la seguridad del sistema depende en última instancia de la distribución económica del stake. Si el stake está concentrado en pocas manos, la promesa de descentralización se debilita.

La cuarta limitación es la latencia mínima en condiciones adversas. Mientras que el fast path ofrece sub-segundo, si las condiciones de red son malas o si líderes consecutivos son maliciosos, la latencia puede aumentar a varios segundos. Para aplicaciones que requieren garantías estrictas de latencia máxima (no solo promedio), esta variabilidad puede ser problemática.

Estas limitaciones no invalidan la tecnología; la sitúan en su contexto. Narwhal + Bullshark son una herramienta extraordinariamente poderosa para redes que necesitan alto rendimiento, finalidad rápida y tolerancia a fallos bizantinos, con validadores que disponen de buena infraestructura de red. Para redes más pequeñas, con requisitos de rendimiento modestos o con participantes de infraestructura limitada, protocolos más simples como Tendermint pueden ser la elección más sensata.

El viaje de la información: la vida de una transacción de principio a fin

Para consolidar todo lo que hemos visto, sigamos el viaje completo de una transacción desde que un usuario la envía hasta que queda confirmada de forma definitiva. Imaginaremos que Marta, en Madrid, quiere enviar 100 unidades de un token digital a Pedro, en Buenos Aires, a través de una red con 100 validadores distribuidos por el mundo.

Momento cero: envío. Marta abre su aplicación, introduce la dirección de Pedro y la cantidad, y pulsa «Enviar». Su aplicación construye la transacción, la firma con la clave privada de Marta, y la envía al validador más cercano. Este validador está en Frankfurt.

Milisegundo 50: recepción y agrupación. El validador de Frankfurt recibe la transacción de Marta junto con cientos de otras transacciones de otros usuarios. Las agrupa en un lote y calcula su hash. El lote se almacena localmente.

Milisegundo 100: construcción del vértice. Es el turno de Frankfurt de producir su vértice para la ronda actual. El validador empaqueta los hashes de sus lotes recientes y las referencias a vértices de la ronda anterior (de validadores en Tokio, São Paulo, Nueva York y docenas de otros), y emite el vértice a todos los demás validadores.

Milisegundo 200–400: firmas de validadores. Los 99 validadores restantes reciben el vértice de Frankfurt. Cada uno verifica que tiene los lotes correspondientes (si no los tiene, los solicita), comprueba las referencias, y si todo es correcto, firma el vértice y envía la firma de vuelta a Frankfurt.

Milisegundo 500: certificado. Frankfurt ha recibido firmas de 67 validadores (2f+1, con f = 33). Agrega las firmas BLS en un único certificado compacto. El vértice de Frankfurt tiene ahora un certificado: la prueba criptográfica de que una supermayoría de la red ha visto y verificado los datos. La transacción de Marta está disponible y verificada, pero aún no está ordenada.

Milisegundo 600: siguiente ronda. Una nueva ronda comienza. Los validadores producen nuevos vértices que referencian al vértice certificado de Frankfurt (entre otros). El DAG crece.

Milisegundo 800: evaluación del ancla. En esta ronda, el validador designado como líder produce su ancla. Es el validador de Singapur. Bullshark examina si una supermayoría de los vértices de la ronda de evaluación tiene camino hasta el ancla de Singapur de la ronda anterior. Con el fast path activo y buenas condiciones de red, el ancla se compromete.

Milisegundo 900: orden definitivo. Bullshark, al comprometer el ancla, recorre el DAG hacia atrás desde el ancla, recopilando todos los vértices alcanzables que aún no habían sido ordenados. Entre ellos está el vértice de Frankfurt que contiene la transacción de Marta. Todos los validadores honestos, aplicando las mismas reglas al mismo DAG, llegan al mismo orden.

Segundo 1: confirmación. La transacción de Marta está definitivamente confirmada. Pedro tiene 100 tokens más en su cuenta. La transacción no puede revertirse, no puede modificarse, no puede desaparecer. La aplicación de Marta muestra «Transferencia completada».

Todo el viaje —desde que Marta pulsa «Enviar» hasta que la transacción es irrevocablemente final— ha tardado alrededor de un segundo. Un segundo para que cien validadores distribuidos por cinco continentes se pongan de acuerdo sobre el estado exacto de la red, con garantía matemática de que ningún atacante que controle hasta un tercio de ellos puede corromper el resultado. Es un logro técnico extraordinario, construido sobre cuarenta años de investigación en sistemas distribuidos.

Para saber más: referencias y lecturas recomendadas

Los artículos y publicaciones que sustentan lo expuesto en este texto constituyen algunas de las contribuciones más importantes en la teoría y práctica de los sistemas de consenso distribuido. Para quienes deseen profundizar, la siguiente selección cubre desde los fundamentos teóricos hasta las implementaciones más recientes.

• Danezis, G., Kokoris-Kogias, L., Sonnino, A., & Spiegelman, A. (2022). «Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus». Proceedings of the Seventeenth European Conference on Computer Systems (EuroSys ’22). El artículo fundacional que introduce Narwhal como capa de disponibilidad de datos y Tusk como primer protocolo de ordenación sobre el DAG. Presenta las mediciones de rendimiento que demostraron el potencial de la separación entre datos y consenso.
• Spiegelman, A., Giridharan, N., Sonnino, A., & Kokoris-Kogias, L. (2022). «Bullshark: DAG BFT Protocols Made Practical». Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security (CCS ’22). Presenta Bullshark como evolución práctica de Tusk, con la adición del camino rápido para condiciones de red favorables y una latencia significativamente reducida.
• Lamport, L., Shostak, R., & Pease, M. (1982). «The Byzantine Generals Problem». ACM Transactions on Programming Languages and Systems, 4(3), 382–401. El artículo clásico que formaliza el problema del consenso bizantino y demuestra los límites teóricos de la tolerancia a fallos (n ≥ 3f+1). Lectura obligatoria para cualquier persona interesada en sistemas distribuidos.
• Castro, M. & Liskov, B. (1999). «Practical Byzantine Fault Tolerance». Proceedings of the Third Symposium on Operating Systems Design and Implementation (OSDI ’99). El primer protocolo BFT práctico, que demostró que el consenso bizantino podía implementarse con rendimiento aceptable para sistemas reales. Sigue siendo la referencia contra la que se miden todos los protocolos posteriores.
• Yin, M., Malkhi, D., Reiter, M. K., Gueta, G. G., & Abraham, I. (2019). «HotStuff: BFT Consensus with Linearity and Responsiveness». Proceedings of the 2019 ACM Symposium on Principles of Distributed Computing (PODC ’19). Introduce el paradigma de complejidad de mensajes lineal y rotación de líder suave, estableciendo la base sobre la que se construyeron tanto Diem como los protocolos DAG posteriores.
• Buchman, E. (2016). «Tendermint: Byzantine Fault Tolerance in the Age of Blockchains». Tesis de maestría (M.A.Sc.), University of Guelph. La descripción formal del protocolo Tendermint, que popularizó el consenso BFT en el ecosistema blockchain y sirvió como base para la red Cosmos y decenas de proyectos derivados.
• Keidar, I., Kokoris-Kogias, L., Naor, O., & Spiegelman, A. (2021). «All You Need is DAG». Proceedings of the 2021 ACM Symposium on Principles of Distributed Computing (PODC ’21). Presenta DAG-Rider, la demostración formal de que es posible construir consenso BFT con orden total sobre un DAG sin ningún mensaje adicional más allá de los necesarios para construir el propio DAG. Estableció el fundamento teórico para Bullshark.
• Blackshear, S., Chursin, A., Danezis, G., Kichidis, A., Kokoris-Kogias, L., et al. (2023). «Sui Lutris: A Blockchain Combining Broadcast and Consensus». Describe la arquitectura de la blockchain Sui, que combina Narwhal, Bullshark y un mecanismo de certificación directa para transacciones sin conflicto, logrando rendimientos excepcionales en la práctica.
• Gelashvili, R., Kokoris-Kogias, L., Sonnino, A., Spiegelman, A., & Xiang, Z. (2023). «Jolteon and Ditto: Network-Adaptive Efficient Consensus with Asynchronous Fallback». Explora cómo los protocolos de consenso basados en DAG pueden adaptarse dinámicamente a las condiciones de la red, alternando entre modos síncronos y asíncronos según la situación.
• Babel, K., Chursin, A., Danezis, G., Kichidis, A., Kokoris-Kogias, L., et al. (2023). «Mysticeti: Low-Latency DAG Consensus with Fast Commit Path». Presenta la evolución más reciente de los protocolos DAG, adoptada por Sui como sucesor de Bullshark, con latencias aún menores y una arquitectura optimizada para el caso común.

«El consenso no es un problema técnico: es un problema de confianza. Durante milenios, los seres humanos han buscado formas de ponerse de acuerdo sin necesidad de confiar ciegamente unos en otros: códigos legales, contratos, instituciones, moneda respaldada por Estados. La criptografía moderna y los protocolos de consenso como Narwhal y Bullshark representan el último capítulo de esa búsqueda. Por primera vez en la historia, podemos construir sistemas donde miles de participantes anónimos, sin confiar entre sí, alcanzan acuerdos irrevocables en fracciones de segundo, con garantías matemáticas que ningún contrato legal podría igualar. No es la eliminación de la confianza; es su transformación. De confiar en personas e instituciones pasamos a confiar en matemáticas y protocolos. Y esa transformación, silenciosa y profunda, está redefiniendo los cimientos sobre los que se construye la cooperación humana.»