En la primera parte, investigamos cómo funciona el consenso clásico PBFT (Tolerancia Byzantine a fallos práctica) y cómo operan las primeras versiones de HotStuff. También aprendimos cómo MonadBFT resuelve el problema de bifurcación final de HotStuff, es decir, el problema de que los bloques válidos a veces son descartados en sistemas de tuberías.
Este problema de bifurcación causa dos problemas principales: 1) Interfiere con las recompensas de los constructores de bloques honestos, 2) Puede llevar a un estancamiento de la red.
MonadBFT introdujo reglas de re-propuesta y un mecanismo de votación sin respaldo para eliminar el problema de bifurcación en el tail, asegurando que cualquier bloque debidamente aprobado de proponentes honestos pueda entrar en la cadena.
En la segunda parte, exploraremos otras dos características de MonadBFT: 1) la finalización especulativa y 2) la capacidad de respuesta optimista. También discutiremos el impacto de MonadBFT en los desarrolladores.
Finalidad de especulación de una sola ronda
Además de resistir bifurcaciones en la cola, otra característica principal de MonadBFT es la finalización especulativa de una sola ronda.
En la práctica, esto significa que los clientes y los usuarios pueden recibir la confirmación de la transacción inmediatamente después de que el bloque obtenga la mayoría de los votos, incluso antes de que se complete la siguiente ronda.
Recuerda que, en el protocolo HotStuff de referencia, un bloque generalmente debe pasar por al menos dos etapas (como Fast-Hotstuff y Diem-BFT) para ser considerado finalizado (irreversible): una etapa obtiene un certificado de número legal (QC) (bloqueando el bloque con ≥2f+1 votos), la segunda etapa es que el siguiente líder construye y presenta el bloque basado en ese certificado de número legal (QC).
Este compromiso en dos fases es necesario para garantizar la seguridad: una vez que un número suficiente de nodos honestos ha bloqueado un bloque, los bloques en conflicto no pueden alcanzar el quórum, y la siguiente ronda de compromisos lo hará permanente. Por lo tanto, el cliente generalmente puede necesitar esperar hasta que se genere el siguiente bloque o la siguiente ronda antes de saber si la transacción anterior se ha confirmado de forma definitiva.
MonadBFT básicamente permite que las transacciones se consideren suficientemente finales (operables de manera segura) después de solo una ronda de votación. Esto se conoce como finalización especulativa.
Cuando un líder propone un Bloquear y los validadores votan para formar el QC de dicho Bloquear, este Bloquear se encuentra en estado de votación (bloqueado por el número legal de personas). En MonadBFT, una vez que los validadores forman el QC, ejecutan inmediatamente las transacciones de ese Bloquear e incluso envían a los clientes una confirmación preliminar, indicando que el Bloquear ha sido (especulativamente) aceptado. Es como decir "tenemos una abrumadora mayoría que está de acuerdo con este Bloquear. A menos que ocurra algo muy inesperado, se puede considerar que este Bloquear está confirmado."
Esta confirmación instantánea es optimista. El Bloquear aún no se ha presentado en el libro mayor. Esto sucederá cuando aparezca la próxima propuesta y se confirme (QC-on QC), pero en circunstancias normales, nada lo revocará. La única situación que puede revocar un Bloquear de ejecución especulativa es un ataque equivalente por parte del líder (es decir, proponer dos Bloquear diferentes en la misma altura para dispersar el voto).
Puedes ver la finalización especulativa como un buen subproducto de la resistencia a los forks de cola. La resistencia a los forks de cola garantiza que, incluso si el próximo líder falla, la propuesta actual no será descartada (gracias a la reproposición y las reglas de NEC). La única situación en la que se descartan los bloques de ejecución especulativa es cuando el proponente original sufre un ataque equivalente (un error de doble firma demostrablemente malicioso), y esta situación: 1) puede ser detectada a través de QC de conflicto; 2) puede ser castigada; 3) es extremadamente rara.
En el protocolo anterior, no garantizaban que el siguiente líder volvería a presentar el bloque anterior, por lo que la bifurcación de la cola es posible, rompiendo así la hipótesis especulativa.
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 amortiguamiento o un tiempo de espera. Esto es para asegurarse de que todos los mensajes hayan llegado antes de continuar. Es un mecanismo de protección diseñado para manejar las peores situaciones, como el colapso del líder o la falta total de envío de información.
Estos tiempos de espera suelen ser demasiado conservadores. Si la red funciona correctamente y todos los validadores se comportan adecuadamente, entonces la espera fija se convierte en un gasto innecesario. Los bloques podrían completarse más rápido, pero el protocolo los ha retrasado por si acaso.
MonadBFT introdujo la capacidad de respuesta optimista, lo que significa que el protocolo puede avanzar inmediatamente basado en la información de la red, en lugar de depender siempre de un temporizador fijo. El principio de diseño aquí se puede resumir como "si se puede ir rápido, se va rápido; solo se es paciente cuando es necesario".
El diseño de MonadBFT permite que, en condiciones normales e incluso durante la recuperación de fallos, no se detenga a esperar un tiempo de espera programado si no es necesario.
En la ruta feliz (lo que significa que tenemos un líder honesto): No hay retrasos integrados en las propuestas o votaciones. Una vez que es el turno del líder, propone un bloque. Los validadores votan inmediatamente al recibir una propuesta válida. Cuando el líder (o más precisamente, el siguiente líder, porque en el pipeline HotStuff, los votos se envían al siguiente proponente) recoge 2f+1 votos, se forma QC y se puede difundir. En un diseño de respuesta optimista, esto desencadenará inmediatamente la siguiente etapa.
En la práctica, esto significa que si la latencia de la red entre los nodos es de 100 milisegundos, el consenso podría completarse en solo unos pocos cientos de milisegundos para una ronda (sumando los costos de cálculo y agregación).
Si no es necesario, no esperará, por ejemplo, el "tiempo de ranura" de un segundo completo. Esto es diferente del modelo de ranura y época adoptado por la red principal de Ethereum. En Ethereum, el intervalo de tiempo para la producción de bloques está fijado en 12 segundos. Incluso si todos están preparados con antelación, el protocolo esperará.
El enfoque de MonadBFT elimina los retrasos innecesarios. Conserva la estructura de HotStuff en pipeline, pero elimina la estricta regulación de "debe esperar Δ segundos" en circunstancias normales. Esto significa que puede superar a los sistemas con restricciones de tiempo en términos de capacidad de respuesta, sin sacrificar la seguridad.
En la ruta de la infelicidad (fallo del líder): En muchos protocolos de consenso, cuando el líder no logra proponer un bloque, otros nodos solo se darán cuenta de esto después de un tiempo de espera Δ. Por ejemplo, si Δ es de 1 segundo, entonces ese tiempo se desperdicia esencialmente. La forma en que MonadBFT maneja esto es diferente. Cuando los validadores detectan que la propuesta se ha perdido, inmediatamente transmiten un mensaje de tiempo de espera (TC o certificado de tiempo de espera). Una vez que ocurren 2f+1 tiempos de espera, el próximo líder toma el control. La transición a una nueva vista es provocada por pruebas basadas en el quórum, no por el reloj.
Comparación con el consenso de hotstuff-family
MonadBFT se basa en la serie de protocolos de consenso HotStuff, pero se destaca al implementar una combinación de una serie de características ideales. Los protocolos tempranos a menudo se optimizaban para ciertas dimensiones, como el rendimiento de la canalización o la comunicación lineal, pero tenían que sacrificar otros aspectos. MonadBFT combina de manera única la complejidad de mensajes lineales, la presentación en canalización, una potente resistencia a bifurcaciones de cola, la capacidad de respuesta instantánea sin retraso fijo y un mecanismo de recuperación eficiente, al tiempo que conserva la rápida finalización y garantías de alta disponibilidad. La siguiente tabla resume la comparación de MonadBFT con otros protocolos BFT de liderazgo rotativo en estas dimensiones clave:
¿Qué significa esto para los desarrolladores y los usuarios?
Para los desarrolladores, MonadBFT significa varios puntos:
Modelo de determinación final más simple: Usando MonadBFT, puede considerar los bloques con QC (votación de la gran mayoría) como realmente finalizados, ya que el protocolo los finalizará o impondrá una penalización. Los desarrolladores pueden operar con un alto grado de confianza de manera segura con 1 confirmación de bloque.
Mejorar la experiencia del usuario de la aplicación: Si está construyendo una aplicación de alto rendimiento (intercambio, juegos, etc.), la baja latencia y la resistencia a fork de MonadBFT se traducirán en una experiencia de usuario más fluida. Los usuarios pueden ver casi de inmediato que sus operaciones son confirmadas, y no se encontrarán a menudo con confusas reorganizaciones o retrocesos. De esta manera, puede diseñar aplicaciones con determinación final y actualizaciones rápidas.
Comportamiento determinista: las reglas más estrictas de MonadBFT (como los requisitos de re-propuesta) reducen la incertidumbre en la inclusión de bloques. Debido a factores sutiles de tiempo, como si los votos o los tiempos de espera llegan primero al líder, hay menos "casos límite" en los que los bloques son incluidos o saltados. MonadBFT reemplaza esta ambigüedad sensible al tiempo con reglas claras y evidencia verificable. Esto facilita la corrección de los protocolos de inferencia y las pruebas. También proporciona una base clara para identificar nodos fallidos (por ejemplo, si alguien no logra re-proponer o propone bloques en conflicto, usted sabe que han violado el protocolo).
Espacio de escalabilidad: Si usted es un desarrollador preocupado por la escalabilidad, MonadBFT le ofrece más espacio antes de encontrar cuellos de botella. En comparación con los protocolos secundarios, puede aumentar más fácilmente el tamaño del bloque o el número de validadores. Además, funciones como la propagación de bloques mediante codificación borrada significan que puede enviar grandes cantidades de datos a través de la red sin agotar excesivamente un solo nodo. Esto hace posible apuntar a un mayor rendimiento, abriendo espacio de diseño para aplicaciones en cadena más ambiciosas.
Para el usuario final: Los usuarios comunes no entenderán nada de lo que estamos discutiendo aquí, pero sentirán su impacto. Con MonadBFT como base de la cadena Monad, los usuarios pueden esperar todas las buenas características a continuación sin sacrificar la descentralización y la resistencia a la censura.
Confirmación más rápida: Las transacciones (como enviar tokens, intercambiar activos, acuñar NFT, ejecutar transacciones) serán confirmadas rápidamente.
Reducir accidentes: La consistencia del estado de la cadena es más alta, ya que cosas como los forks de cola, que esencialmente pertenecen a la reorganización, se han eliminado.
Justicia y transparencia: La mejora del consenso implica indirectamente que el funcionamiento de la cadena es más justo. Ningún validador individual puede revisar fácilmente las transacciones o manipular el orden entre bloques.
Conclusión
En resumen, MonadBFT introduce cuatro innovaciones clave sobre la base del consenso estilo HotStuff en pipeline:
Resistencia a bifurcaciones finales: MonadBFT es el primer protocolo BFT en línea que elimina ataques de bifurcaciones finales. Logra esto al permitir que el próximo líder vuelva a proponer el bloque de la última votación en caso de que el líder anterior falle, o presente un Certificado de No Respaldo (NEC) para demostrar que el bloque carece de apoyo. Esto garantiza que cualquier bloque que reciba el apoyo de la gran mayoría no será desechado, protegiendo así las recompensas de los líderes honestos y previniendo la reorganización maliciosa y la extracción de MEV entre bloques.
Finalidad de la especulación de una sola ronda: los validadores pueden confirmar bloques después de una comunicación de una sola ronda (una propuesta de un líder y una votación), proporcionando a los clientes una garantía de inclusión inmediata. Esta confirmación especulativa solo se restablecerá en caso de un ataque equivalente del líder (un comportamiento que puede ser probado y castigado), lo que la convierte en una suposición de seguridad en la práctica.
Capacidad de respuesta optimista: el protocolo se ejecuta a la velocidad de la red sin latencia inherente. Los líderes avanzan en el consenso tan pronto como reciben los votos necesarios, y los cambios de vista ocurren tan pronto como se observa un tiempo de espera de quórum, en lugar de esperar un intervalo de tiempo de espera fijo. Este diseño con capacidad de respuesta optimista minimiza los tiempos de espera y maximiza el rendimiento, a la vez que sigue siendo robusto en caso de asincronías y errores.
Comunicación lineal: En la ruta feliz (es decir, el líder es honesto), la complejidad de los mensajes y la verificación tiene una relación lineal con el número de validadores. MonadBFT conserva el eficiente modo de comunicación de HotStuff, utilizando firmas agregadas y un simple líder para la difusión a los validadores, lo que permite que el protocolo se expanda a cientos de validadores sin cuellos de botella en el rendimiento.
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 2): ¿Qué significa para desarrolladores y usuarios?
En la primera parte, investigamos cómo funciona el consenso clásico PBFT (Tolerancia Byzantine a fallos práctica) y cómo operan las primeras versiones de HotStuff. También aprendimos cómo MonadBFT resuelve el problema de bifurcación final de HotStuff, es decir, el problema de que los bloques válidos a veces son descartados en sistemas de tuberías.
Este problema de bifurcación causa dos problemas principales: 1) Interfiere con las recompensas de los constructores de bloques honestos, 2) Puede llevar a un estancamiento de la red.
MonadBFT introdujo reglas de re-propuesta y un mecanismo de votación sin respaldo para eliminar el problema de bifurcación en el tail, asegurando que cualquier bloque debidamente aprobado de proponentes honestos pueda entrar en la cadena.
En la segunda parte, exploraremos otras dos características de MonadBFT: 1) la finalización especulativa y 2) la capacidad de respuesta optimista. También discutiremos el impacto de MonadBFT en los desarrolladores.
Finalidad de especulación de una sola ronda
Además de resistir bifurcaciones en la cola, otra característica principal de MonadBFT es la finalización especulativa de una sola ronda.
En la práctica, esto significa que los clientes y los usuarios pueden recibir la confirmación de la transacción inmediatamente después de que el bloque obtenga la mayoría de los votos, incluso antes de que se complete la siguiente ronda.
Recuerda que, en el protocolo HotStuff de referencia, un bloque generalmente debe pasar por al menos dos etapas (como Fast-Hotstuff y Diem-BFT) para ser considerado finalizado (irreversible): una etapa obtiene un certificado de número legal (QC) (bloqueando el bloque con ≥2f+1 votos), la segunda etapa es que el siguiente líder construye y presenta el bloque basado en ese certificado de número legal (QC).
Este compromiso en dos fases es necesario para garantizar la seguridad: una vez que un número suficiente de nodos honestos ha bloqueado un bloque, los bloques en conflicto no pueden alcanzar el quórum, y la siguiente ronda de compromisos lo hará permanente. Por lo tanto, el cliente generalmente puede necesitar esperar hasta que se genere el siguiente bloque o la siguiente ronda antes de saber si la transacción anterior se ha confirmado de forma definitiva.
MonadBFT básicamente permite que las transacciones se consideren suficientemente finales (operables de manera segura) después de solo una ronda de votación. Esto se conoce como finalización especulativa.
Cuando un líder propone un Bloquear y los validadores votan para formar el QC de dicho Bloquear, este Bloquear se encuentra en estado de votación (bloqueado por el número legal de personas). En MonadBFT, una vez que los validadores forman el QC, ejecutan inmediatamente las transacciones de ese Bloquear e incluso envían a los clientes una confirmación preliminar, indicando que el Bloquear ha sido (especulativamente) aceptado. Es como decir "tenemos una abrumadora mayoría que está de acuerdo con este Bloquear. A menos que ocurra algo muy inesperado, se puede considerar que este Bloquear está confirmado."
Esta confirmación instantánea es optimista. El Bloquear aún no se ha presentado en el libro mayor. Esto sucederá cuando aparezca la próxima propuesta y se confirme (QC-on QC), pero en circunstancias normales, nada lo revocará. La única situación que puede revocar un Bloquear de ejecución especulativa es un ataque equivalente por parte del líder (es decir, proponer dos Bloquear diferentes en la misma altura para dispersar el voto).
Puedes ver la finalización especulativa como un buen subproducto de la resistencia a los forks de cola. La resistencia a los forks de cola garantiza que, incluso si el próximo líder falla, la propuesta actual no será descartada (gracias a la reproposición y las reglas de NEC). La única situación en la que se descartan los bloques de ejecución especulativa es cuando el proponente original sufre un ataque equivalente (un error de doble firma demostrablemente malicioso), y esta situación: 1) puede ser detectada a través de QC de conflicto; 2) puede ser castigada; 3) es extremadamente rara.
En el protocolo anterior, no garantizaban que el siguiente líder volvería a presentar el bloque anterior, por lo que la bifurcación de la cola es posible, rompiendo así la hipótesis especulativa.
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 amortiguamiento o un tiempo de espera. Esto es para asegurarse de que todos los mensajes hayan llegado antes de continuar. Es un mecanismo de protección diseñado para manejar las peores situaciones, como el colapso del líder o la falta total de envío de información.
Estos tiempos de espera suelen ser demasiado conservadores. Si la red funciona correctamente y todos los validadores se comportan adecuadamente, entonces la espera fija se convierte en un gasto innecesario. Los bloques podrían completarse más rápido, pero el protocolo los ha retrasado por si acaso.
MonadBFT introdujo la capacidad de respuesta optimista, lo que significa que el protocolo puede avanzar inmediatamente basado en la información de la red, en lugar de depender siempre de un temporizador fijo. El principio de diseño aquí se puede resumir como "si se puede ir rápido, se va rápido; solo se es paciente cuando es necesario".
El diseño de MonadBFT permite que, en condiciones normales e incluso durante la recuperación de fallos, no se detenga a esperar un tiempo de espera programado si no es necesario.
En la ruta feliz (lo que significa que tenemos un líder honesto): No hay retrasos integrados en las propuestas o votaciones. Una vez que es el turno del líder, propone un bloque. Los validadores votan inmediatamente al recibir una propuesta válida. Cuando el líder (o más precisamente, el siguiente líder, porque en el pipeline HotStuff, los votos se envían al siguiente proponente) recoge 2f+1 votos, se forma QC y se puede difundir. En un diseño de respuesta optimista, esto desencadenará inmediatamente la siguiente etapa.
En la práctica, esto significa que si la latencia de la red entre los nodos es de 100 milisegundos, el consenso podría completarse en solo unos pocos cientos de milisegundos para una ronda (sumando los costos de cálculo y agregación).
Si no es necesario, no esperará, por ejemplo, el "tiempo de ranura" de un segundo completo. Esto es diferente del modelo de ranura y época adoptado por la red principal de Ethereum. En Ethereum, el intervalo de tiempo para la producción de bloques está fijado en 12 segundos. Incluso si todos están preparados con antelación, el protocolo esperará.
El enfoque de MonadBFT elimina los retrasos innecesarios. Conserva la estructura de HotStuff en pipeline, pero elimina la estricta regulación de "debe esperar Δ segundos" en circunstancias normales. Esto significa que puede superar a los sistemas con restricciones de tiempo en términos de capacidad de respuesta, sin sacrificar la seguridad.
En la ruta de la infelicidad (fallo del líder): En muchos protocolos de consenso, cuando el líder no logra proponer un bloque, otros nodos solo se darán cuenta de esto después de un tiempo de espera Δ. Por ejemplo, si Δ es de 1 segundo, entonces ese tiempo se desperdicia esencialmente. La forma en que MonadBFT maneja esto es diferente. Cuando los validadores detectan que la propuesta se ha perdido, inmediatamente transmiten un mensaje de tiempo de espera (TC o certificado de tiempo de espera). Una vez que ocurren 2f+1 tiempos de espera, el próximo líder toma el control. La transición a una nueva vista es provocada por pruebas basadas en el quórum, no por el reloj.
Comparación con el consenso de hotstuff-family
MonadBFT se basa en la serie de protocolos de consenso HotStuff, pero se destaca al implementar una combinación de una serie de características ideales. Los protocolos tempranos a menudo se optimizaban para ciertas dimensiones, como el rendimiento de la canalización o la comunicación lineal, pero tenían que sacrificar otros aspectos. MonadBFT combina de manera única la complejidad de mensajes lineales, la presentación en canalización, una potente resistencia a bifurcaciones de cola, la capacidad de respuesta instantánea sin retraso fijo y un mecanismo de recuperación eficiente, al tiempo que conserva la rápida finalización y garantías de alta disponibilidad. La siguiente tabla resume la comparación de MonadBFT con otros protocolos BFT de liderazgo rotativo en estas dimensiones clave:
¿Qué significa esto para los desarrolladores y los usuarios?
Para los desarrolladores, MonadBFT significa varios puntos:
Modelo de determinación final más simple: Usando MonadBFT, puede considerar los bloques con QC (votación de la gran mayoría) como realmente finalizados, ya que el protocolo los finalizará o impondrá una penalización. Los desarrolladores pueden operar con un alto grado de confianza de manera segura con 1 confirmación de bloque.
Mejorar la experiencia del usuario de la aplicación: Si está construyendo una aplicación de alto rendimiento (intercambio, juegos, etc.), la baja latencia y la resistencia a fork de MonadBFT se traducirán en una experiencia de usuario más fluida. Los usuarios pueden ver casi de inmediato que sus operaciones son confirmadas, y no se encontrarán a menudo con confusas reorganizaciones o retrocesos. De esta manera, puede diseñar aplicaciones con determinación final y actualizaciones rápidas.
Comportamiento determinista: las reglas más estrictas de MonadBFT (como los requisitos de re-propuesta) reducen la incertidumbre en la inclusión de bloques. Debido a factores sutiles de tiempo, como si los votos o los tiempos de espera llegan primero al líder, hay menos "casos límite" en los que los bloques son incluidos o saltados. MonadBFT reemplaza esta ambigüedad sensible al tiempo con reglas claras y evidencia verificable. Esto facilita la corrección de los protocolos de inferencia y las pruebas. También proporciona una base clara para identificar nodos fallidos (por ejemplo, si alguien no logra re-proponer o propone bloques en conflicto, usted sabe que han violado el protocolo).
Espacio de escalabilidad: Si usted es un desarrollador preocupado por la escalabilidad, MonadBFT le ofrece más espacio antes de encontrar cuellos de botella. En comparación con los protocolos secundarios, puede aumentar más fácilmente el tamaño del bloque o el número de validadores. Además, funciones como la propagación de bloques mediante codificación borrada significan que puede enviar grandes cantidades de datos a través de la red sin agotar excesivamente un solo nodo. Esto hace posible apuntar a un mayor rendimiento, abriendo espacio de diseño para aplicaciones en cadena más ambiciosas.
Para el usuario final: Los usuarios comunes no entenderán nada de lo que estamos discutiendo aquí, pero sentirán su impacto. Con MonadBFT como base de la cadena Monad, los usuarios pueden esperar todas las buenas características a continuación sin sacrificar la descentralización y la resistencia a la censura.
Confirmación más rápida: Las transacciones (como enviar tokens, intercambiar activos, acuñar NFT, ejecutar transacciones) serán confirmadas rápidamente.
Reducir accidentes: La consistencia del estado de la cadena es más alta, ya que cosas como los forks de cola, que esencialmente pertenecen a la reorganización, se han eliminado.
Justicia y transparencia: La mejora del consenso implica indirectamente que el funcionamiento de la cadena es más justo. Ningún validador individual puede revisar fácilmente las transacciones o manipular el orden entre bloques.
Conclusión
En resumen, MonadBFT introduce cuatro innovaciones clave sobre la base del consenso estilo HotStuff en pipeline:
Resistencia a bifurcaciones finales: MonadBFT es el primer protocolo BFT en línea que elimina ataques de bifurcaciones finales. Logra esto al permitir que el próximo líder vuelva a proponer el bloque de la última votación en caso de que el líder anterior falle, o presente un Certificado de No Respaldo (NEC) para demostrar que el bloque carece de apoyo. Esto garantiza que cualquier bloque que reciba el apoyo de la gran mayoría no será desechado, protegiendo así las recompensas de los líderes honestos y previniendo la reorganización maliciosa y la extracción de MEV entre bloques.
Finalidad de la especulación de una sola ronda: los validadores pueden confirmar bloques después de una comunicación de una sola ronda (una propuesta de un líder y una votación), proporcionando a los clientes una garantía de inclusión inmediata. Esta confirmación especulativa solo se restablecerá en caso de un ataque equivalente del líder (un comportamiento que puede ser probado y castigado), lo que la convierte en una suposición de seguridad en la práctica.
Capacidad de respuesta optimista: el protocolo se ejecuta a la velocidad de la red sin latencia inherente. Los líderes avanzan en el consenso tan pronto como reciben los votos necesarios, y los cambios de vista ocurren tan pronto como se observa un tiempo de espera de quórum, en lugar de esperar un intervalo de tiempo de espera fijo. Este diseño con capacidad de respuesta optimista minimiza los tiempos de espera y maximiza el rendimiento, a la vez que sigue siendo robusto en caso de asincronías y errores.
Comunicación lineal: En la ruta feliz (es decir, el líder es honesto), la complejidad de los mensajes y la verificación tiene una relación lineal con el número de validadores. MonadBFT conserva el eficiente modo de comunicación de HotStuff, utilizando firmas agregadas y un simple líder para la difusión a los validadores, lo que permite que el protocolo se expanda a cientos de validadores sin cuellos de botella en el rendimiento.