Uno, dos y tres chains: la taxonomía de commit antes de HotStuff

Antes de entrar a highQC, multipipeline o Fast-HotStuff conviene hacer una pausa. Pequeña, pero necesaria. En consenso BFT hay una pregunta que parece doméstica y termina siendo estructural: ¿cuántas evidencias consecutivas necesita un protocolo antes de decir “esto ya no se mueve”? [5]

Esa pregunta es la taxonomía de commit. Si la saltas, HotStuff aparece como una criatura extraña que pide tres cadenas porque sí. Si la miras con calma, el diseño empieza a ordenar la habitación: una cadena da intuición, dos cadenas reducen latencia bajo ciertas reglas, tres cadenas compran una forma limpia de safety, responsiveness y view-change lineal. [1] [5]

Este artículo es un puente. Viene después de PBFT, Tendermint y Streamlet y de locks/unlocks, y prepara el terreno para QC/highQC. Es decir: no estamos agregando teoría por deporte. Estamos poniendo piso para que los siguientes diagramas no parezcan una pizarra caída del cielo.

Comparación

Tres formas de mirar el commit

One-chain

Una certificación sobre una propuesta ya empuja decisión o casi decisión.

Ventaja

latencia baja

Riesgo

reglas extra de lock

• útil como intuición inicial
• delicado cuando hay líder equivocado o red adversarial

Two-chain

Dos bloques certificados consecutivos bastan si el protocolo carga evidencia adicional.

Ventaja

commit más corto

Costo

pruebas más ricas

• aparece en variantes rápidas
• obliga a cuidar view-change y selección de punta

Three-chain

Tres certificaciones consecutivas permiten comprometer el abuelo con una regla uniforme.

Ventaja

simplicidad modular

Costo

una fase lógica más

• base mental de Chained HotStuff
• facilita pipeline y cambio de vista lineal

Figura 1

Cuatro lentes para leer el commit

Fuentes:[1][2][3][5]

📖 Cómo leer esta figura (Detalle explicativo)

La cuadrícula compara cuatro modelos de izquierda a derecha dentro de cada panel. DLS usa una certificación y exige disciplina externa de lock; PBFT encadena prepare y commit y conserva un expediente de vista; Tendermint combina dos quórums con locks, validRound y espera; HotStuff acumula tres enlaces QC consecutivos para comprometer un ancestro. Los paneles son lentes conceptuales, no equivalencias exactas de mensajes.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en pestaña nueva

La idea base: commit no es votar bonito

En un sistema normal, “votar” suena a elegir. En BFT, votar es más duro: una firma es una promesa verificable que puede quedar registrada para siempre. Cuando una réplica firma una propuesta, no solo dice “me gusta”. Dice: “según lo que he visto, esta propuesta no viola mi lock ni la evidencia segura conocida”.

Por eso el commit no puede depender de una emoción del líder. Necesita una regla mecánica. Y esa regla debe sobrevivir a tres molestias: líderes malos, mensajes retrasados y réplicas bizantinas que pueden firmar con intención torcida si el protocolo se los permite.

La aritmética de quórums ya nos dijo algo importante: dos quórums de 2f + 1 dentro de 3f + 1 se intersectan en al menos una réplica correcta. Pero esa intersección por sí sola no finaliza una historia. Falta saber qué prometió esa réplica correcta y cuándo una promesa anterior bloquea una historia incompatible. [1]

Ahí entra la taxonomía. Una regla one-chain intenta finalizar rápido, pero necesita condiciones estrictas para que el voto no se contradiga luego. Una regla two-chain reduce espera, pero normalmente debe transportar evidencia adicional en view-change. Una regla three-chain hace una apuesta pedagógicamente más limpia: si ves tres bloques certificados consecutivos, el abuelo queda protegido por suficiente continuidad de evidencia.

Figura 2

La regla visual de tres cadenas

Fuentes:[5]

📖 Cómo leer esta figura (Detalle explicativo)

