HotStuff-2 y frontera moderna: dos fases, Twins y DAG-BFT

Llegamos al borde: HotStuff-2, testing Byzantine y DAG-BFT. [1] [2] [3] Esta frontera es divertida porque ya no basta con preguntar "¿cuántas fases tiene?". También tienes que preguntar:

• ¿qué comunicación paga en camino feliz?
• ¿qué paga en peor caso?
• ¿cómo prueba safety?
• ¿separa difusión de datos y ordenamiento?
• ¿qué ocurre bajo ataques de performance?

HotStuff-2: dos fases sin pedir disculpas

HotStuff-2 responde una pregunta que quedó dando vueltas: ¿eran necesarias las tres fases para mantener las propiedades deseadas? [1] [9]

La respuesta del trabajo de Malkhi y Nayak es potente: una variante de dos fases puede lograr comunicación peor caso O(n²), comunicación optimista lineal, commits de dos fases dentro de una vista y optimistic responsiveness. [1] [5]

El mapa también conserva dos escalones que explican cómo llegamos ahí: Fast-HotStuff formaliza la recuperación de dos cadenas con AggQC, y Jolteon/Ditto separa el camino rápido del fallback adaptativo. [10] [11]

Figura 1

Familia y frontera

Fuentes:[9][10][11][1][2][3][4]

📖 Cómo leer esta figura (Detalle explicativo)

El grafo se lee desde HotStuff hacia variantes y herramientas. Las flechas superiores siguen optimizaciones de latencia dentro de la familia; las ramas inferiores muestran fallback y testing adversarial; la rama verde separa disponibilidad y orden mediante DAG-BFT. La posición expresa relación conceptual, no una cronología estricta ni compatibilidad automática.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en pestaña nueva

Twins: si no pruebas equivocation, ella te prueba a ti

Twins propone una forma elegante de generar comportamiento bizantino: duplica un nodo con la misma identidad. Para el resto del sistema, ambos gemelos parecen el mismo validador, pero pueden enviar mensajes distintos. [2]

Eso permite materializar:

• equivocation del líder;
• doble voto;
• pérdida de locks;
• particiones por ronda.

No reemplaza una prueba formal, pero sí convierte fallas bizantinas en escenarios ejecutables. Para futuros labs con ResilientDB o implementaciones HotStuff-like, esta idea vale oro. [2]

Narwhal/Tusk/Bullshark: no todo lo moderno es HotStuff

Narwhal y Tusk empujan otra línea: separar difusión confiable de transacciones y ordenamiento. Narwhal usa un DAG como mempool de alto throughput; Tusk y luego Bullshark exploran consenso sobre esa estructura. [3] [4]

No confundamos:

• HotStuff es líder, vistas, QCs y cadena;
• DAG-BFT usa una estructura de DAG para desacoplar difusión/orden;
• ambos están en BFT moderno, pero no son el mismo animal.

Papers recientes para seguir

Esta serie te deja la base. El estado del arte sigue moviéndose:

• HotStuff-2: dos fases con las propiedades fuertes que nos interesan. [1]
• Pike y variantes two-phase: dos fases, linealidad y view-change flexible. [12]
• HotStuff-1: especulación de una fase para finality temprana. [13]
• P-HotStuff: paralelismo para atacar throughput sensible a latencia de propagación. [7]
• HotStuff-2 vs HotStuff: comparación experimental útil para diseñar labs propios. [6]
• Responsiveness bajo delay adversarial: modelos que muestran que responsiveness no siempre es ganancia universal. [5]
• ChonkyBFT: diseño inspirado por FAB Paxos, Fast-HotStuff y HotStuff-2 para ZKsync. [8]
• Bullshark y DAG-BFT: rendimiento alto al cambiar la arquitectura del pipeline. [4]

Cierre de serie

Si llegaste hasta aquí, ya puedes leer un paper HotStuff sin sentir que cada símbolo trae una navaja escondida.

La ruta mental completa:

El siguiente paso natural en TrautsLab es laboratorio: implementar o instrumentar una variante, forzar líderes malos, medir latencia/throughput y documentar con trazas. Porque leer papers está muy bien; hacer que fallen con cariño, mejor.

