View-change en HotStuff: pacemaker, timeouts y líderes tercos

Un líder puede fallar de muchas formas. Puede caerse. Puede proponer tarde. Puede proponer dos cosas. Puede mirar al vacío como si estuviera esperando inspiración divina.

El protocolo no puede quedarse ahí contemplando el drama. Necesita cambiar de vista.

El pacemaker no decide, coordina

HotStuff suele separarse en dos piezas: [1]

• el core consensus, que define cuándo votar, formar QCs y comprometer bloques;
• el pacemaker, que ayuda a las réplicas a moverse de una vista a otra.

Esa separación es sanísima. El consenso protege safety. El pacemaker empuja liveness. Si los mezclas demasiado, terminas con un protocolo que funciona... hasta que alguien lo implementa.

Figura 1

View-change guiado por highQC

Fuentes:[1]

📖 Cómo leer esta figura (Detalle explicativo)

El timeout mueve a las réplicas a una nueva vista. Cada una envía su QC más alto al líder entrante; el líder espera 2f + 1 mensajes, verifica firmas y membresía, selecciona el highQC de mayor vista y propone un hijo suyo. Las réplicas aceptan solo si la propuesta satisface safeNode respecto de su lock local.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en pestaña nueva

New-view: llevar evidencia al nuevo líder

Cuando una réplica entra a una nueva vista, envía un mensaje new-view al líder de esa vista. Ese mensaje incluye el QC más alto que conoce. [1]

El líder reúne suficientes mensajes, elige el highQC y propone un bloque que extiende esa evidencia. [1]

La diferencia con diseños más antiguos es el sabor de la evidencia. En vez de arrastrar un expediente enorme de estados parcialmente preparados, HotStuff intenta que el QC y la cadena carguen lo esencial.

Timeout certificates

En implementaciones modernas aparece otro objeto útil: el Timeout Certificate. Un TC prueba que suficientes réplicas abandonaron una vista. No reemplaza el QC: complementa la coordinación para que las réplicas no queden dispersas en vistas distintas. [2] [3]

No todos los papers presentan exactamente los mismos detalles de pacemaker. Esta es una zona donde producción, teoría y ergonomía se cruzan. Por eso conviene leer el paper original junto con DiemBFT/Jolteon más adelante. [1] [2] [3]

Qué pasa si el líder nuevo también falla

Se repite el proceso. Timeouts, nueva vista, nuevo líder, evidencia más alta. Esto puede sonar lento, pero HotStuff busca que el costo del cambio de líder sea lineal en comunicación durante el diseño original, una diferencia crucial frente a view-changes más pesados. [1]

El protocolo no promete que un líder malo sea productivo. Promete que un líder malo no debería poder romper safety y que, bajo sincronía parcial, eventualmente un líder correcto podrá avanzar.

La idea que te llevas

El view-change de HotStuff es menos una "elección política" y más un traspaso de expediente:

aquí está la evidencia más alta que conocemos; propón desde ahí o no te voto.

Con eso listo, ya podemos separar las tres palabras que más se mezclan en discusiones de consenso: safety, liveness y responsiveness.

Profundización conceptual

Modelo mental: el pacemaker toca la campana

El pacemaker no es el juez del protocolo; es el metrónomo. Su trabajo es lograr que suficientes réplicas miren la misma vista durante el tiempo suficiente para que un líder correcto pueda recolectar votos. Si el pacemaker se mueve demasiado lento, el sistema se queda mirando líderes muertos. Si se mueve demasiado rápido, las réplicas viven desfasadas y ningún líder alcanza a juntar evidencia.

La parte elegante de HotStuff es separar ese ritmo de la regla de safety. El core consensus dice qué propuestas son votables y cuándo un bloque queda comprometido. El pacemaker ayuda a que las réplicas lleguen al lugar donde esa regla puede ejecutarse. Esta separación es una señal de buen diseño: una pieza empuja progreso; la otra preserva memoria.

En producción, el pacemaker se vuelve más áspero. Hay latencias reales, relojes imperfectos, nodos que reinician, validadores bajo DDoS y operadores con café tibio. Por eso DiemBFT, Jolteon y Ditto afinan esta zona con timeout certificates, reputación de líder o fallback. [2] [3]