Cada bloque apunta a su padre y lleva un QC que certifica esa relación. El primer bloque inicia continuidad, el segundo protege al padre y el tercero permite comprometer al abuelo. Las alturas y QCs deben ser consecutivos: tres cajas próximas sin relación padre-hijo no satisfacen la regla.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en pestaña nueva

One-chain: tentador, pero pide disciplina

La versión más agresiva del commit sería: “si tengo suficiente apoyo para un bloque, lo finalizo”. Es una intuición natural. Si 2f + 1 firmaron, ¿por qué esperar? La respuesta corta es que un quórum certificado prueba apoyo, pero no siempre prueba que el sistema no pueda ver otra historia compatible con locks anteriores.

En protocolos con una cadena, la carga conceptual se mueve a otra parte. Debes tener reglas de propuesta, validación y lock muy precisas. Si un líder puede hacer equivocation o si las réplicas pueden moverse a una rama alternativa sin evidencia de desbloqueo, la finalización rápida se vuelve peligrosa.

Esto no hace inútil la idea one-chain. Hace que sea una zona de diseño con dientes. En sistemas muy controlados, con supuestos fuertes o con componentes adicionales, se puede buscar menor latencia. Pero cuando estás enseñando HotStuff desde cero, one-chain no es el mejor punto de partida. Te deja mirando el truco sin ver la cuerda que lo sostiene.

Two-chain: el deseo razonable de recortar latencia

Two-chain es más interesante. No dice “finalicemos con cualquier firma”, sino “si logramos dos niveles de certificación y cargamos la evidencia correcta, quizá no necesitemos esperar una tercera fase lógica”. Este es el mundo donde empiezan a aparecer variantes como Fast-HotStuff, Jolteon/Ditto y discusiones modernas sobre dos fases.

La trampa de two-chain es pensar que todo se simplifica. En realidad, muchas veces simplificas el camino feliz y complicas el camino infeliz. Si la red está bien y el líder es correcto, reducir una fase puede bajar latencia. Pero si hay timeout, líder terco o propuestas sobre puntas viejas, necesitas demostrar que la nueva propuesta extiende la evidencia correcta. No basta con que el líder diga “este era mi highQC, confía”.

Por eso two-chain y AggQC son pareja natural en ciertos diseños. El protocolo recorta distancia, pero cuando cambia la vista debe cargar una prueba agregada de lo que el quórum vio. En otras palabras: la tercera cadena no desaparece gratis; parte de su seguridad se convierte en evidencia adicional. [5]

Three-chain: más lento en papel, más ordenado para enseñar

HotStuff básico prefiere la claridad de tres cadenas. Un bloque se compromete cuando hay una cadena certificada de tres bloques consecutivos que lo extiende. A nivel visual, eso se lee así: B1 <- B2 <- B3, con QCs en los enlaces, permite comprometer B1 o su ancestro según la formulación usada. [5]

¿Por qué eso ayuda? Porque el protocolo puede tratar cada vista de forma genérica. Un líder propone extendiendo el highQC; las réplicas votan si la propuesta respeta reglas de seguridad; el líder agrega votos en un QC; el siguiente líder continúa. La fase no vive tanto en nombres de mensajes distintos, sino en la profundidad certificada de la cadena.

Esa uniformidad abre la puerta al multipipeline. Si cada vista ejecuta el mismo patrón, las fases se solapan sobre alturas distintas. La vista actual prepara un bloque y al mismo tiempo contribuye a pre-commit, commit o decide de ancestros. Esa es la elegancia de Chained HotStuff: la receta deja de ser una escalera manual y se vuelve una cinta transportadora con invariantes. [5]

Matriz de Decisión

Cómo elegir la lectura correcta

Reglas de Decisión Rápida

¿El commit aparece con una sola certificación?Busca locks, valid rounds, evidencia de desbloqueo y restricciones de propuesta.

Trátalo como one-chain con reglas externas fuertes.

¿El camino feliz finaliza en dos niveles?Mira qué prueba se exige durante timeout o view-change.

Léelo como two-chain con costo desplazado al camino infeliz.

¿La seguridad se explica por tres bloques certificados consecutivos?Verás QC, highQC y commit por profundidad de cadena.

