El núcleo de la cadena de bloques radica en lograr un consenso global estricto: es decir, sin importar en qué país o zona horaria se distribuyan los nodos de la red, todos los participantes deben finalmente alcanzar un acuerdo sobre un conjunto de resultados objetivos.
Pero en la realidad, las redes distribuidas no son ideales: hay nodos que se desconectan, hay nodos que mienten, e incluso hay personas que causan daños intencionados. En este caso, ¿cómo logra el sistema "hablar con una sola voz" y mantener el consenso?
Este es el problema que el protocolo de consenso debe resolver. Es, en esencia, un conjunto de reglas que guía a un grupo de nodos que son independientes entre sí e incluso no completamente confiables, sobre cómo llegar a un acuerdo unificado sobre el orden y el contenido de cada transacción.
Y una vez que este "estricto consenso" se establezca, la cadena de bloques podrá desbloquear muchas características clave, como la protección de la propiedad digital, un modelo monetario antiinflacionario y una estructura de colaboración social escalable. Pero el requisito es que el protocolo de consenso debe garantizar simultáneamente dos fundamentos básicos:
No se pueden confirmar dos bloques que se contradicen entre sí.
La red debe avanzar continuamente, no puede quedarse atascada o detenerse.
MonadBFT es el último avance tecnológico en esta dirección.
Revisión breve de la evolución del protocolo de consenso
El campo de los mecanismos de consenso ha sido investigado durante décadas. Los primeros protocolos, como PBFT (Tolerancia a fallos bizantinos prácticos), ya podían manejar una situación muy realista: incluso si hay algunos nodos en la red que fallan, actúan mal o dicen tonterías, mientras no superen 1/3 del total, el sistema aún puede alcanzar un consenso.
El diseño de estos protocolos tempranos es bastante "tradicional": en cada ronda se elige un líder, quien inicia la propuesta, y los demás validadores votan varias veces sobre esta propuesta, confirmando paso a paso el orden de las transacciones.
Todo el proceso de votación generalmente pasa por varias etapas, como pre-preparar, preparar, comprometer y responder. En cada etapa, todos los validadores deben comunicarse entre sí. En otras palabras, cada uno tiene que hablar con todos, y la cantidad de mensajes crece de manera "exponencial".
La complejidad de esta estructura de comunicación es n²; es decir, si hay 100 validadores en la red, cada ronda de consenso podría requerir la transmisión de casi 10,000 mensajes.
Esto no es un gran problema en redes pequeñas, pero una vez que aumenta el número de validadores, la carga de comunicación del sistema se vuelve rápidamente insostenible, lo que afecta directamente la eficiencia.
Esta estructura de "cada uno debe comunicarse con todos" es en realidad muy ineficiente. Por ejemplo, en una red con 100 nodos, cada ronda de consenso podría tener que procesar decenas de miles de mensajes.
Esto puede manejarse en un pequeño círculo, pero si se coloca en una red de cadena de bloques abierta y global, la carga de comunicación se vuelve inmediatamente inaceptable. Así, protocolos BFT tempranos como PBFT y Tendermint generalmente solo se utilizan en escenarios de red permitida (permissioned network) o en sistemas con muy pocos validadores, donde apenas pueden funcionar.
Para que el protocolo BFT también pueda adaptarse a un entorno de cadena pública sin permisos, algunos diseños de nueva generación han comenzado a adoptar formas de comunicación más ligeras: permitir que cada validador solo se comunique con el líder, en lugar de que todos se comuniquen entre sí.
Esto reduce la complejidad del mensaje de n² a n, lo que aligera significativamente la carga del sistema.
El protocolo HotStuff fue propuesto en 2018 precisamente para abordar este problema de escalabilidad. Su diseño es muy claro: reemplazar el complejo proceso de votación de PBFT con una estructura de comunicación más simple y liderada por el líder.
La característica clave de HotStuff es lo que se llama comunicación lineal (linear communication). En su mecanismo, cada validador solo necesita enviar su voto al líder actual, y el líder empaqueta estos votos para generar un Certificado de Quórum (QC, prueba de mayoría legal).
Este QC es esencialmente una firma colectiva que demuestra a toda la red: "La mayoría de los nodos está de acuerdo con esta propuesta."
En comparación, el modo de comunicación de PBFT es "broadcasting total", donde todos hablan en el grupo, lo que hace que la situación sea bastante caótica. El modo de HotStuff se asemeja más a "una persona recoge, una vez empaqueta", manteniendo una operación eficiente sin importar cuántas personas haya en la red.
Además de la comunicación lineal, HotStuff también se puede actualizar a una versión en tuberías (pipelined HotStuff) para mejorar la eficiencia.
En el HotStuff original, el mismo validador actúa como líder en múltiples rondas de manera consecutiva, hasta que un bloque sea completamente confirmado. Este proceso es "procesar un bloque por ronda", concentrando toda la energía en avanzar el actual.
Y en la línea de producción HotStuff, el mecanismo es aún más flexible: en cada ronda se elige un nuevo líder, y la tarea de cada líder es doble:
Una vez empaquetada la votación de la ronda anterior en un Certificado de Quorum (QC), se transmite a toda la red;
Un nuevo Bloquear se está proponiendo, preparando para iniciar la siguiente ronda.
Es decir, ya no se trata de "confirmar uno antes de procesar el siguiente", sino de un sistema de línea de producción donde diferentes líderes se turnan para ser responsables de cada etapa. El anterior propone un bloque, el siguiente lo confirma y continúa proponiendo nuevos bloques, el consenso en la cadena de bloques se transmite como una carrera de relevos.
Esta es la origen de la metáfora "línea de producción": el bloque actual todavía está en proceso de confirmación, mientras que el siguiente ya está en preparación, con múltiples pasos en paralelo, mejorando la eficiencia de procesamiento.
En resumen, protocolos como HotStuff han hecho mejoras significativas en dos dimensiones en comparación con BFT tradicional:
Uno, la comunicación es más ligera, cada validador solo necesita comunicarse con el líder;
En segundo lugar, la eficiencia de procesamiento es mayor, ya que varios procesos de confirmación de bloques pueden realizarse en paralelo.
Esto ha convertido a HotStuff en un modelo de diseño para muchos mecanismos de consenso de bloques PoS modernos. Pero como todo, hay ventajas y desventajas: aunque la estructura de línea de producción es potente, también introduce sigilosamente un riesgo estructural que no es fácil de detectar.
A continuación, vamos a profundizar en este problema central: bifurcación final (Tail Forking).
Problema de bifurcación final (Tail-Forking)
Aunque HotStuff, especialmente su versión en línea, resuelve el problema de escalabilidad de los protocolos de consenso, también introduce algunos nuevos desafíos. El más crítico y a menudo el más fácil de pasar por alto es el problema de "Forking en la cola" (Tail Forking).
¿Qué es un bifurcación en la cola? Se puede entender simplemente como: una reestructuración inesperada de bloque en la "cola" de la cadena de bloques (reorg).
Específicamente, hay un bloque que es válido, ya se ha propagado con éxito a la mayoría de los nodos validadores y ha recibido suficientes votos de apoyo; por lo tanto, debería ser confirmado y escrito en la cadena principal. Sin embargo, al final, fue "saltar" y fue descartado (huérfano), reemplazado por otro nuevo bloque en la misma altura.
Esto no es un error, ni un ataque, sino que se debe a la posibilidad de "caída de la cadena" que existe en la estructura de diseño del protocolo. ¿No suena un poco injusto? Entonces, ¿cómo sucede esto?
Hemos mencionado anteriormente que cada líder en la línea de producción HotStuff tiene dos tareas:
A. Proponer un nuevo Bloquear (por ejemplo Bₙ₊₁)
B. Recoger votos para el bloque del líder anterior, generando QC (por ejemplo, completar la confirmación final para Bₙ)
Estas dos tareas son paralelas, se relevan alternativamente. Pero el problema está aquí.
Un ejemplo: supongamos que Alice es la líder, ella propuso el bloque Bₙ en la altura n, este bloque obtuvo el voto de una supermayoría, ya está "casi confirmado". A continuación, Bob debe asumir el liderazgo y continuar avanzando con el siguiente bloque de la cadena Bₙ₊₁, al mismo tiempo que debe empaquetar el QC de Bₙ (prueba de mayoría legal) en su propuesta, completando así la confirmación final de Bₙ.
Pero si Bob está desconectado en ese momento, o si deliberadamente no presenta el QC de Bₙ, entonces habrá un problema.
Porque nadie completó el QC del bloque de Alice, el registro de votación de Bₙ no pudo propagarse, este bloque que debería haber sido confirmado fue "tratado fríamente" y finalmente fue ignorado por toda la red.
Esta es la esencia de la bifurcación final: el bloque del líder anterior es omitido debido a la negligencia o malicia del siguiente líder.
¿Por qué es grave la bifurcación final?
Los problemas de bifurcación en la parte final se centran principalmente en dos aspectos: 1) el mecanismo de incentivos se ve afectado, 2) la actividad del sistema se ve amenazada.
Primero, se traga la recompensa: si se descarta un bloque, el líder que lo propuso no recibirá ninguna recompensa. Ya sea que se trate de recompensas en bloque o tarifas de transacción. Por ejemplo, Alice propuso un bloqueo legítimo y recibió un voto de mayoría calificada, pero debido a los errores o acciones maliciosas de Bob, el bloqueo no se confirmó y Alice no obtuvo un centavo al final. Esto conduce a una estructura de incentivos incorrecta: los nodos maliciosos como Bob pueden "quemar" su fuente de recompensa saltándose el bloqueo de su oponente. Este tipo de comportamiento no requiere un ataque técnico, solo una "no cooperación" deliberada para debilitar las ganancias del competidor. Si este tipo de cosas suceden repetidamente, con el tiempo, reducirá la participación y la equidad de todo el sistema, e incluso inducirá la colusión entre nodos.
En segundo lugar, el espacio de ataque MEV se expande: la horquilla de cola también plantea un problema más insidioso pero grave: el MEV (Valor Máximo Extraíble) tiene más espacio para ser manipulado maliciosamente. He aquí un ejemplo: Digamos que Alice tiene una valiosa operación de arbitraje en su bloque. Si Bob quiere causar problemas, puede confabularse con la próxima líder, Carol, y deliberadamente no extender el bloqueo de Alice. Carol luego reconstruye un nuevo bloque a la misma altura, "robando" el intercambio de arbitraje original de Alice, haciendo que el MEV gane el suyo. Esta práctica de "reorganización de la cabeza de la cadena + colusión y apropiación" sigue siendo un bloqueo según las reglas en la superficie, pero en realidad es un saqueo bien diseñado. Peor aún, induce a la "colusión" entre los líderes, convirtiendo la confirmación de bloques en un juego de participación en beneficios en lugar de un servicio público.
Tercero, la destrucción de la garantía de finalización afecta la experiencia del usuario: en comparación con los protocolos de tipo Nakamoto, una gran ventaja de BFT es la finalización determinista: una vez que un bloque se ha enviado, no se puede revertir. Sin embargo, la bifurcación final rompe esta garantía, especialmente en aquellos bloques que "han recibido votos pero aún no han sido confirmados oficialmente". Algunas dapps de alta capacidad de procesamiento suelen desear poder leer datos inmediatamente después de que el bloque ha sido aprobado por votación para reducir la latencia, y si ese bloque se descarta repentinamente, puede llevar a una reversión del estado del usuario: por ejemplo, un saldo de cuenta anómalo, transacciones de alto apalancamiento recién completadas que desaparecen sin explicación, o el estado del juego que se reinicia de repente.
Cuarto, puede provocar fallos en cadena: En general, una bifurcación en la parte final puede hacer que un bloque se confirme una ronda más tarde, lo que no tiene un gran impacto. Pero en algunos escenarios marginales, si varios líderes consecutivos eligen saltarse el bloque anterior, el sistema puede quedar en un estado de estancamiento, sin que nadie esté dispuesto a "tomar" el bloque anterior. El avance de toda la cadena se detiene hasta que finalmente aparece un líder "dispuesto a asumir la responsabilidad", y la red puede continuar avanzando.
Aunque anteriormente también ha habido algunas soluciones, como el mecanismo de evitación de bifurcaciones finales propuesto por el protocolo BeeGees, a menudo requiere sacrificar el rendimiento, como reintroducir la complejidad de la comunicación secundaria, lo que no compensa los costos.
¿Qué es MonadBFT?
MonadBFT es un nuevo protocolo de consenso diseñado específicamente para resolver el problema de bifurcación final. Su gran ventaja radica en que, al abordar los riesgos estructurales, no sacrifica las ventajas de rendimiento que ofrece el pipeline HotStuff. En otras palabras, MonadBFT no es un reinicio desde cero, sino una optimización continua basada en el marco central de HotStuff. Conserva tres características clave:
Rotación de líderes (rotating leader): se elige un nuevo líder en cada ronda para avanzar en la cadena;
Compromisos en cadena (pipelined commits): múltiples procesos de confirmación de bloques pueden superponerse.
Comunicación lineal (linear messaging): cada validador solo necesita comunicarse con el líder, ahorrando una gran cantidad de costos de red.
Pero solo con estos tres puntos, no es suficiente seguro. Para cerrar la brecha estructural del bifurcación de cola, MonadBFT añadió dos mecanismos clave:
Mecanismo de Re-Propuesta (Re-Proposal)
Certificado sin respaldo (NEC, No-Endorsement Certificate)
Mecanismo de Re-Propuesta
En el protocolo BFT, el tiempo se divide en rondas (denominadas view), y en cada ronda hay un líder responsable de proponer un nuevo bloque. Si el líder falla (por ejemplo, no propone el bloque a tiempo, o la propuesta es inválida), el sistema cambiará a la siguiente ronda y elegirá un nuevo líder.
MonadBFT ha añadido un mecanismo que asegura que durante el cambio de vista, cualquier bloque propuesto de manera honesta no se "caiga" debido a la rotación del líder.
Cuando el líder actual falla, los validadores emiten un mensaje de cambio de ronda firmado (view change), indicando que la ronda actual ha expirado.
Particularmente, este mensaje no solo indica "se agotó el tiempo", sino que también debe incluir la información del bloque de la última votación de ese validador, lo que equivale a decir: "no he recibido una propuesta válida, este es el último bloque que veo."
El nuevo líder recogerá estos mensajes de tiempo de espera de un supermayoría (2f+1) de nodos validadores y los combinará en un certificado de tiempo de espera (Timeout Certificate, TC). Este TC representa: cuando la ronda anterior falla, la instantánea de consenso unificado de toda la red sobre el "bloque de cabeza de cadena". El nuevo líder seleccionará el bloque de mayor altura (o el número de vista más reciente), denominado high_tip.
Requisitos de MonadBFT: La propuesta del nuevo líder debe incluir un TC legítimo y debe volver a proponer el bloque pendiente más alto en el TC, dando a este bloque la oportunidad de ser confirmado nuevamente.
¿Por qué? Como mencionamos anteriormente: no queremos que un bloque que está a punto de ser confirmado desaparezca.
Un ejemplo: Supongamos que Alice es la líder de la vista 5, ha propuesto un bloque válido y ha recibido la mayoría de los votos. A continuación, el líder de la vista 6, Bob, está fuera de línea y no ha podido avanzar el proceso de la cadena. Cuando Carol asume el liderazgo de la vista 7, según las reglas de MonadBFT, ella debe incluir TC y volver a proponer el bloque de Alice. De esta manera, el trabajo honesto de Alice no será en vano.
Si Carol no tiene el bloque de Alice, puede solicitarlo a otros nodos. Los nodos pueden:
Proporcionar el Bloquear, o
Devuelve un mensaje "sin respaldo" (No-Endorsement, NE) firmado, indicando que no posee este bloque (más adelante se presentará su mecanismo). (Hasta f nodos bizantinos pueden optar por ignorar la solicitud y no responder.)
Una vez que Carol reproponga el bloque de Alice, obtendrá una oportunidad adicional de propuesta, asegurando que no será "castigada en cadena" por el fracaso del líder de la ronda anterior.
El propósito de este mecanismo de re-propuesta es claro: asegurar que el avance de la cadena sea justo y que ningún trabajo válido se pierda silenciosamente debido a mala suerte o a que alguien interfiera.
Certificado sin respaldo (NEC)
Continuando con el ejemplo anterior: Después de que el tiempo de Bob se agote, Carol solicita a otros validadores que proporcionen el bloque high_tip (es decir, el bloque de Alice). En este momento, al menos 2f+1 validadores responderán:
Proporciona el bloque de Alice
Enviar un mensaje NE firmado, indicando que no se ha recibido el Bloquear de Alice.
Tan pronto como Carol reciba el Bloquear de Alice, deberá volver a proponerlo según las reglas. Solo podrá omitir el Bloquear y proponer uno nuevo si al menos f+1 validadores han firmado el mensaje NE.
¿Por qué f+1? En un sistema BFT compuesto por 3f+1 validadores, solo puede haber un máximo de f posibles malhechores. Si el bloque de Alice realmente recibió el voto de una supermayoría, al menos 2f+1 nodos honestos lo han recibido.
Por lo tanto, si Carol afirma que "no puedo obtener el bloque de Alice", debe presentar f+1 firmas de validadores que demuestren que estas personas no han recibido nada. Esto constituye un Certificado de No-Endoso (No-Endorsement Certificate, NEC).
NEC es el certificado de "exención" del líder: es una prueba verificable que indica que el bloque anterior aún no está listo para ser confirmado, no se ha saltado maliciosamente, sino que se ha "renunciado" de manera justificada.
Reproponer + Certificado sin respaldo = Solución a la bifurcación final
MonadBFT establece un conjunto de reglas claras y rigurosas para el manejo de la cadena a través de la introducción del mecanismo de re-propuesta (Re-Proposal) y el certificado sin respaldo (NEC, No-Endorsement Certificate):
O finalizar la提交 definitiva del bloque que está "cerca de ser confirmado"; o proporcionar suficiente evidencia que demuestre que dicho bloque no cumple con las condiciones para ser confirmado, de lo contrario, no se permitirá omitir o reemplazar el bloque anterior.
Este mecanismo asegura que: cualquier bloque que haya obtenido una mayoría legal de votos no será abandonado debido a errores del líder o evasiones intencionadas. El riesgo estructural de bifurcación en la cola se disuelve sistemáticamente, y el protocolo puede imponer restricciones claras sobre comportamientos indebidos de salto.
Si un líder intenta saltar el bloque anterior sin razón, pero no puede proporcionar evidencia de NEC, el protocolo identificará y rechazará inmediatamente dicha acción. El comportamiento de salto sin evidencia criptográfica será considerado ilegal y no recibirá apoyo de consenso de la red.
Desde el punto de vista de los incentivos económicos, este diseño proporciona una protección clara a los validadores:
Siempre que se presente de manera honesta un bloque y obtenga apoyo en la votación, su recompensa no será despojada debido a fallos en etapas posteriores.
Incluso en situaciones extremas, como cuando un nodo salta intencionadamente su ronda de propuesta para intentar ayudar a otros a apoderarse del MEV del bloque anterior, el protocolo forzará a los líderes sucesivos a volver a proponer el bloque original, impidiendo que los atacantes obtengan beneficios económicos al saltarse el proceso.
Más importante aún, MonadBFT no ha sacrificado el rendimiento del protocolo para mejorar la seguridad.
Diseños anteriores para hacer frente a las bifurcaciones finales (como el protocolo BeeGees) aunque poseen cierta capacidad de protección, a menudo dependen de una alta complejidad de comunicación (n²) o activan procesos de comunicación pesada en cada ronda, lo que puede aumentar significativamente la carga del sistema en la práctica.
La estrategia de diseño de MonadBFT es más ingeniosa:
Solo se inicia comunicación adicional (como mensajes de tiempo de espera, re-propuesta de bloques) en caso de fallos de vista o excepciones. En la ruta regular en la que la mayoría de los líderes honestos continúan creando bloques, el protocolo sigue manteniendo un estado de funcionamiento ligero y eficiente.
Este equilibrio dinámico entre rendimiento y seguridad es una de las principales ventajas de MonadBFT en comparación con los protocolos anteriores.
Resumen
Este artículo revisa los mecanismos básicos del consenso PBFT tradicional, analiza la trayectoria de desarrollo del protocolo HotStuff y explica en detalle cómo MonadBFT resuelve el problema de bifurcación final inherente a HotStuff en la estructura de la capa del protocolo.
La bifurcación final distorsionará los incentivos económicos del proponente del bloque y representa una amenaza potencial para la actividad de la red. MonadBFT asegura que cualquier bloque propuesto por líderes honestos que reciba la mayoría legal de votos no será abandonado o saltado, introduciendo un mecanismo de reapropiación y un certificado sin respaldo (NEC).
En el siguiente artículo, continuaremos explorando otras dos características centrales de MonadBFT:
Finalidad Especulativa
Responsividad Optimista
y analizar más a fondo el significado práctico de estos mecanismos para los validadores y desarrolladores.
Continuará.
Ver originales
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
MonadBFT análisis (parte 1): ¿cómo resolver el problema de bifurcación final?
El núcleo de la cadena de bloques radica en lograr un consenso global estricto: es decir, sin importar en qué país o zona horaria se distribuyan los nodos de la red, todos los participantes deben finalmente alcanzar un acuerdo sobre un conjunto de resultados objetivos.
Pero en la realidad, las redes distribuidas no son ideales: hay nodos que se desconectan, hay nodos que mienten, e incluso hay personas que causan daños intencionados. En este caso, ¿cómo logra el sistema "hablar con una sola voz" y mantener el consenso?
Este es el problema que el protocolo de consenso debe resolver. Es, en esencia, un conjunto de reglas que guía a un grupo de nodos que son independientes entre sí e incluso no completamente confiables, sobre cómo llegar a un acuerdo unificado sobre el orden y el contenido de cada transacción.
Y una vez que este "estricto consenso" se establezca, la cadena de bloques podrá desbloquear muchas características clave, como la protección de la propiedad digital, un modelo monetario antiinflacionario y una estructura de colaboración social escalable. Pero el requisito es que el protocolo de consenso debe garantizar simultáneamente dos fundamentos básicos:
No se pueden confirmar dos bloques que se contradicen entre sí.
La red debe avanzar continuamente, no puede quedarse atascada o detenerse.
MonadBFT es el último avance tecnológico en esta dirección.
Revisión breve de la evolución del protocolo de consenso
El campo de los mecanismos de consenso ha sido investigado durante décadas. Los primeros protocolos, como PBFT (Tolerancia a fallos bizantinos prácticos), ya podían manejar una situación muy realista: incluso si hay algunos nodos en la red que fallan, actúan mal o dicen tonterías, mientras no superen 1/3 del total, el sistema aún puede alcanzar un consenso.
El diseño de estos protocolos tempranos es bastante "tradicional": en cada ronda se elige un líder, quien inicia la propuesta, y los demás validadores votan varias veces sobre esta propuesta, confirmando paso a paso el orden de las transacciones.
Todo el proceso de votación generalmente pasa por varias etapas, como pre-preparar, preparar, comprometer y responder. En cada etapa, todos los validadores deben comunicarse entre sí. En otras palabras, cada uno tiene que hablar con todos, y la cantidad de mensajes crece de manera "exponencial".
La complejidad de esta estructura de comunicación es n²; es decir, si hay 100 validadores en la red, cada ronda de consenso podría requerir la transmisión de casi 10,000 mensajes.
Esto no es un gran problema en redes pequeñas, pero una vez que aumenta el número de validadores, la carga de comunicación del sistema se vuelve rápidamente insostenible, lo que afecta directamente la eficiencia.
Esta estructura de "cada uno debe comunicarse con todos" es en realidad muy ineficiente. Por ejemplo, en una red con 100 nodos, cada ronda de consenso podría tener que procesar decenas de miles de mensajes.
Esto puede manejarse en un pequeño círculo, pero si se coloca en una red de cadena de bloques abierta y global, la carga de comunicación se vuelve inmediatamente inaceptable. Así, protocolos BFT tempranos como PBFT y Tendermint generalmente solo se utilizan en escenarios de red permitida (permissioned network) o en sistemas con muy pocos validadores, donde apenas pueden funcionar.
Para que el protocolo BFT también pueda adaptarse a un entorno de cadena pública sin permisos, algunos diseños de nueva generación han comenzado a adoptar formas de comunicación más ligeras: permitir que cada validador solo se comunique con el líder, en lugar de que todos se comuniquen entre sí.
Esto reduce la complejidad del mensaje de n² a n, lo que aligera significativamente la carga del sistema.
El protocolo HotStuff fue propuesto en 2018 precisamente para abordar este problema de escalabilidad. Su diseño es muy claro: reemplazar el complejo proceso de votación de PBFT con una estructura de comunicación más simple y liderada por el líder.
La característica clave de HotStuff es lo que se llama comunicación lineal (linear communication). En su mecanismo, cada validador solo necesita enviar su voto al líder actual, y el líder empaqueta estos votos para generar un Certificado de Quórum (QC, prueba de mayoría legal).
Este QC es esencialmente una firma colectiva que demuestra a toda la red: "La mayoría de los nodos está de acuerdo con esta propuesta."
En comparación, el modo de comunicación de PBFT es "broadcasting total", donde todos hablan en el grupo, lo que hace que la situación sea bastante caótica. El modo de HotStuff se asemeja más a "una persona recoge, una vez empaqueta", manteniendo una operación eficiente sin importar cuántas personas haya en la red.
Además de la comunicación lineal, HotStuff también se puede actualizar a una versión en tuberías (pipelined HotStuff) para mejorar la eficiencia.
En el HotStuff original, el mismo validador actúa como líder en múltiples rondas de manera consecutiva, hasta que un bloque sea completamente confirmado. Este proceso es "procesar un bloque por ronda", concentrando toda la energía en avanzar el actual.
Y en la línea de producción HotStuff, el mecanismo es aún más flexible: en cada ronda se elige un nuevo líder, y la tarea de cada líder es doble:
Una vez empaquetada la votación de la ronda anterior en un Certificado de Quorum (QC), se transmite a toda la red;
Un nuevo Bloquear se está proponiendo, preparando para iniciar la siguiente ronda.
Es decir, ya no se trata de "confirmar uno antes de procesar el siguiente", sino de un sistema de línea de producción donde diferentes líderes se turnan para ser responsables de cada etapa. El anterior propone un bloque, el siguiente lo confirma y continúa proponiendo nuevos bloques, el consenso en la cadena de bloques se transmite como una carrera de relevos.
Esta es la origen de la metáfora "línea de producción": el bloque actual todavía está en proceso de confirmación, mientras que el siguiente ya está en preparación, con múltiples pasos en paralelo, mejorando la eficiencia de procesamiento.
En resumen, protocolos como HotStuff han hecho mejoras significativas en dos dimensiones en comparación con BFT tradicional:
Uno, la comunicación es más ligera, cada validador solo necesita comunicarse con el líder;
En segundo lugar, la eficiencia de procesamiento es mayor, ya que varios procesos de confirmación de bloques pueden realizarse en paralelo.
Esto ha convertido a HotStuff en un modelo de diseño para muchos mecanismos de consenso de bloques PoS modernos. Pero como todo, hay ventajas y desventajas: aunque la estructura de línea de producción es potente, también introduce sigilosamente un riesgo estructural que no es fácil de detectar.
A continuación, vamos a profundizar en este problema central: bifurcación final (Tail Forking).
Problema de bifurcación final (Tail-Forking)
Aunque HotStuff, especialmente su versión en línea, resuelve el problema de escalabilidad de los protocolos de consenso, también introduce algunos nuevos desafíos. El más crítico y a menudo el más fácil de pasar por alto es el problema de "Forking en la cola" (Tail Forking).
¿Qué es un bifurcación en la cola? Se puede entender simplemente como: una reestructuración inesperada de bloque en la "cola" de la cadena de bloques (reorg).
Específicamente, hay un bloque que es válido, ya se ha propagado con éxito a la mayoría de los nodos validadores y ha recibido suficientes votos de apoyo; por lo tanto, debería ser confirmado y escrito en la cadena principal. Sin embargo, al final, fue "saltar" y fue descartado (huérfano), reemplazado por otro nuevo bloque en la misma altura.
Esto no es un error, ni un ataque, sino que se debe a la posibilidad de "caída de la cadena" que existe en la estructura de diseño del protocolo. ¿No suena un poco injusto? Entonces, ¿cómo sucede esto?
Hemos mencionado anteriormente que cada líder en la línea de producción HotStuff tiene dos tareas:
A. Proponer un nuevo Bloquear (por ejemplo Bₙ₊₁)
B. Recoger votos para el bloque del líder anterior, generando QC (por ejemplo, completar la confirmación final para Bₙ)
Estas dos tareas son paralelas, se relevan alternativamente. Pero el problema está aquí.
Un ejemplo: supongamos que Alice es la líder, ella propuso el bloque Bₙ en la altura n, este bloque obtuvo el voto de una supermayoría, ya está "casi confirmado". A continuación, Bob debe asumir el liderazgo y continuar avanzando con el siguiente bloque de la cadena Bₙ₊₁, al mismo tiempo que debe empaquetar el QC de Bₙ (prueba de mayoría legal) en su propuesta, completando así la confirmación final de Bₙ.
Pero si Bob está desconectado en ese momento, o si deliberadamente no presenta el QC de Bₙ, entonces habrá un problema.
Porque nadie completó el QC del bloque de Alice, el registro de votación de Bₙ no pudo propagarse, este bloque que debería haber sido confirmado fue "tratado fríamente" y finalmente fue ignorado por toda la red.
Esta es la esencia de la bifurcación final: el bloque del líder anterior es omitido debido a la negligencia o malicia del siguiente líder.
¿Por qué es grave la bifurcación final?
Los problemas de bifurcación en la parte final se centran principalmente en dos aspectos: 1) el mecanismo de incentivos se ve afectado, 2) la actividad del sistema se ve amenazada.
Primero, se traga la recompensa: si se descarta un bloque, el líder que lo propuso no recibirá ninguna recompensa. Ya sea que se trate de recompensas en bloque o tarifas de transacción. Por ejemplo, Alice propuso un bloqueo legítimo y recibió un voto de mayoría calificada, pero debido a los errores o acciones maliciosas de Bob, el bloqueo no se confirmó y Alice no obtuvo un centavo al final. Esto conduce a una estructura de incentivos incorrecta: los nodos maliciosos como Bob pueden "quemar" su fuente de recompensa saltándose el bloqueo de su oponente. Este tipo de comportamiento no requiere un ataque técnico, solo una "no cooperación" deliberada para debilitar las ganancias del competidor. Si este tipo de cosas suceden repetidamente, con el tiempo, reducirá la participación y la equidad de todo el sistema, e incluso inducirá la colusión entre nodos.
En segundo lugar, el espacio de ataque MEV se expande: la horquilla de cola también plantea un problema más insidioso pero grave: el MEV (Valor Máximo Extraíble) tiene más espacio para ser manipulado maliciosamente. He aquí un ejemplo: Digamos que Alice tiene una valiosa operación de arbitraje en su bloque. Si Bob quiere causar problemas, puede confabularse con la próxima líder, Carol, y deliberadamente no extender el bloqueo de Alice. Carol luego reconstruye un nuevo bloque a la misma altura, "robando" el intercambio de arbitraje original de Alice, haciendo que el MEV gane el suyo. Esta práctica de "reorganización de la cabeza de la cadena + colusión y apropiación" sigue siendo un bloqueo según las reglas en la superficie, pero en realidad es un saqueo bien diseñado. Peor aún, induce a la "colusión" entre los líderes, convirtiendo la confirmación de bloques en un juego de participación en beneficios en lugar de un servicio público.
Tercero, la destrucción de la garantía de finalización afecta la experiencia del usuario: en comparación con los protocolos de tipo Nakamoto, una gran ventaja de BFT es la finalización determinista: una vez que un bloque se ha enviado, no se puede revertir. Sin embargo, la bifurcación final rompe esta garantía, especialmente en aquellos bloques que "han recibido votos pero aún no han sido confirmados oficialmente". Algunas dapps de alta capacidad de procesamiento suelen desear poder leer datos inmediatamente después de que el bloque ha sido aprobado por votación para reducir la latencia, y si ese bloque se descarta repentinamente, puede llevar a una reversión del estado del usuario: por ejemplo, un saldo de cuenta anómalo, transacciones de alto apalancamiento recién completadas que desaparecen sin explicación, o el estado del juego que se reinicia de repente.
Cuarto, puede provocar fallos en cadena: En general, una bifurcación en la parte final puede hacer que un bloque se confirme una ronda más tarde, lo que no tiene un gran impacto. Pero en algunos escenarios marginales, si varios líderes consecutivos eligen saltarse el bloque anterior, el sistema puede quedar en un estado de estancamiento, sin que nadie esté dispuesto a "tomar" el bloque anterior. El avance de toda la cadena se detiene hasta que finalmente aparece un líder "dispuesto a asumir la responsabilidad", y la red puede continuar avanzando.
Aunque anteriormente también ha habido algunas soluciones, como el mecanismo de evitación de bifurcaciones finales propuesto por el protocolo BeeGees, a menudo requiere sacrificar el rendimiento, como reintroducir la complejidad de la comunicación secundaria, lo que no compensa los costos.
¿Qué es MonadBFT?
MonadBFT es un nuevo protocolo de consenso diseñado específicamente para resolver el problema de bifurcación final. Su gran ventaja radica en que, al abordar los riesgos estructurales, no sacrifica las ventajas de rendimiento que ofrece el pipeline HotStuff. En otras palabras, MonadBFT no es un reinicio desde cero, sino una optimización continua basada en el marco central de HotStuff. Conserva tres características clave:
Rotación de líderes (rotating leader): se elige un nuevo líder en cada ronda para avanzar en la cadena;
Compromisos en cadena (pipelined commits): múltiples procesos de confirmación de bloques pueden superponerse.
Comunicación lineal (linear messaging): cada validador solo necesita comunicarse con el líder, ahorrando una gran cantidad de costos de red.
Pero solo con estos tres puntos, no es suficiente seguro. Para cerrar la brecha estructural del bifurcación de cola, MonadBFT añadió dos mecanismos clave:
Mecanismo de Re-Propuesta (Re-Proposal)
Certificado sin respaldo (NEC, No-Endorsement Certificate)
Mecanismo de Re-Propuesta
En el protocolo BFT, el tiempo se divide en rondas (denominadas view), y en cada ronda hay un líder responsable de proponer un nuevo bloque. Si el líder falla (por ejemplo, no propone el bloque a tiempo, o la propuesta es inválida), el sistema cambiará a la siguiente ronda y elegirá un nuevo líder.
MonadBFT ha añadido un mecanismo que asegura que durante el cambio de vista, cualquier bloque propuesto de manera honesta no se "caiga" debido a la rotación del líder.
Cuando el líder actual falla, los validadores emiten un mensaje de cambio de ronda firmado (view change), indicando que la ronda actual ha expirado.
Particularmente, este mensaje no solo indica "se agotó el tiempo", sino que también debe incluir la información del bloque de la última votación de ese validador, lo que equivale a decir: "no he recibido una propuesta válida, este es el último bloque que veo."
El nuevo líder recogerá estos mensajes de tiempo de espera de un supermayoría (2f+1) de nodos validadores y los combinará en un certificado de tiempo de espera (Timeout Certificate, TC). Este TC representa: cuando la ronda anterior falla, la instantánea de consenso unificado de toda la red sobre el "bloque de cabeza de cadena". El nuevo líder seleccionará el bloque de mayor altura (o el número de vista más reciente), denominado high_tip.
Requisitos de MonadBFT: La propuesta del nuevo líder debe incluir un TC legítimo y debe volver a proponer el bloque pendiente más alto en el TC, dando a este bloque la oportunidad de ser confirmado nuevamente.
¿Por qué? Como mencionamos anteriormente: no queremos que un bloque que está a punto de ser confirmado desaparezca.
Un ejemplo: Supongamos que Alice es la líder de la vista 5, ha propuesto un bloque válido y ha recibido la mayoría de los votos. A continuación, el líder de la vista 6, Bob, está fuera de línea y no ha podido avanzar el proceso de la cadena. Cuando Carol asume el liderazgo de la vista 7, según las reglas de MonadBFT, ella debe incluir TC y volver a proponer el bloque de Alice. De esta manera, el trabajo honesto de Alice no será en vano.
Si Carol no tiene el bloque de Alice, puede solicitarlo a otros nodos. Los nodos pueden:
Proporcionar el Bloquear, o
Devuelve un mensaje "sin respaldo" (No-Endorsement, NE) firmado, indicando que no posee este bloque (más adelante se presentará su mecanismo). (Hasta f nodos bizantinos pueden optar por ignorar la solicitud y no responder.)
Una vez que Carol reproponga el bloque de Alice, obtendrá una oportunidad adicional de propuesta, asegurando que no será "castigada en cadena" por el fracaso del líder de la ronda anterior.
El propósito de este mecanismo de re-propuesta es claro: asegurar que el avance de la cadena sea justo y que ningún trabajo válido se pierda silenciosamente debido a mala suerte o a que alguien interfiera.
Certificado sin respaldo (NEC)
Continuando con el ejemplo anterior: Después de que el tiempo de Bob se agote, Carol solicita a otros validadores que proporcionen el bloque high_tip (es decir, el bloque de Alice). En este momento, al menos 2f+1 validadores responderán:
Proporciona el bloque de Alice
Enviar un mensaje NE firmado, indicando que no se ha recibido el Bloquear de Alice.
Tan pronto como Carol reciba el Bloquear de Alice, deberá volver a proponerlo según las reglas. Solo podrá omitir el Bloquear y proponer uno nuevo si al menos f+1 validadores han firmado el mensaje NE.
¿Por qué f+1? En un sistema BFT compuesto por 3f+1 validadores, solo puede haber un máximo de f posibles malhechores. Si el bloque de Alice realmente recibió el voto de una supermayoría, al menos 2f+1 nodos honestos lo han recibido.
Por lo tanto, si Carol afirma que "no puedo obtener el bloque de Alice", debe presentar f+1 firmas de validadores que demuestren que estas personas no han recibido nada. Esto constituye un Certificado de No-Endoso (No-Endorsement Certificate, NEC).
NEC es el certificado de "exención" del líder: es una prueba verificable que indica que el bloque anterior aún no está listo para ser confirmado, no se ha saltado maliciosamente, sino que se ha "renunciado" de manera justificada.
Reproponer + Certificado sin respaldo = Solución a la bifurcación final
MonadBFT establece un conjunto de reglas claras y rigurosas para el manejo de la cadena a través de la introducción del mecanismo de re-propuesta (Re-Proposal) y el certificado sin respaldo (NEC, No-Endorsement Certificate):
O finalizar la提交 definitiva del bloque que está "cerca de ser confirmado"; o proporcionar suficiente evidencia que demuestre que dicho bloque no cumple con las condiciones para ser confirmado, de lo contrario, no se permitirá omitir o reemplazar el bloque anterior.
Este mecanismo asegura que: cualquier bloque que haya obtenido una mayoría legal de votos no será abandonado debido a errores del líder o evasiones intencionadas. El riesgo estructural de bifurcación en la cola se disuelve sistemáticamente, y el protocolo puede imponer restricciones claras sobre comportamientos indebidos de salto.
Si un líder intenta saltar el bloque anterior sin razón, pero no puede proporcionar evidencia de NEC, el protocolo identificará y rechazará inmediatamente dicha acción. El comportamiento de salto sin evidencia criptográfica será considerado ilegal y no recibirá apoyo de consenso de la red.
Desde el punto de vista de los incentivos económicos, este diseño proporciona una protección clara a los validadores:
Siempre que se presente de manera honesta un bloque y obtenga apoyo en la votación, su recompensa no será despojada debido a fallos en etapas posteriores.
Incluso en situaciones extremas, como cuando un nodo salta intencionadamente su ronda de propuesta para intentar ayudar a otros a apoderarse del MEV del bloque anterior, el protocolo forzará a los líderes sucesivos a volver a proponer el bloque original, impidiendo que los atacantes obtengan beneficios económicos al saltarse el proceso.
Más importante aún, MonadBFT no ha sacrificado el rendimiento del protocolo para mejorar la seguridad.
Diseños anteriores para hacer frente a las bifurcaciones finales (como el protocolo BeeGees) aunque poseen cierta capacidad de protección, a menudo dependen de una alta complejidad de comunicación (n²) o activan procesos de comunicación pesada en cada ronda, lo que puede aumentar significativamente la carga del sistema en la práctica.
La estrategia de diseño de MonadBFT es más ingeniosa:
Solo se inicia comunicación adicional (como mensajes de tiempo de espera, re-propuesta de bloques) en caso de fallos de vista o excepciones. En la ruta regular en la que la mayoría de los líderes honestos continúan creando bloques, el protocolo sigue manteniendo un estado de funcionamiento ligero y eficiente.
Este equilibrio dinámico entre rendimiento y seguridad es una de las principales ventajas de MonadBFT en comparación con los protocolos anteriores.
Resumen
Este artículo revisa los mecanismos básicos del consenso PBFT tradicional, analiza la trayectoria de desarrollo del protocolo HotStuff y explica en detalle cómo MonadBFT resuelve el problema de bifurcación final inherente a HotStuff en la estructura de la capa del protocolo.
La bifurcación final distorsionará los incentivos económicos del proponente del bloque y representa una amenaza potencial para la actividad de la red. MonadBFT asegura que cualquier bloque propuesto por líderes honestos que reciba la mayoría legal de votos no será abandonado o saltado, introduciendo un mecanismo de reapropiación y un certificado sin respaldo (NEC).
En el siguiente artículo, continuaremos explorando otras dos características centrales de MonadBFT:
Finalidad Especulativa
Responsividad Optimista
y analizar más a fondo el significado práctico de estos mecanismos para los validadores y desarrolladores.
Continuará.