De PBFT a cadenas: el puente mental hacia HotStuff

HotStuff no cayó del cielo con gafas de sol. Es parte de una línea de diseño: PBFT mostró que BFT podía ser práctico, Tendermint llevó esa intuición al mundo blockchain, y Streamlet ayudó a enseñar los protocolos de cadena con una simplicidad casi sospechosa. [1] [2] [3] [4]

Este post no intenta cubrir cada detalle de esos protocolos. Su trabajo es más humilde y más útil: dejarte listo para entender por qué HotStuff habla en bloques, vistas, QCs y locks.

Comparación

Tres escalones antes de HotStuff

PBFT

Replicación práctica con primario, prepare, commit y view-change.

Tendermint

Rondas blockchain con propuesta, prevote, precommit y locks.

Streamlet

Versión pedagógica para pensar en cadenas y notarización.

PBFT: el abuelo práctico

PBFT organiza una decisión con un primario que propone y réplicas que intercambian evidencia. Su camino normal suele explicarse como: [1]

Flujo visual

Camino normal de PBFT

1. 01request
2. 02pre-prepare
3. 03prepare
4. 04commit
5. 05reply

El problema no es que PBFT sea "malo". El problema es que el view-change tiene que arrastrar suficiente evidencia para no romper decisiones parcialmente preparadas. Ahí se vuelve fácil equivocarse. Y cuando un protocolo vive en blockchains con rotación frecuente de líderes, esa complejidad duele. [1]

Tendermint: locks para no firmar cualquier cosa

Tendermint acerca la conversación a blockchain: un conjunto de validadores intenta acordar el siguiente bloque. Usa rondas con prevote y precommit, y una idea central: si una réplica se bloquea sobre cierto valor, no debería votar alegremente por un valor incompatible. [2]

Eso nos prepara para una pregunta que HotStuff responde con certificados:

¿Cómo hace el nuevo líder para saber qué valor seguro debe extender?

En Tendermint, el protocolo depende más de esperas temporales. En HotStuff, la ambición es que un líder correcto pueda avanzar cuando tenga suficiente evidencia, sin esperar innecesariamente el peor timeout.

Streamlet: notarizar cadenas

Streamlet es valioso porque baja el ruido. Presenta una manera simple de pensar en bloques notarizados y commits por estructura de cadena. Si ves varias certificaciones consecutivas, puedes empezar a razonar sobre cuándo un ancestro se vuelve seguro. [3]

Línea de tiempo

Evolución de la intuición

1. 1999

   PBFT

   BFT práctico para replicación de estado

2. 2018

   Tendermint

   BFT blockchain con gossip, rondas y locks

3. 2020

   Streamlet

   modelo pedagógico de cadenas notarizadas

4. 2019+

   HotStuff

   linealidad, responsiveness y commit encadenado

Lo que HotStuff toma y reordena

HotStuff absorbe varias lecciones:

• de PBFT: no finalices sin evidencia fuerte;
• de Tendermint: locks y líderes rotativos son parte del mundo blockchain;
• de Streamlet: las cadenas certificadas pueden hacer visible el commit;
• de DLS: liveness necesita hablar de sincronía parcial, no de magia.

La diferencia está en el empaque. HotStuff usa Quorum Certificates como moneda de evidencia. Un QC dice: "suficientes réplicas votaron por esto". El highQC dice: "de todas las evidencias que conozco, esta es la de vista más alta". [4]

Ese pequeño objeto es la llave del siguiente post.

Profundización conceptual

Modelo mental: tres formas de transportar memoria

PBFT, Tendermint y Streamlet pueden leerse como tres respuestas a una misma angustia: cuando cambia el líder, ¿cómo evitamos que el nuevo líder actúe como si el pasado no hubiera existido? [1] [2] [3]

PBFT transporta memoria como expediente. El view-change debe reunir información sobre lo que estaba preparado o casi comprometido para que el nuevo primario no proponga algo que contradiga una decisión en camino. Funciona, pero el expediente puede volverse pesado. [1]

Tendermint transporta memoria como lock. Si una réplica queda bloqueada sobre un valor, no debería apoyar uno incompatible salvo que vea evidencia suficiente para desbloquear. Es una intuición muy poderosa para blockchains: no basta con que el líder proponga; las réplicas cargan memoria de rondas previas.

Streamlet transporta memoria como cadena notarizada. La evidencia aparece en bloques sucesivos. En vez de mirar solo "un voto por un valor", miras la forma de la cadena: qué bloques tienen certificación y qué ancestros quedan protegidos por certificaciones posteriores.