Estás en el modelo mental de HotStuff básico.

Profundización conceptual

Modelo mental: cada cadena compra una promesa adicional

Piensa en una cadena certificada como una pila de promesas. Una promesa sola dice: “un quórum vio esto”. Dos promesas consecutivas dicen: “un quórum vio esto y luego otro quórum aceptó extenderlo”. Tres promesas dicen algo más fuerte: “hubo suficiente continuidad para que abandonar el ancestro requiera contradecir evidencia que al menos una réplica correcta no debería contradecir”. [3] [4] [5]

No es una metáfora perfecta, pero sirve. El protocolo no confía en la buena memoria del cluster. Confía en objetos verificables: votos, QCs, locks, highQC, timeout certificates, aggregate proofs. Cuando la cadena crece, esos objetos se acumulan de forma que una historia incompatible tendría que atravesar la intersección de quórums.

La palabra clave aquí es continuidad. BFT no solo quiere mayoría; quiere continuidad verificable entre vistas.

Invariante: un commit seguro debe resistir una historia alternativa

El invariante que debes buscar es este: si un bloque se considera finalizado, ninguna ejecución válida del protocolo debería poder finalizar un bloque conflictivo. Para que eso funcione, las réplicas correctas no pueden firmar alegremente dos ramas incompatibles después de quedar bloqueadas. Y si se desbloquean, debe ser por evidencia más fuerte, no por cansancio.

En Tendermint, eso se ve en validRound, locks y reglas de unlock. [3] En HotStuff, eso se ve en highQC y en la regla de extensión segura. [5] En Fast-HotStuff, se ve en AggQC cuando la vista cambia después de timeout. Los nombres cambian, el instinto es el mismo: no dejes que un líder use una historia vieja o ambigua para arrastrar el sistema.

Escenario adversarial: el líder propone desde una punta legal pero floja

Imagina que varias réplicas vieron un QC alto, pero el nuevo líder propone extendiendo un QC más viejo. La propuesta quizá no sea conflictiva de inmediato. Puede incluso ser “legal” bajo una regla débil. El problema es de progreso y de calidad de la historia: el sistema empieza a caminar sobre una rama menos útil, desaprovecha evidencia reciente y puede caer en ataques de rendimiento.

Con three-chain, la regla uniforme y el highQC reducen ese margen. [5] Con two-chain, necesitas demostrar mejor qué highQC vio el quórum. Por eso la taxonomía no es solo safety: también afecta performance, view-change y complejidad operativa.

Cómo leer los próximos artículos

Cuando leas QC/highQC, pregunta: “¿qué promesa representa este certificado?”. Cuando leas multipipeline, pregunta: “¿qué fase lógica está empujando esta altura?”. Cuando leas Fast-HotStuff, pregunta: “¿qué evidencia compensa haber recortado camino?”. Si vienes de PBFT, busca cómo el expediente de view-change se transforma en certificados portables. [2] [5]

Si mantienes esas tres preguntas, la serie deja de sentirse como una lista de papers y empieza a parecer un mapa. Y ese es el punto: no memorizar nombres, sino reconocer estructuras.

Referencias

Bibliografía académica

Formato IEEENumerado para ingeniería, sistemas y protocolos.

1. [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.

   PaperID: BFT-DLS-1988🔗 Abrir fuente

   Base para entender por qué el progreso requiere supuestos temporales y por qué no basta con contar votos.

2. [2]

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

   PaperID: BFT-PBFT-1999🔗 Abrir fuente

   Referencia clásica para fases pre-prepare/prepare/commit y quórums BFT prácticos.

3. [3]

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

   PaperID: BFT-TENDERMINT-2018🔗 Abrir fuente

   Ayuda a conectar locks, rondas y finality blockchain antes de HotStuff.

4. [4]

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

   PaperID: BFT-STREAMLET-2020🔗 Abrir fuente

   Puente pedagógico para leer commits por cadenas certificadas.

5. [5]

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

   PaperID: HOTSTUFF-2019🔗 Abrir fuente

   Fuente primaria para QC, highQC, three-chain commit y Chained HotStuff.