El núcleo de la cadena de bloques es lograr un estricto consenso global: es decir, independientemente de dónde estén distribuidos los nodos de la red en qué país o zona horaria, todos los participantes deben alcanzar en última instancia un consenso sobre un conjunto de resultados objetivos.

Pero la realidad de las redes distribuidas no es ideal: los nodos se desconectan, los nodos mienten, e incluso algunos sabotean intencionalmente. En este caso, ¿cómo hace el sistema para "hablar con una sola voz" y mantener la consistencia?

Este es el problema que el protocolo de consenso busca resolver. Esencialmente, es un conjunto de reglas para guiar a un grupo de nodos independientes e incluso parcialmente no confiables sobre cómo llegar a una decisión unificada sobre el orden y el contenido de cada transacción.

Y una vez que se establece este 'consenso estricto', la cadena de bloques puede desbloquear muchas características clave, como la protección de los derechos de propiedad digital, modelos de moneda antiinflacionaria y estructuras escalables de colaboración social. Pero la premisa es que el protocolo de consenso en sí mismo debe garantizar dos aspectos fundamentales al mismo tiempo:

• Dos bloques en conflicto no pueden ser confirmados;
• La red debe seguir avanzando y no puede quedarse atascada o detenerse.

MonadBFT es el último avance tecnológico en esta dirección.

Una breve revisión de la evolución de los protocolos de consenso

En el campo del mecanismo de consenso, en realidad se ha estudiado durante décadas. El primer grupo de protocolos, como PBFT (Practical Byzantine Fault Tolerance), ya puede manejar una situación muy realista: incluso si algunos nodos en la red dejan caer la cadena, se comportan maliciosamente o dicen tonterías, siempre y cuando no excedan un tercio del número total, el sistema aún puede alcanzar un consenso.

El diseño de estos primeros protocolos es más "tradicional": se selecciona un líder en cada ronda para iniciar una propuesta, y otros validadores votan en esta propuesta en varias rondas para confirmar gradualmente el orden de las transacciones.

El proceso de votación completo suele pasar por varias etapas, como pre-preparación, preparación, compromiso y respuesta. En cada etapa, todos los validadores necesitan comunicarse entre sí. En otras palabras, todos tienen que decirle a todos los demás, y el volumen de mensajes crece de forma explosiva en un patrón de 'malla'.

La complejidad de esta estructura de comunicación es n², es decir, si hay 100 validadores en la red, cada ronda de consenso puede requerir la transmisión de casi 10,000 mensajes.

En una pequeña red, esto no es un problema, pero una vez que el número de validadores aumenta, la carga de comunicación del sistema rápidamente se volverá insoportable, afectando directamente la eficiencia.

Fuente de información:https://medium.com/coinmonks/pbft-understanding-the-algorithm-b7a7869650ae

La estructura de comunicación secundaria 'todos hablan con todos' es en realidad muy ineficiente. Por ejemplo, en una red con 100 validadores, cada ronda de consenso puede necesitar procesar decenas de miles de mensajes.

Esto todavía se puede gestionar en un círculo pequeño, pero cuando se coloca en una red de cadena global y abierta, la carga de comunicación se vuelve inmediatamente inaceptable. Por lo tanto, los protocolos BFT tempranos como PBFT y Tendermint suelen usarse solo en redes con permisos o sistemas con muy pocos validadores para funcionar apenas.

Para permitir que el protocolo BFT se adapte a entornos de cadena pública sin permisos, algunos diseños de próxima generación se están moviendo hacia métodos de comunicación más ligeros: permitiendo que cada validador se comunique solo con el líder, en lugar de con todos los miembros.

Esto optimiza la complejidad del mensaje de n² original a n, reduciendo en gran medida la carga del sistema.

El protocolo HotStuff fue propuesto en 2018 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 concisa y liderada por un líder.

Una de las características clave de HotStuff es la llamada comunicación lineal. En su mecanismo, cada validador solo necesita enviar su voto al líder actual, quien luego empaqueta estos votos para generar un Certificado de Cuórum (QC).

Este QC es esencialmente una firma colectiva, demostrando a toda la red: 'La mayoría de los nodos están de acuerdo con esta propuesta.'

