Tendermint visto desde HotStuff: locks, unlocks y evidencia

Tendermint suele enseñarse como una secuencia de rondas: propose, prevote, precommit, commit. [1] HotStuff suele enseñarse como QCs, highQC, locks y cadenas. [4] Si los miras por separado, parecen familias distintas. Si los miras con paciencia, ambos están obsesionados con la misma pregunta: ¿qué evidencia permite avanzar sin romper safety?

El artículo de xufeisofly sobre Tendermint desde HotStuff es valioso porque no se queda en “Tendermint tiene locks”. Pregunta qué lógica hay debajo: por qué un validador queda bloqueado, cuándo puede desbloquear, cómo rota el proposer, qué papel tiene la evidencia y por qué slashing no es un accesorio legalista sino parte del sistema de incentivos. [3]

Este post cierra la expansión avanzada de la serie porque Tendermint es un espejo útil. Nos ayuda a releer HotStuff sin dogma. Muchas ideas que en HotStuff aparecen como lockedQC, highQC o chain commit tienen parientes conceptuales en LockedValue, LockedRound y ValidRound.

Figura 1

Locks y unlocks: la coreografía mínima

Fuentes:[1][2]

📖 Cómo leer esta figura (Detalle explicativo)

Lee de izquierda a derecha por rondas. En la primera, suficientes prevotes generan un lock sobre B1; en la segunda, una propuesta distinta solo puede progresar si demuestra una ronda válida superior; en la tercera, la evidencia común permite que 2/3+ converjan y hagan commit. Las flechas representan el cambio de estado condicionado por evidencia, no un desbloqueo por timeout solamente.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en pestaña nueva

Secuencia temporal

Tendermint: lock y unlock a través de rondas

Actor1Propuesta r2Prevote3Precommit4Ronda r+1

Proposer

Proposal(B,r)incluye validRound

Proposal(B′)debe superar locks

Validadores

2f + 1 prevotesB reúne apoyo

precommit(B)crea lock local

Estado seguro

LockedValue=BLockedRound=r

ValidRound ≥ runlock verificable

Lectura: El unlock nace de evidencia superior, no del cansancio ni del reloj.

Lock no significa “para siempre”

Un lock es una promesa local condicionada por evidencia. Si un validador ve suficientes prevotes por un valor B en una ronda, puede quedar bloqueado: no debería votar por valores conflictivos sin una razón fuerte. Esa razón fuerte es la que evita que el protocolo decida dos historias incompatibles. [1] [2]

Pero si el lock fuera absoluto, el protocolo podría morir. Supón que algunos validadores quedan bloqueados en B1, pero no se logra commit porque la red falla. En rondas posteriores, si nadie puede desbloquear con evidencia superior, liveness queda atrapada. Tendermint necesita ValidRound y reglas de unlock para que una propuesta pueda convencer a validadores bloqueados sin abrir la puerta a conflictos inseguros. [2]

HotStuff resuelve el mismo drama con otro vocabulario. Una réplica mantiene locks y evalúa si una propuesta es segura respecto a su lockedQC. El líder intenta proponer extendiendo highQC. Si el sistema cambia de vista, debe transportar evidencia para no proponer sobre una rama insegura. [4]

La diferencia de lenguaje no debe distraer: ambos protocolos negocian entre memoria de seguridad y necesidad de progreso.

Proposer rotation, evidence y slashing

La rotación de proposer en Tendermint no es solo reparto de turnos. Es parte de la resiliencia operacional. Si un proposer falla o actúa mal, la ronda puede avanzar. Si un validador firma dos cosas incompatibles, aparece evidencia. Si el sistema económico castiga esa evidencia, el protocolo no solo espera honestidad; la incentiva. [3]

Aquí se ve una diferencia de foco con muchos papers de consenso. El paper formal te dice bajo qué supuestos el protocolo mantiene safety/liveness. La implementación blockchain necesita además:

• identificar firmas conflictivas;
• propagar evidencia;
• almacenarla durante una ventana válida;
• castigar según reglas económicas;
• evitar que el castigo se vuelva una fuente nueva de ataques.

HotStuff-like systems también necesitan pensar incentivos, aunque el paper base no siempre lo ponga en primer plano. Fast-HotStuff, por ejemplo, abre preguntas interesantes sobre aggregate signatures y visibilidad de firmantes. Si puedes saber quién votó y quién no, puedes diseñar incentivos o penalizaciones distintas. Si la agregación oculta demasiado, el protocolo puede ser seguro pero pobre para accountability.

Profundización conceptual

Modelo mental: locks como memoria segura

Un lock es memoria. No memoria de “me gustó este bloque”, sino memoria de “vi suficiente evidencia para no traicionar esta rama a la ligera”. Esa memoria protege contra líderes que intentan reescribir la historia con propuestas seductoras pero débiles.

En Tendermint, LockedValue y LockedRound capturan esa memoria. En HotStuff, lockedQC cumple un rol análogo. [2] [4] El lector puede mapear:

