La arquitectura de Workers en Narwhal: Desacoplar propagación y orden

En Narwhal y Bullshark vimos la idea general: separar la difusión confiable de transacciones del protocolo que decide el orden. En el cuello de botella de la doble transmisión vimos por qué esa separación importa: si el líder transporta todo el payload, su ancho de banda limita a todo el sistema.

Este artículo baja un nivel. Narwhal no solo separa mempool y consenso como capas lógicas; también divide cada validador en un proceso primary y varios procesos workers, que pueden correr en máquinas distintas. [1] Esa decisión de arquitectura es la que permite hablar de escalado horizontal del mempool.

El cuello de botella del validador monolítico

En un protocolo con líder como HotStuff, el líder de cada vista propone un bloque que contiene los comandos de clientes y lo envía a todas las réplicas. [3] Ese diseño hace muy limpio el razonamiento de safety, pero concentra dos trabajos en la misma máquina: decidir el orden y mover los datos.

Pensemos qué hace un validador monolítico en cada paso. Recibe transacciones de clientes, las valida, las retransmite a sus pares, participa en el consenso y persiste el resultado. Todas esas tareas compiten por la misma tarjeta de red, la misma CPU y el mismo disco. Cuando la carga crece, el validador no puede crecer más allá de lo que una sola máquina soporta.

Los autores de Narwhal parten de una observación concreta: en los sistemas BFT de su época, difundir transacciones y ordenarlas estaban mezclados, y el costo de mover datos dominaba el rendimiento. [1] Su propuesta es que el consenso trabaje sobre referencias pequeñas, mientras el volumen de datos circula por otro camino que se puede paralelizar.

Figura 1

Arquitectura interna de un validador Narwhal: Primary y Nodos Workers

Fuentes:

[1]

Cómo leer esta figura

El diagrama muestra un validador i con un primary arriba y tres workers debajo. Los clientes envían transacciones a los tres workers. Cada worker intercambia batches con los workers de otros validadores. Un arco etiquetado solo digests sube de los workers al primary, que ordena el DAG con certificados.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

Qué hace un worker: batches, pares y digests

El worker es el proceso que toca las transacciones. Recibe los envíos de los clientes, los agrupa en batches y envía cada batch a los workers correspondientes de los demás validadores. [1] Un worker de un validador conversa con su par en cada uno de los otros validadores; no necesita hablar con los primaries ajenos.

Cuando un worker recibe un batch de un par, lo almacena. Cuando un worker termina de difundir un batch propio, entrega a su primary solo el digest, es decir, el hash que identifica ese batch. [1] El primary nunca recibe el contenido de las transacciones: trabaja con identificadores de tamaño fijo.

Este reparto tiene una consecuencia práctica fácil de pasar por alto. El tamaño de los mensajes que ve el primary no depende del tamaño de las transacciones, sino de cuántos digests entran en su header. Los bytes pesados viajan en paralelo por varios pares de workers, cada uno con su propia conexión.

Ojo con una confusión frecuente: el worker no "certifica" nada por sí mismo en el modelo del paper. La garantía de disponibilidad que el consenso usa se construye un nivel más arriba, sobre los headers de los primaries. El worker aporta el almacenamiento que hace que esa garantía sea verdadera.

Qué hace el primary: headers, votos y certificados

El primary es el proceso que construye el DAG. En cada ronda, el primary de un validador arma un header que contiene los digests reportados por sus workers y referencias a al menos $2f + 1$ certificados de la ronda anterior. [1] Luego lo difunde a los primaries de los demás validadores.

Un primary correcto firma el header de otro validador solo si es válido: debe ser el primero que recibe de ese autor en esa ronda y debe apoyarse en certificados de la ronda anterior. Además, antes de votar comprueba que sus propios workers ya tienen los batches cuyos digests aparecen en el header. [1] Cuando el autor reúne $2f + 1$ firmas, el header se convierte en un certificado de disponibilidad, que podrá ser referenciado en la ronda siguiente.

La idea se parece a un QC de HotStuff, porque ambos son conjuntos de $2f + 1$ firmas sobre un mismo objeto. [3] La diferencia está en lo que prometen: un QC de HotStuff es un paso hacia el commit de un bloque, mientras que un certificado de Narwhal promete que el header y sus datos están disponibles, sin decir nada todavía sobre el orden.

Por qué la separación escala horizontalmente

Con esta división, aumentar la capacidad de difusión ya no exige una máquina más grande. Un validador puede ejecutar más workers, cada uno en su propia máquina, y repartir entre ellos el tráfico de clientes y de batches. [1] El primary sigue haciendo el mismo trabajo de metadatos: más workers significan más digests por header, no más bytes de transacciones atravesando el primary.

La evaluación del paper muestra exactamente ese efecto: al añadir workers por validador, el throughput crece de forma aproximadamente lineal sin un aumento apreciable de latencia en sus experimentos. [1] Conviene leer ese resultado con su contexto: es una medición de una implementación concreta, en un despliegue concreto, y no un teorema que valga para cualquier red o cualquier tamaño de comité.

La misma arquitectura sirve de base a otros protocolos. Bullshark se presenta como un protocolo de consenso sobre un DAG estilo Narwhal y hereda de esa capa la difusión escalable de datos. [2] Esa reutilización es la prueba más clara de que la división primary/worker pertenece al mempool, no a un algoritmo de orden en particular.

Lo que la división no resuelve

La separación no es gratis. Un validador pasa a ser un pequeño sistema distribuido interno: si un worker se cae, el primary no puede votar headers ajenos que referencian batches que ese worker debía guardar, porque la regla de almacenamiento previo no se cumple. La disponibilidad del validador depende ahora de varias máquinas, no de una.

Tampoco resuelve el orden. Narwhal entrega un DAG de certificados con buenas propiedades de disponibilidad y causalidad, pero el orden total lo decide otro protocolo encima: Tusk en el paper original, o un protocolo con líder como HotStuff ejecutado sobre los certificados. [1] Bullshark es otra opción para esa capa superior, con un camino rápido bajo sincronía parcial. [2]

Finalmente, la ganancia depende de que el cuello de botella fuera realmente la difusión. Si el costo dominante está en ejecutar transacciones o en verificar firmas, añadir workers no lo elimina. La pregunta útil antes de escalar no es "¿cuántos workers?", sino "¿qué recurso se satura primero?".

Siguiente lectura

Con la división primary/worker clara, el siguiente paso es mirar cómo los certificados forman un grafo por rondas y cómo un protocolo ordena ese grafo sin mensajes extra: Tusk, consenso asíncrono sin timeouts. Si quieres repasar el problema que motiva todo esto, vuelve a el cuello de botella de la doble transmisión.