Por el contrario, el modo de comunicación de PBFT es 'transmitir a todos', donde todos hablan en el grupo, lo que a veces conduce a una escena caótica. El modo de HotStuff es más como 'uno reúne, uno empaca a la vez', lo que puede mantener una operación eficiente independientemente de cuántas personas estén en la red.

La figura compara la estructura de comunicación de salida del ventilador de HotStuff con el modo totalmente interconectado de PBFT Fuente:

https://www.mdpi.com/1424-8220/24/16/5417

Además de la comunicación lineal, HotStuff se puede actualizar aún más a una versión en serie, utilizada para mejorar la eficiencia.

En el HotStuff original, el mismo validador actuará como líder durante múltiples rondas seguidas, hasta que un bloque esté completamente confirmado. Este proceso es 'procesar un bloque por ronda', con todos los esfuerzos centrados en avanzar el actual.

En el pipeline de HotStuff, el mecanismo es aún más flexible: se selecciona un nuevo líder en cada ronda, y cada líder tiene dos tareas:

• Empaquete la última ronda de votos en un Certificado de Quórum (QC) por un lado y transmítalo a toda la red;
• Por un lado, proponga un nuevo bloque, listo para comenzar la siguiente ronda.

En otras palabras, ya no es "confirmar uno antes de procesar el siguiente", sino como una línea de producción, diferentes líderes se turnan para ser responsables de cada paso. El anterior propone un bloque, el siguiente lo confirma y continúa proponiendo nuevos bloques, y 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 ensamblaje”: el bloque actual todavía está en proceso de confirmación, mientras que el siguiente ya está en preparación, múltiples pasos son paralelos, aumentando la eficiencia de rendimiento.

En resumen, protocolos como HotStuff han logrado mejoras significativas en dos dimensiones sobre el BFT tradicional:

• Primero, la comunicación es más ligera, con cada validador solo necesitando comunicarse con el líder;
• En segundo lugar, la eficiencia de procesamiento es mayor y varios procesos de confirmación de bloques pueden ejecutarse en paralelo.

Esto hace que HotStuff sea una plantilla de diseño para muchos mecanismos de consenso blockchain PoS modernos. Pero todo tiene sus pros y sus contras: mientras que la estructura de canalización es potente en rendimiento, también introduce silenciosamente un riesgo estructural no fácilmente descubrible.

A continuación, vamos a adentrarnos en este problema central: Tail Forking.

Problema de bifurcación en cola al final

Aunque HotStuff, especialmente su versión en serie, resuelve el problema de escalabilidad del protocolo de consenso, también introduce algunos desafíos nuevos. El más crucial y fácilmente pasado por alto es el llamado problema de "Tail Forking".

¿Qué es un tenedor de cola? Se puede entender simplemente como: un blockchain experimenta una reorganización accidental de bloques en la 'cola' de la cadena.

Específicamente, hay un bloque que es válido, ha sido propagado con éxito a la mayoría de validadores y ha recibido suficientes votos. En teoría, debería ser confirmado y escrito en la cadena principal inmediatamente. Sin embargo, al final, es "saltado", huérfano y reemplazado por otro nuevo bloque en la misma altura.

Esto no es un error, ni un ataque, sino porque en la estructura de diseño del propio protocolo, existe la posibilidad de este 'seguimiento de cadena'. ¿Suena un poco injusto? Entonces, ¿cómo sucede esto?

Como mencionamos anteriormente, cada líder del pipeline de HotStuff tiene dos tareas:

• A. Proponer un nuevo bloque (como Bₙ₊₁)
• B. Recopilar votos para el bloque del líder anterior para generar QC (por ejemplo, para confirmar finalmente Bₙ)

Estas dos tareas son paralelas, se turnan para transmitir. Pero el problema surge aquí.

Por ejemplo, supongamos que Alice es la líder, y propuso el bloque Bₙ en la altura n, el cual recibió una supermayoría de votos y está "casi confirmado".

