HotStuff multipipeline: de fases a cadena viva

Aquí había un hueco importante: hablar de highQC, view-change y tres cadenas sin mostrar el multipipeline deja a HotStuff como si fuera una receta por pasos. Y HotStuff no se entiende bien como receta. Se entiende como una cinta transportadora donde cada vista empuja evidencia para que la siguiente vista pueda avanzar. [1]

En el HotStuff básico, uno puede nombrar cuatro fases: prepare, pre-commit, commit y decide. Eso ayuda al comienzo, pero si te quedas ahí, el lector imagina un protocolo que termina una vista completa y recién después arranca otra. Chained HotStuff hace algo más elegante: reutiliza el mismo patrón de propuesta/voto/QC en cada altura y deja que las fases queden representadas por la profundidad de la cadena. [1]

La idea corta: cada nuevo bloque certificado sirve como fase para sí mismo y como evidencia para ancestros. El pipeline no elimina seguridad; la empaqueta en GenericQC y la mueve en una cadena de bloques.

Figura 1

PBFT vs HotStuff: la diferencia que se ve en carriles

Fuentes:[1][2][3]

📖 Cómo leer esta figura (Detalle explicativo)

Lee cada carril horizontal como una réplica y el tiempo de izquierda a derecha. En PBFT, las diagonales entre réplicas forman intercambios todos-contra-todos; en HotStuff, los mensajes convergen en el líder de cada fase y regresan como propuesta o QC. La comparación muestra por qué la agregación reduce la comunicación normal sin eliminar la evidencia de quórum.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en pestaña nueva

El contraste anterior viene del corazón del paper y de la presentación didáctica que usamos como apoyo visual: PBFT se entiende como fases con mucho intercambio entre réplicas; Basic HotStuff conserva fases, pero empuja el intercambio hacia un patrón líder ↔ réplicas y certificados portables. [2]

La comparación no dice que PBFT sea “malo” y HotStuff “bueno”. Dice otra cosa: los dos compran safety y liveness con mecánicas distintas. PBFT usa fases donde las réplicas tienen que convencerse entre ellas. [3] HotStuff usa un líder que recolecta votos, produce un QC compacto y hace que el siguiente líder pueda continuar con una prueba manejable. [1] [4]

Esa diferencia explica por qué HotStuff habla tanto de view-change lineal. Si quieres cambiar de líder con frecuencia, no puedes pedir que cada cambio arrastre una mudanza completa de mensajes cuadráticos. Necesitas evidencia comprimida. [1] [3]

La intuición del multipipeline

En una vista aislada, el líder propone y las réplicas votan. Si hay 2f + 1 votos, aparece un QC. Si lo cuentas fase por fase, repites el mismo dibujo cuatro veces. El insight de Chained HotStuff es decir: “si el código de las fases se parece tanto, ¿por qué no convertirlo en un mismo paso genérico repetido sobre una cadena?”. [1]

En vez de tener muchos tipos de mensaje, cada vista produce un bloque con un QC que justifica su padre. Con suficiente profundidad, los ancestros quedan comprometidos. El commit deja de ser un evento suelto y se vuelve una propiedad de una cadena certificada.

Figura 2

Multipipeline de Chained HotStuff

Fuentes:[1][2]

📖 Cómo leer esta figura (Detalle explicativo)

Las columnas son vistas consecutivas y las filas son fases lógicas. Sigue una diagonal de QCs: el bloque nuevo prepara su propia evidencia mientras el QC transportado hace avanzar a sus padres hacia pre-commit, commit y decide. La cadena inferior identifica qué ancestro queda comprometido cuando aparecen tres certificaciones consecutivas.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en pestaña nueva

Hay una trampa frecuente: creer que multipipeline significa paralelismo libre. No. Es pipeline con dependencia. La vista v+2 no puede inventarse una historia porque todavía debe transportar evidencia compatible con lo que ocurrió antes. La ganancia viene de solapar fases lógicas, no de ignorar los locks.

En términos prácticos, cuando ves una implementación HotStuff-like, busca tres cosas:

1. qué objeto representa el bloque/propuesta;
2. qué objeto representa el QC o certificado;
3. cómo una propuesta decide cuál QC usar como justificación.

Si esos tres objetos están claros, el pipeline empieza a leerse solo.

GenericQC: la pieza que baja la presión mental

En la presentación que revisamos, una idea aparece varias veces: todas las fases terminan generando algo parecido a un QC. Por eso el protocolo se simplifica al usar un GenericQC. El nombre importa menos que la función: una prueba agregada, verificable, de que un quórum apoyó una pieza concreta de historia. [2] [1]

