HotStuff: de cero a estado del arte
Artículo 15 de 77
19%
completado
Sincronía parcial y quórums: la calma antes de HotStuff
Qué significa GST, por qué la red no necesita ser perfecta y cómo los quórums sostienen safety mientras liveness espera mejores condiciones.
Prerequisitos recomendados
Si alguno de estos conceptos todavía está medio nebuloso, empieza por aquí. Te ahorra tropiezos y un par de cejas fruncidas.
Separa safety de liveness bajo sincronía parcial y conecta GST, Δ y quórums con el progreso de un protocolo BFT.
- Consenso BFT desde cero
- Intersección de quórums
Continúa cuando puedas explicar qué garantiza el protocolo antes y después de GST sin asumir una red perfecta.
La frase "parcialmente síncrono" parece inventada para dormir audiencias. Pero en consenso BFT es una de las ideas que separa un protocolo bonito en pizarra de uno que puede sobrevivir a internet.
El modelo viene de Dwork, Lynch y Stockmeyer: no asumimos que la red siempre tiene un límite conocido de entrega; asumimos que eventualmente hay un periodo suficientemente estable. A ese punto se le suele llamar GST: Global Stabilization Time. [1]
Línea de tiempo
La historia de una red parcialmente síncrona
Antes
Asincronía práctica
timeouts falsos, líderes sospechados, mensajes que llegan tarde
GST
La red se estabiliza
no sabemos cuándo ocurre, pero eventualmente ocurre
Después
Progreso posible
un líder correcto puede reunir votos y avanzar
Safety no espera a GST
Aquí está el truco: safety no debería depender de que la red esté bonita. Si la red retrasa mensajes durante minutos, el protocolo no debería finalizar dos bloques incompatibles.
Liveness sí es otra historia. Para progresar, el sistema necesita que los mensajes de suficientes réplicas correctas lleguen a tiempo. Por eso los protocolos tienen pacemakers, timeouts y cambios de líder. [1]
Tres números que debes memorizar
Quórums
Aritmética BFT mínima
Réplicas totales
3f + 1mínimo para tolerar f bizantinas
Quórum
2f + 1suficiente para certificar una propuesta
Intersección
f + 1garantiza al menos una réplica correcta compartida
La intersección es la bisagra. Si dos quórums válidos se cruzan en al menos f + 1, y como máximo f son malos, entonces hay una réplica correcta que puede impedir que dos decisiones contradictorias se certifiquen sin romper las reglas. [1]
Responsiveness: la palabra que HotStuff puso de moda
Un protocolo responsive no tiene que esperar el peor timeout Δ cuando la red real está entregando mensajes en δ. Si el líder correcto recibe votos rápido, avanza rápido. [2]
Δ contra δ
📖 Cómo leer esta figura (Detalle explicativo)
La línea temporal distingue el límite conocido Δ del retardo real δ después de GST. Los mensajes correctos llegan dentro de δ, mucho antes del timeout; un protocolo responsive forma el QC al recibir el quórum y avanza sin esperar hasta Δ. El timeout sigue siendo la red de seguridad para el líder o la red defectuosos.
Por qué esto importa para HotStuff
HotStuff combina tres deseos que históricamente costaba tener juntos: [2]
- comunicación lineal en el camino feliz;
- cambio de líder simple;
- progreso responsive con líder correcto después de GST.
No significa que todo sea gratis. Timeouts mal calibrados pueden disparar cambios de vista innecesarios. Líderes malos pueden frenar. La red puede jugar sucio. Pero la estructura de quórums hace que el sistema no tenga que elegir entre "seguro" y "eventualmente vivo" de manera artesanal.
Flujo visual
Cómo se lee una ronda BFT
La señal de que lo entendiste
Si alguien te pregunta por qué HotStuff no decide con mayoría simple, responde con calma:
Porque en BFT no basta con ganar una votación; necesitas que cualquier certificado futuro se cruce con evidencia correcta del pasado.
Esa frase parece pequeña, pero carga media serie encima.
Profundización conceptual
Modelo mental: la red como clima, no como contrato
La sincronía parcial se entiende mejor si dejas de imaginar la red como un contrato y empiezas a verla como clima. En un sistema síncrono fuerte, el contrato dice: "todo mensaje llega antes de Δ". En uno asíncrono puro, nadie te promete nada útil sobre tiempos. DLS propone el punto intermedio que se parece más a producción: durante un rato puede llover horizontalmente, pero eventualmente aparece una ventana donde los mensajes entre réplicas correctas llegan dentro de un límite razonable.
Ese "eventualmente" es GST. Lo importante es que las réplicas no saben cuándo ocurrió. Si lo supieran, el problema sería más cómodo: esperarían hasta GST y listo, cafecito. Como no lo saben, usan timeouts, rondas y cambios de líder para tantear el terreno. Un timeout no prueba que alguien sea bizantino; solo dice que, desde la silla de esa réplica, el mundo no respondió a tiempo.
Por eso la sincronía parcial es tan útil para HotStuff. Permite diseñar protocolos cuya seguridad no depende del reloj, pero cuyo progreso sí se activa cuando la red deja de comportarse como una licuadora con Wi-Fi. [1] [2]
Invariante: safety no debe pedirle permiso al reloj
El invariante fuerte es este: aunque la red esté antes de GST, aunque los mensajes lleguen tarde y aunque las réplicas sospechen falsamente del líder, el protocolo no debe finalizar dos historias incompatibles. Safety es una propiedad de todos los prefijos finitos de una ejecución. Si se rompe en el segundo 17, ya no sirve decir "pero en el segundo 80 la red se estabilizaba". El daño ya ocurrió.
Liveness sí tiene otra naturaleza. Para que el sistema avance, necesita que suficientes mensajes correctos lleguen, que haya un líder correcto durante una ventana útil y que el pacemaker no mantenga a las réplicas corriendo en círculos. Por eso los papers separan con tanto cuidado "nunca decide mal" de "eventualmente decide". En una buena explicación de HotStuff, estas dos garantías no se mezclan en una sopa.
Quórums sostienen el lado de safety: la intersección obliga a que la memoria honesta cruce certificados. GST sostiene el lado de liveness: después de estabilizarse la red, esa memoria puede circular a tiempo.
Escenario adversarial: timeouts que parecen evidencia
Supón que el líder es correcto, pero la red retrasa sus mensajes a un subconjunto de réplicas. Algunas ven una propuesta válida; otras disparan timeout y pasan a la siguiente vista. Si el protocolo tratara cada timeout como prueba de corrupción, castigaría a nodos correctos por culpa de la red. Peor aún: podría hacer que grupos distintos avancen con percepciones incompatibles.
La defensa no es ignorar timeouts; sin timeouts nunca escaparías de un líder muerto. La defensa es hacer que el timeout solo cambie el ritmo del protocolo, no la verdad de las decisiones. Una réplica puede sospechar, moverse de vista y enviar evidencia al próximo líder, pero no debería borrar su lock ni votar por una rama incompatible solo porque se impacientó. El reloj ayuda a buscar progreso; no autoriza a romper safety.
Este patrón se repite en HotStuff: un pacemaker puede mover vistas, pero la seguridad vive en la evidencia certificada. Si alguna explicación convierte el pacemaker en el guardián de safety, sospecha. El pacemaker toca la campana; los QCs y locks deciden qué caminos son seguros. [2]
Cómo leer el paper desde aquí
Cuando un paper dice "partial synchrony", identifica cuál de estas preguntas responde:
- ¿Existe un límite de entrega pero no se conoce?
- ¿El límite se conoce, pero solo vale después de un tiempo desconocido?
- ¿La seguridad vale siempre o solo después de estabilización?
- ¿La terminación/progreso depende de un líder correcto, de aleatoriedad, de fallback asíncrono o de un pacemaker específico?
En DLS, busca la separación entre safety y termination. [1] En HotStuff, lee responsiveness como una propiedad posterior a estabilización: si el líder correcto puede recolectar votos rápido, no debería esperar el timeout máximo. [2] Para comparar esa promesa con PBFT, Tendermint y HotStuff-2, usa la lectura comparativa como mapa, no como reemplazo del paper primario. [3] Para analizar qué ocurre cuando el adversario manipula el retardo, contrasta además con el estudio específico de responsiveness encadenada. [4]
La frase operativa es: los relojes ayudan a vivir; los quórums ayudan a no mentir.
Una buena lectura práctica consiste en dibujar dos líneas: arriba, lo que el protocolo promete incluso si la red está insoportable; abajo, lo que promete cuando la red mejora. Si un argumento de liveness se cuela en la línea de safety, hay olor a bug. Si un argumento de safety depende de "esperemos un poquito más", también. Esa separación mental es pequeña, pero evita una cantidad absurda de malentendidos.
Bibliografía académica
- [1]
C. Dwork, N. Lynch, and L. Stockmeyer, "Consensus in the Presence of Partial Synchrony," Journal of the ACM, vol. 35, no. 2, pp. 288-323, 1988.
Base formal para GST, sincronía parcial y progreso eventual.
- [2]
M. Yin, D. Malkhi, M. K. Reiter, G. G. Gueta, and I. Abraham, "HotStuff: BFT Consensus in the Lens of Blockchain," in Proc. PODC, 2019.
Usa sincronía parcial para razonar sobre responsiveness y view-change.
- [3]
D. Malkhi and K. Nayak, "What is the difference between PBFT, Tendermint, HotStuff, and HotStuff-2?," Decentralized Thoughts, 2023.
Resumen técnico útil para contrastar familias BFT sin perder el modelo.
- [4]
H. Tang et al., "Unraveling Responsiveness of Chained BFT Consensus with Network Delay," arXiv:2501.03695, 2025.
Análisis de responsiveness encadenada bajo retardos de red adversariales.
Rutas vecinas
Si este tema te abrió hambre, sigue por aquí.
Series y labs que comparten área o dependen de esta ruta. Pocas opciones, para no convertir la curiosidad en menú infinito.
Labs para convertir lectura en práctica
Sigue leyendo
Ideas conectadas con este artículo
Una ruta corta para continuar sin abrir veinte pestañas y perder el hilo.
Consenso BFT desde cero: réplicas, quórums y fallas bizantinas
Primer paso de la serie HotStuff: qué problema resuelve BFT, por qué aparece n >= 3f + 1 y cómo separar safety de liveness sin drama matemático.
Fast-HotStuff: dos cadenas, AggQC y la letra pequeña
Por qué Fast-HotStuff intenta reducir latencia, cómo usa AggQC para probar highQC en cambios de vista y qué trade-offs aparecen en firmas agregadas.
HotStuff multipipeline: de fases a cadena viva
Cómo Chained HotStuff convierte prepare, pre-commit, commit y decide en una línea temporal de vistas, GenericQC y commits por profundidad de cadena.
HotStuff: QC, highQC y la regla de tres cadenas
El núcleo visual de HotStuff: cómo una propuesta se convierte en QC, por qué highQC guía al líder y cuándo una cadena certificada permite comprometer un bloque.