EnParte 1,examinamos cómo funciona el consenso clásico PBFT y cómo operan las versiones anteriores de HotStuff. También analizamos cómo MonadBFT resuelve el problema de bifurcación de cola de HotStuff, que es un problema en el que a veces se dejan atrás bloques válidos en sistemas en línea.

Este problema de bifurcación de cola crea dos grandes problemas: 1) desordena las recompensas para los constructores de bloques honestos y 2) puede potencialmente paralizar la red.

MonadBFT introduce la regla de Reproposal y los mecanismos de voto sin aval para eliminar el problema de tail-forking, asegurando que cualquier bloque correctamente aprobado de un proponente honesto siempre se incluirá en la cadena.

En la parte 2 exploramos las otras dos características de MonadBFT que son 1) finalidad especulativa y 2) capacidad de respuesta optimista. También exploraremos las implicaciones de MonadBFT para los desarrolladores.

Finalidad especulativa de una ronda

Además de la resistencia a la bifurcación de cola, otra característica importante de MonadBFT es la finalidad especulativa dentro de una sola ronda.

En términos prácticos, esto significa que los clientes y usuarios pueden recibir una confirmación de su transacción inmediatamente después de que un bloque reciba una supermayoría de votos, incluso antes de que se complete la próxima ronda.

Recuerde que en los protocolos de línea base HotStuff, un bloque generalmente no se considera final (irreversible) hasta que haya pasado por al menos dos fases (por ejemplo, Fast-Hotstuff y Diem-BFT): una fase para obtener un Certificado de Cuórum (bloquear el bloque con ≥2f+1 votos), y una segunda fase en la que el próximo líder se basa en ese CC y compromete el bloque.

Este compromiso de dos fases es necesario para garantizar la seguridad: una vez que suficientes nodos honestos han bloqueado un bloque, ningún bloque conflictivo puede reunir un quórum, y el compromiso en la siguiente ronda lo hace permanente. Por lo tanto, normalmente, un cliente podría tener que esperar a que se produzca el siguiente bloque o la siguiente ronda antes de saber que la transacción anterior es definitiva.

MonadBFT básicamente permite que una transacción se considere lo suficientemente final (segura para actuar) después de solo una ronda de votación. Esto se llama finalidad especulativa.

Cuando un líder propone un bloque y los validadores votan para formar un CQ para ese bloque, ese bloque está ahora en un estado Votado (está bloqueado por un quórum). En MonadBFT, los validadores ejecutarán las transacciones del bloque tan pronto como formen el CQ e incluso enviarán una confirmación preliminar a los clientes indicando que el bloque está (especulativamente) aceptado. Esto es como decir: 'Tenemos una supermayoría de acuerdo en este bloque. A menos que ocurra algo muy inesperado, considera este bloque confirmado'.

Esta confirmación inmediata es optimista. El bloque aún no se ha confirmado en el libro mayor. Eso sucederá cuando llegue la próxima propuesta y la finalice (QC-on QC), pero bajo condiciones normales, nada lo revocará. El único escenario que puede revertir un bloque ejecutado especulativamente es si el líder se equivocó (es decir, propuso dos bloques diferentes en la misma altura para dividir el voto).

Puede considerar la finalidad especulativa como un buen subproducto de la resistencia al tail-forking. La resistencia al tail-forking garantiza que incluso si el próximo líder se bloquea, la propuesta actual no se abandonará (gracias a las reglas de reproposición y NEC). Por lo tanto, el único momento en que se elimina un bloque ejecutado especulativamente es si el proponente original equivocó (falta de doble firma que es demostrablemente maliciosa), que es: 1) detectable a través de CQ conflictivas, 2) punible con pérdida y 3) extremadamente raro.

En protocolos anteriores, no garantizaban que el próximo líder volviera a proponer el bloque anterior, por lo que era posible el tail-forking, rompiendo suposiciones de especulación.

Respuesta Optimista

En la mayoría de los protocolos de consenso, hay una espera incorporada después de cada ronda, como un período de espera o tiempo de espera. Esto es para asegurarse de que todos los mensajes hayan llegado antes de avanzar. Es un mecanismo de protección destinado a manejar el peor de los casos, como cuando un líder se bloquea o no envía nada en absoluto.