Invariante: el nuevo líder hereda evidencia

El invariante del view-change es: una nueva vista no empieza desde cero. El líder nuevo debe recolectar mensajes de suficientes réplicas y proponer usando la mejor evidencia segura que aparece en esa colección. Si ignora el highQC, las réplicas correctas deberían rechazar la propuesta. [1]

La razón vuelve a ser intersección de quórums. Si una decisión antigua estaba suficientemente avanzada, al menos una parte de esa memoria aparece en réplicas correctas. Al reunir 2f + 1 mensajes new-view, el nuevo líder intersecta con quórums relevantes del pasado. No obtiene una bola de cristal, pero sí una muestra BFT suficientemente fuerte para no actuar como turista perdido.

Este invariante también explica por qué el new-view no es "hola, estoy vivo". Es un mensaje con equipaje: lleva el QC más alto conocido. El protocolo necesita ese equipaje para que la libertad del nuevo líder no se convierta en impunidad.

Escenario adversarial: vistas dispersas y líder terco

Supón que un líder bizantino retrasa propuestas a algunas réplicas y envía propuestas conflictivas a otras. Un grupo hace timeout y avanza; otro se queda esperando porque sí recibió algo; un tercero está atrasado por red. Ahora el siguiente líder recibe evidencia incompleta y el adversario intenta que proponga sobre una rama baja, donde puede montar un fork.

Un view-change sano hace dos cosas. Primero, junta suficientes new-view para que no dependa de una minoría ruidosa. Segundo, elige el QC de vista más alta entre lo recolectado. Esto no garantiza que el líder sea honesto, pero sí da a las réplicas una regla local para validar: si el líder no extiende la evidencia que debería extender, no recibe votos correctos.

Los timeout certificates ayudan con otra parte del drama: alinear a las réplicas sobre el hecho de que una vista murió. No deciden bloques; coordinan movimiento. Si confundes TC con QC, mezclas sincronización con seguridad y el protocolo empieza a sonar más simple de lo que realmente es. [2] [3]

Cómo leer el paper

En el paper de HotStuff, lee el view-change buscando qué información se preserva, no solo qué mensajes se mandan. Pregunta: [1]

1. ¿qué incluye una réplica en new-view?;
2. ¿cuántos mensajes espera el nuevo líder?;
3. ¿cómo se calcula highQC?;
4. ¿qué condición verifica una réplica antes de votar por la nueva propuesta?;
5. ¿qué parte pertenece al core consensus y qué parte queda al pacemaker?

Después compara con DiemBFT/Jolteon. Ahí verás que el paper original deja espacio de diseño alrededor del pacemaker. Eso no es una debilidad; es una frontera práctica. Distintas implementaciones pueden elegir cómo manejar timeouts, reputación de líder y coordinación de vista, mientras no traicionen el invariante central: el nuevo líder debe cargar la memoria segura del sistema. [2] [3]

La lectura madura de view-change es esta: cambiar de líder no es pasar página; es pasar expediente.

También conviene leer los diagramas de view-change de derecha a izquierda. No empieces preguntando "¿quién es el próximo líder?". Empieza preguntando "¿qué decisión antigua podría estar en riesgo si el próximo líder propone mal?". Luego mira qué mensaje evita ese riesgo. Esa inversión cambia la lectura: el new-view deja de parecer trámite y se vuelve una cadena de custodia.

En labs futuros, esta idea se puede convertir en prueba: simula un líder que omite el QC más alto conocido y verifica que las réplicas correctas rechacen la propuesta. Si el test pasa, no probaste todo HotStuff, pero sí probaste una de sus costillas.

La otra prueba útil es de coordinación: fuerza timeouts parciales y comprueba que un TC solo mueva vistas, no que autorice una rama insegura. Esa distinción mantiene limpio el diseño: TC para juntarnos en la siguiente sala; QC/highQC para decidir qué historia llevamos bajo el brazo.

Si esa frase se mantiene en tu cabeza, el pacemaker deja de parecer magia negra y empieza a parecer ingeniería de tráfico.