A continuación, debería ser el turno de Bob de asumir el papel de líder, continuar avanzando hasta el siguiente bloque Bₙ₊₁ de la cadena, e incluir también el QC (Compromiso Calificado) de Bₙ en su propuesta para completar la confirmación final de Bₙ.

Pero si Bob está desconectado en este momento, o no envía intencionalmente el QC de Bₙ, entonces hay un problema.

Porque nadie empaquetó el bloque de Alice con QC, el registro de votación de Bₙ no se difundió. Este bloque, que debería haber sido confirmado, fue así 'procesado en frío' y finalmente ignorado por toda la red.

Esta es la esencia de un tenedor de cola: se salta un bloque del líder anterior debido a la negligencia o malicia del siguiente líder.

¿Por qué es tan severa la horquilla de la cola?

El problema del tail fork se centra principalmente en dos aspectos: 1) el mecanismo de incentivos se ve interrumpido, 2) la actividad del sistema se ve amenazada.

Primero, las recompensas son engullidas:

Si un bloque es abandonado, el líder que lo propuso no recibirá ninguna recompensa, ya sea recompensas por bloque o tarifas de transacción. Por ejemplo, si Alice propuso un bloque válido y recibió un apoyo abrumador en la votación, pero debido a un error u operación maliciosa de Bob, el bloque no pudo ser confirmado, Alice no recibirá ni un centavo al final. Esto llevará a una estructura de incentivos defectuosa: nodos maliciosos como Bob pueden 'cortar' su fuente de recompensa al saltarse los bloques de sus oponentes. Este comportamiento no requiere ataques técnicos, solo 'no cooperación' deliberada para debilitar las ganancias de los competidores. Si esto sucede repetidamente, con el tiempo, la participación y la equidad de todo el sistema disminuirán, e incluso provocarán la colusión entre nodos.

Segundo, la superficie de ataque de MEV se expande:

Las horquillas de cola también plantean un problema más insidioso pero grave: hay más espacio para que el MEV (Valor Máximo Extraíble) sea 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, socavar la garantía de finalidad, afectando la experiencia del usuario:

En comparación con los protocolos tipo Nakamoto, una gran ventaja de BFT es la finalidad determinista: una vez que se ha comprometido un bloque, no se puede revertir. Sin embargo, el tail fork perturba esta garantía, especialmente en bloques que están 'precomprometidos pero no formalmente confirmados'. Algunas dapps de alto rendimiento a menudo desean leer datos inmediatamente después de la votación del bloque para reducir la latencia, y si el bloque se descarta repentinamente, puede causar una reversión del estado del usuario, como saldos de cuenta anormales, operaciones de alto apalancamiento que acaban de completarse desapareciendo sin motivo alguno, o reinicios repentinos del estado del juego.

Cuarto, puede causar un fallo por reacción en cadena:

En general, un tenedor de cola solo puede retrasar la confirmación de un bloque durante una ronda, lo cual no tiene un gran impacto. Sin embargo, en algunos casos excepcionales, si varios líderes consecutivos eligen saltarse el bloque anterior, el sistema puede quedarse atascado y nadie esté dispuesto a "hacerse cargo" del bloque anterior. Toda la cadena queda atascada hasta que aparezca finalmente un líder dispuesto a asumir la responsabilidad, y la red continuará avanzando.

Aunque ha habido algunas soluciones anteriormente, como el mecanismo de evitación de bifurcación de cola propuesto por el protocolo BeeGees, a menudo requieren sacrificar rendimiento, como reintroducir complejidad de comunicación secundaria, lo cual no vale la pérdida.

¿Qué es MonadBFT?

MonadBFT es un protocolo de consenso de nueva generación diseñado específicamente para abordar el problema de la bifurcación de cola. Su fortaleza radica en: al abordar vulnerabilidades estructurales, no sacrifica las ventajas de rendimiento que aporta el pipeline de HotStuff. En otras palabras, MonadBFT no está comenzando de nuevo, sino que continúa optimizando basado en el marco central de HotStuff. Conserva tres características clave:

1) Líder rotativo: Seleccionar un nuevo líder para cada ronda para impulsar la cadena hacia adelante;
2) Compromisos en serie: Los procesos de confirmación de varios bloques pueden solaparse;
3) Comunicación Lineal (mensajería lineal): Cada validador solo necesita comunicarse con el líder, ahorrando una gran cantidad de sobrecarga de red.

