Safety, liveness y responsiveness en HotStuff

En consenso distribuido hay tres palabras que suelen aparecer juntas y confundidas: safety, liveness y responsiveness. Mezclarlas es la forma más rápida de sonar seguro diciendo algo falso. [1] [2]

Vamos por partes.

Safety: el protocolo se niega a olvidar

Safety en HotStuff depende de reglas de voto, locks, QCs e intersección de quórums. Si una réplica correcta vota siguiendo las reglas, no debería ayudar a certificar dos ramas incompatibles. [1]

La razón de fondo vuelve a ser la misma:

Dos certificados válidos se cruzan en al menos f + 1 réplicas. Como solo f pueden ser bizantinas, una correcta está en el cruce. Esa réplica correcta es el hilo de memoria que impide que el sistema se contradiga.

Liveness: eventualmente, no inmediatamente

Liveness necesita que la red deje de portarse como duende. En sincronía parcial, después de GST hay un límite realista para mensajes entre réplicas correctas. El pacemaker ajusta vistas y timeouts hasta que un líder correcto tenga chance de reunir votos. [1]

Si la red sigue retrasando todo para siempre, ningún protocolo determinista BFT parcialmente síncrono te debe progreso infinito. Y si alguien te vende eso sin matices, cuidado: probablemente también vende café "blockchain".

Responsiveness: no esperar el peor reloj

La propiedad que hizo famoso a HotStuff es combinar linealidad y responsiveness. La idea: [1] [4]

si después de GST el líder es correcto y los mensajes llegan en δ, el protocolo avanza con δ, no esperando el timeout máximo Δ.

Figura 1

Optimistic responsiveness

Fuentes:[5][1][4]

📖 Cómo leer esta figura (Detalle explicativo)

La figura coloca GST como punto de estabilización y compara dos relojes: Δ es la espera máxima configurada, δ es el retraso observado. Cuando el líder es correcto, las respuestas de 2f + 1 réplicas permiten avanzar en δ. Si no aparece ese quórum, el pacemaker todavía usa el timeout para abandonar la vista.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en pestaña nueva

El trade-off que viene después

HotStuff usa tres fases en la versión clásica para conseguir la combinación deseada. Luego aparecen variantes que intentan reducir fases: [1] [3]

• Fast-HotStuff pregunta si la ronda adicional es necesaria en la práctica;
• Jolteon reduce latencia en un diseño 2-chain;
• HotStuff-2 muestra que dos fases pueden bastar para ciertas propiedades fuertes;
• estudios recientes modelan cuándo responsiveness ayuda y cuándo puede abrir superficies de performance attack.

Eso no invalida HotStuff. Lo vuelve más interesante. El paper original puso una base limpia; los trabajos posteriores exploran cuánto se puede apretar sin romper invariantes. [2] [3]

La versión corta

Safety protege la historia. Liveness protege el avance eventual. Responsiveness protege el camino feliz de esperas artificiales.

HotStuff es importante porque logró una combinación que antes era difícil de tener junta en un protocolo parcialmente síncrono: safety BFT, comunicación lineal, view-change manejable y progreso responsive bajo buenas condiciones. [1] [4]

Ahora sí estamos listos para mirar producción: LibraBFT/DiemBFT, Jolteon y Ditto.

Profundización conceptual

Modelo mental: tres garantías, tres enemigos

Safety pelea contra la contradicción. Su enemigo es el fork finalizado: dos historias incompatibles que ambas parecen legítimas. Liveness pelea contra el estancamiento. Su enemigo es el sistema que no decide nunca, aunque ya haya suficientes réplicas correctas intentando avanzar. Responsiveness pelea contra la espera artificial. Su enemigo es el protocolo que, incluso con red rápida y líder correcto, se queda mirando el timeout máximo como quien espera permiso de una burocracia celestial.