El GenericQC normalmente necesita:

• número de vista o altura;
• referencia al bloque/propuesta;
• padre, abuelo o hashes necesarios para verificar la cadena;
• firmas agregadas o evidencia equivalente;
• reglas para confirmar que el bloque certificado no contradice el lock local.

Esa estructura permite escribir programas event-driven más simples. Una réplica recibe una propuesta, verifica su justificación, decide si vota y actualiza su estado local. El líder siguiente recibe votos, produce un QC y lo incrusta en la siguiente propuesta.

Aquí se ve por qué los artículos previos de la serie eran prerequisitos. Si todavía no tienes claro 2f + 1, quórums, highQC y view-change, el multipipeline parece una coreografía de flechas. Cuando esos conceptos ya están en la cabeza, las flechas se vuelven transporte de evidencia.

Profundización conceptual

Modelo mental: la línea de ensamblaje

Piensa en una fábrica con estaciones. En la primera estación entra una propuesta. En la segunda estación esa propuesta se convierte en evidencia. En la tercera, esa evidencia permite bloquear una decisión futura. En la cuarta, un ancestro queda listo para ejecutarse. La fábrica no espera a que una pieza llegue al final para meter la siguiente; mete piezas una tras otra, pero cada estación mantiene reglas estrictas.

Chained HotStuff hace eso con vistas. Cada vista produce un bloque que empuja a los anteriores. Si B3 tiene QC para B2, y B2 tiene QC para B1, y B1 tiene QC para B0, entonces B0 ya no es una idea flotante. Está cubierto por suficiente evidencia acumulada. [1]

La chispa es que la seguridad se expresa como distancia certificada. Ya no necesitas recordar cuatro nombres de fase en cada explicación; puedes mirar una cadena y preguntar cuánta profundidad certificada tiene.

Invariante: pipeline no rompe locks

El invariante que no se negocia es este: una réplica correcta no debe votar por una propuesta que contradiga su estado seguro. El pipeline puede solapar trabajo, pero no puede convertir un lock en decoración. Si un líder propone una rama que no extiende evidencia aceptable, la réplica correcta tiene que rechazarla.

Eso mantiene la intersección de quórums viva. Dos ramas conflictivas no pueden acumular commits correctos si los votos honestos siguen respetando locks y QCs. El pipeline gana latencia; no gana permiso para saltarse el protocolo.

Esta distinción es muy importante para leer claims de rendimiento. Un gráfico que muestra mejor throughput puede estar midiendo batching, networking, firmas o mempool, no necesariamente el core de consenso. En HotStuff puro, la pregunta sigue siendo: ¿qué evidencia permite votar?, ¿qué evidencia permite cambiar de vista?, ¿qué evidencia permite comprometer?

Escenario adversarial: líder impaciente en medio de la cinta

Imagina un líder que recibe votos para B2, pero no comunica bien el QC resultante. Algunas réplicas ven QC(B2); otras solo conocen QC(B1). Ahora llega otro líder y quiere proponer rápido. Si solo mira su estado local, puede extender una rama vieja. Si las réplicas aceptan eso sin revisar highQC y lock, el pipeline se bifurca.

El diseño obliga a que la nueva propuesta cargue evidencia suficiente. En HotStuff clásico, el view-change recoge QCs y selecciona el de vista más alta. En variantes como Fast-HotStuff, la historia se vuelve más delicada y aparece AggQC para probar que el líder está extendiendo la punta correcta. Ese es el siguiente artículo.

El escenario enseña una regla práctica: el pipeline no es solo una optimización; es una forma de no repetir mensajes. Pero cuando la red se porta mal, la evidencia vuelve al centro del escenario.

Cómo leer el paper

En el paper de HotStuff, no leas Chained HotStuff como “la versión productiva y ya”. Léelo como una transformación conceptual: [1] [4]

1. primero entiende el protocolo por fases;
2. luego observa que las fases tienen forma repetida;
3. después mira cómo los QCs se convierten en enlaces de una cadena;
4. finalmente conecta la regla de commit con la profundidad certificada.

Cuando encuentres figuras de PBFT contra HotStuff, no te quedes en la estética de flechas. Pregunta qué flecha representa broadcast del líder, qué flecha representa voto de réplica, qué flecha representa agregación y qué flecha representa evidencia portable. Esa lectura evita confundir “menos flechas en el dibujo” con “menos seguridad”. [3] [1]

La frase para llevar: Chained HotStuff no desaparece fases; las convierte en historia certificada.