Estos tiempos de espera a menudo son demasiado conservadores. Si la red está funcionando normalmente y todos los validadores se comportan correctamente, esa espera fija se convierte en una sobrecarga innecesaria. Los bloques podrían haber sido finalizados más rápido, pero el protocolo se contuvo por si acaso.

MonadBFT introduce una capacidad de respuesta optimista, lo que significa que el protocolo puede avanzar inmediatamente en función de los mensajes de la red, en lugar de depender siempre de temporizadores fijos. El principio de diseño aquí se puede resumir como "rápido cuando puede, paciente cuando debe."

MonadBFT está diseñado de tal manera que tanto en el caso normal como incluso en la recuperación de una falla, no se detiene durante un tiempo de espera predeterminado si no es necesario.

• En el camino feliz (significa que tenemos un líder honesto): No hay retraso incorporado en la propuesta o votación. Tan pronto como un líder tiene el turno, propone un bloque. Tan pronto como los validadores reciben una propuesta válida, votan. En el momento en que el líder (o más bien, el próximo líder, ya que los votos van al próximo proponente en HotStuff en línea) recoge 2f+1 votos, se forma el QC y se puede diseminar. En un diseño optimista y receptivo, esto desencadena la siguiente fase inmediatamente.

En la práctica, esto significa que si la latencia de red entre los nodos es, digamos, 100 ms, el consenso potencialmente puede terminar una ronda en solo un par de cientos de milisegundos (más los gastos generados por la computación y la agregación).

No espera, por ejemplo, un segundo completo de "tiempo de ranura" si no es necesario. Esto contrasta con la red principal de Ethereum que sigue unamodelo de espacio y épocaEn Ethereum, la producción de bloques está fijada en intervalos de 12 segundos. Incluso si todos están listos antes, el protocolo espera.

El enfoque de MonadBFT elimina retrasos innecesarios. Conserva la estructura de HotStuff en línea pero elimina la rígida regla de "debes esperar Δ segundos" en el caso normal. Esto significa que puede superar a los sistemas limitados por tiempo en capacidad de respuesta sin sacrificar la seguridad.

• En la ruta infeliz (falla del líder): En muchos protocolos de consenso, cuando un líder falla al proponer un bloque, otros nodos solo se dan cuenta de esto después de que haya pasado un tiempo de espera Δ. Si Δ es, por ejemplo, 1 segundo, ese tiempo se pierde esencialmente. MonadBFT maneja esto de manera diferente. Cuando los validadores detectan una propuesta faltante, inmediatamente transmiten mensajes de tiempo de espera (TC o Certificado de Tiempo de Espera). Tan pronto como se vean 2f+1 de estos tiempos de espera, el próximo líder toma el control. La transición a la nueva vista es desencadenada por evidencia basada en quórum, no por el reloj.

Comparación con el consenso de la familia hotstuff

MonadBFT se basa en la línea de protocolos de consenso de la familia HotStuff, pero se destaca al lograr una combinación de propiedades deseables que ningún diseño previo ha logrado integrar completamente sin compromisos. Los protocolos anteriores a menudo estaban optimizados para algunas dimensiones como el rendimiento en serie o la comunicación lineal, pero tenían que sacrificar otras. MonadBFT logra combinar de manera única una complejidad de mensajería lineal, compromisos en serie, resistencia fuerte a bifurcaciones de cola, capacidad de respuesta instantánea sin retrasos fijos y mecanismos de recuperación eficientes, todo mientras preserva la finalidad rápida y garantías de alta vivacidad. La tabla a continuación resume cómo MonadBFT se compara con otros protocolos BFT de líder rotativo en estas dimensiones críticas:

¿Qué significa esto para los desarrolladores y usuarios?

Para los desarrolladores, MonadBFT significa un par de cosas:

