Marco Shoal: Soltar la latencia de Bullshark en Aptos con una solución innovadora
Aptos Labs ha abordado recientemente dos importantes problemas abiertos en DAG BFT, lo que ha reducido significativamente la latencia y ha eliminado por primera vez la necesidad de tiempos de espera en el protocolo de consistencia determinista. En general, en condiciones sin fallos, la latencia de Bullshark se ha mejorado en un 40%, y en caso de fallos, se ha mejorado en un 80%.
Shoal es un marco que mejora el protocolo de consenso basado en Narwhal ( mediante el procesamiento en línea y un mecanismo de reputación de líderes, como DAG-Rider, Tusk, Bullshark ). El procesamiento en línea reduce la latencia de ordenamiento del DAG al introducir un punto de anclaje en cada ronda, mientras que el mecanismo de reputación de líderes mejora aún más el problema de latencia al asegurar que los puntos de anclaje estén asociados con los nodos de validación más rápidos. Además, la reputación de los líderes permite a Shoal aprovechar la construcción de DAG asíncrona para eliminar los mecanismos de tiempo de espera en todos los escenarios. Esto permite que Shoal ofrezca una característica que llamamos "respuesta universal", que incluye las propiedades de respuesta optimista normalmente necesarias.
La tecnología de Shoal es muy simple, implica ejecutar múltiples instancias del protocolo subyacente una por una en orden. Por lo tanto, cuando se instancia Bullshark, el efecto que obtenemos es como un grupo de "tiburones" que están en una carrera de relevos.
Antecedentes y Motivación
En la búsqueda de un alto rendimiento en las redes de blockchain, la gente ha estado enfocándose en Soltar la complejidad de la comunicación. Sin embargo, este enfoque no ha llevado a un aumento significativo en el throughput. Por ejemplo, el Hotstuff implementado en las primeras versiones de Diem solo logró 3500 TPS, muy por debajo de nuestro objetivo de 100,000+ TPS.
El reciente avance se debe a la comprensión de que la propagación de datos es el principal cuello de botella basado en el protocolo de los líderes y puede beneficiarse de la paralelización. El sistema Narwhal separa la propagación de datos de la lógica de consenso central, proponiendo una arquitectura en la que todos los validadores propagan datos simultáneamente, mientras que el componente de consenso solo ordena una pequeña cantidad de metadatos. El documento de Narwhal reporta un rendimiento de 160,000 TPS.
En artículos anteriores, presentamos Quorum Store - nuestra implementación de Narwhal, que separa la propagación de datos del consenso, y cómo lo utilizamos para escalar el protocolo de consenso actual Jolteon. Jolteon es un protocolo basado en líderes que combina la ruta rápida lineal de Tendermint con cambios de vista al estilo PBFT, lo que puede Soltar la latencia de Hotstuff en un 33%. Sin embargo, es evidente que los protocolos de consenso basados en líderes no pueden aprovechar plenamente el potencial de rendimiento de Narwhal. A pesar de que se separa la propagación de datos del consenso, a medida que aumenta el rendimiento, el líder de Hotstuff/Jolteon sigue estando limitado.
Por lo tanto, decidimos desplegar Bullshark sobre Narwhal DAG - un protocolo de consenso sin costo de comunicación. Desafortunadamente, en comparación con Jolteon, la estructura DAG que soporta Bullshark de alto rendimiento conlleva un costo de latencia del 50%.
Este artículo presentará cómo Shoal puede reducir significativamente la latencia de Bullshark.
Fondo DAG-BFT
Cada vértice en el DAG de Narwhal está asociado con una ronda. Para entrar en la ronda r, los validadores deben primero obtener n-f vértices que pertenecen a la ronda r-1. Cada validador puede difundir un vértice por ronda, y cada vértice debe referenciar al menos n-f vértices de la ronda anterior. Debido a la asincronía de la red, diferentes validadores pueden observar diferentes vistas locales del DAG en cualquier momento.
Una propiedad clave del DAG es la no ambigüedad: si dos nodos de validación tienen el mismo vértice v en su vista local del DAG, entonces tienen la misma historia causal de v.
Orden de secuencia
Se puede lograr consenso sobre el orden total de todos los vértices en el DAG sin costos adicionales de comunicación. Para ello, los validadores en DAG-Rider, Tusk y Bullshark interpretan la estructura del DAG como un protocolo de consenso, donde los vértices representan propuestas y las aristas representan votos.
Aunque la lógica de la intersección de grupos en la estructura DAG es diferente, todos los protocolos de consenso basados en Narwhal existentes tienen la siguiente estructura:
Punto de anclaje programado: cada pocas rondas (, como en dos rondas de ) en Bullshark, habrá un líder previamente determinado, y el vértice del líder se llama punto de anclaje.
Puntos de anclaje de ordenación: los validadores deciden de manera independiente pero determinista qué puntos de anclaje ordenar y cuáles omitir.
Historia causal ordenada: los validadores procesan uno a uno la lista de anclajes ordenados, para cada anclaje, clasifican todos los vértices anteriores desordenados en su historia causal mediante ciertas reglas deterministas.
La clave para satisfacer la seguridad es asegurar que en el paso 2, todos los nodos de validación honestos creen una lista de anclajes ordenada, de modo que todos los listados compartan el mismo prefijo. En Shoal, hacemos las siguientes observaciones sobre todos los protocolos mencionados anteriormente:
Todos los validadores acuerdan el primer punto de anclaje ordenado.
Bullshark latencia
La latencia de Bullshark depende del número de rondas entre los puntos de anclaje ordenados en el DAG. Aunque la versión sincronizada más práctica de Bullshark tiene una mejor latencia que la versión asincrónica, todavía está lejos de ser la óptima.
Problema 1: latencia media de bloque. En Bullshark, cada ronda par tiene un ancla, y los vértices de cada ronda impar se interpretan como votos. En situaciones comunes, se requieren dos rondas de DAG para ordenar los anclajes; sin embargo, los vértices en la historia causal de los anclajes requieren más rondas para esperar que se ordenen los anclajes. En situaciones comunes, los vértices de la ronda impar requieren tres rondas, mientras que los vértices no anclados de la ronda par requieren cuatro rondas.
Problema 2: latencia de fallos. El análisis de latencia anterior se aplica a situaciones sin fallos; por otro lado, si el líder de alguna ronda no logra transmitir el punto de anclaje lo suficientemente rápido, no se podrá ordenar el punto de anclaje (, por lo que se omite ), lo que lleva a que todos los vértices no ordenados de las rondas anteriores deban esperar a que se ordene el siguiente punto de anclaje. Esto puede Soltar significativamente el rendimiento de la red de replicación geográfica, especialmente porque Bullshark utiliza un tiempo de espera para esperar al líder.
Marco Shoal
Shoal resolvió estos dos problemas de latencia, mejorando Bullshark( o cualquier otro protocolo BFT basado en Narwhal) a través del procesamiento en línea, permitiendo que haya un ancla en cada ronda y reduciendo la latencia de todos los vértices no ancla en el DAG a tres rondas. Shoal también introdujo un mecanismo de reputación de líder sin costo en el DAG, lo que hace que la selección se incline hacia líderes rápidos.
Desafío
En el contexto del protocolo DAG, el procesamiento en pipeline y la reputación del líder se consideran problemas difíciles, por las siguientes razones:
Los intentos anteriores de procesamiento en línea intentaron modificar la lógica central de Bullshark, pero esto parecía ser esencialmente imposible.
La reputación del líder se introduce en DiemBFT y se formaliza en Carousel, seleccionando dinámicamente a futuros líderes basándose en el rendimiento pasado de los validadores, la idea del punto de anclaje en (Bullshark. Aunque la existencia de desacuerdos sobre la identidad del líder no viola la seguridad de estos protocolos, en Bullshark, puede llevar a ordenamientos completamente diferentes, lo que plantea el núcleo del problema, es decir, que seleccionar dinámicamente y de manera determinista los anclajes de ronda es necesario para resolver el consenso, y los validadores deben llegar a un acuerdo sobre la historia ordenada para elegir futuros puntos de anclaje.
Como evidencia de la dificultad del problema, notamos que la implementación de Bullshark, incluida la que actualmente está en el entorno de producción, no soporta estas características.
![Explicación detallada del marco Shoal: ¿Cómo reducir la latencia de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Protocolo
A pesar de los desafíos mencionados, la solución se ha demostrado que está oculta en la simplicidad.
En Shoal, confiamos en la capacidad de realizar cálculos locales en DAG y hemos logrado la capacidad de almacenar y reinterpretar la información de rondas anteriores. Con la idea central de que todos los validadores acuerden el primer ancla ordenada, Shoal combina secuencialmente múltiples instancias de Bullshark para procesarlas en línea, de modo que ) el primer ancla ordenada sea el punto de cambio de las instancias, así como ( la historia causal del ancla se utiliza para calcular la reputación del líder.
) procesamiento en línea
V que mapea las rondas a los líderes. Shoal ejecuta una instancia de Bullshark tras otra, de modo que para cada instancia, el punto de anclaje está determinado previamente por el mapeo F. Cada instancia ordena un punto de anclaje, lo que desencadena el cambio a la siguiente instancia.
En un principio, Shoal lanzó la primera instancia de Bullshark en la primera ronda del DAG y la ejecutó hasta que se determinó el primer ancla ordenada, como en la ronda r. Todos los validadores estuvieron de acuerdo con este ancla. Por lo tanto, todos los validadores pueden acordar de manera determinista reinterpretar el DAG a partir de la ronda r+1. Shoal solo lanzó una nueva instancia de Bullshark en la ronda r+1.
En el mejor de los casos, esto permite que Shoal ordene un punto de anclaje en cada ronda. El punto de anclaje de la primera ronda es ordenado por la primera instancia. Luego, Shoal comienza una nueva instancia en la segunda ronda, que tiene su propio punto de anclaje, el cual es ordenado por esa instancia, y luego, otra nueva instancia ordena el punto de anclaje en la tercera ronda, y este proceso continúa.
reputación del líder
Durante el salto de puntos de anclaje en la clasificación de Bullshark, la latencia aumentará. En este caso, la técnica de procesamiento en línea no puede ayudar, ya que no se pueden iniciar nuevas instancias antes de que se clasifique el punto de anclaje de la instancia anterior. Shoal asegura que es menos probable que se elijan líderes correspondientes para manejar los puntos de anclaje perdidos en el futuro, asignando un puntaje a cada nodo de validación basado en el historial de actividad reciente de cada nodo de validación mediante un mecanismo de reputación. Los validadores que respondan y participen en el protocolo recibirán puntajes altos; de lo contrario, se asignarán puntajes bajos a los nodos de validación, ya que pueden estar fallando, lentos o actuando de mala fe.
Su concepto es recalcular de manera determinista el mapeo predefinido F desde la ronda hasta el líder cada vez que se actualiza la puntuación, inclinándose hacia los líderes con puntuaciones más altas. Para que los validadores lleguen a un consenso sobre el nuevo mapeo, deben llegar a un consenso sobre la puntuación, logrando así un consenso sobre la historia utilizada para derivar la puntuación.
En Shoal, el procesamiento en línea y la reputación del líder pueden combinarse de forma natural, ya que ambos utilizan la misma tecnología central, es decir, reinterpretar el DAG después de alcanzar un consenso sobre el primer ancla ordenada.
De hecho, la única diferencia es que, después de ordenar los puntos de anclaje en la ronda r, los validadores solo necesitan calcular un nuevo mapeo F' a partir de la ronda r+1, basándose en la historia causal de los puntos de anclaje ordenados en la ronda r. Luego, los nodos de validación comienzan a ejecutar una nueva instancia de Bullshark utilizando la función de selección de puntos de anclaje actualizada F' a partir de la ronda r+1.
Eliminar el tiempo de espera
El tiempo de espera juega un papel crucial en todas las implementaciones BFT de sincronización determinista basadas en líderes. Sin embargo, la complejidad que introducen aumenta la cantidad de estados internos que deben ser gestionados y observados, lo que incrementa la complejidad del proceso de depuración y requiere más técnicas de observabilidad.
El tiempo de espera también aumentará significativamente la latencia.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
10 me gusta
Recompensa
10
4
Compartir
Comentar
0/400
ZKProofEnthusiast
· hace21h
Hmm, los que llevan soal no son todos bastante absurdos.
Ver originalesResponder0
SchrodingerWallet
· hace21h
¿Esta ola 3 va a To the moon?
Ver originalesResponder0
SmartContractPlumber
· hace21h
La mejora de la capa de consenso es la que más fácilmente puede provocar riesgos en cadena. Hablemos de nuevos agujeros después.
Ver originalesResponder0
DecentralizedElder
· hace21h
Está increíble. ¿Puede esta latencia realmente llegar al 10%?
Shoal: El nuevo marco de Aptos reduce significativamente la latencia de Bullshark y elimina la necesidad de tiempo de espera.
Marco Shoal: Soltar la latencia de Bullshark en Aptos con una solución innovadora
Aptos Labs ha abordado recientemente dos importantes problemas abiertos en DAG BFT, lo que ha reducido significativamente la latencia y ha eliminado por primera vez la necesidad de tiempos de espera en el protocolo de consistencia determinista. En general, en condiciones sin fallos, la latencia de Bullshark se ha mejorado en un 40%, y en caso de fallos, se ha mejorado en un 80%.
Shoal es un marco que mejora el protocolo de consenso basado en Narwhal ( mediante el procesamiento en línea y un mecanismo de reputación de líderes, como DAG-Rider, Tusk, Bullshark ). El procesamiento en línea reduce la latencia de ordenamiento del DAG al introducir un punto de anclaje en cada ronda, mientras que el mecanismo de reputación de líderes mejora aún más el problema de latencia al asegurar que los puntos de anclaje estén asociados con los nodos de validación más rápidos. Además, la reputación de los líderes permite a Shoal aprovechar la construcción de DAG asíncrona para eliminar los mecanismos de tiempo de espera en todos los escenarios. Esto permite que Shoal ofrezca una característica que llamamos "respuesta universal", que incluye las propiedades de respuesta optimista normalmente necesarias.
La tecnología de Shoal es muy simple, implica ejecutar múltiples instancias del protocolo subyacente una por una en orden. Por lo tanto, cuando se instancia Bullshark, el efecto que obtenemos es como un grupo de "tiburones" que están en una carrera de relevos.
Antecedentes y Motivación
En la búsqueda de un alto rendimiento en las redes de blockchain, la gente ha estado enfocándose en Soltar la complejidad de la comunicación. Sin embargo, este enfoque no ha llevado a un aumento significativo en el throughput. Por ejemplo, el Hotstuff implementado en las primeras versiones de Diem solo logró 3500 TPS, muy por debajo de nuestro objetivo de 100,000+ TPS.
El reciente avance se debe a la comprensión de que la propagación de datos es el principal cuello de botella basado en el protocolo de los líderes y puede beneficiarse de la paralelización. El sistema Narwhal separa la propagación de datos de la lógica de consenso central, proponiendo una arquitectura en la que todos los validadores propagan datos simultáneamente, mientras que el componente de consenso solo ordena una pequeña cantidad de metadatos. El documento de Narwhal reporta un rendimiento de 160,000 TPS.
En artículos anteriores, presentamos Quorum Store - nuestra implementación de Narwhal, que separa la propagación de datos del consenso, y cómo lo utilizamos para escalar el protocolo de consenso actual Jolteon. Jolteon es un protocolo basado en líderes que combina la ruta rápida lineal de Tendermint con cambios de vista al estilo PBFT, lo que puede Soltar la latencia de Hotstuff en un 33%. Sin embargo, es evidente que los protocolos de consenso basados en líderes no pueden aprovechar plenamente el potencial de rendimiento de Narwhal. A pesar de que se separa la propagación de datos del consenso, a medida que aumenta el rendimiento, el líder de Hotstuff/Jolteon sigue estando limitado.
Por lo tanto, decidimos desplegar Bullshark sobre Narwhal DAG - un protocolo de consenso sin costo de comunicación. Desafortunadamente, en comparación con Jolteon, la estructura DAG que soporta Bullshark de alto rendimiento conlleva un costo de latencia del 50%.
Este artículo presentará cómo Shoal puede reducir significativamente la latencia de Bullshark.
Fondo DAG-BFT
Cada vértice en el DAG de Narwhal está asociado con una ronda. Para entrar en la ronda r, los validadores deben primero obtener n-f vértices que pertenecen a la ronda r-1. Cada validador puede difundir un vértice por ronda, y cada vértice debe referenciar al menos n-f vértices de la ronda anterior. Debido a la asincronía de la red, diferentes validadores pueden observar diferentes vistas locales del DAG en cualquier momento.
Una propiedad clave del DAG es la no ambigüedad: si dos nodos de validación tienen el mismo vértice v en su vista local del DAG, entonces tienen la misma historia causal de v.
Orden de secuencia
Se puede lograr consenso sobre el orden total de todos los vértices en el DAG sin costos adicionales de comunicación. Para ello, los validadores en DAG-Rider, Tusk y Bullshark interpretan la estructura del DAG como un protocolo de consenso, donde los vértices representan propuestas y las aristas representan votos.
Aunque la lógica de la intersección de grupos en la estructura DAG es diferente, todos los protocolos de consenso basados en Narwhal existentes tienen la siguiente estructura:
Punto de anclaje programado: cada pocas rondas (, como en dos rondas de ) en Bullshark, habrá un líder previamente determinado, y el vértice del líder se llama punto de anclaje.
Puntos de anclaje de ordenación: los validadores deciden de manera independiente pero determinista qué puntos de anclaje ordenar y cuáles omitir.
Historia causal ordenada: los validadores procesan uno a uno la lista de anclajes ordenados, para cada anclaje, clasifican todos los vértices anteriores desordenados en su historia causal mediante ciertas reglas deterministas.
La clave para satisfacer la seguridad es asegurar que en el paso 2, todos los nodos de validación honestos creen una lista de anclajes ordenada, de modo que todos los listados compartan el mismo prefijo. En Shoal, hacemos las siguientes observaciones sobre todos los protocolos mencionados anteriormente:
Todos los validadores acuerdan el primer punto de anclaje ordenado.
Bullshark latencia
La latencia de Bullshark depende del número de rondas entre los puntos de anclaje ordenados en el DAG. Aunque la versión sincronizada más práctica de Bullshark tiene una mejor latencia que la versión asincrónica, todavía está lejos de ser la óptima.
Problema 1: latencia media de bloque. En Bullshark, cada ronda par tiene un ancla, y los vértices de cada ronda impar se interpretan como votos. En situaciones comunes, se requieren dos rondas de DAG para ordenar los anclajes; sin embargo, los vértices en la historia causal de los anclajes requieren más rondas para esperar que se ordenen los anclajes. En situaciones comunes, los vértices de la ronda impar requieren tres rondas, mientras que los vértices no anclados de la ronda par requieren cuatro rondas.
Problema 2: latencia de fallos. El análisis de latencia anterior se aplica a situaciones sin fallos; por otro lado, si el líder de alguna ronda no logra transmitir el punto de anclaje lo suficientemente rápido, no se podrá ordenar el punto de anclaje (, por lo que se omite ), lo que lleva a que todos los vértices no ordenados de las rondas anteriores deban esperar a que se ordene el siguiente punto de anclaje. Esto puede Soltar significativamente el rendimiento de la red de replicación geográfica, especialmente porque Bullshark utiliza un tiempo de espera para esperar al líder.
Marco Shoal
Shoal resolvió estos dos problemas de latencia, mejorando Bullshark( o cualquier otro protocolo BFT basado en Narwhal) a través del procesamiento en línea, permitiendo que haya un ancla en cada ronda y reduciendo la latencia de todos los vértices no ancla en el DAG a tres rondas. Shoal también introdujo un mecanismo de reputación de líder sin costo en el DAG, lo que hace que la selección se incline hacia líderes rápidos.
Desafío
En el contexto del protocolo DAG, el procesamiento en pipeline y la reputación del líder se consideran problemas difíciles, por las siguientes razones:
Los intentos anteriores de procesamiento en línea intentaron modificar la lógica central de Bullshark, pero esto parecía ser esencialmente imposible.
La reputación del líder se introduce en DiemBFT y se formaliza en Carousel, seleccionando dinámicamente a futuros líderes basándose en el rendimiento pasado de los validadores, la idea del punto de anclaje en (Bullshark. Aunque la existencia de desacuerdos sobre la identidad del líder no viola la seguridad de estos protocolos, en Bullshark, puede llevar a ordenamientos completamente diferentes, lo que plantea el núcleo del problema, es decir, que seleccionar dinámicamente y de manera determinista los anclajes de ronda es necesario para resolver el consenso, y los validadores deben llegar a un acuerdo sobre la historia ordenada para elegir futuros puntos de anclaje.
Como evidencia de la dificultad del problema, notamos que la implementación de Bullshark, incluida la que actualmente está en el entorno de producción, no soporta estas características.
![Explicación detallada del marco Shoal: ¿Cómo reducir la latencia de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Protocolo
A pesar de los desafíos mencionados, la solución se ha demostrado que está oculta en la simplicidad.
En Shoal, confiamos en la capacidad de realizar cálculos locales en DAG y hemos logrado la capacidad de almacenar y reinterpretar la información de rondas anteriores. Con la idea central de que todos los validadores acuerden el primer ancla ordenada, Shoal combina secuencialmente múltiples instancias de Bullshark para procesarlas en línea, de modo que ) el primer ancla ordenada sea el punto de cambio de las instancias, así como ( la historia causal del ancla se utiliza para calcular la reputación del líder.
) procesamiento en línea
V que mapea las rondas a los líderes. Shoal ejecuta una instancia de Bullshark tras otra, de modo que para cada instancia, el punto de anclaje está determinado previamente por el mapeo F. Cada instancia ordena un punto de anclaje, lo que desencadena el cambio a la siguiente instancia.
En un principio, Shoal lanzó la primera instancia de Bullshark en la primera ronda del DAG y la ejecutó hasta que se determinó el primer ancla ordenada, como en la ronda r. Todos los validadores estuvieron de acuerdo con este ancla. Por lo tanto, todos los validadores pueden acordar de manera determinista reinterpretar el DAG a partir de la ronda r+1. Shoal solo lanzó una nueva instancia de Bullshark en la ronda r+1.
En el mejor de los casos, esto permite que Shoal ordene un punto de anclaje en cada ronda. El punto de anclaje de la primera ronda es ordenado por la primera instancia. Luego, Shoal comienza una nueva instancia en la segunda ronda, que tiene su propio punto de anclaje, el cual es ordenado por esa instancia, y luego, otra nueva instancia ordena el punto de anclaje en la tercera ronda, y este proceso continúa.
reputación del líder
Durante el salto de puntos de anclaje en la clasificación de Bullshark, la latencia aumentará. En este caso, la técnica de procesamiento en línea no puede ayudar, ya que no se pueden iniciar nuevas instancias antes de que se clasifique el punto de anclaje de la instancia anterior. Shoal asegura que es menos probable que se elijan líderes correspondientes para manejar los puntos de anclaje perdidos en el futuro, asignando un puntaje a cada nodo de validación basado en el historial de actividad reciente de cada nodo de validación mediante un mecanismo de reputación. Los validadores que respondan y participen en el protocolo recibirán puntajes altos; de lo contrario, se asignarán puntajes bajos a los nodos de validación, ya que pueden estar fallando, lentos o actuando de mala fe.
Su concepto es recalcular de manera determinista el mapeo predefinido F desde la ronda hasta el líder cada vez que se actualiza la puntuación, inclinándose hacia los líderes con puntuaciones más altas. Para que los validadores lleguen a un consenso sobre el nuevo mapeo, deben llegar a un consenso sobre la puntuación, logrando así un consenso sobre la historia utilizada para derivar la puntuación.
En Shoal, el procesamiento en línea y la reputación del líder pueden combinarse de forma natural, ya que ambos utilizan la misma tecnología central, es decir, reinterpretar el DAG después de alcanzar un consenso sobre el primer ancla ordenada.
De hecho, la única diferencia es que, después de ordenar los puntos de anclaje en la ronda r, los validadores solo necesitan calcular un nuevo mapeo F' a partir de la ronda r+1, basándose en la historia causal de los puntos de anclaje ordenados en la ronda r. Luego, los nodos de validación comienzan a ejecutar una nueva instancia de Bullshark utilizando la función de selección de puntos de anclaje actualizada F' a partir de la ronda r+1.
Eliminar el tiempo de espera
El tiempo de espera juega un papel crucial en todas las implementaciones BFT de sincronización determinista basadas en líderes. Sin embargo, la complejidad que introducen aumenta la cantidad de estados internos que deben ser gestionados y observados, lo que incrementa la complejidad del proceso de depuración y requiere más técnicas de observabilidad.
El tiempo de espera también aumentará significativamente la latencia.