Esta separación ayuda porque un protocolo puede mejorar una propiedad y empeorar otra. Reducir fases puede bajar latencia, pero exigir view-change más complejo. Hacer fallback asíncrono puede mejorar robustez bajo ataques, pero agregar maquinaria. Centralizar agregación en líder puede reducir comunicación, pero hacer más sensible al líder. No hay almuerzo gratis; a veces hay menú ejecutivo, pero gratis no.

La lectura seria de un paper BFT pregunta siempre: ¿qué garantía se mantiene?, ¿bajo qué modelo?, ¿qué costo se movió a otro lado? [2]

Invariante: safety sobrevive a cualquier prefijo de ejecución

El invariante de safety es el más duro: debe valer incluso en prefijos de ejecución donde la red todavía no se estabilizó. Si dos valores incompatibles se finalizan antes de GST, la promesa está rota. No se arregla con "luego convergió". En sistemas distribuidos, un fork finalizado no es un malentendido; es una herida. [5] [1]

La forma típica de la prueba combina quórums e historia local. Si una rama obtiene suficiente evidencia, cualquier rama incompatible futura necesita cruzarse con réplicas correctas que participaron o quedaron bloqueadas por esa evidencia. La regla de voto debe impedir que esas réplicas correctas apoyen la contradicción. Por eso los proofs hablan tanto de locks, QCs y vistas: son la contabilidad de qué sabía una réplica cuando firmó.

Liveness, en cambio, no puede prometerse bajo asincronía determinista total. Necesita que la red eventualmente permita coordinación. Responsiveness añade un matiz: cuando esa coordinación ya es posible, no penalices el camino feliz esperando el peor reloj.

Escenario adversarial: responsiveness bajo delay manipulado

Imagina una red donde el adversario no puede romper firmas ni controlar más de f réplicas, pero sí puede retrasar mensajes de forma selectiva antes de GST. Puede hacer que líderes correctos parezcan lentos, que algunas réplicas cambien de vista antes que otras y que el sistema pague varios timeouts. En ese tramo, responsiveness no salva la fiesta; todavía no estamos en el clima donde la propiedad aplica.

Después de GST, el adversario ya no puede retrasar indefinidamente los mensajes correctos. Si aparece un líder correcto y las réplicas están razonablemente alineadas, HotStuff busca avanzar al ritmo real de entrega. Pero incluso ahí hay matices: un líder puede ser DDoSeado en producción, los paquetes pueden tener colas, la agregación de firmas cuesta CPU y el mempool puede ser el cuello de botella. La propiedad formal no significa "latencia cero"; significa "no esperar artificialmente Δ cuando la evidencia ya llegó". [1] [4]

Esta diferencia es vital para leer benchmarks. Una curva de latencia no prueba por sí sola una propiedad de responsiveness; puede estar midiendo implementación, red, batching, firma agregada, mempool o hardware.

Cómo leer claims de performance

Cuando un paper o post diga "más rápido que HotStuff", hazle cuatro preguntas:

1. ¿Está comparando camino feliz, líder fallido o peor caso?
2. ¿Mantiene safety bajo el mismo modelo de fallas?
3. ¿La mejora reduce fases, cambia view-change, usa fallback o mueve costo al líder?
4. ¿El experimento mide consenso puro o incluye mempool, ejecución y red?

HotStuff es famoso por combinar comunicación lineal, responsiveness y view-change limpio en sincronía parcial. [1] Jolteon cambia la latencia del commit con una regla 2-chain y acepta otro costo de cambio de vista. Ditto agrega una ruta para condiciones adversariales más duras. HotStuff-2 empuja la frontera de dos fases. [3] Cada uno merece leerse como un cambio de balance, no como una simple barra de velocidad.

La manera más sana de estudiar la familia es llevar una libreta de trade-offs: qué garantiza, qué asume, qué mejora y qué complica. Sí, suena menos glamuroso que "protocolo definitivo". También envejece mucho mejor.