Profundización conceptual

Modelo mental: la frontera tiene ejes, no una corona

El estado del arte no es una fila de protocolos esperando coronación. Es un mapa con ejes. Un eje reduce latencia de commit: Jolteon, HotStuff-2, HotStuff-1 y variantes de dos fases viven cerca de ahí. [1] Otro eje aumenta robustez bajo condiciones malas: Ditto, fallback asíncrono y análisis de responsiveness bajo delay adversarial. [5] Otro eje cambia el pipeline: Narwhal, Tusk y Bullshark separan difusión de datos y ordenamiento con DAGs para atacar throughput. [3] [4]

Si mezclas esos ejes, todo parece contradicción. Un paper DAG-BFT puede lograr alto throughput sin ser "otro HotStuff". Un paper de dos fases puede mejorar latencia sin resolver mempool. Un paper de testing como Twins no es un protocolo de consenso, pero puede descubrir fallas en implementaciones de consenso. Cada pieza responde una pregunta distinta.

La lectura madura es taxonómica: ubica el paper antes de evaluarlo. Primero familia, luego modelo, luego claim.

Invariante: menos fases no significa menos deuda

Cuando un protocolo reduce fases, la deuda no desaparece automáticamente. Puede moverse al view-change, a supuestos de sincronía, a caminos de fallback, a especulación, a firmas adicionales o a complejidad de implementación. Eso no es malo; es diseño. Lo peligroso es leer "two-phase" como sinónimo de "estrictamente superior".

El invariante de análisis es: compara siempre bajo el mismo adversario. Si un paper promete latencia menor en camino feliz, pregunta qué ocurre con líder fallido. Si promete throughput alto, pregunta si el cuello de botella estaba en consenso o en difusión de transacciones. Si promete robustness, pregunta qué paga cuando la red vuelve a estar bien.

HotStuff-2 pertenece a la familia HotStuff porque sigue razonando sobre vistas, commits, responsiveness y comunicación bajo un modelo BFT. [1] [9] Narwhal/Tusk/Bullshark están al lado, no encima: cambian la arquitectura del pipeline con DAG mempool y ordenamiento posterior. [3] [4]

Escenario adversarial: el bug que solo aparece con gemelos

Twins es precioso porque convierte una falla bizantina abstracta en un experimento barato: dos procesos comparten identidad y pueden enviar mensajes distintos. Para una implementación, eso es incómodo en el mejor sentido. Un nodo "único" puede votar doble, equivocar al líder o aparecer en dos particiones lógicas. [2]

Muchos bugs de consenso no aparecen en pruebas felices. Aparecen cuando una réplica correcta recibe evidencia en orden raro, cuando el líder ve una parte del mundo y otro líder ve otra, o cuando el mismo validador parece haber firmado dos cosas. Twins fuerza esas escenas sin pedirte construir un adversario sobrenatural.

Para TrautsLab, esta es una línea de labs excelente: tomar una implementación HotStuff-like, modelar gemelos, romper supuestos de red y observar si locks, QCs y view-change hacen lo que prometen. Un paper se entiende mejor cuando lo haces sudar.

Cómo leer el estado del arte sin mezclar familias

Usa una ficha por paper:

1. Familia: HotStuff-like, DAG-BFT, testing, pacemaker, speculative finality o throughput.
2. Claim principal: latencia, comunicación, robustness, testing, implementación o análisis formal.
3. Modelo: parcial sincronía, asincronía, committee permissioned, firmas, threshold signatures, mempool separado.
4. Costo escondido: view-change, fallback, batching, líder, workers, storage o complejidad.
5. Lab posible: qué experimento lo probaría o lo haría fallar.

Con esa ficha, HotStuff-2, P-HotStuff, ChonkyBFT, Bullshark y Twins dejan de ser una sopa de nombres. [1] [7] [8] [4] [2] Se vuelven herramientas en estantes distintos. Y cuando llegue el momento de construir un lab serio, sabremos qué estamos midiendo: commit latency, throughput de difusión, resiliencia a líder malo, o bugs de safety bajo equivocation.