• Modelo de Finalidad más Simple: Con MonadBFT, puedes tratar un bloque que tiene un QC (votación de supermayoría) como efectivamente finalizado para la mayoría de propósitos, porque el protocolo lo finalizará o penalizará si no. Los desarrolladores pueden actuar de forma segura en confirmaciones de 1 bloque con alta confianza.
• Mejora de la UX para aplicaciones: Si estás desarrollando una aplicación de alto rendimiento (intercambio, juego, etc.), la baja latencia y la resistencia a bifurcaciones de MonadBFT se traducen en una experiencia de usuario más fluida. Los usuarios ven sus acciones confirmadas casi al instante y rara vez se encuentran con reorganizaciones o retrocesos confusos. Esto te permite diseñar aplicaciones que asumen la finalidad y actualizaciones rápidas.
• Comportamiento determinístico: las reglas más estrictas de MonadBFT (como el requisito de reproposición) reducen la no determinismo en la inclusión de bloques. Hay menos escenarios de "casos límite" en los que un bloque podría ser incluido o saltado dependiendo de la temporización sutil, como si un voto o un tiempo de espera alcanzara primero al líder. MonadBFT reemplaza tal ambigüedad sensible al tiempo con reglas explícitas y evidencia verificable. Esto facilita razonar sobre la corrección del protocolo y probarlo. También proporciona motivos claros para identificar nodos defectuosos (por ejemplo, si alguien no vuelve a proponer o propone un bloque en conflicto, sabes que violaron el protocolo).
• Margen de escalabilidad: Si eres un desarrollador preocupado por la escalabilidad, MonadBFT te brinda más margen antes de alcanzar cuellos de botella. Puedes aumentar los tamaños de bloque o el número de validadores de manera más cómoda que en un protocolo cuadrático. Y características como la difusión de bloques con codificación de borrado significan que puedes enviar una gran cantidad de datos a través de la red sin sobrecargar los nodos individuales. Esto hace posible apuntar a una mayor capacidad de procesamiento que abre espacio de diseño para aplicaciones en cadena más ambiciosas.

Para los usuarios finales: un usuario común no sabrá sobre nada de lo que discutimos aquí, pero siente sus efectos. Con MonadBFT como base de Monad en la cadena, los usuarios pueden esperar todas las cualidades agradables a continuación sin sacrificar la descentralización y la resistencia a la censura.

• Confirmaciones más rápidas: Las transacciones (como enviar tokens, intercambiar activos, acuñar NFT, ejecutar operaciones) se confirmarán muy rápidamente.
• Menos Sorpresas: La consistencia del estado de la cadena es mayor, ya que se elimina cosas como el tail-forking, que es básicamente una reorganización
• Equidad y Transparencia: Las mejoras en el consenso significan indirectamente que la operación de la cadena es más justa. Ningún validador individual puede censurar fácilmente transacciones o jugar con el orden en los bloques.

Conclusión

Para recapitular, MonadBFT introduce cuatro innovaciones fundamentales sobre el consenso de estilo HotStuff con canalización:

Resistencia a Colas Bifurcadas: MonadBFT es el primer protocolo BFT en línea para eliminar los ataques de colas bifurcadas. Logra esto al requerir que el próximo líder vuelva a proponer el último bloque votado si el líder anterior falló, o de lo contrario muestre un Certificado de No-Endoso (NEC) como prueba de que el bloque carecía de apoyo. Esto garantiza que ningún bloque respaldado por una supermayoría será abandonado, protegiendo las recompensas de los líderes honestos y evitando reorganizaciones maliciosas y la extracción de MEV entre bloques.

Finalidad especulativa en una ronda: Los validadores pueden confirmar un bloque después de una sola ronda de comunicación (una propuesta de líder y votos), brindando a los clientes una garantía inmediata de inclusión. Esta confirmación especulativa solo se revertirá si el líder equivoca (un acto que puede ser probado y castigado), lo que lo convierte en una suposición segura en la práctica.

Capacidad de respuesta optimista: El protocolo opera a la velocidad de la red sin retrasos inherentes. Los líderes avanzan en el consenso tan pronto como se reciben los votos necesarios, y los cambios de vista ocurren tan pronto como se observa un quórum de tiempos de espera, en lugar de esperar un intervalo de tiempo fijo. Este diseño optimista y receptivo minimiza los tiempos de espera y maximiza el rendimiento, mientras maneja de manera robusta la asincronía y las fallas cuando ocurren.

Comunicación Lineal: En el camino feliz (significando que el líder es honesto), la complejidad del mensaje y la autenticación es lineal en el número de validadores. MonadBFT conserva el patrón de comunicación eficiente de HotStuff, utilizando firmas agregadas y transmisiones simples de líder a validadores, lo que permite que el protocolo escale a cientos de validadores sin cuellos de botella de rendimiento.

Descargo de responsabilidad：

1. Este artículo ha sido reimpreso de [michael_lwy]. Todos los derechos de autor pertenecen al autor original [michael_lwy]. Si hay objeciones a esta reimpresión, por favor contacte alGate Learnequipo, y lo resolverán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.