El núcleo de la blockchain 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 llegar a un acuerdo sobre un conjunto de resultados objetivos.
Pero las redes distribuidas en la realidad no son ideales: hay nodos que se desconectan, nodos que mienten e incluso personas que intentan sabotear. En este caso, ¿cómo logra el sistema "unánime" mantener la coherencia?
Ese es el problema que los protocolos de consenso están diseñados para resolver. Básicamente, se trata de un conjunto de reglas que guían a un grupo de nodos independientes, si no de plena confianza, para tomar decisiones unificadas sobre el orden y el contenido de cada transacción.
Una vez que se establece este "consenso estricto", la blockchain puede 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 la condición es que el propio protocolo de consenso debe garantizar simultáneamente dos fundamentos básicos:
No puede haber dos bloques en conflicto que sean confirmados.
La red debe seguir avanzando, no puede quedar 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 estudiado durante décadas. Los primeros protocolos, como PBFT (tolerancia a fallos bizantinos práctica), 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, siempre que no superen el 1/3 del total, el sistema aún puede llegar a 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 sobre esta propuesta en varias rondas, confirmando paso a paso el orden de las transacciones.
Todo el proceso de votación generalmente pasa por varias etapas, como pre-prepare, prepare, commit, reply. En cada etapa, todos los validadores deben comunicarse entre sí. En otras palabras, cada uno debe hablar con todos, lo que provoca un aumento explosivo en la cantidad de mensajes en una "red".
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 el número de validadores aumenta, la carga de comunicación del sistema se volverá rápidamente insostenible, y la eficiencia caerá directamente.
Fuente de información:
Esta estructura de "cada persona tiene que comunicarse con cada persona" en la segunda comunicación es, de hecho, muy ineficiente. Por ejemplo, en una red con 100 validadores, 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 abierta a nivel global, la carga de comunicación se vuelve inmediatamente inaceptable. Por lo tanto, protocolos BFT tempranos como PBFT y Tendermint generalmente se utilizan solo en escenarios de redes permitidas (permissioned network) o en sistemas con muy pocos validadores, donde apenas pueden funcionar.
Con el fin de adaptar el protocolo BFT a un entorno de cadena pública sin permisos, algunos diseños de próxima generación han comenzado a moverse hacia una forma de comunicación más ligera: cada validador solo se comunica con el líder, en lugar de con todos los miembros del equipo.
Esto ha optimizado la complejidad del mensaje de n² a n —— aliviando significativamente la carga del sistema.
El protocolo HotStuff fue propuesto en 2018, precisamente para abordar este problema de escalabilidad. Su filosofía de diseño es muy clara: reemplazar el complejo proceso de votación de PBFT con una estructura de comunicación más simple y liderada por un líder.
La característica clave de HotStuff es la llamada comunicación lineal. En su mecanismo, cada validador solo necesita enviar sus votos al líder actual, quien luego empaqueta esos votos para generar un Certificado de Quórum (QC).
Este QC es esencialmente una firma colectiva que demuestra a toda la red: "La mayoría de los nodos han aceptado esta propuesta."
En comparación, el modo de comunicación de PBFT es "difusión total", donde todos hablan en el grupo, lo que provoca un caos considerable. El modo de HotStuff es más como "una persona recopila, una vez empaqueta", manteniendo una operación eficiente sin importar cuántas personas haya en la red.
La imagen anterior compara la estructura de comunicación de difusión de HotStuff con el modo de interconexión en red completa de PBFT.
Fuentes:
Además de la comunicación lineal, HotStuff también puede actualizarse a una versión en tubería (pipelined HotStuff) para mejorar la eficiencia.
En el HotStuff original, el mismo validador actúa como líder en múltiples rondas consecutivas, hasta que un bloque se confirma completamente. Este proceso es "un ciclo para procesar un bloque", donde toda la energía se concentra en avanzar el actual.
En la línea de producción HotStuff, el mecanismo es aún más flexible: en cada ronda se selecciona un nuevo líder, y la tarea de cada líder tiene dos objetivos:
Empacando la votación de la ronda anterior en un Certificado de Quorum (QC) y transmitiéndolo a toda la red;
Proponer un nuevo bloque y prepararse para comenzar la siguiente ronda.
Es decir, ya no es "confirmar uno y luego procesar el siguiente", sino que es como una línea de producción, donde diferentes líderes son responsables de cada etapa por turnos. El anterior propone un bloque, el siguiente lo confirma y continúa proponiendo nuevos bloques, el consenso en la cadena se transmite como una carrera de relevos.
Este es el origen de la metáfora de la "línea de montaje": el bloque actual aún está pasando por el proceso de confirmación, y el siguiente ya está en preparación, con múltiples pasos en paralelo para mejorar la eficiencia del rendimiento.
En resumen, los protocolos como HotStuff han realizado mejoras significativas en dos dimensiones en comparación con los BFT tradicionales:
En primer lugar, 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 múltiples procesos de confirmación de bloques pueden realizarse en paralelo.
Esto ha convertido a HotStuff en una plantilla de diseño para muchos mecanismos de consenso de blockchain PoS modernos. Pero como en todo, hay pros y contras: aunque la estructura de tuberías es potente, también introduce silenciosamente un riesgo estructural que no es fácil de detectar.
A continuación, vamos a profundizar en este problema central: la bifurcación de cola (Tail Forking).
Problema de bifurcación de cola (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. Uno de los más críticos, y que a menudo se pasa por alto, es el llamado problema de "Tail Forking".
¿Qué es un fork en la cola? Se puede entender simplemente como: hubo una reorganización inesperada de bloques en la "cola" de la blockchain (reorg).
En concreto, hay un bloque que es válido, que ya se ha propagado con éxito a la mayoría de los validadores y que ha recibido suficientes votos de apoyo, por lo que debería ser confirmado y escrito en la cadena principal. Pero al final, fue "saltado" y desechado (huérfano), siendo reemplazado por otro nuevo bloque en la misma altura.
Esto no es un bug, ni un ataque, sino que es porque en la estructura de diseño del protocolo en sí, existe la posibilidad de que ocurra este "caída de cadena". ¿No suena un poco injusto? Entonces, ¿cómo ocurre esto realmente?
Hemos mencionado anteriormente que cada líder de la línea de producción HotStuff tiene dos tareas:
A. Proponer un nuevo bloque (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 radica aquí.
Por ejemplo: supongamos que Alice es la líder, ella propuso el bloque Bₙ en la altura n, y este bloque recibió la mayoría superpoblada de votos, ya está "casi confirmado".
A continuación, Bob debe asumir el liderazgo y continuar avanzando al siguiente bloque de la cadena Bₙ₊₁, y también debería incluir el QC (prueba de mayoría legal) de Bₙ en su propuesta para completar 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.
Debido a que nadie completó el QC de empaquetado del bloque de Alice, el registro de votación de Bₙ no pudo propagarse, y este bloque que debería haber sido confirmado fue "tratado en frío" y finalmente ignorado por toda la red.
Esta es la esencia de la bifurcación final: el bloque del líder anterior es saltado debido a la negligencia o malicia del próximo líder.
¿Por qué es grave la bifurcación final?
Los problemas de bifurcación de la cola se concentran principalmente en dos aspectos: 1) Se rompe el mecanismo de incentivos, 2) Se amenaza la actividad del sistema.
Primero, la recompensa fue devorada:
Si un bloque es abandonado, su líder no recibirá ninguna recompensa. Ni la recompensa por bloque ni las tarifas de transacción. Por ejemplo, si Alice propone un bloque legítimo y obtiene el apoyo de una supermayoría de votos, pero debido a un error o a una acción maliciosa de Bob, este bloque no es confirmado, Alice no recibirá ni un centavo. Esto dará lugar a una estructura de incentivos errónea: nodos maliciosos como Bob pueden "cortar" la fuente de recompensas de sus oponentes al saltarse sus bloques. Este comportamiento no requiere un ataque técnico, solo necesita una "falta de cooperación" deliberada para debilitar los ingresos de los competidores. Si esto ocurre repetidamente, con el tiempo, la participación y la equidad del sistema disminuirán, e incluso puede inducir a la colusión entre nodos.
En segundo lugar, el espacio de ataque MEV se expande:
Un problema más oculto pero grave que trae la bifurcación final es que el espacio para la manipulación maliciosa del MEV (valor máximo extraíble) ha aumentado. Por ejemplo: supongamos que en el bloque de Alice hay una transacción de arbitraje de gran valor. Si Bob tiene malas intenciones, puede colludir con el próximo líder, Carol, para no difundir el bloque de Alice. Luego, Carol puede reconstruir un nuevo bloque en la misma altura y "copiar" la transacción de arbitraje de Alice, convirtiendo las ganancias del MEV en suyas. Este enfoque de "reorganización de la cadena + apropiación coludida" parece seguir las reglas al crear bloques, pero en realidad es un saqueo cuidadosamente diseñado. Lo peor es que puede inducir a los líderes a establecer "relaciones de conspiración", convirtiendo la confirmación de bloques en un juego de distribución de beneficios, en lugar de un servicio público.
Tercero, dañar la garantía de finalización afecta la experiencia del usuario:
En comparación con los protocolos tipo Nakamoto, una gran ventaja del BFT es el finalismo determinista: una vez que un bloque es confirmado, no puede ser revertido. Pero las bifurcaciones en la parte final destruyen esta garantía, especialmente en aquellos bloques que "han recibido votos pero aún no están confirmados oficialmente". Algunos dapps de alta capacidad de procesamiento suelen desear poder leer datos inmediatamente después de que el bloque haya sido votado para reducir la latencia, y si ese bloque es descartado repentinamente, podría llevar a un retroceso en el estado del usuario—por ejemplo, saldos de cuentas anómalos, transacciones de alto apalancamiento recién completadas que desaparecen sin razón, o estados de juegos que se reinician de repente.
Cuarto, puede provocar fallos en cadena:
En general, un fork en la parte final puede hacer que un bloque se confirme un ciclo más tarde, lo cual no es un gran impacto. Sin embargo, en algunos escenarios extremos, si varios líderes consecutivos eligen saltarse el bloque anterior, el sistema puede quedar en un estado de estancamiento, donde nadie está dispuesto a "asumir" el bloque anterior. Todo el avance de 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 evasión de bifurcación final propuesto por el protocolo BeeGees, a menudo requieren sacrificar el rendimiento, como reintroducir la complejidad de la comunicación secundaria, lo que no vale la pena.
¿Qué es MonadBFT?
MonadBFT es un nuevo protocolo de consenso diseñado específicamente para resolver el problema de bifurcaciones finales. Su gran ventaja radica en que, al abordar los riesgos estructurales, no sacrifica las ventajas de rendimiento que aporta el HotStuff en su flujo de trabajo. En otras palabras, MonadBFT no es un reinicio total, sino que se basa en el marco central de HotStuff y continúa optimizando. Conserva tres características clave:
Líder rotativo (rotating leader): se elige un nuevo líder en cada ronda para avanzar la cadena;
Confirmaciones en línea (pipelined commits): el proceso de confirmación de múltiples bloques puede 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 seguridad. Para cerrar la vulnerabilidad estructural de bifurcación en la parte trasera, MonadBFT añadió dos mecanismos clave:
Mecanismo de Re-Propuesta (Re-Proposal)
Certificado sin respaldo (NEC, No-Endorsement Certificate)
Mecanismo de Re-Proposición
En el protocolo BFT, el tiempo se divide en rondas (llamadas 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 pasará a la siguiente ronda y elegirá un nuevo líder.
MonadBFT ha añadido un mecanismo que garantiza que, durante el cambio de vista, ningún bloque propuesto de manera honesta se "pierda" debido al cambio de líder.
Cuando el líder actual falla, los validadores envían un mensaje de cambio de vista firmado, indicando que la ronda actual ha caducado.
Lo especial es que este mensaje no solo indica "se ha agotado 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 validadores y los combinará en un Certificado de Tiempo de Espera (Timeout Certificate, TC). Este TC representa: cuando la ronda anterior falla, un instantáneo de la percepción unificada 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, para que este bloque tenga nuevamente la oportunidad de ser confirmado.
¿Por qué? Como mencionamos anteriormente: no queremos que un bloque que está cerca de ser confirmado desaparezca.
Por 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 en el proceso de la cadena. Cuando Carol asuma el liderazgo de la vista 7, según las reglas de MonadBFT, 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 bloque, 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 vuelva a proponer el bloque de Alice, obtendrá una oportunidad adicional de propuesta, asegurando que no sea "responsabilizada" por el fracaso del líder anterior.
El propósito de este mecanismo de re-propuesta es claro: asegurar que el avance de la cadena sea justo, y que cualquier trabajo válido no sea descartado silenciosamente debido a mala suerte o a la interferencia de alguien.
Certificado sin respaldo (NEC)
Continuando con el ejemplo anterior: después de que se agote el tiempo de Bob, Carol pide 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.
O enviar un mensaje NE firmado, indicando que no ha recibido el bloque de Alice.
Tan pronto como Carol reciba el bloque de Alice, debe volver a proponerlo de acuerdo con las reglas. Carol solo puede omitir ese bloque 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 obtuvo el voto de la supermayoría, entonces al menos 2f+1 nodos honestos lo han recibido.
Por lo tanto, si Carol afirma "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 Sin Endoso (No-Endorsement Certificate, NEC).
NEC es el certificado de "exoneración" del líder: es una evidencia verificable que indica que el bloque anterior no está listo para ser confirmado, no se omite de manera maliciosa, sino que se "renuncia" de manera razonada.
Reproponer + Certificado sin respaldo = Solucionar bifurcaciones finales
MonadBFT establece un conjunto de reglas rigurosas y claras para el manejo de la cadena mediante la introducción del mecanismo de re-propuesta (Re-Proposal) y el certificado sin respaldo (NEC, No-Endorsement Certificate):
Completar la presentación final del bloque "cerca de ser confirmado";
Proporcionar suficientes pruebas para demostrar que el bloque aún no cumple con las condiciones para ser confirmado,
De lo contrario, no se permite 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 un error del líder o a una evasión intencionada.
Los riesgos estructurales de la bifurcación final se han sistematizado, y el protocolo puede imponer restricciones claras sobre comportamientos inapropiados de omisión.
Si un líder intenta saltarse el bloque anterior sin motivo, pero no logra proporcionar evidencia NEC, el protocolo reconocerá y rechazará inmediatamente esa acción. El salto sin evidencia criptográfica se considerará ilegal y no recibirá el apoyo del consenso de la red.
Desde la perspectiva de los incentivos económicos, este diseño proporciona una protección clara a los validadores:
Siempre que un bloque se proponga de manera honesta y reciba apoyo en la votación, su recompensa no será despojada debido a fallas en las etapas posteriores;
Incluso en situaciones extremas, como cuando un nodo salta deliberadamente su turno de propuesta para intentar ayudar a otros a capturar el MEV del bloque anterior, el protocolo obligará a los líderes sucesivos a priorizar la re-propuesta del bloque original, de modo que los atacantes no puedan obtener beneficios económicos al saltarse el proceso.
Lo más importante es que MonadBFT no ha sacrificado el rendimiento del protocolo para mejorar la seguridad.
Algunos diseños anteriores para abordar 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 habilitan un proceso de comunicación pesado en cada ronda, lo que en la práctica aumenta significativamente la carga del sistema.
La estrategia de diseño de MonadBFT es más ingeniosa:
Solo se inicia comunicación adicional (como mensajes de tiempo de espera, propuestas de bloques) en caso de fallos en la vista o excepciones. En la mayoría de las rutas regulares donde líderes honestos producen bloques de manera continua, el protocolo mantiene un estado de operación 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 endógeno de HotStuff desde la estructura de la capa del protocolo.
La bifurcación en la parte final distorsionará los incentivos económicos de los proponentes de bloques y también representa una amenaza potencial para la actividad de la red. MonadBFT garantiza que cualquier bloque propuesto por líderes honestos y que obtenga una mayoría legal de votos no será abandonado ni saltado, al introducir un mecanismo de reapertura y certificados sin respaldo (NEC).
En el próximo artículo, continuaremos explorando otras dos características centrales de MonadBFT:
Finalidad Especulativa (Speculative Finality)
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: redefiniendo la seguridad del consenso de la cadena de bloques, despidiéndonos del riesgo de bifurcación final
Autor: michaellwy
El núcleo de la blockchain 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 llegar a un acuerdo sobre un conjunto de resultados objetivos.
Pero las redes distribuidas en la realidad no son ideales: hay nodos que se desconectan, nodos que mienten e incluso personas que intentan sabotear. En este caso, ¿cómo logra el sistema "unánime" mantener la coherencia?
Ese es el problema que los protocolos de consenso están diseñados para resolver. Básicamente, se trata de un conjunto de reglas que guían a un grupo de nodos independientes, si no de plena confianza, para tomar decisiones unificadas sobre el orden y el contenido de cada transacción.
Una vez que se establece este "consenso estricto", la blockchain puede 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 la condición es que el propio protocolo de consenso debe garantizar simultáneamente dos fundamentos básicos:
No puede haber dos bloques en conflicto que sean confirmados.
La red debe seguir avanzando, no puede quedar 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 estudiado durante décadas. Los primeros protocolos, como PBFT (tolerancia a fallos bizantinos práctica), 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, siempre que no superen el 1/3 del total, el sistema aún puede llegar a 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 sobre esta propuesta en varias rondas, confirmando paso a paso el orden de las transacciones.
Todo el proceso de votación generalmente pasa por varias etapas, como pre-prepare, prepare, commit, reply. En cada etapa, todos los validadores deben comunicarse entre sí. En otras palabras, cada uno debe hablar con todos, lo que provoca un aumento explosivo en la cantidad de mensajes en una "red".
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 el número de validadores aumenta, la carga de comunicación del sistema se volverá rápidamente insostenible, y la eficiencia caerá directamente.
Fuente de información:
Esta estructura de "cada persona tiene que comunicarse con cada persona" en la segunda comunicación es, de hecho, muy ineficiente. Por ejemplo, en una red con 100 validadores, 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 abierta a nivel global, la carga de comunicación se vuelve inmediatamente inaceptable. Por lo tanto, protocolos BFT tempranos como PBFT y Tendermint generalmente se utilizan solo en escenarios de redes permitidas (permissioned network) o en sistemas con muy pocos validadores, donde apenas pueden funcionar.
Con el fin de adaptar el protocolo BFT a un entorno de cadena pública sin permisos, algunos diseños de próxima generación han comenzado a moverse hacia una forma de comunicación más ligera: cada validador solo se comunica con el líder, en lugar de con todos los miembros del equipo.
Esto ha optimizado la complejidad del mensaje de n² a n —— aliviando significativamente la carga del sistema.
El protocolo HotStuff fue propuesto en 2018, precisamente para abordar este problema de escalabilidad. Su filosofía de diseño es muy clara: reemplazar el complejo proceso de votación de PBFT con una estructura de comunicación más simple y liderada por un líder.
La característica clave de HotStuff es la llamada comunicación lineal. En su mecanismo, cada validador solo necesita enviar sus votos al líder actual, quien luego empaqueta esos votos para generar un Certificado de Quórum (QC).
Este QC es esencialmente una firma colectiva que demuestra a toda la red: "La mayoría de los nodos han aceptado esta propuesta."
En comparación, el modo de comunicación de PBFT es "difusión total", donde todos hablan en el grupo, lo que provoca un caos considerable. El modo de HotStuff es más como "una persona recopila, una vez empaqueta", manteniendo una operación eficiente sin importar cuántas personas haya en la red.
La imagen anterior compara la estructura de comunicación de difusión de HotStuff con el modo de interconexión en red completa de PBFT.
Fuentes:
Además de la comunicación lineal, HotStuff también puede actualizarse a una versión en tubería (pipelined HotStuff) para mejorar la eficiencia.
En el HotStuff original, el mismo validador actúa como líder en múltiples rondas consecutivas, hasta que un bloque se confirma completamente. Este proceso es "un ciclo para procesar un bloque", donde toda la energía se concentra en avanzar el actual.
En la línea de producción HotStuff, el mecanismo es aún más flexible: en cada ronda se selecciona un nuevo líder, y la tarea de cada líder tiene dos objetivos:
Empacando la votación de la ronda anterior en un Certificado de Quorum (QC) y transmitiéndolo a toda la red;
Proponer un nuevo bloque y prepararse para comenzar la siguiente ronda.
Es decir, ya no es "confirmar uno y luego procesar el siguiente", sino que es como una línea de producción, donde diferentes líderes son responsables de cada etapa por turnos. El anterior propone un bloque, el siguiente lo confirma y continúa proponiendo nuevos bloques, el consenso en la cadena se transmite como una carrera de relevos.
Este es el origen de la metáfora de la "línea de montaje": el bloque actual aún está pasando por el proceso de confirmación, y el siguiente ya está en preparación, con múltiples pasos en paralelo para mejorar la eficiencia del rendimiento.
En resumen, los protocolos como HotStuff han realizado mejoras significativas en dos dimensiones en comparación con los BFT tradicionales:
En primer lugar, 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 múltiples procesos de confirmación de bloques pueden realizarse en paralelo.
Esto ha convertido a HotStuff en una plantilla de diseño para muchos mecanismos de consenso de blockchain PoS modernos. Pero como en todo, hay pros y contras: aunque la estructura de tuberías es potente, también introduce silenciosamente un riesgo estructural que no es fácil de detectar.
A continuación, vamos a profundizar en este problema central: la bifurcación de cola (Tail Forking).
Problema de bifurcación de cola (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. Uno de los más críticos, y que a menudo se pasa por alto, es el llamado problema de "Tail Forking".
¿Qué es un fork en la cola? Se puede entender simplemente como: hubo una reorganización inesperada de bloques en la "cola" de la blockchain (reorg).
En concreto, hay un bloque que es válido, que ya se ha propagado con éxito a la mayoría de los validadores y que ha recibido suficientes votos de apoyo, por lo que debería ser confirmado y escrito en la cadena principal. Pero al final, fue "saltado" y desechado (huérfano), siendo reemplazado por otro nuevo bloque en la misma altura.
Esto no es un bug, ni un ataque, sino que es porque en la estructura de diseño del protocolo en sí, existe la posibilidad de que ocurra este "caída de cadena". ¿No suena un poco injusto? Entonces, ¿cómo ocurre esto realmente?
Hemos mencionado anteriormente que cada líder de la línea de producción HotStuff tiene dos tareas:
A. Proponer un nuevo bloque (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 radica aquí.
Por ejemplo: supongamos que Alice es la líder, ella propuso el bloque Bₙ en la altura n, y este bloque recibió la mayoría superpoblada de votos, ya está "casi confirmado".
A continuación, Bob debe asumir el liderazgo y continuar avanzando al siguiente bloque de la cadena Bₙ₊₁, y también debería incluir el QC (prueba de mayoría legal) de Bₙ en su propuesta para completar 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.
Debido a que nadie completó el QC de empaquetado del bloque de Alice, el registro de votación de Bₙ no pudo propagarse, y este bloque que debería haber sido confirmado fue "tratado en frío" y finalmente ignorado por toda la red.
Esta es la esencia de la bifurcación final: el bloque del líder anterior es saltado debido a la negligencia o malicia del próximo líder.
¿Por qué es grave la bifurcación final?
Los problemas de bifurcación de la cola se concentran principalmente en dos aspectos: 1) Se rompe el mecanismo de incentivos, 2) Se amenaza la actividad del sistema.
Primero, la recompensa fue devorada:
Si un bloque es abandonado, su líder no recibirá ninguna recompensa. Ni la recompensa por bloque ni las tarifas de transacción. Por ejemplo, si Alice propone un bloque legítimo y obtiene el apoyo de una supermayoría de votos, pero debido a un error o a una acción maliciosa de Bob, este bloque no es confirmado, Alice no recibirá ni un centavo. Esto dará lugar a una estructura de incentivos errónea: nodos maliciosos como Bob pueden "cortar" la fuente de recompensas de sus oponentes al saltarse sus bloques. Este comportamiento no requiere un ataque técnico, solo necesita una "falta de cooperación" deliberada para debilitar los ingresos de los competidores. Si esto ocurre repetidamente, con el tiempo, la participación y la equidad del sistema disminuirán, e incluso puede inducir a la colusión entre nodos.
En segundo lugar, el espacio de ataque MEV se expande:
Un problema más oculto pero grave que trae la bifurcación final es que el espacio para la manipulación maliciosa del MEV (valor máximo extraíble) ha aumentado. Por ejemplo: supongamos que en el bloque de Alice hay una transacción de arbitraje de gran valor. Si Bob tiene malas intenciones, puede colludir con el próximo líder, Carol, para no difundir el bloque de Alice. Luego, Carol puede reconstruir un nuevo bloque en la misma altura y "copiar" la transacción de arbitraje de Alice, convirtiendo las ganancias del MEV en suyas. Este enfoque de "reorganización de la cadena + apropiación coludida" parece seguir las reglas al crear bloques, pero en realidad es un saqueo cuidadosamente diseñado. Lo peor es que puede inducir a los líderes a establecer "relaciones de conspiración", convirtiendo la confirmación de bloques en un juego de distribución de beneficios, en lugar de un servicio público.
Tercero, dañar la garantía de finalización afecta la experiencia del usuario:
En comparación con los protocolos tipo Nakamoto, una gran ventaja del BFT es el finalismo determinista: una vez que un bloque es confirmado, no puede ser revertido. Pero las bifurcaciones en la parte final destruyen esta garantía, especialmente en aquellos bloques que "han recibido votos pero aún no están confirmados oficialmente". Algunos dapps de alta capacidad de procesamiento suelen desear poder leer datos inmediatamente después de que el bloque haya sido votado para reducir la latencia, y si ese bloque es descartado repentinamente, podría llevar a un retroceso en el estado del usuario—por ejemplo, saldos de cuentas anómalos, transacciones de alto apalancamiento recién completadas que desaparecen sin razón, o estados de juegos que se reinician de repente.
Cuarto, puede provocar fallos en cadena:
En general, un fork en la parte final puede hacer que un bloque se confirme un ciclo más tarde, lo cual no es un gran impacto. Sin embargo, en algunos escenarios extremos, si varios líderes consecutivos eligen saltarse el bloque anterior, el sistema puede quedar en un estado de estancamiento, donde nadie está dispuesto a "asumir" el bloque anterior. Todo el avance de 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 evasión de bifurcación final propuesto por el protocolo BeeGees, a menudo requieren sacrificar el rendimiento, como reintroducir la complejidad de la comunicación secundaria, lo que no vale la pena.
¿Qué es MonadBFT?
MonadBFT es un nuevo protocolo de consenso diseñado específicamente para resolver el problema de bifurcaciones finales. Su gran ventaja radica en que, al abordar los riesgos estructurales, no sacrifica las ventajas de rendimiento que aporta el HotStuff en su flujo de trabajo. En otras palabras, MonadBFT no es un reinicio total, sino que se basa en el marco central de HotStuff y continúa optimizando. Conserva tres características clave:
Líder rotativo (rotating leader): se elige un nuevo líder en cada ronda para avanzar la cadena;
Confirmaciones en línea (pipelined commits): el proceso de confirmación de múltiples bloques puede 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 seguridad. Para cerrar la vulnerabilidad estructural de bifurcación en la parte trasera, MonadBFT añadió dos mecanismos clave:
Mecanismo de Re-Propuesta (Re-Proposal)
Certificado sin respaldo (NEC, No-Endorsement Certificate)
Mecanismo de Re-Proposición
En el protocolo BFT, el tiempo se divide en rondas (llamadas 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 pasará a la siguiente ronda y elegirá un nuevo líder.
MonadBFT ha añadido un mecanismo que garantiza que, durante el cambio de vista, ningún bloque propuesto de manera honesta se "pierda" debido al cambio de líder.
Cuando el líder actual falla, los validadores envían un mensaje de cambio de vista firmado, indicando que la ronda actual ha caducado.
Lo especial es que este mensaje no solo indica "se ha agotado 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 validadores y los combinará en un Certificado de Tiempo de Espera (Timeout Certificate, TC). Este TC representa: cuando la ronda anterior falla, un instantáneo de la percepción unificada 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, para que este bloque tenga nuevamente la oportunidad de ser confirmado.
¿Por qué? Como mencionamos anteriormente: no queremos que un bloque que está cerca de ser confirmado desaparezca.
Por 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 en el proceso de la cadena. Cuando Carol asuma el liderazgo de la vista 7, según las reglas de MonadBFT, 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 bloque, 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 vuelva a proponer el bloque de Alice, obtendrá una oportunidad adicional de propuesta, asegurando que no sea "responsabilizada" por el fracaso del líder anterior.
El propósito de este mecanismo de re-propuesta es claro: asegurar que el avance de la cadena sea justo, y que cualquier trabajo válido no sea descartado silenciosamente debido a mala suerte o a la interferencia de alguien.
Certificado sin respaldo (NEC)
Continuando con el ejemplo anterior: después de que se agote el tiempo de Bob, Carol pide 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.
O enviar un mensaje NE firmado, indicando que no ha recibido el bloque de Alice.
Tan pronto como Carol reciba el bloque de Alice, debe volver a proponerlo de acuerdo con las reglas. Carol solo puede omitir ese bloque 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 obtuvo el voto de la supermayoría, entonces al menos 2f+1 nodos honestos lo han recibido.
Por lo tanto, si Carol afirma "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 Sin Endoso (No-Endorsement Certificate, NEC).
NEC es el certificado de "exoneración" del líder: es una evidencia verificable que indica que el bloque anterior no está listo para ser confirmado, no se omite de manera maliciosa, sino que se "renuncia" de manera razonada.
Reproponer + Certificado sin respaldo = Solucionar bifurcaciones finales
MonadBFT establece un conjunto de reglas rigurosas y claras para el manejo de la cadena mediante la introducción del mecanismo de re-propuesta (Re-Proposal) y el certificado sin respaldo (NEC, No-Endorsement Certificate):
Completar la presentación final del bloque "cerca de ser confirmado";
Proporcionar suficientes pruebas para demostrar que el bloque aún no cumple con las condiciones para ser confirmado,
De lo contrario, no se permite 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 un error del líder o a una evasión intencionada.
Los riesgos estructurales de la bifurcación final se han sistematizado, y el protocolo puede imponer restricciones claras sobre comportamientos inapropiados de omisión.
Si un líder intenta saltarse el bloque anterior sin motivo, pero no logra proporcionar evidencia NEC, el protocolo reconocerá y rechazará inmediatamente esa acción. El salto sin evidencia criptográfica se considerará ilegal y no recibirá el apoyo del consenso de la red.
Desde la perspectiva de los incentivos económicos, este diseño proporciona una protección clara a los validadores:
Siempre que un bloque se proponga de manera honesta y reciba apoyo en la votación, su recompensa no será despojada debido a fallas en las etapas posteriores;
Incluso en situaciones extremas, como cuando un nodo salta deliberadamente su turno de propuesta para intentar ayudar a otros a capturar el MEV del bloque anterior, el protocolo obligará a los líderes sucesivos a priorizar la re-propuesta del bloque original, de modo que los atacantes no puedan obtener beneficios económicos al saltarse el proceso.
Lo más importante es que MonadBFT no ha sacrificado el rendimiento del protocolo para mejorar la seguridad.
Algunos diseños anteriores para abordar 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 habilitan un proceso de comunicación pesado en cada ronda, lo que en la práctica aumenta significativamente la carga del sistema.
La estrategia de diseño de MonadBFT es más ingeniosa:
Solo se inicia comunicación adicional (como mensajes de tiempo de espera, propuestas de bloques) en caso de fallos en la vista o excepciones. En la mayoría de las rutas regulares donde líderes honestos producen bloques de manera continua, el protocolo mantiene un estado de operación 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 endógeno de HotStuff desde la estructura de la capa del protocolo.
La bifurcación en la parte final distorsionará los incentivos económicos de los proponentes de bloques y también representa una amenaza potencial para la actividad de la red. MonadBFT garantiza que cualquier bloque propuesto por líderes honestos y que obtenga una mayoría legal de votos no será abandonado ni saltado, al introducir un mecanismo de reapertura y certificados sin respaldo (NEC).
En el próximo artículo, continuaremos explorando otras dos características centrales de MonadBFT:
Finalidad Especulativa (Speculative Finality)
Responsividad Optimista
y analizar más a fondo el significado práctico de estos mecanismos para los validadores y desarrolladores.
Continuará.