Marco Shoal: Mejora de la latencia del consenso Bullshark en Aptos
Aptos Labs recientemente resolvió dos importantes problemas abiertos en DAG BFT, reduciendo significativamente la latencia y eliminando por primera vez la necesidad de tiempo de espera en protocolos asíncronos determinísticos. En general, mejoró la latencia de Bullshark en un 40% en condiciones sin fallos y en un 80% en condiciones de fallo.
Shoal es un marco que mejora el protocolo de consenso basado en Narwhal ( a través del procesamiento en línea y el mecanismo de reputación del líder, como DAG-Rider, Tusk y Bullshark ). El procesamiento en línea reduce la latencia de ordenamiento de DAG al introducir un punto de anclaje en cada ronda, mientras que el mecanismo de reputación del líder mejora aún más el problema de latencia al asegurar que el punto de anclaje esté asociado con el nodo de validación más rápido. Además, la reputación del líder permite a Shoal aprovechar la construcción de DAG asíncrono para eliminar los tiempos de espera en todos los escenarios. Esto permite que Shoal ofrezca una propiedad conocida como respuesta universal, que incluye la respuesta optimista normalmente requerida.
La tecnología de Shoal es relativamente simple, involucrando múltiples instancias de protocolos subyacentes que se ejecutan en orden. Al instanciar con Bullshark, obtenemos un grupo de "tiburones" que están en una carrera de relevos.
Contexto y Motivación
En la búsqueda de un alto rendimiento de la red blockchain, las personas han estado enfocadas en reducir la complejidad de la comunicación. Sin embargo, este enfoque no ha logrado un aumento significativo en el rendimiento. Por ejemplo, el Hotstuff implementado en las primeras versiones de Diem solo alcanzó 3500 TPS, muy por debajo del objetivo de 100k+ 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 informa de un rendimiento de 160,000 TPS.
En artículos anteriores, presentamos Quorum Store. Narwhal implementa la separación de la propagación de datos y el consenso, así como cómo utilizarlo 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 al estilo PBFT, lo que puede reducir la latencia de Hotstuff en un 33%. Sin embargo, los protocolos de consenso basados en líderes no pueden aprovechar plenamente el potencial de rendimiento de Narwhal. A pesar de separar la propagación de datos del consenso, a medida que aumenta el rendimiento, los líderes de Hotstuff/Jolteon siguen estando limitados.
Por lo tanto, decidimos implementar Bullshark sobre Narwhal DAG, que es un protocolo de consenso sin costos de comunicación. Desafortunadamente, en comparación con Jolteon, la estructura DAG que soporta el alto rendimiento de Bullshark conlleva un costo de latencia del 50%.
Este artículo presentará cómo Shoal reduce significativamente la latencia de Bullshark.
Fondo de DAG-BFT
Cada vértice en el DAG de Narwhal está asociado con una ronda. Para entrar en la ronda r, el 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 de las propiedades clave del DAG es que no es ambiguo: 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 llegar a un consenso sobre el orden total de todos los vértices en el DAG sin costo adicional 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 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 habrá un líder previamente determinado, y el pico del líder se llama punto de anclaje.
Ordenación de anclajes: los validadores deciden de manera independiente pero determinista qué anclajes ordenar y cuáles omitir.
Orden histórico causal: los validadores procesan uno a uno la lista de anclajes ordenados y ordenan todos los vértices desordenados anteriores en la historia causal de cada anclaje.
La clave para satisfacer la seguridad es asegurarse de que en el paso (2), todos los nodos de validación honestos creen una lista de anclajes ordenada, de modo que todas las listas compartan el mismo prefijo. En Shoal, hacemos las siguientes observaciones sobre todos los protocolos mencionados anteriormente:
Todos los validadores están de acuerdo con 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, sigue estando lejos de ser óptima.
Pregunta 1: latencia promedio de bloques. En Bullshark, cada ronda par tiene un punto de anclaje, y el vértice de cada ronda impar se interpreta como un voto. En situaciones comunes, se requieren dos rondas de DAG para ordenar los puntos de anclaje; sin embargo, los vértices en la historia causal de los puntos de anclaje requieren más rondas para esperar que los puntos de anclaje sean ordenados. En situaciones comunes, los vértices en rondas impares requieren tres rondas, mientras que los vértices no anclados en rondas pares requieren cuatro rondas.
Pregunta 2: latencia de casos de fallos. El análisis de latencia anterior se aplica a situaciones sin fallos; por otro lado, si un líder de ronda no logra transmitir suficientemente rápido el anclaje, no se puede ordenar el anclaje ( y, por lo tanto, se omite ). Por lo tanto, todos los vértices no ordenados de las rondas anteriores deben esperar a que se ordene el siguiente anclaje. Esto disminuirá 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 pipeline, permitiendo que haya un ancla 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íder de cero 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 paralelo y la reputación del líder se consideran problemas difíciles, por las siguientes razones:
Anteriormente, los intentos de procesamiento en línea intentaron 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 futuros líderes según el rendimiento 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, podrían llevar a un orden completamente diferente, lo que plantea la cuestión central de que seleccionar anclas de manera dinámica y determinista es necesario para resolver el consenso, y los validadores necesitan 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.
) protocolo
A pesar de los desafíos mencionados, la solución se esconde en la simplicidad. En Shoal, dependemos de la capacidad de realizar cálculos locales en DAG y hemos implementado la capacidad de almacenar y reinterpretar la información de rondas anteriores. Con la perspicacia central de que todos los validadores coinciden en el primer punto de anclaje ordenado, Shoal combina secuencialmente múltiples instancias de Bullshark para procesarlas en una tubería, haciendo que ### el primer punto de anclaje ordenado sea el punto de cambio de las instancias, así como ( la historia causal de los puntos de anclaje se utilice para calcular la reputación de los líderes.
) procesamiento en línea
V que asigna rondas a líderes. Shoal ejecuta instancias de Bullshark una tras otra, de modo que para cada instancia, el ancla es determinado previamente por el mapeo F. Cada instancia ordena un ancla, lo que desencadena el cambio a la siguiente instancia.
Inicialmente, 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 acordaron este ancla. Por lo tanto, todos los validadores pueden acordar de manera definitiva 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 a Shoal ordenar un ancla en cada ronda. El punto de anclaje de la primera ronda se ordena según la primera instancia. Luego, Shoal comienza una nueva instancia en la segunda ronda, que tiene su propio punto de anclaje, y ese ancla es ordenada por esa instancia, luego, otra nueva instancia ordena el punto de anclaje en la tercera ronda, y luego el proceso continúa.
reputación del líder
Al saltar puntos de anclaje durante el ordenamiento de Bullshark, la latencia aumenta. En este caso, la técnica de procesamiento en línea no puede ayudar, ya que no se puede iniciar una nueva instancia antes de que se ordene el punto de anclaje de la instancia anterior. Shoal asegura que es poco 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 según el historial de actividad reciente de cada nodo de validación mediante el uso de un mecanismo de reputación. Los validadores que responden y participan en el protocolo recibirán una puntuación alta; de lo contrario, los nodos de validación recibirán una puntuación baja, ya que pueden estar caídos, lentos o actuar maliciosamente.
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 alcanzar un consenso sobre la puntuación, logrando así un consenso en la historia utilizada para derivar las puntuaciones.
En Shoal, el procesamiento en línea y la reputación del líder pueden combinarse de manera natural, ya que ambos utilizan la misma tecnología central, que es reinterpretar el DAG una vez alcanzado el 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 usar la función de selección de puntos de anclaje actualizada F' para ejecutar una nueva instancia de Bullshark a partir de la ronda r+1.
No hay más tiempo de espera
El tiempo de espera juega un papel crucial en todas las implementaciones BFT de consenso determinístico basadas en líderes. Sin embargo, la complejidad que introducen aumenta la cantidad de estados internos que necesitan 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, 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 pagará la penalización completa por la latencia de tiempo de espera al líder fallido. Por lo tanto, la configuración del tiempo de espera no puede ser demasiado conservadora, pero si el tiempo de espera es demasiado corto, el protocolo puede saltarse a buenos líderes. Por ejemplo, hemos observado que, en situaciones 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, el protocolo basado en líderes ### como Hotstuff
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.
9 me gusta
Recompensa
9
6
Republicar
Compartir
Comentar
0/400
SchrodingerProfit
· hace17h
Esta vez Aptos va a To the moon.
Ver originalesResponder0
CodeAuditQueen
· 08-11 05:48
La optimización de algoritmos complejos también presenta riesgos de reentrada de potencia computacional. Espero que no haya un naufragio en la cuneta.
Ver originalesResponder0
metaverse_hermit
· 08-11 05:48
aptos todavía está vivo tql
Ver originalesResponder0
ReverseTradingGuru
· 08-11 05:47
Otra vez ha sido actualizado, alcista.
Ver originalesResponder0
DeadTrades_Walking
· 08-11 05:31
La mejora de la eficiencia está bien, recuerda enviar los resultados.
El marco Shoal mejora la eficiencia de consenso de Aptos: Bullshark reduce la latencia en un 40-80%.
Marco Shoal: Mejora de la latencia del consenso Bullshark en Aptos
Aptos Labs recientemente resolvió dos importantes problemas abiertos en DAG BFT, reduciendo significativamente la latencia y eliminando por primera vez la necesidad de tiempo de espera en protocolos asíncronos determinísticos. En general, mejoró la latencia de Bullshark en un 40% en condiciones sin fallos y en un 80% en condiciones de fallo.
Shoal es un marco que mejora el protocolo de consenso basado en Narwhal ( a través del procesamiento en línea y el mecanismo de reputación del líder, como DAG-Rider, Tusk y Bullshark ). El procesamiento en línea reduce la latencia de ordenamiento de DAG al introducir un punto de anclaje en cada ronda, mientras que el mecanismo de reputación del líder mejora aún más el problema de latencia al asegurar que el punto de anclaje esté asociado con el nodo de validación más rápido. Además, la reputación del líder permite a Shoal aprovechar la construcción de DAG asíncrono para eliminar los tiempos de espera en todos los escenarios. Esto permite que Shoal ofrezca una propiedad conocida como respuesta universal, que incluye la respuesta optimista normalmente requerida.
La tecnología de Shoal es relativamente simple, involucrando múltiples instancias de protocolos subyacentes que se ejecutan en orden. Al instanciar con Bullshark, obtenemos un grupo de "tiburones" que están en una carrera de relevos.
Contexto y Motivación
En la búsqueda de un alto rendimiento de la red blockchain, las personas han estado enfocadas en reducir la complejidad de la comunicación. Sin embargo, este enfoque no ha logrado un aumento significativo en el rendimiento. Por ejemplo, el Hotstuff implementado en las primeras versiones de Diem solo alcanzó 3500 TPS, muy por debajo del objetivo de 100k+ 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 informa de un rendimiento de 160,000 TPS.
En artículos anteriores, presentamos Quorum Store. Narwhal implementa la separación de la propagación de datos y el consenso, así como cómo utilizarlo 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 al estilo PBFT, lo que puede reducir la latencia de Hotstuff en un 33%. Sin embargo, los protocolos de consenso basados en líderes no pueden aprovechar plenamente el potencial de rendimiento de Narwhal. A pesar de separar la propagación de datos del consenso, a medida que aumenta el rendimiento, los líderes de Hotstuff/Jolteon siguen estando limitados.
Por lo tanto, decidimos implementar Bullshark sobre Narwhal DAG, que es un protocolo de consenso sin costos de comunicación. Desafortunadamente, en comparación con Jolteon, la estructura DAG que soporta el alto rendimiento de Bullshark conlleva un costo de latencia del 50%.
Este artículo presentará cómo Shoal reduce significativamente la latencia de Bullshark.
Fondo de DAG-BFT
Cada vértice en el DAG de Narwhal está asociado con una ronda. Para entrar en la ronda r, el 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 de las propiedades clave del DAG es que no es ambiguo: 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 llegar a un consenso sobre el orden total de todos los vértices en el DAG sin costo adicional 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 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 habrá un líder previamente determinado, y el pico del líder se llama punto de anclaje.
Ordenación de anclajes: los validadores deciden de manera independiente pero determinista qué anclajes ordenar y cuáles omitir.
Orden histórico causal: los validadores procesan uno a uno la lista de anclajes ordenados y ordenan todos los vértices desordenados anteriores en la historia causal de cada anclaje.
La clave para satisfacer la seguridad es asegurarse de que en el paso (2), todos los nodos de validación honestos creen una lista de anclajes ordenada, de modo que todas las listas compartan el mismo prefijo. En Shoal, hacemos las siguientes observaciones sobre todos los protocolos mencionados anteriormente:
Todos los validadores están de acuerdo con 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, sigue estando lejos de ser óptima.
Pregunta 1: latencia promedio de bloques. En Bullshark, cada ronda par tiene un punto de anclaje, y el vértice de cada ronda impar se interpreta como un voto. En situaciones comunes, se requieren dos rondas de DAG para ordenar los puntos de anclaje; sin embargo, los vértices en la historia causal de los puntos de anclaje requieren más rondas para esperar que los puntos de anclaje sean ordenados. En situaciones comunes, los vértices en rondas impares requieren tres rondas, mientras que los vértices no anclados en rondas pares requieren cuatro rondas.
Pregunta 2: latencia de casos de fallos. El análisis de latencia anterior se aplica a situaciones sin fallos; por otro lado, si un líder de ronda no logra transmitir suficientemente rápido el anclaje, no se puede ordenar el anclaje ( y, por lo tanto, se omite ). Por lo tanto, todos los vértices no ordenados de las rondas anteriores deben esperar a que se ordene el siguiente anclaje. Esto disminuirá 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 pipeline, permitiendo que haya un ancla 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íder de cero 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 paralelo y la reputación del líder se consideran problemas difíciles, por las siguientes razones:
Anteriormente, los intentos de procesamiento en línea intentaron 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 futuros líderes según el rendimiento 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, podrían llevar a un orden completamente diferente, lo que plantea la cuestión central de que seleccionar anclas de manera dinámica y determinista es necesario para resolver el consenso, y los validadores necesitan 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.
) protocolo
A pesar de los desafíos mencionados, la solución se esconde en la simplicidad. En Shoal, dependemos de la capacidad de realizar cálculos locales en DAG y hemos implementado la capacidad de almacenar y reinterpretar la información de rondas anteriores. Con la perspicacia central de que todos los validadores coinciden en el primer punto de anclaje ordenado, Shoal combina secuencialmente múltiples instancias de Bullshark para procesarlas en una tubería, haciendo que ### el primer punto de anclaje ordenado sea el punto de cambio de las instancias, así como ( la historia causal de los puntos de anclaje se utilice para calcular la reputación de los líderes.
) procesamiento en línea
V que asigna rondas a líderes. Shoal ejecuta instancias de Bullshark una tras otra, de modo que para cada instancia, el ancla es determinado previamente por el mapeo F. Cada instancia ordena un ancla, lo que desencadena el cambio a la siguiente instancia.
Inicialmente, 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 acordaron este ancla. Por lo tanto, todos los validadores pueden acordar de manera definitiva 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 a Shoal ordenar un ancla en cada ronda. El punto de anclaje de la primera ronda se ordena según la primera instancia. Luego, Shoal comienza una nueva instancia en la segunda ronda, que tiene su propio punto de anclaje, y ese ancla es ordenada por esa instancia, luego, otra nueva instancia ordena el punto de anclaje en la tercera ronda, y luego el proceso continúa.
reputación del líder
Al saltar puntos de anclaje durante el ordenamiento de Bullshark, la latencia aumenta. En este caso, la técnica de procesamiento en línea no puede ayudar, ya que no se puede iniciar una nueva instancia antes de que se ordene el punto de anclaje de la instancia anterior. Shoal asegura que es poco 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 según el historial de actividad reciente de cada nodo de validación mediante el uso de un mecanismo de reputación. Los validadores que responden y participan en el protocolo recibirán una puntuación alta; de lo contrario, los nodos de validación recibirán una puntuación baja, ya que pueden estar caídos, lentos o actuar maliciosamente.
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 alcanzar un consenso sobre la puntuación, logrando así un consenso en la historia utilizada para derivar las puntuaciones.
En Shoal, el procesamiento en línea y la reputación del líder pueden combinarse de manera natural, ya que ambos utilizan la misma tecnología central, que es reinterpretar el DAG una vez alcanzado el 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 usar la función de selección de puntos de anclaje actualizada F' para ejecutar una nueva instancia de Bullshark a partir de la ronda r+1.
No hay más tiempo de espera
El tiempo de espera juega un papel crucial en todas las implementaciones BFT de consenso determinístico basadas en líderes. Sin embargo, la complejidad que introducen aumenta la cantidad de estados internos que necesitan 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, 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 pagará la penalización completa por la latencia de tiempo de espera al líder fallido. Por lo tanto, la configuración del tiempo de espera no puede ser demasiado conservadora, pero si el tiempo de espera es demasiado corto, el protocolo puede saltarse a buenos líderes. Por ejemplo, hemos observado que, en situaciones 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, el protocolo basado en líderes ### como Hotstuff