HotStuff: de cero a estado del arte
Artículo 6 de 47
13%
completado al llegar aquí
Sistemas distribuidosNota de investigación14 min de lectura
Quórums en acción: ¿Por qué 2f+1 votos garantizan que las mayorías se crucen?
Por qué dos quórums de 2f+1 votos entre 3f+1 réplicas comparten al menos f+1 nodos y cómo esa réplica correcta común impide certificar bloques en conflicto.
Ruta HotStuff: 0/47
Prerequisitos recomendados
Si alguno de estos conceptos todavía está medio nebuloso, empieza por aquí. Te ahorra tropiezos y un par de cejas fruncidas.
Comprende la demostración formal de la intersección de quórums en consenso BFT: por qué la supermayoría q = 2f + 1 garantiza que dos decisiones cualesquiera compartan al menos una réplica correcta.
- Consenso BFT desde cero (bft-consensus-from-zero)
- Sincronía parcial y quórums (partial-synchrony-quorums-bft)
Detente cuando puedas demostrar algebraicamente que dos quórums de tamaño 2f + 1 en una red de 3f + 1 nodos se solapan en al menos f + 1 nodos.
Glosario de Notación Matemática y Criptográfica
Definición conceptual para n dentro del contexto de consenso BFT.
Ruta mental de la Intersección de Quórums BFT
Comité Mínimo
n = 3f + 1
Tamaño de Quórum
q = 2f + 1
Solapamiento de Quórums
2q - n = f + 1
Memoria Correcta
Al menos 1 nodo correcto
Decodificador Didáctico de Conceptos BFT
En palabras simples: Si tienes 10 palomas y 9 nidos, al menos un nido tendrá 2 palomas. En BFT, si dos grupos ocupan cada uno más de dos tercios de la red, es imposible que no compartan miembros.
Detalle técnico: Argumento combinatorio: la suma de las cardinalidades de dos quórums supermayoritarios excede el tamaño total del comité.
En palabras simples: Dos comisiones de 7 miembros en una cámara de 10 legisladores siempre comparten al menos 4 sillas. Si 3 legisladores son corruptos, la cuarta silla pertenece a un legislador honesto.
Detalle técnico: Intersección mínima |Q1 ∩ Q2| >= f + 1 que garantiza la presencia de al menos un nodo correcto en la intersección.
En Consenso BFT desde cero aparecieron tres números que se repiten en toda la literatura: réplicas, quórums de votos y la capacidad de tolerar fallas bizantinas. Memorizarlos es fácil. Saber defenderlos frente a un diseño alternativo es otra cosa, y es lo que separa a quien configura un comité de quien lo entiende.
¿Por qué exactamente ? ¿Qué se rompe si exigimos ? ¿Por qué no subir a para estar "más seguros"? Este artículo responde las tres preguntas con una sola herramienta, la inclusión-exclusión de conjuntos, y muestra cómo PBFT y HotStuff convierten esa aritmética en un invariante de safety.
Del umbral de Lamport al tamaño de quórum
El punto de partida histórico es el problema de los generales bizantinos. Lamport, Shostak y Pease demostraron que, con mensajes orales (no firmados), ningún algoritmo resuelve el acuerdo si un tercio o más de los participantes son traidores; hacen falta más de generales para tolerar traidores. [2] El mismo trabajo muestra que con mensajes firmados el umbral cambia, de modo que conviene recordar que depende del modelo y no es una constante universal. [2]
Para los protocolos que nos interesan, el modelo relevante es la sincronía parcial. Dwork, Lynch y Stockmeyer probaron que, en ese modelo y con fallas bizantinas, el consenso es posible si y solo si , incluso cuando las réplicas pueden autenticar sus mensajes. [4] Es decir, las firmas ayudan a detectar equivocaciones, pero no permiten bajar del umbral de un tercio cuando la red puede retrasar mensajes de forma arbitraria antes de estabilizarse.
PBFT tomó ese límite y lo convirtió en ingeniería: con réplicas, cada fase del protocolo avanza cuando una réplica reúne mensajes coincidentes, y ese conjunto funciona como certificado. [1] HotStuff conserva exactamente la misma regla, aunque la empaqueta en un objeto explícito: un QC es un conjunto de votos firmados sobre la misma propuesta y la misma vista. [3] Con , es precisamente .
La demostración algebraica del solapamiento
Imaginemos un conjunto de réplicas de tamaño . Supongamos que el protocolo exige formar un quórum de respuestas para validar un bloque o una transacción.
Si dos quórums y aprueban dos decisiones (por ejemplo, aprueba la transacción y aprueba la transacción ), queremos acotar el tamaño de su intersección .
Por el principio de inclusión-exclusión de conjuntos:
Dado que el número total de réplicas en la red es , la unión de cualquier par de quórums no puede exceder :
Sustituyendo la desigualdad:
Sustituyendo el tamaño de cada quórum y el tamaño del comité :
La cota es ajustada: existen pares de quórums que comparten exactamente réplicas, de modo que el protocolo no puede contar con un margen mayor. Con hay réplicas, quórums de y un cruce mínimo de . Con hay réplicas, quórums de y un cruce de al menos . Con hay réplicas, quórums de y un cruce de al menos , el caso de la analogía parlamentaria del inicio.
Teorema de Intersección de Quórums BFT
Por qué una réplica correcta en el cruce impide la bifurcación
El punto crítico no es solo cuántos nodos se cruzan, sino quiénes se cruzan.
Si el cruce fuera de nodos o menos, el adversario podría controlar a todos los nodos de la intersección. Un nodo bizantino puede equivocar: firmar un voto para que entrega al líder que arma y otro voto para que entrega a quien arma . Ambos certificados quedarían completos y dos réplicas correctas podrían ejecutar historias incompatibles, que es exactamente la forma de un doble gasto.
Al forzar :
- El adversario puede controlar a lo sumo nodos en el solapamiento.
- Queda obligatoriamente al menos un nodo correcto () en el solapamiento.
- Las réplicas correctas siguen las reglas del protocolo: en PBFT aceptan a lo sumo un pre-prepare por vista y número de secuencia, y en HotStuff votan a lo sumo por una propuesta en cada fase de una vista. [1] [3]
Por lo tanto, no aportará su voto a la segunda propuesta en conflicto, y el quórum no puede completarse. Nótese la forma de la prueba: no razonamos sobre lo que hace el adversario, sino sobre lo que no puede hacer una sola réplica correcta. Ese patrón, "encontrar un testigo correcto en la intersección", reaparece en casi todas las pruebas de safety de la familia BFT.
Análisis Comparativo de Tamaños de Quórum
La ventana entre safety y liveness
¿Por qué no elegimos un quórum más grande, como , para estar aún más seguros? Porque el consenso distribuido debe equilibrar safety (no decidir cosas incompatibles) con liveness (seguir decidiendo).
Las dos propiedades imponen cotas opuestas sobre . Para safety necesitamos que la intersección supere a los bizantinos:
Para liveness necesitamos que el quórum pueda formarse aunque réplicas callen para siempre, porque un nodo bizantino puede simplemente no votar:
La ventana es no vacía solo si , es decir, si . Este cálculo no reemplaza la prueba de imposibilidad de los papers, pero muestra de dónde sale intuitivamente el umbral: con ambas cotas coinciden en , y no queda margen para elegir otro valor. [4]
Con en una red de nodos, estaríamos asumiendo que como máximo una réplica falla. Si nodos sufren una caída o un ataque de denegación de servicio, solo responderán réplicas, y para eso es menos que . La red no viola safety, pero queda paralizada. Por ende, es el único punto que cumple ambas condiciones a la vez:
- Suficientemente grande para garantizar (safety).
- Suficientemente pequeño para formarse con las réplicas correctas sin esperar a las restantes (liveness).
La intersección es una propiedad puramente combinatoria: vale con cualquier patrón de retrasos. La formación del quórum, en cambio, necesita que los mensajes de réplicas correctas lleguen a tiempo, y eso solo está garantizado después de GST en el modelo de sincronía parcial. [4] Esa asimetría explica por qué en Sincronía parcial y quórums safety no espera a la red y liveness sí.
Impacto Operativo de la Intersección de Quórums
Configurar incorrectamente el parámetro de quórum en una red BFT permisionada puede permitir que dos líderes certifiquen transferencias contradictorias.
Con n = 3f + 1 y q = 2f + 1, dos certificados para la misma vista siempre comparten una réplica correcta que se niega a votar dos veces.
Intersección entre vistas: lo que el cruce no resuelve solo
La regla "una réplica correcta no vota dos propuestas distintas en la misma vista y fase" protege contra dos certificados en conflicto dentro de la misma vista. Pero los protocolos cambian de líder, y una réplica correcta sí puede votar en la vista y en la vista . Si nada más la restringiera, la intersección por sí sola no impediría revertir una decisión ya tomada.
La solución es transportar la memoria de la intersección a través del cambio de vista. En PBFT, el nuevo líder debe reunir mensajes de cambio de vista de réplicas, y cada uno incluye los certificados preparados que esa réplica conoce. [1] Como cualquier decisión anterior fue certificada por réplicas, ese conjunto de cambio de vista se cruza con el quórum de la decisión en al menos una réplica correcta, que reporta el certificado y obliga al nuevo líder a respetarlo.
HotStuff aplica la misma aritmética con otros objetos. Cada réplica guarda un lockedQC, y el predicado safeNode solo permite votar una propuesta que extienda ese bloqueo o que traiga un QC de vista más alta. [3] El argumento de safety vuelve a apoyarse en un testigo correcto: si un bloque se confirmó, un quórum quedó bloqueado en él, y cualquier QC conflictivo posterior necesitaría el voto de alguna réplica correcta de ese quórum, que su regla de bloqueo le prohíbe emitir. Los detalles están en QC, highQC y three-chain.
Lo importante para este artículo es la separación de responsabilidades. La intersección de quórums aporta el testigo; los locks y las reglas de cambio de vista aseguran que el testigo recuerde lo que vio. Sin intersección, los locks no alcanzan a nadie; sin locks, la intersección solo protege una vista aislada.
Checklist mental de la Intersección de Quórums
5 de 5 revisados
Bibliografía académica
- [1]
M. Castro and B. Liskov, "Practical Byzantine Fault Tolerance," OSDI, 1999.
Quórums de 2f + 1 entre 3f + 1 réplicas y certificados transportados en el cambio de vista.
- [2]
L. Lamport, R. Shostak, and M. Pease, "The Byzantine Generals Problem," ACM TOPLAS, vol. 4, no. 3, pp. 382-401, 1982, doi: 10.1145/357172.357176
Artículo seminal que establece el umbral de más de 3m generales con mensajes orales.
- [3]
M. Yin, D. Malkhi, M. K. Reiter, G. G. Gueta, and I. Abraham, "HotStuff: BFT Consensus in the Lens of Blockchain," PODC, 2019.
QC de n - f votos, lockedQC y el predicado safeNode como uso de la intersección entre vistas.
- [4]
C. Dwork, N. Lynch, and L. Stockmeyer, "Consensus in the Presence of Partial Synchrony," JACM, 1988.
Cota n >= 3f + 1 para fallas bizantinas bajo sincronía parcial y el papel de GST en liveness.
Siguiente lectura
Para ver cómo la intersección convive con GST y los timeouts, continúa con Sincronía parcial y quórums. Si quieres seguir el mismo testigo correcto a través de PBFT, Tendermint y Streamlet, el puente está en PBFT, Tendermint y Streamlet.
Rutas vecinas
Si este tema te abrió hambre, sigue por aquí.
Series y labs que comparten área o dependen de esta ruta. Pocas opciones, para no convertir la curiosidad en menú infinito.
Series relacionadas
Ethereum: de historia a labs
Serie progresiva para entender Ethereum desde el whitepaper, forks y The Merge hasta EVM, Solidity, proof-of-stake, rollups, account abstraction, DeFi, observabilidad y laboratorios reproducibles.
Substrate: del runtime al consenso propio
Serie de 20 capítulos, de neófito a experto, sobre Substrate (Polkadot SDK): runtime en Wasm, FRAME, extrinsics, estado, pesos, actualizaciones sin fork, Aura, BABE, GRANDPA, sincronización, parachains, XCM, Sassafras, BEEFY y cómo conectar un consenso BFT propio a un nodo.
Ruta práctica: activos digitales en la operación
Nueve módulos, de menor a mayor dependencia, para decidir cómo usar custodia, wallets, llaves, firmas multifirma y MPC, AML/KYT y stablecoins con Fireblocks, BitGo, Kaleido, Circle y Tether.
Labs para convertir lectura en práctica
Prueba de trabajo y reajuste de dificultad
Laboratorio determinista para medir el costo de la prueba de trabajo y ver cómo el reajuste por altura de bloque estabiliza el tiempo entre bloques.
Consensus benchmark
Banco reproducible para comparar consenso BFT y documentar los trade-offs de HotStuff-2.
Ethereum local: Anvil, wallet y primera transacción
Laboratorio base para levantar una red local, crear cuentas, firmar transacciones y observar receipts sin gastar ETH real.
RPC y Cast: leer Ethereum con lupa
Ejercicios con JSON-RPC y Cast para consultar bloques, nonces, gas, receipts, logs y errores reproducibles.
Sigue leyendo
Ideas conectadas con este artículo
Una ruta corta para continuar sin abrir veinte pestañas y perder el hilo.
Sincronía parcial y quórums: la calma antes de HotStuff
Qué significa GST, por qué la red no necesita ser perfecta y cómo los quórums sostienen safety mientras liveness espera mejores condiciones.
Consenso BFT desde cero: réplicas, quórums y fallas bizantinas
Primer paso de la serie HotStuff: qué problema resuelve BFT, por qué aparece n >= 3f + 1 y cómo separar safety de liveness sin drama matemático.
Fast-HotStuff: dos cadenas, AggQC y la letra pequeña
Por qué Fast-HotStuff intenta reducir latencia, cómo usa AggQC para probar highQC en cambios de vista y qué trade-offs aparecen en firmas agregadas.
HotStuff multipipeline: de fases a cadena viva
Cómo Chained HotStuff convierte prepare, pre-commit, commit y decide en una línea temporal de vistas, GenericQC y commits por profundidad de cadena.