Pero simplemente confiar en estos tres puntos no es lo suficientemente seguro. Para tapar la vulnerabilidad estructural de la horquilla de cola, MonadBFT ha añadido dos mecanismos clave:

1) Mecanismo obligatorio de repropuesta (Re-Proposal)
2) Certificado de No-Endoso (NEC)

Mecanismo de Re-Propuesta

En el protocolo BFT, el tiempo se divide en rondas (llamadas vistas), con un líder en cada ronda responsable de proponer un nuevo bloque. Si el líder falla (por ejemplo, al no proponer un bloque a tiempo o con una propuesta inválida), el sistema cambia a la siguiente ronda y selecciona un nuevo líder.

MonadBFT ha añadido un mecanismo para asegurar que cualquier bloque propuesto honestamente durante el proceso de cambio de vista no ‘dejará caer la cadena’ debido a la rotación del líder.

Cuando el líder actual falla, los validadores enviarán un mensaje firmado para un cambio de ronda (cambio de vista), indicando que la ronda actual ha expirado.

En particular, este mensaje no solo indica 'tiempo agotado', sino que también debe incluir la información de bloque del voto reciente del validador, lo que equivale a decir, 'no recibí una propuesta válida, este es el último bloque que veo actualmente'.

La nueva ronda de líderes recopilará estos mensajes de tiempo de espera de los validadores de la supermayoría (2f+1) y los fusionará en un Certificado de Tiempo de Espera (TC). Este TC representa la instantánea cognitiva unificada del 'bloque de cabeza de cadena' de toda la red cuando falla la ronda anterior. El nuevo líder seleccionará el bloque con la altura más alta (o el número de vista más reciente), conocido como high_tip, de este.

MonadBFT requiere: La propuesta de un nuevo líder debe incluir un TC válido y debe proponer de nuevo el bloque pendiente más alto en el TC para dar a este bloque otra oportunidad de ser confirmado.