HotStuff toma esa familia de ideas y la comprime en QCs portables. Un QC es evidencia que el líder puede mostrar, y highQC es la mejor evidencia conocida para escoger una extensión segura. [4]

Invariante: el valor seguro sobrevive al cambio de líder

El invariante que une estos protocolos es: un cambio de líder no debe borrar la información necesaria para preservar safety. Si una propuesta llegó lo suficientemente lejos como para bloquear a réplicas correctas o formar evidencia fuerte, el próximo líder tiene que respetar esa historia.

En PBFT, el protocolo evita que un nuevo primario ignore estados preparados. En Tendermint, las reglas de lock evitan que validadores salten de rama sin justificación. En Streamlet, las notarizaciones consecutivas hacen visible qué ancestro se puede comprometer. En HotStuff, highQC resume la evidencia más alta que el líder debe extender.

La superficie cambia, pero la pregunta es la misma: ¿qué información del pasado obliga al futuro? Si un protocolo no responde eso con precisión, su view-change es una puerta abierta para bifurcaciones.

Escenario adversarial: el líder se cae justo antes del commit

Imagina que un líder correcto propuso un bloque y reunió buena parte de los votos, pero cae antes de que todos vean el commit. Algunas réplicas creen que el bloque está casi decidido; otras apenas lo vieron; unas pocas bizantinas intentan convencer al nuevo líder de empezar una rama incompatible.

PBFT resuelve esto haciendo que el view-change incluya evidencia suficiente sobre operaciones preparadas. [1] Tendermint exige que los validadores respeten locks, de modo que no voten libremente por el primer bloque bonito que aparezca en la siguiente ronda. [2] Streamlet y HotStuff empujan la memoria hacia la estructura de cadena: si hay certificaciones consecutivas, ciertos ancestros quedan protegidos. [3] [4]

Este escenario explica por qué "cambiar de líder" no es una tarea administrativa. Es el punto donde muchos protocolos se rompen. Un líder nuevo necesita libertad para recuperar liveness, pero no tanta libertad como para reescribir lo que una mayoría BFT ya dejó encaminado.

Cómo leer los papers como puente

Lee PBFT buscando dos capas: el camino normal y el view-change. El camino normal enseña prepare/commit; el view-change enseña por qué la seguridad no termina cuando falla el primario. Si solo lees la parte feliz, te quedas con el tráiler.

Lee Tendermint buscando locks, rondas y timeouts. Pregunta cuándo un validador puede cambiar de opinión y qué evidencia necesita. Esa pregunta te prepara para entender por qué HotStuff habla de safeNode y de extender el QC correcto.

Lee Streamlet buscando pedagogía de cadenas: notarización, commits por profundidad y una narrativa más limpia para razonar sobre ancestros. No lo uses como sustituto total de protocolos de producción; úsalo como gimnasio mental.

Luego entra a HotStuff con una pregunta concreta: ¿cómo convertir toda esa memoria en un objeto pequeño, verificable y fácil de pasar al siguiente líder? La respuesta empieza con QC y se vuelve interesante con highQC.

El puente mental queda así: PBFT te enseña que la memoria del protocolo importa; Tendermint te enseña que votar dos veces sin disciplina es peligroso; Streamlet te enseña que una cadena certificada puede hacer visible el commit; HotStuff intenta que todo eso viaje con menos equipaje. Si esa frase ya te suena natural, el siguiente post sobre QC/highQC deja de parecer jerga y empieza a parecer carpintería fina.

La señal de comprensión es poder explicar el cambio de líder sin usar la palabra "reiniciar". Un protocolo BFT no reinicia; hereda evidencia. Esa herencia es la bisagra entre todos estos diseños.

Referencias

Bibliografía académica

Formato IEEENumerado para ingeniería, sistemas y protocolos.

1. [1]

   M. Castro and B. Liskov, "Practical Byzantine Fault Tolerance," in Proc. OSDI, 1999.

   PaperID: BFT-PBFT-1999🔗 Abrir fuente

   Antecedente clave para prepared/committed-local y view-change.

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

   Puente hacia validadores, rondas, prevote/precommit y locks.

3. [3]

   B. Chan and E. Shi, "Streamlet: Textbook Streamlined Blockchains," IACR ePrint 2020/088, 2020.

   PaperID: BFT-STREAMLET-2020🔗 Abrir fuente

   Modelo pedagógico para pensar en cadenas notarizadas.

4. [4]

   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.

   PaperID: HOTSTUFF-2019🔗 Abrir fuente

   Reordena estas ideas alrededor de QC, highQC y commit encadenado.