El marco Shoal soltara significativamente la demora de Bullshark en Aptos, mejorando notablemente el rendimiento de la línea de producción y el mecanismo de reputación.
Marco Shoal: Mejora del retraso de Bullshark en Aptos
Aptos Labs ha resuelto recientemente dos importantes problemas abiertos en DAG BFT, reduciendo significativamente la latencia y eliminando por primera vez la necesidad de pausas en un protocolo determinista real. En general, la latencia de Bullshark mejoró un 40% en condiciones sin fallas y un 80% en condiciones de falla.
Shoal es un marco que mejora cualquier protocolo de consenso basado en Narwhal ( a través de pipelines y la reputación de los líderes, como DAG-Rider, Tusk, Bullshark ). La pipeline reduce la latencia de ordenamiento de DAG al introducir un ancla en cada ronda, y la reputación del líder mejora aún más la latencia al garantizar que el ancla esté asociada con los nodos de validación más rápidos. Además, la reputación del líder permite que Shoal aproveche la construcción asíncrona de DAG para eliminar los tiempos de espera en todos los escenarios. Esto permite que Shoal ofrezca lo que llamamos la propiedad de respuesta universal, que contiene la respuesta optimista que generalmente se requiere.
Técnicamente, Shoal ejecuta múltiples instancias de protocolos subyacentes en orden. Así que cuando se instancia Bullshark, obtenemos un grupo de "tiburones" compitiendo en una carrera de relevos.
Motivación
Al buscar un alto rendimiento en las redes de blockchain, la gente ha estado enfocada en reducir la complejidad de la comunicación. Sin embargo, este enfoque no ha logrado un aumento significativo en el rendimiento. Por ejemplo, Hotstuff implementado en versiones tempranas de Diem solo alcanzó 3500 TPS, muy por debajo del objetivo de 100k+ TPS.
Recientemente, la ruptura se originó en el reconocimiento de que la propagación de datos es el principal cuello de botella basado en el protocolo de los líderes, y se puede beneficiar de la paralelización. El sistema Narwhal separa la propagación de datos de la lógica de consenso, proponiendo una arquitectura en la que todos los validadores propagan datos simultáneamente, y el componente de consenso solo ordena una pequeña cantidad de metadatos. El documento de Narwhal reportó un rendimiento de 160,000 TPS.
Anteriormente presentamos Quorum Store, es decir, la implementación de Narwhal, que separa la propagación de datos de la consenso y cómo usarlo 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 y el cambio de vista estilo PBFT, lo que puede reducir la latencia de Hotstuff en un 33%. Sin embargo, los protocolos de consenso basados en líderes claramente no pueden aprovechar plenamente el potencial de rendimiento de Narwhal. A pesar de separar la propagación de datos de la consenso, a medida que aumenta el rendimiento, los líderes de Hotstuff/Jolteon siguen siendo limitados.
Por lo tanto, decidimos implementar Bullshark sobre Narwhal DAG, un protocolo de consenso sin costo de comunicación. Desafortunadamente, en comparación con Jolteon, la estructura DAG que soporta un alto rendimiento de Bullshark conlleva un costo de latencia del 50%.
Este artículo presenta cómo Shoal reduce significativamente la latencia de Bullshark.
Fondo de DAG-BFT
Cada vértice en el DAG de Narwhal está asociado a un número de ronda. Para entrar en la ronda r, un validador debe 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 de DAG es que no es difusa: si dos nodos de validación tienen el mismo vértice v en su vista local de DAG, entonces tienen exactamente la misma historia causal de v.
Prefacio
Se puede alcanzar un consenso sobre el orden total de todos los vértices en el DAG sin gastos de comunicación adicionales. 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 los bordes representan votos.
Aunque la lógica de 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 reservado: cada pocas rondas (, como en las dos rondas de Bullshark ), habrá un líder predefinido, 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 cuáles puntos de anclaje ordenar y cuáles omitir;
Historia causal ordenada: los validadores procesan uno a uno la lista de puntos ancla ordenados, y para cada punto ancla, ordenan todos los vértices anteriores desordenados en su historia causal mediante reglas deterministas.
La clave para satisfacer la seguridad es asegurarse de que en el paso (2), todas las listas de anclaje ordenadas creadas por los nodos de verificación honestos 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 retraso
La latencia de Bullshark depende del número de rondas entre los puntos de anclaje ordenados en el DAG. Aunque la versión de sincronización más práctica de Bullshark tiene una mejor latencia que la versión asíncrona, aún está lejos de ser óptima.
Pregunta 1: Retraso promedio 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 el ancla; sin embargo, los vértices en la historia causal del ancla requieren más rondas para que el ancla sea ordenado. En situaciones comunes, los vértices en la ronda impar necesitan tres rondas, mientras que los vértices no ancla en la ronda par necesitan cuatro rondas.
Pregunta 2: Retraso en casos de fallos. El análisis de retraso mencionado es aplicable a situaciones sin fallos; por otro lado, si el líder de una ronda no logra transmitir lo suficientemente rápido el ancla, no se puede ordenar el ancla (, por lo que se omite ). Por lo tanto, todos los vértices no ordenados en las primeras rondas deben esperar a que se ordene el siguiente ancla. Esto puede reducir significativamente el rendimiento de la red de replicación geográfica, especialmente porque Bullshark utiliza tiempos de espera para el líder.
Marco de Shoal
Shoal resolvió estos dos problemas de latencia al mejorar Bullshark( o cualquier otro protocolo BFT basado en Narwhal) mediante el uso de tuberías, permitiendo que haya un punto de anclaje en cada ronda y reduciendo la latencia de todos los vértices no anclados en el DAG a tres rondas. Shoal también introdujo un mecanismo de reputación de líderes sin costo en el DAG, lo que hace que la selección favorezca a los líderes rápidos.
Desafío
En el contexto del protocolo DAG, la canalización y la reputación del líder se consideran problemas difíciles, por las siguientes razones:
Anteriormente, la línea de producción intentó modificar la lógica central de Bullshark, pero esto parece ser esencialmente imposible.
La reputación del líder se introduce en DiemBFT y se formaliza en Carousel, seleccionando dinámicamente a los futuros líderes según el desempeño pasado de los validadores en la idea del ancla en Bullshark ( ). Aunque las discrepancias en la identidad del líder no violan la seguridad de estos protocolos, en Bullshark, pueden llevar a un orden completamente diferente, lo que plantea el núcleo del problema: seleccionar anclas de manera dinámica y determinista es necesario para resolver el consenso, y los validadores deben llegar a un acuerdo sobre la historia ordenada para elegir las futuras anclas.
Como evidencia de la dificultad del problema, notamos que la implementación de Bullshark, incluida la implementación actual en el entorno de producción, no admite estas características.
Acuerdo
A pesar de los desafíos mencionados, la solución se encuentra en la simplicidad.
En Shoal, dependemos de la capacidad de realizar cálculos locales sobre el DAG y hemos logrado la capacidad de guardar y reinterpretar la información de las rondas anteriores. Con la percepción central de que todos los validadores están de acuerdo en el primer punto de anclaje ordenado, Shoal combina en secuencia múltiples instancias de Bullshark para procesarlas en paralelo, haciendo que ( el primer punto de anclaje ordenado sea el punto de cambio de las instancias, así como ) la historia causal del punto de anclaje se utilice para calcular la reputación del líder.
Línea de producción
V que asigna rondas a líderes. Shoal ejecuta instancias de Bullshark una tras otra, de modo que para cada instancia, el ancla está predefinido por el mapeo F. Cada instancia ordena un ancla, lo que desencadena el cambio a la siguiente instancia.
Al 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 acuerdan este ancla. Por lo tanto, todos los validadores pueden acordar de manera confiable reinterpretar el DAG a partir de la ronda r+1. Shoal simplemente lanzó una nueva instancia de Bullshark en la ronda r+1.
En el mejor de los casos, esto permite que Shoal ordene un ancla en cada ronda. El ancla de la primera ronda se ordena según la primera instancia. Luego, Shoal inicia una nueva instancia en la segunda ronda, que tiene su propio ancla, la cual es ordenada por esa instancia, y luego, otra nueva instancia ordena el ancla en la tercera ronda, y así continúa el proceso.
Reputación del líder
Durante el periodo de clasificación de Bullshark, al omitir un ancla, la latencia aumentará. En este caso, la tecnología de pipeline no puede ayudar, ya que no se puede iniciar una nueva instancia antes de que se clasifique el ancla de la instancia anterior. Shoal asegura que sea menos probable elegir líderes correspondientes para manejar anclas perdidas en el futuro, asignando una puntuación a cada nodo de validación según el historial de actividad reciente de cada nodo de validación mediante un mecanismo de reputación. Los validadores que responden y participan en el protocolo obtendrán una alta puntuación; de lo contrario, se asignará una baja puntuación a los nodos de validación, ya que pueden fallar, ser lentos o comportarse mal.
Su concepto es recalcular de manera determinista el mapeo predefinido F desde la ronda hasta el líder cada vez que se actualizan los puntajes, favoreciendo a los líderes con puntajes más altos. Para que los validadores alcancen consenso sobre el nuevo mapeo, deben llegar a un consenso sobre los puntajes, logrando así consenso sobre la historia utilizada para derivar los puntajes.
En Shoal, la línea de producción y la reputación del liderazgo pueden combinarse de manera natural, ya que ambas utilizan la misma tecnología central, que consiste en reinterpretar el DAG después de alcanzar un consenso sobre el primer punto de anclaje ordenado.
De hecho, la única diferencia es que, después de ordenar los anclajes 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 anclajes ordenados en la ronda r. Luego, los nodos de validación comienzan a ejecutar una nueva instancia de Bullshark a partir de la ronda r+1 utilizando la función de selección de anclajes actualizada F'.
No hay más tiempo de espera
El tiempo de espera juega un papel crucial en todas las implementaciones BFT determinísticas 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 puede aumentar significativamente la latencia, ya que es muy importante configurarlos adecuadamente y a menudo requieren ajustes dinámicos, ya que depende en gran medida del entorno ( red ). Antes de pasar al siguiente líder, el protocolo paga una penalización completa por la latencia de tiempo de espera para los líderes con fallos. Por lo tanto, la configuración de tiempo de espera no puede ser demasiado conservadora, pero si el tiempo de espera es demasiado corto, el protocolo puede omitir a buenos líderes. Por ejemplo, observamos que, en condiciones de alta carga, los líderes en Jolteon/Hotstuff están sobrecargados y el tiempo de espera ya ha expirado antes de que puedan impulsar el progreso.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
19 me gusta
Recompensa
19
4
Compartir
Comentar
0/400
DeFiChef
· 07-03 15:05
¡Este aumento del 40% en el rendimiento es delicioso!
Ver originalesResponder0
TokenEconomist
· 07-02 09:36
en realidad, la arquitectura de shoal es una obra maestra de la teoría de juegos. piénsalo como un equilibrio de nash donde los validadores optimizan para la reputación = f(velocidad, fiabilidad)...
Ver originalesResponder0
WhaleSurfer
· 07-02 09:33
alcista alcista突破上限啦
Ver originalesResponder0
TokenSleuth
· 07-02 09:24
Aptos esta optimizando alcista, la latencia ha bajado tanto.
El marco Shoal soltara significativamente la demora de Bullshark en Aptos, mejorando notablemente el rendimiento de la línea de producción y el mecanismo de reputación.
Marco Shoal: Mejora del retraso de Bullshark en Aptos
Aptos Labs ha resuelto recientemente dos importantes problemas abiertos en DAG BFT, reduciendo significativamente la latencia y eliminando por primera vez la necesidad de pausas en un protocolo determinista real. En general, la latencia de Bullshark mejoró un 40% en condiciones sin fallas y un 80% en condiciones de falla.
Shoal es un marco que mejora cualquier protocolo de consenso basado en Narwhal ( a través de pipelines y la reputación de los líderes, como DAG-Rider, Tusk, Bullshark ). La pipeline reduce la latencia de ordenamiento de DAG al introducir un ancla en cada ronda, y la reputación del líder mejora aún más la latencia al garantizar que el ancla esté asociada con los nodos de validación más rápidos. Además, la reputación del líder permite que Shoal aproveche la construcción asíncrona de DAG para eliminar los tiempos de espera en todos los escenarios. Esto permite que Shoal ofrezca lo que llamamos la propiedad de respuesta universal, que contiene la respuesta optimista que generalmente se requiere.
Técnicamente, Shoal ejecuta múltiples instancias de protocolos subyacentes en orden. Así que cuando se instancia Bullshark, obtenemos un grupo de "tiburones" compitiendo en una carrera de relevos.
Motivación
Al buscar un alto rendimiento en las redes de blockchain, la gente ha estado enfocada en reducir la complejidad de la comunicación. Sin embargo, este enfoque no ha logrado un aumento significativo en el rendimiento. Por ejemplo, Hotstuff implementado en versiones tempranas de Diem solo alcanzó 3500 TPS, muy por debajo del objetivo de 100k+ TPS.
Recientemente, la ruptura se originó en el reconocimiento de que la propagación de datos es el principal cuello de botella basado en el protocolo de los líderes, y se puede beneficiar de la paralelización. El sistema Narwhal separa la propagación de datos de la lógica de consenso, proponiendo una arquitectura en la que todos los validadores propagan datos simultáneamente, y el componente de consenso solo ordena una pequeña cantidad de metadatos. El documento de Narwhal reportó un rendimiento de 160,000 TPS.
Anteriormente presentamos Quorum Store, es decir, la implementación de Narwhal, que separa la propagación de datos de la consenso y cómo usarlo 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 y el cambio de vista estilo PBFT, lo que puede reducir la latencia de Hotstuff en un 33%. Sin embargo, los protocolos de consenso basados en líderes claramente no pueden aprovechar plenamente el potencial de rendimiento de Narwhal. A pesar de separar la propagación de datos de la consenso, a medida que aumenta el rendimiento, los líderes de Hotstuff/Jolteon siguen siendo limitados.
Por lo tanto, decidimos implementar Bullshark sobre Narwhal DAG, un protocolo de consenso sin costo de comunicación. Desafortunadamente, en comparación con Jolteon, la estructura DAG que soporta un alto rendimiento de Bullshark conlleva un costo de latencia del 50%.
Este artículo presenta cómo Shoal reduce significativamente la latencia de Bullshark.
Fondo de DAG-BFT
Cada vértice en el DAG de Narwhal está asociado a un número de ronda. Para entrar en la ronda r, un validador debe 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 de DAG es que no es difusa: si dos nodos de validación tienen el mismo vértice v en su vista local de DAG, entonces tienen exactamente la misma historia causal de v.
Prefacio
Se puede alcanzar un consenso sobre el orden total de todos los vértices en el DAG sin gastos de comunicación adicionales. 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 los bordes representan votos.
Aunque la lógica de 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 reservado: cada pocas rondas (, como en las dos rondas de Bullshark ), habrá un líder predefinido, 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 cuáles puntos de anclaje ordenar y cuáles omitir;
Historia causal ordenada: los validadores procesan uno a uno la lista de puntos ancla ordenados, y para cada punto ancla, ordenan todos los vértices anteriores desordenados en su historia causal mediante reglas deterministas.
La clave para satisfacer la seguridad es asegurarse de que en el paso (2), todas las listas de anclaje ordenadas creadas por los nodos de verificación honestos 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 retraso
La latencia de Bullshark depende del número de rondas entre los puntos de anclaje ordenados en el DAG. Aunque la versión de sincronización más práctica de Bullshark tiene una mejor latencia que la versión asíncrona, aún está lejos de ser óptima.
Pregunta 1: Retraso promedio 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 el ancla; sin embargo, los vértices en la historia causal del ancla requieren más rondas para que el ancla sea ordenado. En situaciones comunes, los vértices en la ronda impar necesitan tres rondas, mientras que los vértices no ancla en la ronda par necesitan cuatro rondas.
Pregunta 2: Retraso en casos de fallos. El análisis de retraso mencionado es aplicable a situaciones sin fallos; por otro lado, si el líder de una ronda no logra transmitir lo suficientemente rápido el ancla, no se puede ordenar el ancla (, por lo que se omite ). Por lo tanto, todos los vértices no ordenados en las primeras rondas deben esperar a que se ordene el siguiente ancla. Esto puede reducir significativamente el rendimiento de la red de replicación geográfica, especialmente porque Bullshark utiliza tiempos de espera para el líder.
Marco de Shoal
Shoal resolvió estos dos problemas de latencia al mejorar Bullshark( o cualquier otro protocolo BFT basado en Narwhal) mediante el uso de tuberías, permitiendo que haya un punto de anclaje en cada ronda y reduciendo la latencia de todos los vértices no anclados en el DAG a tres rondas. Shoal también introdujo un mecanismo de reputación de líderes sin costo en el DAG, lo que hace que la selección favorezca a los líderes rápidos.
Desafío
En el contexto del protocolo DAG, la canalización y la reputación del líder se consideran problemas difíciles, por las siguientes razones:
Anteriormente, la línea de producción intentó modificar la lógica central de Bullshark, pero esto parece ser esencialmente imposible.
La reputación del líder se introduce en DiemBFT y se formaliza en Carousel, seleccionando dinámicamente a los futuros líderes según el desempeño pasado de los validadores en la idea del ancla en Bullshark ( ). Aunque las discrepancias en la identidad del líder no violan la seguridad de estos protocolos, en Bullshark, pueden llevar a un orden completamente diferente, lo que plantea el núcleo del problema: seleccionar anclas de manera dinámica y determinista es necesario para resolver el consenso, y los validadores deben llegar a un acuerdo sobre la historia ordenada para elegir las futuras anclas.
Como evidencia de la dificultad del problema, notamos que la implementación de Bullshark, incluida la implementación actual en el entorno de producción, no admite estas características.
Acuerdo
A pesar de los desafíos mencionados, la solución se encuentra en la simplicidad.
En Shoal, dependemos de la capacidad de realizar cálculos locales sobre el DAG y hemos logrado la capacidad de guardar y reinterpretar la información de las rondas anteriores. Con la percepción central de que todos los validadores están de acuerdo en el primer punto de anclaje ordenado, Shoal combina en secuencia múltiples instancias de Bullshark para procesarlas en paralelo, haciendo que ( el primer punto de anclaje ordenado sea el punto de cambio de las instancias, así como ) la historia causal del punto de anclaje se utilice para calcular la reputación del líder.
Línea de producción
V que asigna rondas a líderes. Shoal ejecuta instancias de Bullshark una tras otra, de modo que para cada instancia, el ancla está predefinido por el mapeo F. Cada instancia ordena un ancla, lo que desencadena el cambio a la siguiente instancia.
Al 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 acuerdan este ancla. Por lo tanto, todos los validadores pueden acordar de manera confiable reinterpretar el DAG a partir de la ronda r+1. Shoal simplemente lanzó una nueva instancia de Bullshark en la ronda r+1.
En el mejor de los casos, esto permite que Shoal ordene un ancla en cada ronda. El ancla de la primera ronda se ordena según la primera instancia. Luego, Shoal inicia una nueva instancia en la segunda ronda, que tiene su propio ancla, la cual es ordenada por esa instancia, y luego, otra nueva instancia ordena el ancla en la tercera ronda, y así continúa el proceso.
Reputación del líder
Durante el periodo de clasificación de Bullshark, al omitir un ancla, la latencia aumentará. En este caso, la tecnología de pipeline no puede ayudar, ya que no se puede iniciar una nueva instancia antes de que se clasifique el ancla de la instancia anterior. Shoal asegura que sea menos probable elegir líderes correspondientes para manejar anclas perdidas en el futuro, asignando una puntuación a cada nodo de validación según el historial de actividad reciente de cada nodo de validación mediante un mecanismo de reputación. Los validadores que responden y participan en el protocolo obtendrán una alta puntuación; de lo contrario, se asignará una baja puntuación a los nodos de validación, ya que pueden fallar, ser lentos o comportarse mal.
Su concepto es recalcular de manera determinista el mapeo predefinido F desde la ronda hasta el líder cada vez que se actualizan los puntajes, favoreciendo a los líderes con puntajes más altos. Para que los validadores alcancen consenso sobre el nuevo mapeo, deben llegar a un consenso sobre los puntajes, logrando así consenso sobre la historia utilizada para derivar los puntajes.
En Shoal, la línea de producción y la reputación del liderazgo pueden combinarse de manera natural, ya que ambas utilizan la misma tecnología central, que consiste en reinterpretar el DAG después de alcanzar un consenso sobre el primer punto de anclaje ordenado.
De hecho, la única diferencia es que, después de ordenar los anclajes 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 anclajes ordenados en la ronda r. Luego, los nodos de validación comienzan a ejecutar una nueva instancia de Bullshark a partir de la ronda r+1 utilizando la función de selección de anclajes actualizada F'.
No hay más tiempo de espera
El tiempo de espera juega un papel crucial en todas las implementaciones BFT determinísticas 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 puede aumentar significativamente la latencia, ya que es muy importante configurarlos adecuadamente y a menudo requieren ajustes dinámicos, ya que depende en gran medida del entorno ( red ). Antes de pasar al siguiente líder, el protocolo paga una penalización completa por la latencia de tiempo de espera para los líderes con fallos. Por lo tanto, la configuración de tiempo de espera no puede ser demasiado conservadora, pero si el tiempo de espera es demasiado corto, el protocolo puede omitir a buenos líderes. Por ejemplo, observamos que, en condiciones de alta carga, los líderes en Jolteon/Hotstuff están sobrecargados y el tiempo de espera ya ha expirado antes de que puedan impulsar el progreso.
Desafortunadamente, basado en el liderazgo