¿Por qué? Como se mencionó 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, propuso un bloque válido y recibió la mayoría de los votos. A continuación, cuando el líder de la vista 6, Bob, está fuera de línea y no logra avanzar en el proceso de cadena, para cuando Carol asuma el liderazgo de la vista 7, según las reglas de MonadBFT, ella debe incluir TC y proponer nuevamente 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 firmado de 'No-Endoso (NE)', indicando que el remitente no tiene este bloque (su mecanismo se explica más adelante). (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 para asegurarse de que no esté 'involucrada' debido al fracaso del líder anterior.

El papel de este mecanismo de nueva propuesta es claro: asegurar que el avance de la cadena sea justo, y que ningún trabajo válido sea descartado silenciosamente debido a la mala suerte o al sabotaje de alguien.

Certificado no endosable (NEC)

Continuando con el ejemplo anterior: Después de que se acabe el tiempo de Bob, Carol solicita a otros validadores que proporcionen el bloque de high_tip (es decir, el bloque de Alice). En este punto, al menos 2f+1 validadores responderán:

• Proporcione los bloques de Alice
• Envíe un mensaje NE firmado indicando que no ha recibido el bloque de Alice.

Siempre que Carol reciba el bloque de Alice, debe proponerlo nuevamente según las reglas. Carol solo puede omitir el bloque y proponer uno nuevo cuando al menos f+1 validadores hayan firmado el mensaje NE.

¿Por qué f+1? En un sistema BFT compuesto por 3f+1 validadores, como máximo solo f pueden ser maliciosos. Si el bloque de Alice de hecho recibió una supermayoría de votos, entonces al menos 2f+1 nodos honestos lo recibieron.

Por lo tanto, si Carol afirma: “No puedo obtener el bloque de Alice”, debe producir f+1 firmas de validadores para demostrar que ninguno de ellos lo ha recibido. Esto constituye un Certificado de No-Endoso (NEC).

NEC es la credencial de "descargo de responsabilidad" de un líder: es una evidencia verificable de que el bloque anterior no está listo para ser confirmado, no se omite maliciosamente, sino que se "abandona" con razones.

Re-propuesta + Certificado no respaldado = Resolver la cola bifurcada

MonadBFT introduce un conjunto de reglas de procesamiento de cabezas de cadena rigurosas y claras mediante la introducción del mecanismo de repropuesta y el Certificado de No-Endoso (NEC).

O comprométase finalmente con el bloque 'casi confirmado';

Proporcione pruebas suficientes para demostrar que el bloque aún no está listo para ser confirmado,

De lo contrario, no se permite saltar o reemplazar el bloque anterior.

Este mecanismo asegura que cualquier bloque que haya recibido una mayoría legal de votos no será abandonado debido a errores del líder o a circunvenciones intencionales.

Los riesgos estructurales del tenedor de la cola se resuelven sistemáticamente, y el protocolo puede limitar claramente el comportamiento de salto inadecuado.

Si un líder intenta saltarse el bloque anterior sin proporcionar evidencia NEC, el protocolo lo reconocerá de inmediato y rechazará el comportamiento. El comportamiento de salto sin evidencia criptográfica se considerará ilegal y no recibirá el apoyo del consenso de la red.

Desde una perspectiva de incentivos económicos, este diseño proporciona una protección clara para los validadores:

• Siempre y cuando el bloque se proponga honestamente y reciba apoyo en la votación, su recompensa no será privada debido a fallos posteriores.
• Incluso en situaciones extremas, como cuando un nodo omite deliberadamente su propia ronda de propuesta e intenta ayudar a otros a aprovechar el MEV del bloque anterior, el protocolo obligará al líder subsecuente a priorizar la reproposición del bloque original, evitando que el atacante obtenga beneficios económicos al omitir el proceso.

Más importante aún, MonadBFT no sacrificó el rendimiento del protocolo para mejorar la seguridad.

Algunos diseños que abordan horquillas de cola (como el protocolo BeeGees) en el pasado tienen ciertas capacidades de protección, pero a menudo se basan en una alta complejidad de comunicación (n²) o permiten procesos de comunicación pesados en cada ronda, lo que aumenta significativamente la carga del sistema en la práctica.

La estrategia de diseño de MonadBFT es más sofisticada:

La comunicación adicional (como mensajes de tiempo de espera, reapariciones de bloque) solo se inicia cuando falla la vista o existen anomalías. En la ruta regular donde la mayoría de los líderes honestos producen bloques continuamente, el protocolo aún mantiene un estado operativo ligero y eficiente.

El equilibrio dinámico entre rendimiento y seguridad es precisamente una de las ventajas fundamentales de MonadBFT sobre sus protocolos predecesores.

Resumen

Este artículo revisa el mecanismo básico del consenso tradicional PBFT, ordena el camino de desarrollo del protocolo HotStuff y se centra en cómo MonadBFT resuelve el problema de la bifurcación de cola inherente del pipeline HotStuff en la estructura de capa de protocolo.

Los tenedores traseros pueden distorsionar los incentivos económicos de los proponentes de bloques y representar una amenaza potencial para la actividad de la red. MonadBFT asegura que cualquier bloque propuesto por líderes honestos y aprobado por una mayoría estatutaria no será abandonado ni omitido al introducir un mecanismo de reproposición y un Certificado No Endosado (NEC).

En el próximo artículo, continuaremos explorando las otras dos características principales de MonadBFT:

1）Finalidad especulativa
2）Capacidad de respuesta optimista

Un análisis más detallado de estos mecanismos y su importancia práctica para validadores y desarrolladores.

Declaración:

1. Este artículo es reimpreso de [michael_lwy], el copyright pertenece al autor original [michael_lwy]，si tienes alguna objeción a la reimpresión, por favor contactaEquipo Gate Learn)，el equipo lo manejará lo más pronto posible de acuerdo al proceso relevante.
2. Descargo de responsabilidad: Las opiniones y puntos de vista expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las otras versiones del artículo en otros idiomas son traducidas por el equipo de Gate Learn, sin mencionarGate.ioNo copie, distribuya o plagie artículos traducidos sin permiso.