• prevote/precommit con votos y certificados;
• ValidRound con evidencia que permite una propuesta segura;
• LockedValue con estado local de safety;
• highQC con evidencia de mayor vista que orienta al líder.

No son equivalencias perfectas. Son puentes pedagógicos. Y un puente bien usado evita que el lector memorice nombres sin entender presión de diseño.

Invariante: no desbloquear por optimismo

El invariante es que un validador no debe abandonar un lock solo porque apareció una propuesta nueva. Debe existir evidencia de ronda suficiente para justificar el cambio. Si desbloqueas por entusiasmo, puedes votar por conflictos. Si nunca desbloqueas, puedes matar liveness.

Esta tensión es el corazón de muchos protocolos BFT: safety quiere memoria; liveness quiere movimiento. El arte está en definir qué evidencia permite moverse.

HotStuff lo empaqueta en highQC y reglas de voto. Tendermint lo expresa con valid rounds y locks. Ambos tienen que sobrevivir a la misma familia de adversarios: líderes caídos, mensajes retrasados, validadores equivocados o bizantinos y particiones temporales.

Escenario adversarial: el valor que casi se compromete

Imagina que en Round 1 tres validadores prevotean B1, pero el precommit completo no llega a todos. Algunos quedan bloqueados. Round 2 empieza con otro proposer que quiere B2. Si B2 no trae evidencia suficiente, los bloqueados deben resistir. Si resisten todos, quizá no hay progreso. Si aceptan sin evidencia, safety peligra.

La regla de unlock resuelve el punto medio: solo una propuesta respaldada por una ronda válida suficientemente fuerte puede arrastrar a los bloqueados. Ese mecanismo no es un detalle; es el cable que mantiene unida la promesa de safety con la necesidad de salir del atasco. [1] [2]

En HotStuff, la escena análoga aparece cuando el nuevo líder recolecta new-view y elige highQC. El líder no “borra memoria”; la transporta. Esa frase debería quedar como regla mental para toda la serie.

Cómo leer el paper y el artículo

Lee Tendermint en capas. Primero identifica la secuencia propose/prevote/precommit. Después marca dónde nace el lock. Luego pregunta qué evidencia permite unlock. Finalmente mira proposer rotation, evidence y slashing como capas de ingeniería, no como notas al pie.

El artículo de xufeisofly ayuda a hacer esa lectura desde implementación: locks, proposer rotation y slashing aparecen como piezas del sistema real. [3] El whitepaper de Tendermint y los trabajos posteriores sostienen el marco. [1] [2] El artículo previo de esta serie sobre PBFT/Tendermint/Streamlet sirve como entrada suave; este cierra el círculo con lectura operacional.

La conclusión no es que Tendermint “sea HotStuff viejo” ni que HotStuff “reemplace Tendermint”. La conclusión buena es más fina: ambos diseñan memoria segura bajo red imperfecta. Cambian las piezas, pero la presión es la misma.

Una última forma de estudiarlo: dibuja dos columnas. En la izquierda pon el lenguaje Tendermint: round, prevote, precommit, LockedValue, ValidRound. En la derecha pon el lenguaje HotStuff: view, vote, QC, lockedQC, highQC. Luego une solo las ideas, no los nombres. Verás que los protocolos no son clones, pero sí responden a preguntas hermanas. Esa tabla mental ayuda a evitar dos errores: creer que todo BFT moderno es HotStuff con disfraz, o creer que cada nombre nuevo inventa un universo desde cero.

Si después quieres bajar esto a laboratorio, prueba doble firma y proposer caído antes de probar throughput. Primero verifica que evidence se captura, que el lock no se pierde y que el nodo correcto no vota dos historias. La velocidad viene después; safety primero, como buen cinturón de seguridad.

Referencias

Bibliografía académica

Formato IEEENumerado para ingeniería, sistemas y protocolos.

1. [1]

   J. Kwon, "Tendermint: Consensus without Mining," 2014.

   WhitepaperID: TENDERMINT-NO-MINING-2014🔗 Abrir fuente

   Fuente base para la lectura de rondas, prevote, precommit y consenso sin minería.

2. [2]

   E. Buchman, J. Kwon, and Z. Milosevic, "The latest gossip on BFT consensus," arXiv:1807.04938, 2018.

   PaperID: BFT-TENDERMINT-2018🔗 Abrir fuente

   Referencia formal para Tendermint y su análisis BFT.

3. [3]

   xufeisofly, "从 HotStuff 回看 Tendermint (三)," Saliva Group, 2024.

   Engineering noteID: TENDERMINT3-XUFEI-2024🔗 Abrir fuente

   Referencia secundaria para locks, proposer rotation, evidence y slashing desde una lectura de implementación.

4. [4]

   M. Yin, D. Malkhi, M. K. Reiter, G. G. Gueta, and I. Abraham, "HotStuff: BFT Consensus in the Lens of Blockchain," arXiv:1803.05069, 2018.

   PaperID: HOTSTUFF-2019🔗 Abrir fuente

   Base para comparar locks, highQC y reglas de voto desde la familia HotStuff.