Consenso distribuido
Una ruta académica y visual para entender quórums, locks, certificados, cambio de vista, commit chains y las variantes que llevaron HotStuff a producción.
Capítulos
77
47 disponibles · 4 etapas
Nivel
De fundamentos a avanzado
Ingeniería distribuida, ciberseguridad y matemática aplicada
Etapa 01
Capítulos 1–21: intuición, SMR, fallas, quórums, sincronía y el puente hacia PBFT.
14 disponibles de 21
Primer paso de la Masterclass de Consenso BFT: el problema fundamental de log replication, por qué guardar datos es fácil pero acordar su ORDEN es el verdadero reto.
Por qué un saldo digital se puede gastar dos veces si las réplicas no acuerdan un único orden de transacciones, y cómo los quórums 2f+1 lo impiden.
Cómo varias réplicas validan transacciones sin un servidor central: mismo estado inicial, mismo orden y ejecución determinista, la intuición de SMR.
Por qué una réplica puede detenerse, callar o contradecirse, y por qué BFT asume fallas arbitrarias: bugs y ataques producen el mismo síntoma ante el protocolo.
Quinto paso de la Masterclass BFT: la metáfora clásica de Lamport, Shostak y Pease (1982) sobre ejércitos, mensajeros y traición.
Un inventario de manzanas y peras muestra por qué réplicas deterministas que aplican el mismo log ordenado llegan siempre al mismo estado en SMR.
Séptimo paso de la Masterclass BFT: por qué agrupar transacciones en bloques cerrados ahorra ancho de banda y evita atascos de red.
Octavo paso de la Masterclass BFT: las dos garantías inviolables de la teoría de consensos distribuidos (Safety & Liveness).
Noveno paso de la Masterclass BFT: sobrecarga de red y cómputo, desde mensajes O(N^2) en PBFT hasta linealidad O(N) en HotStuff.
Décimo paso y cierre del Módulo 1 de la Masterclass BFT: justificación económica, ROI y eliminación de costos de conciliación.
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.
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.
Por qué ningún consenso determinista asíncrono garantiza terminar con una sola falla por crash, qué es la bivalencia y cómo la evaden los protocolos BFT.
Modelos síncrono, asíncrono y parcialmente síncrono: por qué un mensaje lento no se distingue de uno perdido y qué implica eso para FLP, DLS y 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.
Qué es GST en el modelo DLS de 1988: safety en toda ejecución, liveness tras la estabilización y las dos variantes, con Δ desconocida o válida tras GST.
Por qué un timeout fijo puede dejar sin progreso a un protocolo BFT bajo sincronía parcial y cómo el backoff y el pacemaker recuperan la liveness tras GST.
Jerarquía de fallas en DLS 1988: parada, omisión y bizantina, y por qué bajo sincronía parcial exigen n >= 2f+1 o n >= 3f+1 réplicas, con o sin firmas.
Mensajes orales frente a firmados: por qué las firmas eliminan la cota 3f+1 en el modelo síncrono de Lamport, pero no bajo la sincronía parcial de DLS.
Décimo paso del Módulo 2 (Artículo 20 de 77): análisis de impacto de negocio sobre el tiempo de finalidad de pagos, SLA de red y la asincronía en infraestructuras financieras.
Antes de QC y highQC conviene ver cómo PBFT, Tendermint y Streamlet preparan la intuición de vistas, locks y commits sobre cadenas.
Etapa 02
Capítulos 22–41: PBFT, Tendermint, cadenas, QC/highQC, pacemakers y variantes HotStuff.
16 disponibles de 20
Cómo PBFT (Castro y Liskov, 1999) ordena solicitudes con pre-prepare, prepare y commit, qué certifica cada quórum 2f+1 y por qué su view-change es cuadrático.
Qué viaja en VIEW-CHANGE y NEW-VIEW de PBFT, por qué su costo en autenticadores crece hasta O(n^3) y cómo HotStuff lo reduce a un highQC lineal.
Cómo leer Tendermint con el lente de HotStuff: prevote, precommit, LockedValue, ValidRound, proposer rotation, evidencia y slashing.
Por qué el nuevo líder de Tendermint espera la cota Δ antes de proponer y cómo la fase extra de HotStuff permite avanzar a la velocidad real de la red.
Guía para entender commits de una, dos y tres cadenas, y cómo esa taxonomía prepara QC, highQC, multipipeline y Fast-HotStuff.
El núcleo visual de HotStuff: cómo una propuesta se convierte en QC, por qué highQC guía al líder y cuándo una cadena certificada permite comprometer un bloque.
Por qué un commit de dos cadenas en HotStuff pierde safety o responsividad sin reglas extra, y cómo Fast-HotStuff, Jolteon y HotStuff-2 lo recuperan.
Noveno paso del Módulo 3 (Artículo 29 de 77): guía visual e interactiva para dominar la regla de 3 cadenas de HotStuff.
Décimo paso del Módulo 3 (Artículo 30 de 77): análisis de impacto de negocio comparando PBFT, Tendermint y HotStuff en aplicaciones comerciales e institucionales.
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.
Cómo HotStuff cambia de líder sin perder safety: new-view, highQC, pacemaker y la diferencia entre protocolo de consenso y mecanismo de sincronización.
Cómo el Pacemaker de HotStuff sincroniza vistas sin tocar safety: rotación de líderes, timeouts locales y certificados de timeout de 2f+1 en DiemBFT.
Una separación práctica de las garantías de HotStuff: qué nunca debe pasar, cuándo vuelve a avanzar y por qué responsiveness no significa latencia cero.
Puente entre QC/highQC y Fast-HotStuff: firmas de réplicas, threshold signatures, aggregate signatures y la evidencia que transporta AggQC.
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.
Cómo la familia HotStuff se adapta a producción: DiemBFT v4, líderes fallidos, dos cadenas, reputación de líder y fallback asíncrono.
Octavo paso del Módulo 4 (Artículo 38 de 77): análisis del consenso Jolteon (Gelashvili et al. 2021), su regla de 2 cadenas y su cambio de vista optimizado.
Noveno paso del Módulo 4 (Artículo 39 de 77): análisis de Ditto (Gelashvili et al. 2021) y su mecanismo de alternancia entre camino feliz síncrono y fallback asíncrono.
Qué cambia cuando un nodo Substrate intenta ponerse al día en una cadena con consenso HotStuff-like: headers, snapshots, warp sync y evidencia BFT.
Cierre de la serie HotStuff: HotStuff-2, pruebas Byzantine con Twins, Narwhal/Tusk/Bullshark y cómo leer el estado del arte sin mezclar linajes.
Etapa 03
Capítulos 42–64: Twins, Narwhal, Tusk, Bullshark, Shoal, Mysticeti y ChonkyBFT.
8 disponibles de 23
Segundo paso del Módulo 5 (Artículo 42 de 77): análisis técnico de HotStuff-2 (Malkhi & Nayak 2023) y su mecanismo de confirmación en 2 fases con cambio de vista lineal.
Tercer paso del Módulo 5 (Artículo 43 de 77): análisis del framework Twins (Bano et al. 2020) para simulación automatizada de ataques y testing de consenso.
Cómo Twins duplica réplicas con la misma identidad para emular equivocación y pérdida de estado, y genera escenarios sistemáticos que exponen bugs BFT.
Por qué el líder de PBFT o HotStuff satura su enlace de subida al reenviar el payload completo, y cómo Narwhal separa la difusión de datos del orden total.
Por qué Narwhal no es simplemente otro consenso, cómo separa disponibilidad de datos y ordenamiento, y cómo se conecta con HotStuff/Tusk.
Cómo Narwhal divide cada validador en un primary que certifica headers con digests y varios workers que difunden batches, y por qué eso escala el mempool.
Octavo paso del Módulo 5 (Artículo 48 de 77): análisis técnico de los Certificados de Disponibilidad de Datos (DAC) y la prevención de retención de información.
Cómo el DAG por rondas de Narwhal enlaza cada vértice con 2f+1 certificados previos y por qué Tusk y Bullshark derivan el orden total sin mensajes extra.
Tusk ordena el DAG de Narwhal sin timeouts: una moneda aleatoria compartida elige el líder de cada ola y el orden total sale del grafo sin mensajes extra.
Primer paso del Módulo 6 (Artículo 51 de 77): análisis técnico de Bullshark determinista (Spiegelman et al. 2022) y la fijación de anclas en sincronía parcial.
Segundo paso del Módulo 6 (Artículo 52 de 77): análisis de las limitaciones de latencia en Bullshark provocadas por validadores retardados o desincronizados.
Tercer paso del Módulo 6 (Artículo 53 de 77): análisis técnico del framework Shoal (Spiegelman et al. 2023) y la eliminación de timeouts en DAGs.
Cuarto paso del Módulo 6 (Artículo 54 de 77): análisis del mecanismo de puntuación de reputación local de líderes en Shoal basado en la historia del DAG.
Quinto paso del Módulo 6 (Artículo 55 de 77): análisis del mecanismo de pipelining continuo de anclas en Shoal para máxima densidad de commit.
Sexto paso del Módulo 6 (Artículo 56 de 77): análisis técnico de Mysticeti (Mysten Labs 2024) y la reducción a 3 saltos de red.
Séptimo paso del Módulo 6 (Artículo 57 de 77): análisis del patrón de confirmación implícita de Mysticeti y la eliminación de firmas de votación explícitas.
Octavo paso del Módulo 6 (Artículo 58 de 77): análisis detallado de las reglas de decisión directa e indirecta en Mysticeti-C.
Noveno paso del Módulo 6 (Artículo 59 de 77): análisis técnico de Mysticeti-FPC y la confirmación en 1 salto de red para objetos orientados a dueño.
Décimo paso del Módulo 6 (Artículo 60 de 77): gestión de equivocación en Fast Path y reconfiguración dinámica de época en Mysticeti.
Primer paso del Módulo 7 (Artículo 61 de 77): análisis técnico del protocolo ChonkyBFT (Matter Labs / ZKsync 2025) y su diseño de 1-slot consensus.
Por qué ChonkyBFT, el consenso de ZKsync, acepta n ≥ 5f+1 réplicas en lugar de 3f+1 para confirmar con una sola ronda de votos y finalidad en un slot.
Tercer paso del Módulo 7 (Artículo 63 de 77): análisis del protocolo de cambio de vista de 1 slot en ChonkyBFT.
Qué especifica TLA+ en un consenso BFT, cómo TLC y Apalache buscan contraejemplos a la safety y qué cubren frente a las pruebas tipo Twins.
Etapa 04
Capítulos 65–77: TLA+, Ethereum, incentivos, criptografía, ResilientDB y producción.
9 disponibles de 13
Cómo Casper FFG finaliza checkpoints con enlaces de supermayoría, por qué sus dos reglas de slashing dan accountable safety y cómo Gasper lo une a LMD GHOST.
Sexto paso del Módulo 7 (Artículo 66 de 77): análisis matemático de las dos condiciones de invalidez de voto (Slashing Conditions) en Casper FFG.
Por qué el slashing convierte un ataque a la safety de Casper FFG en un hecho demostrable y costoso, apoyado en la misma intersección de quórums que PBFT.
Por qué la finalidad se detiene si más de un tercio del stake no vota, cómo el inactivity leak de Ethereum la recupera y cuándo finaliza dos ramas en conflicto.
Cuánto pesa un QC con firmas individuales frente a una firma BLS agregada o de umbral, y por qué los emparejamientos encarecen la verificación en consenso BFT.
Décimo paso del Módulo 7 (Artículo 70 de 77): marco de decisión ejecutivo para seleccionar la arquitectura BFT ideal.
Cómo ResilientDB combina un pipeline multihilo de réplicas con GeoBFT: clústeres que ejecutan PBFT local y comparten decisiones certificadas entre regiones.
Segundo paso del Módulo 8 (Artículo 72 de 77): guía práctica del pipeline de consenso en C++ dentro de Apache ResilientDB.
Qué significa tratar a un agente LLM que falla o miente como réplica bizantina: votos, quórums, verificación y lo que afirman dos preprints de 2025.
Por qué los QC de un consenso BFT dependen de firmas, qué cambia al votar con ML-DSA (FIPS 204) y por qué ML-KEM (FIPS 203) protege canales, no votos.
Qué garantiza un zk-SNARK, por qué una prueba Groth16 ocupa tres elementos de grupo y cómo un consenso BFT puede ordenar transacciones validadas por pruebas.
Qué cuesta el consenso bizantino en dispositivos IoT y qué propone EBRC: comité elegido por reputación y VRF, votación en dos fases y una evaluación limitada.
Cierre operativo del Módulo 8 (Artículo 77 de 77): observabilidad, métricas Prometheus y alertas para comités BFT en producción.
Vocabulario operativo
Cada definición incluye una pregunta de control. Si no puedes responderla en el artículo actual, vuelve al prerrequisito antes de seguir.